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.
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/
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
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
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
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 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
> 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
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
>
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
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 the op tracing
* The functions in bytecode.
[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
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
On Mon, 2001-09-17 at 12:32, Dan Sugalski wrote:
> 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 i
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 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
I don't know if this has already been discussed, or is out of the question,
but I wonder since perl does not currently differentiate between numbers and
string, and when it does, it does so very inconsistantly, is there be any
hope for any changes/modificatins for Perl 6.
Many can argue that this
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
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
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
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
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
> "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
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/
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
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
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
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
On Mon, Sep 17, 2001 at 02:30:22PM -0500, Gibbs Tanton - tgibbs wrote:
> 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
Not so. Depending on the implementation malloc(0) may do any of
the f
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 (really storing '\0' is not necessary, but it is always
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
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
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
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 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
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
On Mon, Sep 17, 2001 at 03:26:28PM -0500, Gibbs Tanton - tgibbs wrote:
> 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 (the
> return malloc(size ? size : 1);
>
> That's a constant pointer, and you can read 1 byte beyond it (the '\0')
The '\0'? You mean the pseudorandom byte that happens to be in the
heap at the beginning of the malloc block?
> Anything wrong with that as parrot's malloc wrapper?
That would keep bo
All --
I'm not certain about this, but it sure doesn't look right to me.
(note I did this after turning off fingerprint saving in the
assembler for clarity):
$ perl -e 'print "set_i I0, 4\nend\n"' | assemble.pl | od -x
000 55a1 0131 0002
020 00
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/
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
As near as I can tell, its always been just the bytecode following
without a length specifier. I was going to play with it, but since
we're still deciding on the file format, I thought I'd leave it alone.
Brian
On Mon, 2001-09-17 at 16:06, Gregor N. Purdy wrote:
> All --
>
> I'm not certain a
Folks,
Don't sweat system malloc behaviour all that much at the moment. We are
going to be completely taking over memory allocation internally at some
point reasonably soon, so as long as what you do doesn't crash we should be
fine. (It's OK to leak at this point--either the GC system or the B
At 11:18 AM 9/17/2001 -0600, Sterin, Ilya wrote:
>I don't know if this has already been discussed, or is out of the question,
>but I wonder since perl does not currently differentiate between numbers and
>string, and when it does, it does so very inconsistantly, is there be any
>hope for any chang
Brian --
> As near as I can tell, its always been just the bytecode following
> without a length specifier. I was going to play with it, but since
> we're still deciding on the file format, I thought I'd leave it alone.
Yeah, I just read bytecode.c again and sure enough that's it. My code
is wo
> Don't sweat system malloc behaviour all that much at the moment. We are
> going to be completely taking over memory allocation internally at some
> point reasonably soon, so as long as what you do doesn't crash we should
be
> fine. (It's OK to leak at this point--either the GC system or the
On Mon, Sep 17, 2001 at 05:29:11PM -0400, Dan Sugalski wrote:
> Folks,
>
> Don't sweat system malloc behaviour all that much at the moment. We are
> going to be completely taking over memory allocation internally at some
> point reasonably soon, so as long as what you do doesn't crash we should
On Sun, Sep 16, 2001 at 01:03:17PM -0500, Brian Wheeler wrote:
> 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:
>
> /* JUMP Ix */
> MA
On Tue, Sep 18, 2001 at 12:38:01AM +0300, Jarkko Hietaniemi wrote:
> On Mon, Sep 17, 2001 at 05:29:11PM -0400, Dan Sugalski wrote:
> > Folks,
> >
> > Don't sweat system malloc behaviour all that much at the moment. We are
> > going to be completely taking over memory allocation internally at som
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, though by doing
$array[2] += 0;
It will convert this to an integer, which is not the case at this time.
> > 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 first person to
>
> It is.
>
> Further digging found this comparison discussing malloc and gc
> implementations:
>
> http://www.cs.color
At 10:37 PM 9/17/2001 +0100, Simon Cozens wrote:
>On Sun, Sep 16, 2001 at 01:03:17PM -0500, Brian Wheeler wrote:
> > 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 of
At 12:38 AM 9/18/2001 +0300, Jarkko Hietaniemi wrote:
>On Mon, Sep 17, 2001 at 05:29:11PM -0400, Dan Sugalski wrote:
> > Folks,
> >
> > Don't sweat system malloc behaviour all that much at the moment. We are
> > going to be completely taking over memory allocation internally at some
> > point reas
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 first person to
> >
> > It is.
> >
> > Further digging found this comparison
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
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
> > > > >
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
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
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
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
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
1 - 100 of 112 matches
Mail list logo
