Re: Large string patch

David Lisa Jacobs [EMAIL PROTECTED] writes: From what I could tell, it looks like Dan put it in there as a potential GC hook when allocating the header of a string or PMC (see resources.c). My guess is that he is planning to fire off the GC from the interpreter. If that is the case and we

Making conversion operators consistently named

I noticed that for converting numbers to integers and back there are the named operators iton and ntoi, but for conversions to and from PMCs the set operator is used. Should we make all conversions have their own ops (e.g., pton, ptoi, ...) or should we push all conversions into the set

Re: Large string patch

Here is the string patch with the interpreter left in. Take your pick :-) David Index: Makefile.in === RCS file: /cvs/public/parrot/Makefile.in,v retrieving revision 1.85 diff -c -r1.85 Makefile.in *** Makefile.in 27 Dec 2001

Re: Large string patch

On Sat, Dec 29, 2001 at 10:46:48PM -1000, David Lisa Jacobs wrote: Here is the string patch with the interpreter left in. Take your pick :-) I'll apply this, on the basis of only changing as little as possible at a time. :) Thanks. -- Simon: `hello kitty' douche. If you are getting some

Re: Large string patch

On Sun, Dec 30, 2001 at 12:01:05PM +, Simon Cozens wrote: On Sat, Dec 29, 2001 at 10:46:48PM -1000, David Lisa Jacobs wrote: Here is the string patch with the interpreter left in. Take your pick :-) I'll apply this, on the basis of only changing as little as possible at a time. :)

Re: We're all just Parrot Troopers

On Sun, Dec 30, 2001 at 01:25:58AM -0500, Bryan C. Warnock wrote: Simon's preoccupied. Aye. Book deadline due next week. You'll be lucky to hear anything from me until then. And when I do get back, I'm going to be starting planning compiler front-end stuff. An updated TODO list is needed.

Re: Making conversion operators consistently named

David -- I noticed that for converting numbers to integers and back there are the named operators iton and ntoi, but for conversions to and from PMCs the set operator is used. Should we make all conversions have their own ops (e.g., pton, ptoi, ...) or should we push all conversions into

Re: Making conversion operators consistently named

On Sun, Dec 30, 2001 at 08:46:56AM -0500, Gregor N. Purdy wrote: I still support the idea, but would like Simon / Dan to chime in. I vote for implicit set, too. -- Last week I forgot how to ride a bicycle. -- Steven Wright

One of these things is not like the others...

Mixed modes for *.pl scripts in the main directory. Should all probably be 0644. The main directory is also feeling a little oppressive, but I'm probably just claustrophobic. -- Bryan C. Warnock [EMAIL PROTECTED]

[PATCH] Build stuff (some of it for shared libraries)

All -- I'm working on getting shared library building working, and this is a step in that direction. I made a few changes to the build stuff to scratch a few itches along the way. I'm of a mind to commit this, but I wanted to give you all an opportunity to have a look first. I've attached the

Re: One of these things is not like the others...

Bryan -- Mixed modes for *.pl scripts in the main directory. Should all probably be 0644. Changing them directly in the repository should help. The main directory is also feeling a little oppressive, but I'm probably just claustrophobic. Agreed. I just made the shared libraries build

Re: One of these things is not like the others...

On Sunday 30 December 2001 10:11 am, Gregor N. Purdy wrote: The main directory is also feeling a little oppressive, but I'm probably just claustrophobic. Agreed. I just made the shared libraries build to blib/lib/ to keep them out of the root dir. I'd like to see things generally migrate

Re: We're all just Parrot Troopers

On Sun, 30 Dec 2001, Simon Cozens wrote: An updated TODO list is needed. As is maybe a reminder on bugs.perl.org. The things that I want to happen for 0.0.4 are not sexy. They are definitely not cool things, so I don't exactly expect people to be jumping at the chance to do them. That's

Re: Large string patch

At 08:33 PM 12/29/2001 -1000, David Lisa Jacobs wrote: From what I could tell, it looks like Dan put it in there as a potential GC hook when allocating the header of a string or PMC (see resources.c). My guess is that he is planning to fire off the GC from the interpreter. If that is the case

Re: Making conversion operators consistently named

At 09:56 PM 12/29/2001 -1000, David Lisa Jacobs wrote: I noticed that for converting numbers to integers and back there are the named operators iton and ntoi, but for conversions to and from PMCs the set operator is used. Should we make all conversions have their own ops (e.g., pton, ptoi, ...)

