Doesn't compile. Its seems to be the #ifdef vs #if issue.
Seems. I've fixed it. Try to compile the patch one more time,
please.
prefixing.diff
Description: Binary data
Benjamin Goldberg [EMAIL PROTECTED] writes:
There's no way, in this program, for $x to be out of scope while $y is
in scope.
But we're in Perl6(66)-land, where delete caller.MY{'$x'} and
delete %OUTER::x (sp?) can wreak havoc on your pad from all
sorts of strange places. It ain't moral, but it
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Maybe. But, what happens with:
x = 1
y = lambda: x
del x
z = y()
Does/should this also throw a NameError?
Yep. It throws a NameError. So deleting from the lex pad is ok.
leo
Sean O'Rourke [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
A keyed add vtable doesn't help to provide more semantics. The set vs
assign thread applies here too. On the contrary: to provide all
semantics you would need add_set_p_k_p_k_p_k and add_assign_p_k_p_k_p_k
and
hello,
After reading most of the messages on timely destruction, I still don't quite
understand what it is. If someone has a spare minute free, could you please explain?
Thanks in advance!
Klaas-Jan
Is load_bytecode supposed to provide do semantics (reload the packfile
every time the op is executed) or require semantics (load the packfile
only if it hasn't been loaded already)? I think the only distinction
at the moment would be whether the extra time of rereading the file is
performed.
# New Ticket Created by Kenneth A Graves
# Please include the string: [perl #23355]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23355
As mentioned in another thread, I've found a couple of cases where
parrot loses
On Mon, Aug 18, 2003 at 10:52:50AM -0700, K Stol wrote:
After reading most of the messages on timely destruction, I still don't quite
understand what it is. If someone has a spare minute free, could you please explain?
In perl5 you can write this.
my $Destroyed = 0;
sub DESTROY { $Destroyed
- Original Message -
From: Michael G Schwern [EMAIL PROTECTED]
To: K Stol [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, August 18, 2003 2:04 AM
Subject: Re: What the heck is: timely destruction
On Mon, Aug 18, 2003 at 10:52:50AM -0700, K Stol wrote:
After reading most of the
Vladimir Lipskiy wrote:
Doesn't compile. Its seems to be the #ifdef vs #if issue.
Seems. I've fixed it. Try to compile the patch one more time,
please.
Compiles now but:
$ make test
...
# got: 'Computed goto unavailable in this configuration.
# '
leo
- Original Message -
From: Michael G Schwern [EMAIL PROTECTED]
To: K Stol [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, August 18, 2003 2:49 AM
Subject: Re: What the heck is: timely destruction
On Mon, Aug 18, 2003 at 11:38:22AM -0700, K Stol wrote:
if I understood correctly,
- Original Message -
From: Elizabeth Mattijsen [EMAIL PROTECTED]
To: K Stol [EMAIL PROTECTED]; Michael G Schwern [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, August 18, 2003 3:10 AM
Subject: Re: What the heck is: timely destruction
At 11:56 -0700 8/18/03, K Stol wrote:
Uhm, I
On Mon, Aug 18, 2003 at 11:38:22AM -0700, K Stol wrote:
if I understood correctly, the problem is that some objects should be
destroyed *immediately*, and should not wait for the GC.
Yep. In perl 5 *all* objects and variables are to be destroyed immediately.
This doesn't necessarily mean that
On Mon, Aug 18, 2003 at 11:56:53AM -0700, K Stol wrote:
This doesn't necessarily mean that their memory has to be freed but that
at least their destructor methods are called.
So the objects may be still in memory. I thought the fact that they are
still in memory
was troublesome, but it's
At 11:56 -0700 8/18/03, K Stol wrote:
Uhm, I didn't realize destructor methods were called, but now I see that's
the whole point:
destructor methods should be called when doing timely destruction.
You already said just now:
This doesn't necessarily mean that their memory has to be freed but that
Ron Blaschke [EMAIL PROTECTED] wrote:
The attached patch replaces /Gf with /GF for compiler versions = 13.
Applied, thanks.
leo
Kenneth Graves [EMAIL PROTECTED] wrote:
Is load_bytecode supposed to provide do semantics (reload the packfile
every time the op is executed) or require semantics (load the packfile
only if it hasn't been loaded already)?
It loads the file on each execution of the opcode. But it should really
Lars Balker Rasmussen [EMAIL PROTECTED] wrote:
t/syn/file.t relies on . being in path (in the 3 system(imcc...)
I've prepended a .$PConfig{slash}, thanks.
leo
Kenneth A Graves [EMAIL PROTECTED] wrote:
Tests demonstrating both failures attached (as a patch to
languages/imcc/t/syn/file.t).
Applied, though SKIPping these tests until the semantics of multiple
loading are speced.
The second one is failing due to either double or no fixup, I'll have a
Leopold Toetsch [EMAIL PROTECTED] writes:
With this patch, the major pieces are finished
...
load_bytecode temp.imc
$P0 = global _sub2
.pcc_begin prototyped
.pcc_call $P0
does what it look's like: call the Sub _sub2 in the loaded sorce file.
Cload_bytecode source_file
2003-08-18T13:52:50 K Stol:
After reading most of the messages on timely destruction, I still
don't quite understand what it is. If someone has a spare minute
free, could you please explain?
The other explanations certainly have formality to commend them, but
somehow they didn't make clear to
Michal Wallace [EMAIL PROTECTED] wrote:
It seems that exception handlers get tied to
subroutines when they're created, not when
they're actually used. For example:
## this works:
try:
f = make_function()
f.die() # raise some error
except:
pass
On Mon, 18 Aug 2003, Leopold Toetsch wrote:
Or coroutines shouldn't swap the control stack - I don't know.
They should, sort of.
Coroutines are a pain, but what they have to do is keep track of both the
top *and* bottom of their saved stacks. When a coroutine with active state
is invoked, it
Piers Cawley [EMAIL PROTECTED] wrote:
Cload_bytecode source_file
Does this handle function serialization as well?
Do you mean loading a source or PBC file and spit out bytecode per
subroutine or for one specific subroutine? If so: No - not yet. The Eval
PMC can return a whole packfile via
Dan Sugalski [EMAIL PROTECTED] wrote:
On Mon, 18 Aug 2003, Leopold Toetsch wrote:
Or coroutines shouldn't swap the control stack - I don't know.
They should, sort of.
Coroutines are a pain, but what they have to do is keep track of both the
top *and* bottom of their saved stacks. When a
Hi,
I've noticed that you still can't sleep for fractional time in Parrot -
perhaps not the most critical feature in the world :), I still think
it's a 'nice to have'. I submitted a patch for this last year, which
was on the road to acceptance:
http://archive.develooper.com/[EMAIL
On Monday, August 18, 2003, at 03:50 AM, Leopold Toetsch wrote:
Applied, though SKIPping these tests until the semantics of multiple
loading are speced.
TODO would be better, but it would require patching TestCompiler. Want
it?
-- c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 18 August 2003 10:29 am, Piers Cawley wrote:
Packfile fun
So long assemble.pl, it's been good to know you.
http://xrl.us/puu
Google gives me an error on this:
Unable to find thread. Please recheck the URL.
-BEGIN PGP
Michael G Schwern wrote:
[snip stuff, including a mention of refcounting and it's
(dis)advantages]
So Parrot is going with something else. Don't ask me what it is, I
don't know.
Parrot will do it like Java -- a mark-and-sweep garbage collector --
with the difference that garbage collection
There are a number of shortcomings in the API, which I'd like to address
here, and propose improvments for.
Not so much the string_* functions, but rather with how they work (the
encoding API, the transcoding functions).
To allow user-defined encodings, and user-defined transcoding, (written
in
Steve Fink wrote:
In light of the insane amount of work that's gone into Parrot
recently, I'd say it's about time to cut another release. What else
would people like to slip in? This is not a freeze announcement yet --
I want to know what people think of the state of things they're
working
Perl 6 Summary for the week ending 20030817
Picture, if you will, a sunny garden unaffected by power cuts, floods,
plagues of frog or any of the other troubles that assail us in this
modern world. Picture, if you will, your summarizer sat in this garden
with a laptop on his knee,
Piers,
Regarding your Perl6 Essentials summary:
Or, he can write code for IMCC using Parrot Intermediate Language (known
as PIR for reasons that aren't entirely clear even to one who has been
watching the mailing list since the Parrot project started)
I suppose noone has much read the README
MS == Melvin Smith [EMAIL PROTECTED] writes:
MS I suppose I could have provided some more explanation (I haven't
MS read the book yet) but as the original author of IMCC PIR, I
MS wasn't even contacted out of courtesy to write the chapter and was
MS informed after the book was finished.
Robin Berjon [EMAIL PROTECTED] writes:
Uri Guttman wrote:
MS == Melvin Smith [EMAIL PROTECTED] writes:
MS This has been a major stumbling block for me in getting back
the MS motivation to help with Parrot again.
so if that helps salve your wound, i am sure you contributions (past
and
Uri Guttman wrote:
MS == Melvin Smith [EMAIL PROTECTED] writes:
MS This has been a major stumbling block for me in getting back the
MS motivation to help with Parrot again.
so if that helps salve your wound, i am sure you contributions (past and
future) to parrot are welcomed and appreciated
36 matches
Mail list logo
