Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
>: I'd like to have, if possible a clear indication: that's a plain
>: function or method call and this is not. I think the possible speedup is
>: worth the effort.
> I have no problem with "p
Josh Wilmes wrote:
At 10:22 on 03/18/2004 EST, Andrew Dougherty <[EMAIL PROTECTED]> wrote:
5. You probably don't need to support Eunice anymore.
I think i'm not the only one who would be deeply upset if I ceased to be
congratulated for not running Eunice though.
Ah, but since we'll have One Confi
At 10:22 on 03/18/2004 EST, Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> 5. You probably don't need to support Eunice anymore.
I think i'm not the only one who would be deeply upset if I ceased to be
congratulated for not running Eunice though.
--Josh
I began a little piece of this ages ago- attempting to translate the parts
that identify the platform ($^O, essentially) from metaconfig to something
we could put into Configure.pl.
Even that relatively simple chore wasn't too easy. I should still have
the work-in-progress code for that around
Piers Cawley <[EMAIL PROTECTED]> wrote:
> I knew I forgot something in my last post...
Still:
EÄttätschmentMissin
leo
Larry Wall wrote:
We can certainly make it the default that a routine is not going to
do anything fancy with continuations unless it is explicitly declared
to allow it. As to what that declaration should be, I have no idea.
Probably just a trait that says, "is continuationalizableish" or
some such
parrotunit.tar.gz
Description: Binary data
On Fri, Mar 19, 2004 at 08:57:28AM +0100, Leopold Toetsch wrote:
: What's the usage of Continuations from HLLs point of view? Can we get
: some hints, what is intended?
>From the standpoint of Perl 6, I hope to hide continuations far, far
away in a galaxy long ago. No wait, wrong movie...
We can
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> new P0, .PerlNum
> set P0, 0.0
> print P0
> should IMO print "0.00" rather than "0", because its a floating point
> number and not an integer.
> What are the arguments for printing "0"?
PerlNums evaluating to whole integers (except -0.0 now
Hi,
On Friday 19 March 2004 16:23, Leopold Toetsch wrote:
> I'm currently fixing the code.
> So thanks - not needed.
new P0, .PerlNum
set P0, 0.0
print P0
should IMO print "0.00" rather than "0", because its a floating point
number and not an integer.
What are the arguments for printi
> This idea involves two assumptions:
there are three kinds of people.
those that can count and the others ;)
~ibotty
I knew I forgot something in my last post...
If you unpack this in your parrot directory you'll get
library/parrotunit.imc
library/TestCase.imc
library/TestResult.imc
library/WasRun.imc
t/test.imc
Go to the parrot directory and, do ./parrot t/test.imc and the tests
will run. Annoyingly, everyt
I've been trying to implement a Parrot port of xUnit so we can write
tests natively in parrot and things were going reasonably well until I
reached the point where I needed to do exception handling.
Exception handling hurt my head, badly, so eventually I gave up and
used a continuation instead. H
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> > What ops aren't supposed to
>> be in miniparrot?
> Anything we can't guarantee can be supported on any ANSI-compliant
> platform with very little to no probing. (Ideally, I'd like for
> miniparrot to include no tes
Jens Rieks <[EMAIL PROTECTED]> wrote:
I'm currently fixing the code.
So thanks - not needed.
leo
Arthur Bergman <[EMAIL PROTECTED]> writes:
>This is Ponie, development release 2
>
>
> "And, isn't sanity really just a one-trick ponie anyway? I mean all
>you get is one trick, rational thinking, but when you're good and
>crazy, oooh, oooh, oooh, the sky
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Jens Rieks <[EMAIL PROTECTED]> writes:
>
>>> Hi,
>>>
>>> does the attached test use the Continuation in a correct way?
>>> The test failes, what am I doing wrong?
>
>> Without running it I'm guessing that it p
Leopold Toetsch wrote:
We also need a way to mark ops for inclusion in miniparrot's limited op
set--although it might be better to do that in an external file.
Or mark exclusion, which might be simpler.
Simpler, yes. Safer, no.
> What ops aren't supposed to
be in miniparrot?
Anything we can't gua
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Some weeks ago I posted a proposal for additional hints in ops files. We
>> need additionally (at least):
>>
>> 1) a per argument flag, if this argument is indicating a branch offset
>> 2) Classification of opcodes (s.
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> On Friday 19 March 2004 12:07, Leopold Toetsch wrote:
>> 2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done
>> a few - only to see if it get parsed correctly. This needs a lot of work
>> and thought. Any help is much appreciated he
I may have a possible solution. Disclaimer: I do not really understand
continuations, so I may be completely wrong.
This idea involves two assumptions:
1. Most Parrot code will not use continuations except for returning.
(There will be a significant efficiency loss otherwise.)
2. The most ex
jens
Index: t/pmc/pmc.t
===
RCS file: /cvs/public/parrot/t/pmc/pmc.t,v
retrieving revision 1.84
diff -u -r1.84 pmc.t
--- t/pmc/pmc.t 14 Mar 2004 08:49:16 - 1.84
+++ t/pmc/pmc.t 19 Mar 2004 12:20:49 -
@@ -774,7 +774,7 @@
Hi,
On Friday 19 March 2004 12:07, Leopold Toetsch wrote:
> Some weeks ago I posted a proposal for additional hints in ops files. We
> need additionally (at least):
>
> 1) a per argument flag, if this argument is indicating a branch offset
> or address:
>
>inline op bsr (label INT)
>
> "label"
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote:
>>>
>>>Which brings up again my warnocked question: How can return
>>>continuations get reused?
>
>> Works like this. (No pasm, but it should be obvious)
>
> O
Leopold Toetsch wrote:
Some weeks ago I posted a proposal for additional hints in ops files. We
need additionally (at least):
1) a per argument flag, if this argument is indicating a branch offset
2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done
3) A flag, if the opcode s
Mark A Biggar <[EMAIL PROTECTED]> wrote:
> The real problem is that you always want to use exactly the same code for
> ALL cases of string-to-float conversion.
Yep, was outlined by Larry too. That's already changed.
[ Please don't quote the whole thread, thanks ]
leo
Some weeks ago I posted a proposal for additional hints in ops files. We
need additionally (at least):
1) a per argument flag, if this argument is indicating a branch offset
or address:
inline op bsr (label INT)
"label" is basically "in", additionally there are now "labelvar" and
"labelcons
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> the attached test fails. There is no newline at the end of the file.
> I think that imcc is causing a memory leak due to this, I got error messages
> like:
> "store_sub_in_namespace: sub '__new_class' namespace #1082752832 too
> big.namespace"
Must
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Jens Rieks <[EMAIL PROTECTED]> writes:
>> Hi,
>>
>> does the attached test use the Continuation in a correct way?
>> The test failes, what am I doing wrong?
> Without running it I'm guessing that it prints out something like
> 456=789
> 456=456
> 123=123
The real problem is that you always want to use exactly the same code for
ALL cases of string-to-float conversion. The first public example of this
problem was the FORTRAN II compiler from IBM in the 60's. The compiler and
the IO library was written by two different people and so constants in
pro
Leopold Toetsch wrote:
Courtesy of Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Er...that wasn't me--I was just passing it along, as I said in the
message. (If it was me, I'd likely have committed it myself. ;^) )
Credit goes to Matt Fowles <[EMAIL PROTECTED]>.
(Leo, I tried to send this to you
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> this patch changes the calls of parrot to './parrot'. This is needed when
> the current directory is
> not in $PATH.
Thanks, applied.
leo
Jens Rieks <[EMAIL PROTECTED]> wrote:
> the attached test fails. There is no newline at the end of the file.
Imcc is reading text files. A text file has a newline on *each* line.
The error message could be a bit more user friendly, though.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:38 PM +0100 3/18/04, Leopold Toetsch wrote:
>>
>>Which brings up again my warnocked question: How can return
>>continuations get reused?
> Works like this. (No pasm, but it should be obvious)
Ok. First (and that applies to Jens example too), I'd lik
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> >
> > # define Parrot_is_nzero(x) ((x) == copysign(0.0, -1.0))
use that if signbit isn't, patch? applied ;)
Thanks,
leo
35 matches
Mail list logo