Re: [PATCH] The Code Police [1/

At 09:29 PM 12/29/2001 -0800, Boris Tschirschwitz wrote: Hi. Since there is a code police now: I am sure that no one in his or her right mind would ever want something like opcode_t * code_start in beautified code. Of course, it's not a multiplication--we all know that--but when just

Re: [PATCH] The Code Police [1/

Boris, et al. -- I am sure that no one in his or her right mind would ever want something like opcode_t * code_start in beautified code. Concerns about my state of mind aside... ;) It turns out that I'm the guilty party on this one. The C grammar notwithstanding, my brain

Re: Large string patch

From: Dan Sugalski [EMAIL PROTECTED] At 08:33 PM 12/29/2001 -1000, David Lisa Jacobs wrote: GC will manage all the memory. Everything managed should either be hung off a PMC or an internal structure. (There are GC hooks in the vtable for complex things) So does that mean I can get rid of

[Patch] - Changes iton and ntoi to set operators

This patch moves the conversion routines iton and ntoi into set. Index: core.ops === RCS file: /cvs/public/parrot/core.ops,v retrieving revision 1.61 diff -c -r1.61 core.ops *** core.ops 30 Dec 2001 12:04:56 - 1.61 --- core.ops

Re: [Patch] - Changes iton and ntoi to set operators

David Lisa -- Thanks! Mailer mangling prevents me from applying this. If you send again as an attachment, I can do it. I would like to see the implementations of the new set ops be marked 'inline', and I'd like to see them avoid using local variables, too. Regards, -- Gregor On Sun,

Re: [Patch] - Changes iton and ntoi to set operators

At 07:44 AM 12/30/2001 -1000, David Lisa Jacobs wrote: This patch moves the conversion routines iton and ntoi into set. Got it, thanks. I'll go in as soon as the test build finishes. Dan --it's like

Re: Large string patch

At 07:30 AM 12/30/2001 -1000, David Lisa Jacobs wrote: From: Dan Sugalski [EMAIL PROTECTED] At 08:33 PM 12/29/2001 -1000, David Lisa Jacobs wrote: GC will manage all the memory. Everything managed should either be hung off a PMC or an internal structure. (There are GC hooks in the vtable

Re: [Patch] - Changes iton and ntoi to set operators

Here it is as an attachment. Is that the preferred Parrot Way (TM)? For now, I just moved the existing routines. I will see about inlining them and getting rid of local variables separately. David - Original Message - From: Gregor N. Purdy [EMAIL PROTECTED] Mailer mangling prevents

Re: [Patch] - Changes iton and ntoi to set operators

At 08:15 AM 12/30/2001 -1000, David Lisa Jacobs wrote: Here it is as an attachment. Is that the preferred Parrot Way (TM)? Depends on who you ask. :) I prefer inline if they don't get mangled. Other folks prefer attachments. The current pumpking is the ultimate arbiter here, so it'd be

Re: Large string patch

Here is the patch to make the string buffer separate from the structure again. I also snuck in a patch to the mops.pasm file in examples/assembly that changes an iton op to a set op. From: Dan Sugalski [EMAIL PROTECTED] So you still need the interpreter pointer, you just don't have to pass it.

Picky gcc patch in

Folks, GCC builds now have the -Wall switch enabled. This makes gcc much pickier. Which is good. On the other hand, it shows some sloppiness in the code. This is bad. :) In the future, no checkins that -Wall complains about, please. (Which includes me)

We made slashdot...

And lucky us. :) http://slashdot.org/article.pl?sid=01/12/30/1434242mode=nested assuming that's not munched somewhere. Dan --it's like this--- Dan Sugalski even samurai [EMAIL

Building Parrot on Win32

'lo there, just tried to build Parrot 0.3 (from CVS) on Win32 -- but I didn't succeed. The output of perl Configure.pl can be found at http://www.sebastian-bergmann.de/parrot_configure.txt and the output of nmake can be found at

Re: Large string patch

At 08:33 AM 12/30/2001 -1000, David Lisa Jacobs wrote: Here is the patch to make the string buffer separate from the structure again. I also snuck in a patch to the mops.pasm file in examples/assembly that changes an iton op to a set op. Applied, thanks. We do still need to address the

Re: Building Parrot on Win32

At 09:42 PM 12/30/2001 +0100, Sebastian Bergmann wrote: 'lo there, just tried to build Parrot 0.3 (from CVS) on Win32 -- but I didn't succeed. Argh! Platform quoting issues. Can you edit Makefile and change the appropriate ' to and see how things go from there?

Re: Building Parrot on Win32

Sebastian -- I noticed on your first post of the nmake run log that you ended up re-running Configure.pl. That's not a good sign. I don't know what time you grabbed code from CVS, but if you wouldn't mind doing the following to be *very* sure you've got all the latest checkins, I'd appreciate

