Adam Warner <[EMAIL PROTECTED]> wrote:
> I've taken a first look at Parrot and I'm very impressed. I'd like to
> perform some micro-benchmarking of double floating point code. I have the
> latest CVS version of parrot. I've compiled it upon Debian unstable x86
> with the:
>
>perl Configure.pl
> -Original Message-
> From: Matt Fowles [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 15, 2004 11:27 PM
> To: [EMAIL PROTECTED]; Perl 6 Internals List; perl6-
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Perl 6 Summary for 2004-11-08 through 2004-11-15
>
> Perl 6 Summary for 2
Perl 6 Summary for 2004-11-08 through 2004-11-15
All~
Welcome to yet another Monday summary. This would have been a Sunday
summary, but Avernum (from Spiderweb Software) forcibly prevented it. As
usual, we will start out with Perl 6 Language.
Perl 6 Language
modules and expor
Hi all,
I've taken a first look at Parrot and I'm very impressed. I'd like to
perform some micro-benchmarking of double floating point code. I have the
latest CVS version of parrot. I've compiled it upon Debian unstable x86
with the:
perl Configure.pl --floatval=double
option. Yet the Leibniz
Here's a simple report of new/open tickets from RT.
It's generated using the RT command line tool Robert just pointed me at (plus
some perl scripts)
Feedback about what's useful, not, and missing is appreciated.
Once we have a decent idea of what sort of report will be useful, Robert can
generate
On Mon, 15 Nov 2004 17:19:01 -0500, Matt Fowles <[EMAIL PROTECTED]> wrote:
> Which gives me an evil idea. We could allow bytecode to specify that
> it wanted to start taking full continuations everywhere, but that
> these would never be used below it on the callstack. Thus the regex
> engine coul
Leo~
On Mon, 15 Nov 2004 20:30:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
>
> > Leo~
> >
> > On Mon, 15 Nov 2004 17:36:20 +0100, Leopold Toetsch <[EMAIL PROTECTED]>
> > wrote:
> >
> >>Matt Fowles wrote:
> >>
> >>
> >>>I do mean context + registers and it can do
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32450]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32450 >
Hi,
since a couple of days the example japh16 is dumping core on my Linux
ma
Clinton,
William Coleda has updated Parrot BASIC enough to get
wumpus and screen working, albeit not entirely
cleanly. In IRC, it was mentioned by Dan that we
should be automating some BASIC tests as part of the
test suite. We were wondering what your thoughts on
it were and if you plan on contin
On Sun, Nov 14, 2004 at 12:42:14PM -0800, Jim Keenan wrote:
> Installing and using Devel::Cover on Win32 for the
> first time today, I noticed several things and would
> like to know if my experience is anomalous.
>
> 1. Since I don't have a C-compiler, I first went to
> ActiveState's PPM Reposi
On Mon, Nov 15, 2004 at 08:40:00PM +0200, Gabor Szabo wrote:
> I have a script using Term::ReadLine to get input.
> I'd like to test it by executing it using another script
> and providing answers from the script test script.
> I tried IPC::Run with no success but as I notice even simple redirectio
On Sat, Nov 13, 2004 at 12:33:01PM +1100, Leif Eriksen wrote:
> First, thanx so very much for responding so quickly...
That was just to make up for the short delay here, and the much longer
delay to your last mail to me ;-)
> Paul Johnson wrote:
>
> >On Sat, Nov 13, 2004 at 12:46:16AM +1100, Le
Jeff Clites <[EMAIL PROTECTED]> wrote:
> Picture this call stack:
> main --> A --> B --> C --> D --> E
> The call from D to E uses the "RESUMEABLE" label, and E stores the
> resulting continuation in a global, and everything up to main returns.
> Then, main invokes the continuation, and we
I have a script using Term::ReadLine to get input.
I'd like to test it by executing it using another script
and providing answers from the script test script.
I tried IPC::Run with no success but as I notice even simple redirection
such as
input.pl < in.txt
does not work.
Any ideas how to au
On Nov-10, Will Coleda via RT wrote:
> This is now obsolete, neh?
>
> > > I hack round this with
> > >
> > > $ cp dynclasses/foo.dump .
> >
> > Alternativley, change line 609 of pmc2c2.pl to read
> >
> > unshift @include, ".", "$FindBin::Bin/..", $FindBin::Bin;
> >
> > adding "." to searc
At 9:16 AM -0800 11/15/04, Larry Wall wrote:
On Mon, Nov 15, 2004 at 09:51:58AM +0100, Leopold Toetsch wrote:
: Yes, as said I'm fine too with that. Perl/Python will do that anyway.
: But what about other languages? Are we forcing these to be as dynamic as
: the primary HLL targets?
In Perl 6, any
On Mon, Nov 15, 2004 at 09:51:58AM +0100, Leopold Toetsch wrote:
: Yes, as said I'm fine too with that. Perl/Python will do that anyway.
: But what about other languages? Are we forcing these to be as dynamic as
: the primary HLL targets?
In Perl 6, any assumptions that cause inefficiency should b
On Nov 15, 2004, at 3:27 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Yes, but Jeff's example wasn't really reflecting the problem.
How come?
Your code didn't reuse C after the call.
Oops.
It seems that, in term of cache loc
At 5:32 PM +0100 11/15/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:08 PM +0100 11/15/04, Leopold Toetsch wrote:
>>Anyway: are there already numbers from the big evil subs?
I'd love to see 'em. (Or if you're asking if I've applied this and
tried it, the answer's no.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:08 PM +0100 11/15/04, Leopold Toetsch wrote:
>>The old allocator took three colors.
> Sweet.
To be precise, it used 3 colors with the pre-allocation hack turned on
that colored temps. W/o that it also used 2 colors.
>>Anyway: are there already numb
At 4:08 PM +0100 11/15/04, Leopold Toetsch wrote:
[ x4.patch ]
The register allocator seems to do a great jub. It does e.g. color a
diamond-like interference graph correctly with two colors only:
x
/ \
w z
\ /
y
(the lines denote an i
[ x4.patch ]
The register allocator seems to do a great jub. It does e.g. color a
diamond-like interference graph correctly with two colors only:
x
/ \
w z
\ /
y
(the lines denote an interference - BTW you might create some PIR could
At 12:57 PM +0100 11/15/04, Leopold Toetsch wrote:
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
I was just browsing the Parrot source, and noticed that the threading
implementation is a bit Unix/pthread-centric. For example:
* COND_WAIT takes a mutex because that's how pthreads works, but Win32
co
Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> ... When a full continuation is invoked it
> *copies* its contenxt into place (thus it can be invoked multiple
> times and it will always have its original context).
If you mean by "context" C then yes, this is what
continuations are doing. But the
All~
I think I may know a way around this problem. You will have to bear
with me for a moment as I am not entirely used to speaking in terms of
continuations (I find a similar difficulty in speaking about Math, but
at least I have a commonly accepted lexicon for that ;-).
The view from 10,000 fe
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
>> Yes, but Jeff's example wasn't really reflecting the problem.
> How come?
Your code didn't reuse C after the call.
> ... It seems
> that even this function body shows the problem:
Yes, that one is r
Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> I was just browsing the Parrot source, and noticed that the threading
> implementation is a bit Unix/pthread-centric. For example:
> * COND_WAIT takes a mutex because that's how pthreads works, but Win32
> condition variables (called "events") are kernel
Bill Coffman <[EMAIL PROTECTED]> wrote:
> On Sun, 14 Nov 2004 17:03:33 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> We don't really have that much of a problem. What we have is just
>> something more simple -- the target of a continuation marks the start
>> of a basic block. That means that w
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Jeff Clites writes:
>> a = 1
>> foo()
>> print a
>> b = 10
>> return b
>>
>> It would seem (w/o continuations) that b should be able to re-use a's
>> register, but if it does then we'll print 10 instead of 1 "the second
>> time".
>
Bill Coffman <[EMAIL PROTECTED]> wrote:
[ pdd03 ]
> The way I read it, paragraph one implies that when you print P5 after
> calling foo(), you are expecting to get the return value. You didn't
> save and restore register P5, so you wanted foo() to do something to
> it.
The nasty thing of a func
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:53 PM +0100 11/13/04, Leopold Toetsch wrote:
>>As the analysis of test errors of the new reigster allocator has
>>shown, we have a problem WRT register allocation. This problem isn't
>>new, but as the allocator is more efficiently reusing registers (or
Jeff Clites writes:
> On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
>
> >Matt Fowles <[EMAIL PROTECTED]> wrote:
> >
> >>Yes, but in the case of the continuation resuming after foo, the
> >>continuation should restore the frame to the point where it was taken.
> >> Thus all of the registers w
I was just browsing the Parrot source, and noticed that the threading
implementation is a bit Unix/pthread-centric. For example:
* COND_WAIT takes a mutex because that's how pthreads works, but Win32
condition variables (called "events") are kernel objects that do not
require any other object to b
Installing and using Devel::Cover on Win32 for the
first time today, I noticed several things and would
like to know if my experience is anomalous.
1. Since I don't have a C-compiler, I first went to
ActiveState's PPM Repository, but Devel::Cover's
latest version (0.50) is listed as a FAIL on Win
On Nov 14, 2004, at 3:03 AM, Leopold Toetsch wrote:
Matt Fowles <[EMAIL PROTECTED]> wrote:
Yes, but in the case of the continuation resuming after foo, the
continuation should restore the frame to the point where it was taken.
Thus all of the registers will be exactly as they were when the
continu
35 matches
Mail list logo