Re: Rules for memory allocation and pointing

2001-11-02 Thread Michael L Maraist
On Friday 02 November 2001 05:27 pm, Dan Sugalski wrote: > 1) The pointer in a PMC structure may point to: > >*) Another PMC >*) A buffer object >*) Something non-tracked > > Additionally the buffer object may contain array of buffer object pointers, > or an array of PMC pointers. Flag

Re: chr & ord opcodes, v0.5

2001-11-02 Thread James Mastros
On Fri, Nov 02, 2001 at 11:26:37PM -0300, Daniel Grunblatt wrote: > You forgot the attachment. Whoops. -=- James Mastros ? chr5.diff ? chrord4.diff ? chrord5.diff ? core.ops.mine ? mops.c ? ops.chrord.diff ? ord3.diff ? examples/assembly/chr_table.pasm ? examples/assembly/ord.pasm ? langu

Re: chr & ord opcodes, v0.5

2001-11-02 Thread Daniel Grunblatt
You forgot the attachment. On Fri, 2 Nov 2001, James Mastros wrote: > Hey all. Attached is the latest edition of the chr and ord opcodes patch, > updated and enhanced for the New Way of Strings. > > Let me know of any changes I need to make. > > -=- James Mastros >

BIGNUM memory and questions (was Re: Rules for memory allocation and pointing)

2001-11-02 Thread Uri Guttman
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> 2) A buffer object has the structure: DS> struct { DS>void *memory; DS>INTVAL size; DS> } some questions. i am declaring a BIGNUM struct which points to an array of BIGNUM_WORDs (longest native integer

chr & ord opcodes, v0.5

2001-11-02 Thread James Mastros
Hey all. Attached is the latest edition of the chr and ord opcodes patch, updated and enhanced for the New Way of Strings. Let me know of any changes I need to make. -=- James Mastros

Rules for memory allocation and pointing

2001-11-02 Thread Dan Sugalski
Okay, here's a quick draft of the rules I'm thinking of to govern memory allocation and tracking so the interpreter can GC and dead-object detect properly. 1) The pointer in a PMC structure may point to: *) Another PMC *) A buffer object *) Something non-tracked Additionally the buff

RE: Building on Win32

2001-11-02 Thread Hong Zhang
> Also, note that Hong Zhang ([EMAIL PROTECTED]) has pointed out a > simplification (1 API call rather than 2)... FYI. The GetSystemTimeAsFileTime() takes less than 10 assembly instructions. It just reads the kernel time variable that maps into every address space. > and given I think I've foun

RE: Beginning of dynamic loading -- platform assistance needed

2001-11-02 Thread Hong Zhang
> > Okay, here's the updated scheme. > > > > *) There is a platform/generic.c and platform/generic.h. (OK, it'll > > probably really be unixy, but these days it's close enough) If there is no > > pltform-specific file, this is the one that gets copied to platform.c and > > platform.h > > > >

RE: Building on Win32

2001-11-02 Thread Richard J Cox
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Andy Dougherty) wrote: > Could someone on Win32 also compare this to the perl5 version in > ext/Time/HiRes.xs? There's no reason to have the perl community running > two different versions. In particular, the perl5 version Sorry... don't have

Re: Beginning of dynamic loading -- platform assistance needed

2001-11-02 Thread Andy Dougherty
On Fri, 2 Nov 2001, Dan Sugalski wrote: > At 11:40 AM 11/2/2001 -0500, Andy Dougherty wrote: > >What specifically do you expect might end up in linux.[hc] as opposed to, > >say, solaris.[hc]? How many different *bsd.[ch] files do you propose? How > >many different System V.4-derived platform fil

Re: Beginning of dynamic loading -- platform assistance needed

2001-11-02 Thread Andy Dougherty
On Fri, 2 Nov 2001, Jason Diamond wrote: > Then we could have a "driver" for each platform that consisted of nothing > but #include's of other .c files. Making a directory for each platform might > be appropriate if we do this. I bet that most of the posix "platform" source > files would be #incl

RE: Building on Win32

2001-11-02 Thread Andy Dougherty
On Fri, 2 Nov 2001, Dan Sugalski wrote: > At 12:01 PM 11/2/2001 -0500, Andy Dougherty wrote: > >There's no reason to have the perl community running > >two different versions. > > There is one reason. > > Licensing. Ouch. Well, at least for Configure stuff, there is the following from Configu

RE: Building on Win32