Re: [PATCH] The Code Police [1/

Yeah, int *num; is customary in C, but for some reason C++ people like to write int* num; I am sure I saw some rationale for that in gcc's C++ part, but I can't find it anymore. Apparently C programmers do not fall for that. Boris. On Sun, 30 Dec 2001, Dan Sugalski wrote: At 09:29 PM

Vtables!

At 03:44 PM 12/30/2001 +, Alex Gough wrote: I tried to do some of this yesterday and got myself into a massive muddle, in trying to rescue myself from this muddle I took a wrong turning and found myself in a dark and dismal can of worms. Then I ate the worms, because I was hungry, not

Re: [PATCH] The Code Police [1/

At 04:11 PM 12/30/2001 -0800, Boris Tschirschwitz wrote: Yeah, int *num; is customary in C, but for some reason C++ people like to write int* num; I am sure I saw some rationale for that in gcc's C++ part, but I can't find it anymore. Apparently C programmers do not fall for that. I don't

Re: [PATCH] The Code Police [1/

On Sun, 30 Dec 2001 16:11:35 -0800 (PST), Boris Tschirschwitz wrote: Yeah, int *num; is customary in C, but for some reason C++ people like to write int* num; I am sure I saw some rationale for that in gcc's C++ part, but I can't find it anymore. Apparently C programmers do not fall for

[PATCH] Add -DHAS_JIT to make test_parrot smaller on non jitarchitectures/plataforms.

Daniel Grunblatt. Index: Configure.pl === RCS file: /home/perlcvs/parrot/Configure.pl,v retrieving revision 1.47 diff -u -r1.47 Configure.pl --- Configure.pl31 Dec 2001 03:05:59 - 1.47 +++ Configure.pl

Win32 build problems

Trying to build 0.0.3. perl Configure.pl runs fine. nmake No warnings above. cl -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FC RYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX -I./in clude -Fochartypes/usascii.obj -c

Re: Win32 build problems

At 11:27 PM 12/30/2001 -0800, Sterin, Ilya wrote: The package was downloaded from Simon's directory on CPAN. Could you try a CVS checkout? Things have changed a bunch. (I expect they're still broken on Win32, but at least it'll be broken differently)

[PATCH] - removes unused tmp

Index: core.ops === RCS file: /cvs/public/parrot/core.ops,v retrieving revision 1.64 diff -c -r1.64 core.ops *** core.ops30 Dec 2001 20:45:32 - 1.64 --- core.ops31 Dec 2001 04:20:57 - *** *** 354,360

RE: Win32 build problems

Thanks, I'll try right now. -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 30, 2001 8:33 PM To: Sterin, Ilya; [EMAIL PROTECTED] Subject: Re: Win32 build problems At 11:27 PM 12/30/2001 -0800, Sterin, Ilya wrote: The package was

Re: [PATCH] - removes unused tmp

Applied, thanks. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy

RE: Win32 build problems

Ok, this is what I get on nmake now... ../include\parrot/parrot.h(76) : fatal error C1083: Cannot open include file: 'pa rrot/vtable.h': No such file or directory NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. I don't see a vtable.h in my include/parrot dir. Did something go wrong

RE: Win32 build problems

Ohhh, just though about it, the user/pass is not registered in the cvs server, and I don't need for now. Though the anonymous should of worked, right? Ilya -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 30, 2001 8:33 PM To: Sterin, Ilya;

RE: Win32 build problems

..cvsignore file lists the vtable.h file??? Ilya -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 30, 2001 8:33 PM To: Sterin, Ilya; [EMAIL PROTECTED] Subject: Re: Win32 build problems At 11:27 PM 12/30/2001 -0800, Sterin, Ilya wrote:

RE: Win32 build problems

At 12:55 AM 12/31/2001 -0800, Sterin, Ilya wrote: Ohhh, just though about it, the user/pass is not registered in the cvs server, and I don't need for now. Though the anonymous should of worked, right? It should've worked fine. vtable.h is autogenerated--configure.pl should've made one for you.

RE: Win32 build problems

Ok, sorry guys. I see now it's generated by vtable_h.pl, but am I supposed to run it or is Configure.pl supposed to do it, as I see it now nothing does this. Ilya -Original Message- From: Sterin, Ilya [mailto:[EMAIL PROTECTED]] Sent: Monday, December 31, 2001 12:59 AM To: 'Dan

RE: Win32 build problems

At 01:09 AM 12/31/2001 -0800, Sterin, Ilya wrote: Ok, sorry guys. I see now it's generated by vtable_h.pl, but am I supposed to run it or is Configure.pl supposed to do it, as I see it now nothing does this. The makefile builds it at this point. Try nmake include/parrot/vtable.h and see if

RE: (Disregard all previous) Win32 build problems

OK, nmake is supposed to run the vtable_h.pl and apperently it does, not sure what happened before, though I still get the ../include\parrot/parrot.h(76) : fatal error C1083: Cannot open include file: 'pa rrot/vtable.h': No such file or directory NMAKE : fatal error U1077: 'cl' : return code

RE: (Disregard all previous) Win32 build problems

At 01:11 AM 12/31/2001 -0800, Sterin, Ilya wrote: OK, nmake is supposed to run the vtable_h.pl and apperently it does, not sure what happened before, though I still get the ../include\parrot/parrot.h(76) : fatal error C1083: Cannot open include file: 'pa rrot/vtable.h': No such file or directory

Correction to string patch

David In your last change (splitting buffer allocation from string) I assume you also intended to shorten the initial allocation. Peter Gibbs EmKel Systems Index: string.c === RCS file: /home/perlcvs/parrot/string.c,v retrieving

Re: Large string patch

From: Dan Sugalski [EMAIL PROTECTED] We do still need to address the byte-orientation of the strings. Throwing a single null byte on the end's not enough for buffers that have 16 or 32 bit characters. Agreed. I'll probably have the encoding structure provide the terminating bytes. As a side