At 6:23 PM +0100 11/9/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
That goto's bogus and shouldn't work. I think it does right now, but
I'm OK with making it not work -- it *shouldn't*, since in perl the
eval's an anonymous sub, which means you've done a goto out of a sub
I'd like to cleanup eval.pmc and dynamic code compiling a bit. But
before that I'd like to know:
Which granularity do we allow for eval()ed code?
Can that be an expression or statement too or is it always at least an
(anonymous) subroutine?
Does the compiled code see Parrot registers
, and the associated pmcs (eval, compiler, and so on).
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
)
For an interpreter that is allowing eval (or a namespace that isn't locked
against eval) I think that you could only GC the old definition of redefined
subroutines, and any anonymous subroutines that become unreferenced.
Anything else is the potential lucky destination of a random future eval.
Nicholas Clark
it eval.
But: When compile and eval are separate stages, the HL might be able to
pull the compile stage out of e.g. loops. So I think keeping compiling
and evaling separate makes sense.
Thanks for putting this together,
leo
something, then it had darned well better build it and return it.
How does this play with
eval 'sub bar { change_foo(); } BEGIN { bar(); } (...stuff that depends
on foo...)';
? The semantics of BEGIN{} would seem to require that bar be installed
into the symbol table immediately
On Wed, Jan 22, 2003 at 03:00:37PM -0500, Dan Sugalski wrote:
Destinations. These are a pain, since if we can go anywhere then the
JIT has to do all sorts of nasty and unpleasant things to compensate,
and to make every op a valid destination. Yuck.
Arbitrary jumps are not that difficult to
Design Edict #3: All destinations *must* be marked as such in the
bytecode metadata segment. (I am officially nervous about this, as I
can see a number of ways to subvert this for evil)
[...]
Design Edict #4: Dan is officially iffy on jumps, but can see them as
useful for lower-level
ADDRESS(something). These means that every
sub/method/continuation must be marked by #3
Design Edict #6: The first op in a sub is always a valid
jump/branch/control transfer destination
This is the essentally #3
Now. Eval. The compile opcode going in is phenomenally cool (thanks,
Leo!) but has
Jason Gloudon wrote:
On Tue, Jan 21, 2003 at 08:21:42PM +0100, Leopold Toetsch wrote:
# #!/usr/bin/perl -w
# my $i= 5;
# LAB:
#$i++;
#eval(goto LAB if ($i==6));
Ok. Having inter_cs call DO_OP just seems more involved than it has to be.
Yep.
How about a single self-contained
to be hashed out a bit to make them more JIT-friendly, but
they're the primary transfer destination point
Design Edict #6: The first op in a sub is always a valid
jump/branch/control transfer destination
Now. Eval. The compile opcode going in is phenomenally cool (thanks,
Leo!) but has pointed out some
the JAPHers!
Now. Eval. The compile opcode going in is phenomenally cool
(thanks, Leo!) but has pointed out some holes in the semantics. I
got handwavey and, well, it shows. No cookie for me.
The compreg op should compile the passed code in the language that
is indicated and should load that bytecode
On Tue, Jan 21, 2003 at 12:08:29AM +0100, Leopold Toetsch wrote:
Here is a proposal for inter code segment jumps:
The assembler (imcc) can recognize when a branch ins goes to a different
code segment.
For such a branch, imcc generates this opcode seqence:
inter_cs
if i, ic # or
if i, ic # or whatever
Why do we need branches to go to different code segments ?
Because of this nasty piece of little code:
t/syn/eval_3.imc:
# #!/usr/bin/perl -w
# my $i= 5;
# LAB:
#$i++;
#eval(goto LAB if ($i==6));
#print $i\n;
#
# 7
#
.sub _test
I1 = 5
$S0
:
# #!/usr/bin/perl -w
# my $i= 5;
# LAB:
#$i++;
#eval(goto LAB if ($i==6));
Ok. Having inter_cs call DO_OP just seems more involved than it has to be.
How about a single self-contained inter-segment jump instruction.
Since the compiler knows when a branch is non-local it can always break
Leopold Toetsch wrote:
I have it ready.
It's based on the packfile patch #18056 by Juergen Boemmels. On top of
this patch, it was quite easy to implement multiple code segments.
And yet another f'up me.
Here is a proposal for inter code segment jumps:
The assembler (imcc) can recognize when
Leopold Toetsch wrote:
I have it ready.
- code is ready for debug information, I'll first do it in imcc, which
could generate file/line info on the fly. Next would then be to extend
the PBC format.
And this is working too in imcc, including gdb-stepping into evaled code
segments.
Does
# New Ticket Created by Leon Brocard
# Please include the string: [perl #20400]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20400
It's PASM1, not PASM. However, make test in languages/ook/ still
segfaults for me
Leon Brocard (via RT) wrote:
# New Ticket Created by Leon Brocard
# Please include the string: [perl #20400]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20400
It's PASM1, not PASM. However, make test in
Leopold Toetsch sent the following bits through the ether:
No PASM1 is the one-line assembler PDB_compile in debug.c. If you want
the whole thing, you have to run imcc instead of parrot and with the
PASM compiler, just as the comment states.
Oops, I was confused. ook's 'make test' runs with
Leon Brocard wrote:
Leopold Toetsch sent the following bits through the ether:
Oops, I was confused. ook's 'make test' runs with parrot, so it
doesn't work.
Yep, I should have changed that in the first place too ;-)
... I've attached a patch to config/gen/makefiles/ook.in to
make it work
At 6:06 PM + 1/19/03, Leon Brocard wrote:
Leopold Toetsch sent the following bits through the ether:
No PASM1 is the one-line assembler PDB_compile in debug.c. If you want
the whole thing, you have to run imcc instead of parrot and with the
PASM compiler, just as the comment states.
At 7:38 PM +0100 1/19/03, Leopold Toetsch wrote:
IMHO in the near future, the main makefile of parrot should do
something equivalent to:
$ make
$ cd languages/imcc
$ make
$ cd -
$ mv parrot test_main
$ cp languages/imcc/imcc parrot
No--what we should do in the near future is:
$ make
$
Dan Sugalski wrote:
At 7:38 PM +0100 1/19/03, Leopold Toetsch wrote:
IMHO in the near future, the main makefile of parrot should do
something equivalent to:
$ cp languages/imcc/imcc parrot
No--what we should do in the near future is:
$ make
$ make test
and be done with it. imcc
Leopold Toetsch wrote:
So it seems, that for multiple code segments, we'll have to take the
PackFile_ConstTable out of the structure and include
file/line/debug/whatever information. This would look like:
packfile aka interpreter-code:
- constants
- code_segment[]
- byte_code
-
So I did it. Check in the first version of eval.
First of all, I changed pdd06_pasm, the compile and compreg opcodes
didn't fit really well into - well - my scheme of objects.
A compiler is now a Parrot class, derived from NCI, living in
interpreter-Parrot_compreg_hash. This also needed a change
Leopold Toetsch wrote:
So I did it. Check in the first version of eval.
Test status:
make test succeeds, as well as -P, running the eval progs with JIT or
with -t (trace)/-b (bounds) option fails, probably related to messing
with the byte code.
Fixed.
bug in -j was triggered by garbage
Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20315]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20315
Attached is a first try towards eval.
I have
Leopold Toetsch wrote:
1)
The call function to the compiler/assembler is kept as a NCI. Better
would be a subclass of NCI (Compiler.pmc or so), which provides
invoke_keyed(key, next)
Hmm, I don't know what a NCI is. Where (which files) can I find
information about them?
Jerome
--
[EMAIL
towards eval.
- interpreter has a new data member Parrot_compreg_hash
- parrot registers the PASM1 type i.e. what PDB_eval can parse
- the new Bcompile opcode (ab)uses nci to build a function for calling
PDB_eval
- nci is extended (jit/i386 only), to understand an 'I' param as interpreter
In perl.perl6.internals, you wrote:
Leopold Toetsch wrote:
1)
The call function to the compiler/assembler is kept as a NCI. Better
would be a subclass of NCI (Compiler.pmc or so), which provides
invoke_keyed(key, next)
Hmm, I don't know what a NCI is. Where (which files) can I find
--let's try and work that
out while I'm churning over objects.
I did have a closer look at struct PackFile. I think we have some
possiblities to actually eval()/invoke() the code, depending on the HL:
- new interpreter, nothing shared (unlikely)
- new interpreter, context shared - meaning also
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20315]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20315
Attached is a first try towards eval.
- interpreter has a new data member
with p5, Ive often written
eval {} or carp $ blah;
it seems to work, and it reads nicer (to my eye) than
eval {}; if ($) {}
but I surmise that it works cuz the return-value from the block is non-zero,
for successful eval, and 0 or undef when block dies, not cuz of magical
treatment
On Thu, 2 May 2002, Jim Cromie wrote:
with p5, Ive often written
eval {} or carp $ blah;
it seems to work, and it reads nicer (to my eye) than
eval {}; if ($) {}
but I surmise that it works cuz the return-value from the block is non-zero,
for successful eval, and 0 or undef when
On Thu, May 02, 2002 at 02:33:42PM -0600, Jim Cromie wrote:
with p5, Ive often written
eval {} or carp $ blah;
You generally Don't Want To Do That.
If the eval succeeds, but the last statement in the eval happens to come
out as false, then it'll still carp:
$a = 0; eval { 1
At 02:33 PM 5/2/02 -0600, Jim Cromie wrote:
eval {} or carp $ blah;
it seems to work, and it reads nicer (to my eye) than
eval {}; if ($) {}
% perl -le 'eval { print No exceptions here; 0 } or warn $ blah'
No exceptions here
blah at -e line 1.
--
Peter Scott
Pacific Systems Design
Jim Cromie wrote:
with p5, Ive often written
eval {} or carp $ blah;
it seems to work,
modulo any block that returns false :-(
and it reads nicer (to my eye) than
eval {}; if ($) {}
but I surmise that it works cuz the return-value from the block is non-zero,
for successful
David L. Nicol wrote:
eval ${code}o;
Another brilliant idea from David Nicol!
However, I'm not keen on the syntax.
I'd rather see a different keyword. I'm thinking eval1,
but I'm not very creative. :-/
--
John Porter
Science class should not end in tragedy.
David L. Nicol wrote:
eval ${code}o;
Another brilliant idea from David Nicol!
However, I'm not keen on the syntax.
I'd rather see a different keyword. I'm thinking eval1,
but I'm not very creative. :-/
]- what about :
qe//;# qe{};
OR
qo//
On Tue, 7 Aug 2001 09:27:43 -0400, John Porter wrote:
David L. Nicol wrote:
eval ${code}o;
Another brilliant idea from David Nicol!
Not really.
What I would like is an option to just *compile* a piece of perl code,
without executing it. This kinda works:
$coderef = eval sub
the syntax and semantics
of exception handling, so RFC 119 is unaffected.
Bart Lateur wrote:
On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote:
In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is
set to the result of an eval or do. How does this impact exception
hand
On Thu, 15 Feb 2001 10:04:51 -0300, Branden wrote:
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }' to
have the behaviour of not dying and setting $@ ?
The reason for its existence is simple: history
On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote:
In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is
set to the result of an eval or do. How does this impact exception
handling tests on $@ to determine if an exception was thrown, if $@ can
be set by a do
[EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }'
to
have the behaviour of not dying and setting
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote:
[EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE
the
do BLOCK
form. do FILE behaves just like eval() (except it reads its data from a
source file), while do BLOCK doesn't. Neither.
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }' to
have the
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote:
I find a "let's require some extra hoops and red tape" not very-Perl like.
Perl is there for the programmer; not the other way around.
Please read ``Larry's talk in Atlanta about Perl 6'', the text is in
Glenn Linderman wrote:
Tony Olekshy wrote:
Traditionally Perl has had both the "do" and the "eval" block
forms, the latter which traps, the former which doesn't.
In the perl 5 pocket reference 3rd edition page 63, it claims that
$@ is set to the result of an e
John Porter wrote:
There is no try, there is only do. :-)
Nonsense.
Traditionally Perl has had both the "do" and the "eval" block
forms, the latter which traps, the former which doesn't.
"try" is just a slightly souped-up "eval" that better handl
Greg Williams wrote:
as I remember, the Cno scope; pragma, when used, would simply act as if the
enclosing scope were not in place, enabling such things as:
if ($ints) {
no scope;
use integer;
}
Hmm. Cno scope could be implemented in terms of the rfc 340 Cwith like
so:
At 18:43 -0500 2000/10/02, David L. Nicol wrote:
Hmm. Cno scope could be implemented in terms of the rfc 340 Cwith like
so:
$scope_out_here = with;
if ($ints) {
with $scope_out_here {use integer}
};
Ccaller is about subroutine calls.
Interesting! I have a few questions
On Fri, Sep 29, 2000 at 09:47:00PM -, Perl6 RFC Librarian wrote:
Classic eval:
eval {}
eval ""
Unscoped eval
+eval {}
+eval ""
I like the general idea of this RFC, but the proposed syntax is less than
desirable. What happens with the following?
$res
caller-eval EXPRESSION;
That's mad, bad, scary and dangerous. Let's do it.
Yes, this is cool. In fact, I'm writing Regexp::Func right now as a
prototype for RFC 164 and discovering I could really use this - in fact,
need it.
A couple things:
1. Implement this eval as UNIVERSAL
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
caller-eval BLOCK
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 339
Version: 1
Status: Developing
=head1 ABSTRACT
Ccaller
On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote:
The perl 5 - perl 6 translator should replace calls to 'eval' with
calls to 'perl5_eval', which will recursively call the 5-6 translator
to translate the eval'ed string into perl 6, and will then eval the
result.
Blech, no. eval
On Fri, 15 Sep 2000, Bart Lateur wrote:
On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote:
The perl 5 - perl 6 translator should [recursively handle eval]
Blech, no. eval should stay eval. People are responsible for generating
Perl6 compatible code, if they construct code
eval should stay eval.
Yes, and this is the way to do that.
When you translate a script, the translator should translate things so
that they have the same meanings as they did before. If it doesn't
also translate eval, then your Perl 5 scripts will be using the Perl 6
eval, which isn't
On Fri, 15 Sep 2000 12:01:55 -0400, Mark-Jason Dominus wrote:
When you translate a script, the translator should translate things so
that they have the same meanings as they did before. If it doesn't
also translate eval, then your Perl 5 scripts will be using the Perl 6
eval, which isn't what
My statement: this shouldn't be the programmer's responsibility. If
you're using other people's modules that depend on eval, you're in
trouble anyway. The "local $SIG{__DIE__};" statement should be implicit
at the start of the eval block.
Why wouldn't you want to just get rid of
Why wouldn't you want to just get rid of the whole construct? Is there any
need for it?
It seems safer to kill it.
--tom
201 - 261 of 261 matches
Mail list logo
