I applied this fairly recently; it may be helpful for a parrot-nightly.
C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>perl
Configure.pl --help
Configure.pl - Parrot Configure
Options:
--debugging Enable debugging
--defaults Accept all default values
--define nam
[UPDATED: patch actually attached this time]
All --
I am attaching a revised op tracing patch based on the feedback I got.
Its features are:
* Provides macros in interp_guts.h for setting up arrays with
op names and op arg counts (done via build_interp_starter.pl).
These are used in
All --
I have committed the revised op tracing patch I posted earlier.
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTE
All --
I've just committed some new Perl modules. If nobody else takes
it on, I'll tinker with the assembler and disassembler to make
them use these. This way, as the format changes, it will be
easier to keep things in sync.
>From the commit message (and the header comments of Parrot/PackFile.pm
On Mon, Sep 17, 2001 at 05:54:41PM -0400, Dan Sugalski wrote:
> At 12:51 AM 9/18/2001 +0300, Jarkko Hietaniemi wrote:
> > > > Doug Lea's malloc is in the public domain:
> > > >
> > > > http://g.oswego.edu/dl/html/malloc.html
> > > >
> > > > I don't remember whether that's quadsafe code but the fir
You are right, a simple example now dumps as expected, though I'll have to
go through the rest of my code to see what exactly is pushing it as a
string. Somewhere in there is a wrong type assumption, or maybe not. I'll
take a look.
Ilya
> -Original Message-
> From: Simon Cozens [mailto
At 12:56 AM 9/18/2001 +0300, Jarkko Hietaniemi wrote:
>On Mon, Sep 17, 2001 at 05:54:41PM -0400, Dan Sugalski wrote:
> > At 12:51 AM 9/18/2001 +0300, Jarkko Hietaniemi wrote:
> > > > > Doug Lea's malloc is in the public domain:
> > > > >
> > > > > http://g.oswego.edu/dl/html/malloc.html
> > > > >
It looks like to me that this is only running every day. Can we get it to
run every hour? Perhaps even on demand? I think I have fixed all of the
memory access errors but one.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/15/2001 5:16 PM
Subject: "Automated" Purif
On Mon, Sep 17, 2001 at 05:52:19PM -0400, Dan Sugalski wrote:
> >Which is really going to screw up backpatching. :(
>
> Maybe. I don't think it's as big a deal as you might think it is, since we
> vector through a register, and you can just patch the register load.
The reason I started looking
Wearing my coding standard police hat -
You should remove your cuddled else statements:
i.e. if {
} else {
}
becomes
if {
}
else {
}
other than that, it looks good.
-Original Message-
From: Gregor N. Purdy
To: [EMAIL PROTECTED]
Sent: 9/17/2001 11:37 AM
Subje
On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen <[EMAIL PROTECTED]> wrote:
>
> oops, I forgot to tell anyone. I made CVS export and tar up a
> snapshot every 6 hours. It is available at
> http://cvs.perl.org/snapshots/parrot/
Any chance on rsync? If so, I might set up another smoke suite to bother
It should now be running once an hour. (it broke due to some makefile
changes yesterday).
I can't really do it easily on-demand, due to the way this is set up.
--Josh
At 13:05 on 09/17/2001 CDT, Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> It looks like to me that this is only running
On Tue, 18 Sep 2001, H.Merijn Brand wrote:
> On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen <[EMAIL PROTECTED]> wrote:
> >
> > oops, I forgot to tell anyone. I made CVS export and tar up a
> > snapshot every 6 hours. It is available at
> > http://cvs.perl.org/snapshots/parrot/
>
> Any chance on r
At 11:04 PM 9/17/2001 +0100, Simon Cozens wrote:
>On Mon, Sep 17, 2001 at 05:52:19PM -0400, Dan Sugalski wrote:
> > >Which is really going to screw up backpatching. :(
> >
> > Maybe. I don't think it's as big a deal as you might think it is, since we
> > vector through a register, and you can just
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 02:06 PM 9/17/2001 +0100, Dave Mitchell wrote:
>> If we have one generic stack with all sorts of things on it, why not
>> treat it as a stack of objects, with each object "knowing" what to do
>> with itself when popped? Or mor
At 03:49 PM 9/17/2001 -0600, Sterin, Ilya wrote:
>I guess the problem can be easily solved by converting to integer if a
>mathematical operation is performed, or a similar behavior.
>
>@array = ("one", "two", 3);
>
>All are now internally strings
Yech. With perl 6 they'll probably be two strings
At 02:50 PM 9/17/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 02:06 PM 9/17/2001 +0100, Dave Mitchell wrote:
>
> >> If we have one generic stack with all sorts of things on it, why not
> >> treat it as a stack of objects, with each object
The hourly should be fine...can you do me one other favor and run the
following c snippet through Purify:
int main() {
char* c = (char*)malloc(0);
printf( "%.*s\n", 0, c );
return 0;
}
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/
On Mon, Sep 17, 2001 at 07:09:56PM -0400, Dan Sugalski wrote:
> At 03:49 PM 9/17/2001 -0600, Sterin, Ilya wrote:
> >I guess the problem can be easily solved by converting to integer if a
> >mathematical operation is performed, or a similar behavior.
> >
> >@array = ("one", "two", 3);
> >
> >All ar
Purify instrumented foo (pid 11272)
ABR: Array bounds read:
* This is occurring while in:
_doprnt[libc.so.1]
printf [libc.so.1]
main [ccjq2xev.o]
_start [crt1.o]
* Reading 1 byte from 0x969b0 in the heap.
* Addre
This code:
set I2 0
l2: inc I2
le I2, 5, l2, l3
l3:
wouldn't assemble because the assembler couldn't turn
le into le_i_ic. Patches welcome.
--
Stinginess with privileges is kindness in disguise.
-- Guide to VAX/VMS Security, Sep. 1984
On Mon, Sep 17, 2001 at 03:43:28PM +0100, Simon Cozens wrote:
> Or you could install Digest::MD5. :) I'm not terribly amused by the dependency
> on it, but I guess that for "release" versions of Parrot, the opcode header
> and other autogenerated things will be generated before shipping; much like
Brian --
> > I also did 'vi t/jump.list'. With these hard-coded relative offsets, I
> > think the program should be producing the desired output, but it
> > doesn't. If it did, I could do some tricks in jakoc and/or assemble.pl
> > to create a pseudo-op for jumping to any label, and another for
>
On Mon, Sep 17, 2001 at 02:18:16PM -0500, Gibbs Tanton - tgibbs wrote:
> The hourly should be fine...can you do me one other favor and run the
> following c snippet through Purify:
>
> int main() {
> char* c = (char*)malloc(0);
I can tell without Purify that malloc(0) is unportable.
(As is cal
On Tue, Sep 18, 2001 at 01:14:02AM +0100, Simon Cozens wrote:
> le I2, 5, l2, l3
Ignore me. I'll just remember not to trust anything coming from the person who
sent me that code (you know who you are :)
Simon
--
BITTERNESS:
Never be Afraid to Share Your Dreams with the World,
On Mon, Sep 17, 2001 at 10:38:35AM -0500, Jonathan Scott Duff wrote:
> Parrot/Opcode.pm only uses Digest::MD5 for fingerprinting the opcode
> file which could be done without Digest::MD5 IMHO. For instance,
> using unpack() to checksum the file.
This is much cleaner. Thanks, applied.
--
?warni
In strings.pod, the following string functions are documented and
(most|all) are already implemented:
DOCUMENTED:
chopn
concat
length
substr
string_nprintf
However, Perl5 also includes the following functions that operate on
or otherwise relate to strings:
Well, that explains the last Purify issue. Whenever we substr out 0 bytes
to a NULL register, we create a string by malloc(0). If we later print that
string, then we pass in 0 to printf. I thought that printf would not look
at its argument if the length specifier was 0, but apparently on your s
> Have you built test.pbc?
% make test.pbc
make: `test.pbc' is up to date.
% ../test_prog test.pbc
Can't mmap, code 0
Sorry.
-Hao
On Mon, Sep 17, 2001 at 02:33:53PM -0500, Gibbs Tanton - tgibbs wrote:
> Okey Dokey. With that being the case, it appears we should rethink
> string_grow/string_make. If we get a length of 0, we should allocate 1 byte
> and store '\0' in it
Nope. If we get a length of 0, we don't do anything. S
At 12:50 PM 9/17/2001 -0400, Gregor N. Purdy wrote:
>I wonder... What could I add to Jako so that it could be used to
>implement a simple PMC type? How much more architecture work needs to
>be done before we could start having simple examples that use PMC
>registers?
Not much at the moment. PMCs
there is something wrong with, uh, something...
Currently substr is named substr_s_s_i.
if I write substr_s_s_i S9, S1, I0, I1, all is good.
if I write substr S9, S1, I0, I1, I get an assembler error.
Questions:
* All opcodes include the destination register type in the name
why substr is diffe
The attached patch adds string_nprintf, the last unimplemented
function listed in strings.pod as far as I can see.
It should cope with both the differences in return values for
vsnprintf between different versions of glibc but there are still
a few platforms which may have problems as they have a
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>
> Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Sep 13, 2001 at 09:35:33AM +0100, Tom Hughes wrote:
> > > BTW I have had to resend this because my first attempt was bounc
On Mon, Sep 17, 2001 at 09:33:56AM +0100, Tom Hughes wrote:
> The attached patch adds string_nprintf, the last unimplemented
> function listed in strings.pod as far as I can see.
Thanks; but I think I'm going to wait for the portability police to
comment. There's every likelihood we want to write
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2001 at 09:33:56AM +0100, Tom Hughes
> wrote:
> > The attached patch adds string_nprintf, the last
> unimplemented
> > function listed in strings.pod as far as I can see.
>
> Thanks; but I think I'm going to wait for the portability
>
[EMAIL PROTECTED] (Nathan Torkington) writes:
> Simon Cozens writes:
> > So maybe the best thing would be for people to send patches to the
> > list and Cc [EMAIL PROTECTED]
>
> I wonder if, when RT comes online, we could use that to manage the
> patches. In other words, patches become open "to
[EMAIL PROTECTED] (Dan Sugalski) writes:
> At 11:31 AM 9/14/2001 -0500, Gibbs Tanton - tgibbs wrote:
> >The patch assumes that your source code directory is named parrot. This may
> >have been an invalid assumption, but it is going to be hard to do this patch
> >unless we agree on the name of th
The following .h files need to be moved to include/parrot underneath the
main source directory (right Simon or Dan? :)
bytecode.h
config.h
events.h
exceptions.h
global_setup.h
interp_guts.h
interpreter.h
io.h
memory.h
op.h
parrot.h
register.h
stacks.h
string.h
strnative.h
-Original Message-
Mattia --
> there is something wrong with, uh, something...
> Currently substr is named substr_s_s_i.
> if I write substr_s_s_i S9, S1, I0, I1, all is good.
> if I write substr S9, S1, I0, I1, I get an assembler error.
The assembler uses some simple logic to infer the full opcode from
the abbrev
Buggs --
Thanks. Applied.
> Don't know if this is in your intent.
> Just let me know.
>
> Buggs
>
>
> Index: little_languages/jakoc
> ===
> RCS file: /home/perlcvs/parrot/little_languages/jakoc,v
> retrieving revision 1.3
>
> Assuming there's one general stack to save "stuff" on, where stuff is:
>
> * Scope entries
> * Return addresses for JSRs
> * Saved individual registers
> * Local() calls
Dave's Wild+Whacky+Unworkable Suggestion #42:
If we have one generic stack with all sorts of things on it,
At 02:06 PM 9/17/2001 +0100, Dave Mitchell wrote:
> > Assuming there's one general stack to save "stuff" on, where stuff is:
> >
> > * Scope entries
> > * Return addresses for JSRs
> > * Saved individual registers
> > * Local() calls
>
>Dave's Wild+Whacky+Unworkable Suggestion #42:
Just a warning, all the four arg comparison ops (The ones with a success
and failure destinations) are changing over to three-arg versions (Branch
if true, fall through otherwise). I'll patch up the existing code and
assembly as soon as I get things down.
On Mon, Sep 17, 2001 at 10:38:26PM +0300, Jarkko Hietaniemi wrote:
> How about always allocating size+1 and stomping '\0' to the [size]th bytes?
I'm trying to kill off that age-old C-ism and brainwash people into believing
that a null in a string is just as significant as any other byte, so that
Yep, you were right...I made a patch for you and applied it :)
Thanks!
Tanton
Philip Kendall wrote:
* The trickier one: with the above two changes, test and test2 work,
but test3 tries to pop a non-existent stack frame. In Parrot_pop_i,
should the fragment:
if (chunk_base->prev) {
I've waited till either Configure or make would do something sensible, and I'm
also aware that parrot-nightly isn't stable. Does perl6-internals value input
like this (on a regular basis) or not.
Either way, is there a point in time that parrot is released as pseodo-stable
snapshots like Jarkko d
Okay, I checked out parrot fresh from CVS this morning (after wading
through a *lot* of e-mail) and I find:
*) Configure.pl doesn't like the current state of the manifest and won't
run (at least not for me, though it's misbehaving oddly)
*) Things don't build at all well on CygWin. (They used t
Things work fine for me on cygwin...just be sure that you use cc instead of
ld. Also, you probably don't want to include any libraries. As for the
Manifest I haven't had any problems.
-Original Message-
From: Dan Sugalski
To: [EMAIL PROTECTED]
Sent: 9/17/2001 9:10 AM
Subject: Time for a
On Mon, Sep 17, 2001 at 02:50:29PM +0100, Nicholas Clark wrote:
> Shouldn't that read "ops will not be accepted without accompanying
> regression tests" ?
Yes. Other committers, take note.
Simon
--
} /* the next line is indented funny to preserve old indentation */
- plan9 has a ba
On Mon, Sep 17, 2001 at 04:01:22PM +0200, H. Merijn Brand wrote:
> I've waited till either Configure or make would do something sensible, and I'm
> also aware that parrot-nightly isn't stable. Does perl6-internals value input
> like this (on a regular basis) or not.
Yes, definitely.
> Either way
At 09:16 AM 9/17/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Things work fine for me on cygwin...just be sure that you use cc instead of
>ld.
Had to use gcc, but it seems working now.
>Also, you probably don't want to include any libraries. As for the
>Manifest I haven't had any problems.
I did
All --
While I was working on understanding jump_i, I was wishing I could
see a trace of where the PC was going and what it was executing.
(BTW, the jump.pasm test works now that I hard-coded the offsets
as *word* counts not *byte* counts -- D'Oh!)
I was also concerned that even though I was pro
At 04:41 AM 9/17/2001 -0700, Benjamin Stuhl wrote:
>--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 17, 2001 at 09:33:56AM +0100, Tom Hughes
> > wrote:
> > > The attached patch adds string_nprintf, the last
> > unimplemented
> > > function listed in strings.pod as far as I can see.
> >
On Mon, Sep 17, 2001 at 10:33:41AM -0400, Dan Sugalski wrote:
> is missing!.pasm
> is missing!d.pasm
> is missing!pasm
> is missing!in.c
> is missing!languages/euclid.jako
> is missing!languages/jakoc
> is missing!languages/Makefile
> is missing!languages/fact.jako
> is missing!languages/
On Mon, Sep 17, 2001 at 10:35:36AM -0400, Dan Sugalski wrote:
> At 04:41 AM 9/17/2001 -0700, Benjamin Stuhl wrote:
> >--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> > > On Mon, Sep 17, 2001 at 09:33:56AM +0100, Tom Hughes
> > > wrote:
> > > > The attached patch adds string_nprintf, the last
> > > u
At 10:33 AM 9/17/2001 -0400, Gregor N. Purdy wrote:
>Any thoughts?
The big one is you shouldn't assume that we are only going to have a single
chunk of bytecode--we may well have several loaded from disk, and more
created on the fly by eval/do/dynamic recompilation.
Also, we're trying to keep
Dan --
> Okay, I checked out parrot fresh from CVS this morning (after wading
> through a *lot* of e-mail) and I find:
FYI - I just did:
$ cvs upd
$ make clean
$ make test
without any trouble...
I also did:
$ cd SOME_DIR
$ cvs checkout parrot
$ cd parrot
$ perl Configure.pl
On Mon, Sep 17, 2001 at 10:33:35AM -0400, Gregor N. Purdy wrote:
> as *word* counts not *byte* counts -- D'Oh!)
Isn't assembly programming fun? :)
> */
>
> static int
> -check_magic(void** program_code) {
> +check_magic(void** program_code, long* program_size) {
> +program_size -= sizeof
On Mon, 2001-09-17 at 11:20, Gregor N. Purdy wrote:
>
> I agree that jsr/ret are what I really want, but I'm dying to play
> with baby subroutines in jako, and I think I could play enough games
> with a properly understood jump_i and some assembler magic to make
> them work. I now have jump.pasm
Hi Jarkko,
Here is that the SUSV2 prescribe to do in this situation.
The Single UNIX ® Specification, Version 2, Copyright © 1997 The Open Group
"
NAME
malloc - a memory allocator
...
RETURN VALUE
Upon successful completion with size not equal to 0, malloc() returns a pointer
to
Getting a problem when trying to compile on a Mac OS X box.
I've not looked into it yet but output follows:
cc -lm -lc -o test_prog global_setup.o interpreter.o parrot.o register.o
basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.o
/usr/bin/ld: multiple definitions of symb
On Mon 17 Sep 2001 16:16, Simon Cozens <[EMAIL PROTECTED]> wrote:
> That could be because these aren't in the MANIFEST, so didn't get
> included in the parrot-nightly tarball. I'll fix up the MANIFEST
> and try another tarball so that it builds here.
>
> In fact, try downloading it now.
Okay, th
On Mon, Sep 17, 2001 at 03:47:58PM +0100, James A. Duncan wrote:
> Getting a problem when trying to compile on a Mac OS X box.
> I've not looked into it yet but output follows:
>
> cc -lm -lc -o test_prog global_setup.o interpreter.o parrot.o register.o
>basic_opcodes.o memory.o bytecode.o st
On Mon, Sep 17, 2001 at 04:46:30PM +0200, H. Merijn Brand wrote:
> Can't locate Digest/MD5.pm in @INC (@INC contains: /pro/lib/perl5/5.6.1/PA-RISC2.0
>/pro/lib/perl5/5.6.1 /pro/lib/perl5/site_perl/5.6.1/PA-RISC2.0
>/pro/lib/perl5/site_perl/5.6.1 /pro/lib/perl5/site_perl .) at Parrot/Opcode.pm li
Simon --
> On Mon, Sep 17, 2001 at 10:33:35AM -0400, Gregor N. Purdy wrote:
> > as *word* counts not *byte* counts -- D'Oh!)
>
> Isn't assembly programming fun? :)
Woo-hoo!
> > */
> >
> > static int
> > -check_magic(void** program_code) {
> > +check_magic(void** program_code, long* program
At 10:58 AM 9/17/2001 -0400, Gregor N. Purdy wrote:
>Nor do I. Note that the checks themselves are about as cheap as they
>*can* be, though. And I think that not checking is dangerous. I *did*
>get some segfaults when I was working on the jump_i example. Just try
>running blamo.pasm (attached) on
Dan --
> The big one is you shouldn't assume that we are only going to have a single
> chunk of bytecode--we may well have several loaded from disk, and more
> created on the fly by eval/do/dynamic recompilation.
Yeah. It seems we should have a parrot_bytecode structure that keeps the
pointer
On Mon, Sep 17, 2001 at 11:01:32AM -0400, Dan Sugalski wrote:
> While I'm not fond of segfaults myself, the place to check isn't in the
> interpreter loop.
My view is that if you screw up writing assembly code, you should be
thankful that you get the protection of a segfault.
Same happens if y
Sorry, it's been a bad week. (Don't ask) Gregor, go ahead and re-apply the
constant comparison ops. They're just fine, and I misread the things.
Dan
--"it's like this"---
Dan Sugalski
Simon --
> Or you could install Digest::MD5. :) I'm not terribly amused by the dependency
> on it, but I guess that for "release" versions of Parrot, the opcode header
> and other autogenerated things will be generated before shipping; much like we
> do with embed.pl in Perl 5.
Digest::MD5 was j
On Mon 17 Sep 2001 16:43, Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2001 at 04:46:30PM +0200, H. Merijn Brand wrote:
> > Can't locate Digest/MD5.pm in @INC (@INC contains: /pro/lib/perl5/5.6.1/PA-RISC2.0
>/pro/lib/perl5/5.6.1 /pro/lib/perl5/site_perl/5.6.1/PA-RISC2.0
>/pro/lib/pe
At 11:02 AM 9/17/2001 -0400, Gregor N. Purdy wrote:
>Dan --
> > Also, we're trying to keep the stuff in the loop to a minimum, so for this
> > I'd rather have a separate runops function, as well as having the actual
> > funky stuff in the body separated out. (I'd really like it abstracted out
> >
At 03:53 PM 9/17/2001 +0100, Simon Cozens wrote:
>On Mon, Sep 17, 2001 at 11:01:32AM -0400, Dan Sugalski wrote:
> > While I'm not fond of segfaults myself, the place to check isn't in the
> > interpreter loop.
>
>My view is that if you screw up writing assembly code, you should be
>thankful that y
Dan --
> While I'm not fond of segfaults myself, the place to check isn't in the
> interpreter loop. It's not unwarranted in assuming that it's told to go OK
> places. If we want to check the better place is inside the jump ops.
I'm in agreement, although we still need to watch out for falling
On Sun, 2001-09-16 at 14:26, Gregor N. Purdy wrote:
> Brian --
>
> > Its not going to work, if I understand it correctly. I tried doing it
> > (even set up the symbol '*' to mean the current PC) and do it, but it
> > seems the ops take a relative offset. Take jump_i, for example:
>
> Taking th
> This is because I am crap at declaring globals. Fixed.
>
> Resync your CVS and try again.
It finally built, yay!
Don't have much time to play right now, but does this look ok?
% ../test_prog test.pbc
Can't mmap, code 0
-Hao (testing on Mac OS X)
On Tue, Sep 18, 2001 at 12:06:32AM +0400, Timur Safin wrote:
> Here is that the SUSV2 prescribe to do in this situation.
Unfortunately, it's no good programming to standards; we have to program
around them.
--
I cannot and will not cut my conscience to fit this year's fashions.
On Mon, Sep 17, 2001 at 11:32:50AM -0400, Nguon Hao Ching wrote:
> Don't have much time to play right now, but does this look ok?
>
> % ../test_prog test.pbc
> Can't mmap, code 0
Have you built test.pbc? "make test.pbc" to make sure.
If you have, then, urgh, maybe mmap on Darwin is trick
On Tue, Sep 18, 2001 at 12:06:32AM +0400, Timur Safin wrote:
> Hi Jarkko,
>
> Here is that the SUSV2 prescribe to do in this situation.
>
> The Single UNIX ® Specification, Version 2, Copyright © 1997 The Open Group
> "
> NAME
> malloc - a memory allocator
> ...
I'm reading the same pag
At 12:20 PM 9/17/2001 -0400, Gregor N. Purdy wrote:
>Brian --
> > > It would also be helpful to have jump_ic and absjump_ic, rather than
> > > having to load these things into registers.
> >
> > You can use branch_ic for this. absjump is probably a bad idea since it
> > appears the return value o
Okey Dokey. With that being the case, it appears we should rethink
string_grow/string_make. If we get a length of 0, we should allocate 1 byte
and store '\0' in it (really storing '\0' is not necessary, but it is always
nice to initialize). We can still keep the length as being 0, but this way
I'm working on taking the perl function and stripping out the parts we don't
need. I should have it tonight. My thought is that we can add some stuff
in later and Parrot_printf should only have the bare necessities (therefore
I am throwing out things like maybe_tainted and vector strings). Does
At 11:49 AM 9/17/2001 -0500, Brian Wheeler wrote:
>On Mon, 2001-09-17 at 11:20, Gregor N. Purdy wrote:
> > > > It would also be helpful to have jump_ic and absjump_ic, rather than
> > > > having to load these things into registers.
> > >
> > > You can use branch_ic for this. absjump is probably a
At 1:30 on 09/18/2001 BST, Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2001 at 10:38:35AM -0500, Jonathan Scott Duff wrote:
> > Parrot/Opcode.pm only uses Digest::MD5 for fingerprinting the opcode
> > file which could be done without Digest::MD5 IMHO. For instance,
> > using unpack
Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration:
Platform:
osname=linux, osvers=2.0.35, archname=i386-linux-thread
uname='linux caliban.xs4all.nl 2.0.35 #2 sat jul 18 01:37:18 cest 1998 i686
unknown '
hint=recommended, useposix=true, d_sigaction=define
usethrea
Simon --
> Ignore me. I'll just remember not to trust anything coming from the
> person who sent me that code (you know who you are :)
Note: This will be possible again once I resurrect the reg-const
comparison ops. Dan originally asked me to remove them and then
just recently asked me to put
87 matches
Mail list logo