2001-11-02 Thread Dan Sugalski
At 09:54 AM 11/2/2001 -0800, Brent Dax wrote: >Larry, you're the copyright holder on Perl 5. Can you declare that Perl >6 can copy whatever is needed out of Perl 5 without worrying about >licensing, or something to that effect? I'm not sure he's in a position to do that even with the core code,

RE: Building on Win32

2001-11-02 Thread Brent Dax
Dan Sugalski: # At 12:01 PM 11/2/2001 -0500, Andy Dougherty wrote: # >There's no reason to have the perl community running # >two different versions. # # There is one reason. # # Licensing. # # We don't have a solid license for perl 6 yet, but odds are it'll be # different from perl 5's license, a

Re: Beginning of dynamic loading -- platform assistance needed

2001-11-02 Thread Dan Sugalski
At 11:40 AM 11/2/2001 -0500, Andy Dougherty wrote: >What specifically do you expect might end up in linux.[hc] as opposed to, >say, solaris.[hc]? How many different *bsd.[ch] files do you propose? How >many different System V.4-derived platform files do you propose? That's a very good question.

Re: Building on Win32

2001-11-02 Thread Jason Diamond
> Could someone on Win32 also compare this to the perl5 version in > ext/Time/HiRes.xs? There's no reason to have the perl community running > two different versions. In particular, the perl5 version Where did you get that source? I just downloaded the sources from both ActiveState and CPAN and

RE: Building on Win32

2001-11-02 Thread Dan Sugalski
At 12:01 PM 11/2/2001 -0500, Andy Dougherty wrote: >There's no reason to have the perl community running >two different versions. There is one reason. Licensing. We don't have a solid license for perl 6 yet, but odds are it'll be different from perl 5's license, and until we know they're the s

Re: Beginning of dynamic loading -- platform assistance needed

2001-11-02 Thread Jason Diamond
> What specifically do you expect might end up in linux.[hc] as opposed to, > say, solaris.[hc]? How many different *bsd.[ch] files do you propose? How > many different System V.4-derived platform files do you propose? We could always rename linux.[hc] to posix.[hc] or something similar. Is dlop

RE: Building on Win32

2001-11-02 Thread Andy Dougherty
> > For speed reason, you can use GetSystemTimeAsFileTime(), which is > > very efficient. The Win32 is little-endian only operating system. > > You can use the following code. > > > > void gettimeofday(struct timeval* pTv, void *pDummy); > > { > > __int64 l; > > GetSystemTimeAsFileTime((L

Re: Beginning of dynamic loading -- platform assistance needed

2001-11-02 Thread Andy Dougherty
> I just checked in changes to platforms/linux.[hc] that add wrappers > around the dynamic loading functions that work here. Umm, this worries me a little as being too platform-specific. (Not to pick on anyone in particular, this message just finally nudged me enough to try to write down some th

Beginning of dynamic loading -- platform assistance needed

2001-11-02 Thread Gregor N. Purdy
All -- I just checked in changes to platforms/linux.[hc] that add wrappers around the dynamic loading functions that work here. Could we get versions for other platforms in their respective platforms/*.[hc] files? We need to look at the different preferred methods to settle on a unified interface

RE: Building on Win32

2001-11-02 Thread Gregor N. Purdy
All -- > For speed reason, you can use GetSystemTimeAsFileTime(), which is > very efficient. The Win32 is little-endian only operating system. > You can use the following code. > > void gettimeofday(struct timeval* pTv, void *pDummy); > { > __int64 l; > GetSystemTimeAsFileTime((LPFILETIM

Re: Patch for building on Win32.

2001-11-02 Thread Gregor N. Purdy
Jason -- Thanks. Applied. On Fri, 2001-11-02 at 02:38, Jason Diamond wrote: > Here's a patch to get the latest CVS sources to get everything to build on > my Windows box. > > Here's what I did: > > * Modified Configure.pl, mswin32.pl, and Makefile.in so that the platform > specific files in th

More Regexp Goodness

2001-11-02 Thread Brent Dax
I've been working independently on my own regexp setup. The "patch" is attached, except my diff program ran out of memory when I tried to do a diff of core.ops. Ouch. So the stuff for core.ops is in something that looks like a patch, but really isn't. You'll have to set that up manually. The

Re: Experimental regex support

2001-11-02 Thread Angel Faus
> Dan: > Looks like your mailer wordwrapped the program pretty badly. Could you try > again as either a context or unified diff (-c or -u) and attached to mail? > I'm curious to look at it, as I've only partially considered how we'll do > regexes to date. > Oh, sorry. I should stop sending mails