On Tue, Oct 23, 2001 at 03:02:09AM -0400, James Mastros wrote:
> + /* FIXME: How should I report this error?
If someone's failed to implement ord, that's grounds for a segfault.
> 74658072
Not portable. :(
> output_is( <<'CODE', <
Hey all.
This is a much nicer implementation of ord, which does it properly as a
string encoding "method".
The only real uglyness I see is the "I have no mouth and I must scream"
problem. I could take a Perl_Interpreter * parameter, but the only reason I
need it is to fire off exceptions.
On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
> 1) Build minimal perl 6 with default parameters using platform build tool
But "platform build tool" is going to be 'make' - the alternative is
that we maintain and ship every flavour of batch or shell script we can
think of. I don't
>> Ant is different. Instead of a model where it is extended with shell based
>commands, it is
>> extended using Java classes. Instead of writing shell commands, the
>configuration files
>> are XML based calling out a target tree where various tasks get executed.
>Each task is run
>> by an object
I get a the following error when I do a 'make' with a fresh checkout.
pdump.c: In function `main':
pdump.c:63: warning: passing arg 1 of `PackFile_unpack' from incompatible
pointe
r type
pdump.c:63: warning: passing arg 2 of `PackFile_unpack' from incompatible
pointe
r type
pdump.c:63: warning: p
At 05:00 PM 10/22/2001 -0700, Zach Lipton wrote:
>On 10/22/01 3:44 PM, "Dan Sugalski" <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 23 Oct 2001, Tom Hughes wrote:
> >
> >> In message <[EMAIL PROTECTED]>
> >> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >>
> >>> On Mon, 22 Oct 2001, Sam Tregar wr
On 10/22/01 3:44 PM, "Dan Sugalski" <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Oct 2001, Tom Hughes wrote:
>
>> In message <[EMAIL PROTECTED]>
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>>> On Mon, 22 Oct 2001, Sam Tregar wrote:
>>>
Fresh checkout won't compile on Redhat Linux 7
On Tue, 23 Oct 2001, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 22 Oct 2001, Sam Tregar wrote:
> >
> > > Fresh checkout won't compile on Redhat Linux 7.1:
> >
> > Damn. It compiled cleanly before I checked it in. I'll pa
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Oct 2001, Sam Tregar wrote:
>
> > Fresh checkout won't compile on Redhat Linux 7.1:
>
> Damn. It compiled cleanly before I checked it in. I'll patch up again and
> see what I missed. Probably some odd
On Mon, 22 Oct 2001, Sam Tregar wrote:
> Fresh checkout won't compile on Redhat Linux 7.1:
Damn. It compiled cleanly before I checked it in. I'll patch up again and
see what I missed. Probably some odd dependency or timing issue
somewhere. (It's emacs fault! Yeah, that's the ticket! :)
Fresh checkout won't compile on Redhat Linux 7.1:
string.c: In function `string_compare':
string.c:161: warning: passing arg 1 of pointer to function from
incompatible pointer type
string.c:161: too few arguments to function
string.c:164: warning: passing arg 1 of pointer to function from
incompa
Okay, here's a tentative list 'o stuff that is in the works for Parrot 0.03
(and possibly 0.04):
*) Scalar PMCs
*) Simple I/O
*) Multiple interpreter & thread creation
*) A simple arena allocation system
*) Garbage collection
So in the next week or three we should be able to read and write file
I just finished the skeleton of the PMC/string (and soon bigint/bigfloat)
allocation system and checked it in. This meant a lot of changes to stuff
all over the place. (As a side-effect, we lost the standalone string testing)
I think we're now in a position to start dealing with our own memory
Okay folks, a quick heads up.
*Any* function in the parrot core that allocates a parrot-managed structure
(such as a string or PMC) *must* have a valid interpreter structure hanging
around. I'm in the middle of rejigging everything so we can start
allocating PMCs & string structures, and prope
On Sun, Oct 21, 2001 at 12:45:14PM -0400, Dan Sugalski wrote:
> Okay, we've now got minimal:
>
> *) Parrot assembly
> *) Perl
> *) Python
> *) JVM
> *) Scheme
> *) Jako
> *) Ruby? (Do we? I can't remember for sure)
>
> support for Parrot. This is a cool thing, but it brings up the
At 06:37 PM 10/19/2001 -0400, Jason Gloudon wrote:
>Here is the patch (again) to use the appropriate bitmask determined by
>Configure for the different register chunks.
Applied. Thanks.
Dan
--"it's like this"--
At 07:15 AM 10/22/2001 -0700, Wizard wrote:
> > 1) Do we put them all in the parrot CVS tree
>
>I think it would be good for the languages to be in tree, but I would like
>to have it under a different mechanism for cvs checkout. In other words, the
>default cvs checkout of parrot does NOT check ou
On Tue, 16 Oct 2001, Dan Sugalski wrote:
> An interpreter can get access to a shared PMC in another interpreter
> only at interpreter clone time, or if explicitly passed in via an (as
> yet undetermined) handoff method.
One thing I'd really like to be able to do in Parrot/Perl 6 is to be able
t
> 1) Do we put them all in the parrot CVS tree
I think it would be good for the languages to be in tree, but I would like
to have it under a different mechanism for cvs checkout. In other words, the
default cvs checkout of parrot does NOT check out the languages tree, but a
separate checkout is r
Hi,
>
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> There's nothing really past what make does. The reason for having our own
is:
> *) Make isn't everywhere (like windows)
> *) Make on various platforms has different syntax (VMS, Windows, and Unix
> are all different)
> *) Not speaking for an
20 matches
Mail list logo
