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
Hello. I was wondering if Parrot is going to support
Generators. A generator is a function that returns
multiple times, and I believe, was first made available
in the language ICON. Now, ICON may have taken it a
bit too far (everything is a generator), however,
Python's newest version support
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
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 dire
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 '0x
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
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
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
..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 wr
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;
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
on
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
tedd
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 wa
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 *
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)
Da
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 chartypes/usascii.
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
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
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
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 bec
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 12/2
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 it.
Dan Sugalski wrote:
> Argh! Platform quoting issues. Can you edit Makefile and change the
> appropriate ' to " and see how things go from there?
Okay, it now proceeds further than before, but now it gets stuck at
test_main.c
../include\parrot/parrot.h(76): fatal error C1083:
include file canno
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?
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 byt
'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
http://www.sebastian-bergmann.
And lucky us. :)
http://slashdot.org/article.pl?sid=01/12/30/1434242&mode=nested
assuming that's not munched somewhere.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAI
At 02:44 AM 12/30/2001 -0500, Josh Wilmes wrote:
>I've updated my last patch and split it into three pieces. It's all
>fairly trivial. First, some simple POD fixups to core.ops. Second,
>a few minor code tweaks to silence a few compiler or lint warnings.
>Third, a change to the makefile to turn
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)
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
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 Simo
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 preve
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
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 this"---
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, 2001-
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 3
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
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 b
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 w
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,
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 th
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. Th
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 mi
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 buil
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 pa
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]
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
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 conver
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.
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.
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 a
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 23:57
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 ope
"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 c
54 matches
Mail list logo
