Re: Lexical implementation work

Dan Sugalski wrote: > Nope, not stone tablet at all. More a sketch than anything else, > since I'm not sure yet of all the things Larry's got in store. Ok. I've made some more progress. There's a crude picture of some of the internals at The lexical stuff

Re: memory assumptions

On Tuesday 13 November 2001 06:37 pm, James Mastros wrote: > On Tue, Nov 13, 2001 at 06:14:30PM -0500, Michael L Maraist wrote: > > Extending mem-mngr data-structures (like the linked-list) to the > > definition of a PMC is what I'm worried about; not exposing a function to > > say GC-me-more-ofte

Re: [PATCHES] ord(i,s|sc(,i|ic)?) operator committed, fixed bug in concat()

In message <[EMAIL PROTECTED]> Jeff <[EMAIL PROTECTED]> wrote: > string.c - Added string_ord() and a _string_index() helper function to > help making accommodating different encodings easier. Patched concat() > to deal with null strings. I have just committed an amendment to this to ma

Re: [PATCHES] concat, read, substr, added 'ord' operator, and a SURPRISE

In message <[EMAIL PROTECTED]> Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 03:35 AM 11/11/2001 -0500, James Mastros wrote: > > >No, it isn't. I'm not sure s->strlen is always gaurnteed to be correct; > >string_length(s) is. (I found a case where it was wrong when coding my > >version

Re: memory assumptions

On Tue, Nov 13, 2001 at 06:14:30PM -0500, Michael L Maraist wrote: > Extending mem-mngr data-structures (like the linked-list) to the > definition of a PMC is what I'm worried about; not exposing a function to > say GC-me-more-often. (I appologize for the LISP mneumonic :) Hm. I think that the pr

Re: memory assumptions

On Tuesday 13 November 2001 03:57 pm, James Mastros wrote: > > Unfortunately, this would require hooks into the mem-mngr module, which > > violates it's black-box nature. Not to mention the points you make. > > I don't really see this as ownerous fiddiling with the memory manager; we > want to ha

Re: memory assumptions

On Tuesday 13 November 2001 01:20 pm, Jason Gloudon wrote: > On Mon, Nov 12, 2001 at 11:59:08PM -0500, Michael L Maraist wrote: > > 2) > > Can we assume that a "buffer object" is ONLY accessible by a single > > reverse-path-to-PMC? PMC's or array-buffers can point to other PMC's, so > > it's poss

Re: CVS errors?

At 05:32 PM 11/13/2001 -0500, James Mastros wrote: >Hey all. This probably isn't the right place for this, but: >cvs server: Updating . >cvs server: failed to create lock directory for /home/perlcvs' >(/home/perlcvs/#cvs.lock): Permission denied >cvs server: failed to obtain dir lock in repositor

CVS errors?

Hey all. This probably isn't the right place for this, but: cvs server: Updating . cvs server: failed to create lock directory for /home/perlcvs' (/home/perlcvs/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository /home/perlcvs' cvs [server aborted]: read lock failed

Re: memory assumptions

On Tue, Nov 13, 2001 at 01:51:26PM -0500, Michael L Maraist wrote: > The various texts I'm reading suggest that memory management should be a > black-box module. Naturaly. All texts will suggest that everything should be a black-box module, it's where engineering has been going for the past N^

Re: memory assumptions

On Tuesday 13 November 2001 12:05 pm, Ken Fox wrote: > > Are _all_ handles (PMC's, Strings, or whatever) that serve as > > root-set elements dynamically allocated? > > Nope. Part of the root set includes auto C PMC handles used by > extensions. You also have to think about hardware registers too >

Re: memory assumptions

On Mon, Nov 12, 2001 at 11:59:08PM -0500, Michael L Maraist wrote: > 2) > Can we assume that a "buffer object" is ONLY accessible by a single > reverse-path-to-PMC? PMC's or array-buffers can point to other PMC's, so > it's possible to have multiple paths from the root to an object, but I'm >

Re: memory assumptions

Michael L Maraist wrote: > Are we allowing _any_ dynamic memory to be non-GC-managed? Parrot must allow third party libraries to use the standard system malloc/free. Playing linker games to hide malloc/free gets *really* ugly. > Can we assume that a "buffer object" is ONLY accessible by a single

Re: [PATCHES] ord(i,s|sc(,i|ic)?) operator committed, fixed bug in concat()

Yep, you're right. Apparently my checkin also added two tests for concat() to t/op/string.t that the current parrot was not ready to deal with. In any case, it's all better now. Richard Soderberg wrote: > Did you forget the string.c checkin? Parrot cvs failing, don't see string_ord >anywhere,

Re: polymorphic inline caches

Dan Sugalski <[EMAIL PROTECTED]> writes: > At 11:39 AM 11/12/2001 -0500, Ken Fox wrote: >>Simon Cozens wrote: >> > You save one level of indirection, at a large complexity >> > cost. >> >>A lot less complexity than a JIT though. 100% portable >>code too. > > It's got the same sort of issue that

RE: [PATCHES] ord(i,s|sc(,i|ic)?) operator committed, fixed bug in concat()

Did you forget the string.c checkin? Parrot cvs failing, don't see string_ord anywhere, and cvs logs don't show a string.c update. R. > -Original Message- > From: Jeff [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 12, 2001 11:46 PM > To: [EMAIL PROTECTED] > Subject: [PATCHES] ord