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
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
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 be
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 will be exactly
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
reusing
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 function
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.
It can. You can't
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 we have to
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 objects
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 Ca after the call.
... It seems
that even this function body shows the problem:
Yes, that one is
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
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 Cstruct Parrot_Context then yes, this is what
continuations are
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
[ 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 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
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 numbers
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. I
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 Ca after the call.
Oops.
It seems that, in term of cache
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
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 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 search path
I believe so. I
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
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 find
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, Leif
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 redirection
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 Repository,
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
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32450]
# in the subject line of all future correspondence about this issue.
# URL: 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
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 that. If you keep your
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 could do
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
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
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
-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
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
35 matches
Mail list logo