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
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
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
>
> "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
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
Garrett Goebel wrote:
> Just does compile-time typing for $foo? Not inlining the constant?
You can't assume that the value associated with the symbol is
the same each time through the code, so how can it be inlined?
> I was thinking lowercase typed variables couldn't be rebound, because
> they w
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
> 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
> > 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
> >
> >
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
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
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
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
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,
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
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.
> 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
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
> 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
> > 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
> 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
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
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
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
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
> 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
26 matches
Mail list logo