On Fri, Jan 16, 2004 at 09:27:57AM -0500, Dan Sugalski wrote:
With perl, for example, it's distinctly possible that this:
our $foo; # It's a global
$foo = 12;
if ($foo 10) {
print $foo;
}
will require fetching $foo's PMC out of the global namespace three
times, once for
Jeff Clites [EMAIL PROTECTED] wrote:
Where in the stream would we patch? If not in a loop, you may never hit
the single patched location again, but still might not end for a very
long time
Same as with prederefed run cores: backward branches, invoke*
If we are patching all locations
Damien Neil [EMAIL PROTECTED] wrote:
The JVM is a stack machine. JVM opcodes operate on the stack, not on
main memory. The stack is thread-local. In order for a thread to operate
on a variable, therefore, it must first copy it from main store to thread-
local store (the stack).
Silly me,
Gordon Henriksen [EMAIL PROTECTED] wrote:
Other threads than the target could be executing the same chunk
of JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are converted to absolute memory locations.
leo
Jonathan Worthington [EMAIL PROTECTED] wrote:
The attached patch fixes a problem in imcc/TestCompiler.pm which was causing
all imcpasm tests to fail on Win32.
Applied, as well as the icu.pl patch.
[ Please provide patches relative to parrot root to simplify applying ]
Jonathan
Thanks,
leo
On Fri, 16 Jan 2004 08:09:58 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
I don't know, if we should depend on that, but it would definitely help.
Could some Windows guys have a look at:
http://www.microsoft.com/windows/sfu/
cite
[Interoperability. Integration. Extensibility.]
Chromatic [EMAIL PROTECTED] wrote:
This gets further. Now it's imcc/t/syn/macro, around tests 13 and 14:
Good.
#3 0x0fd0a694 in exit () from /lib/libc.so.6
I've converted this exit() to Parrot_exit() now. If that helps, I'll
change a bunch of other such code too.
leo
Matt Fowles [EMAIL PROTECTED] wrote:
This patch is similar in concept to the first one I sent; however, it is
based off of the new register.c.
Thanks, applied.
I did not fix the manifest because I don't know how. So that needs to
be done.
Its just inserting the filename in MANIFEST -
At 09:27 -0500 1/16/04, Dan Sugalski wrote:
To some extent, yes. I just had a really nasty thought, and I think
the compiler writers need to get Official Rulings on behavior.
With perl, for example, it's distinctly possible that this:
our $foo; # It's a global
$foo = 12;
if ($foo 10) {
Melvin Smith [EMAIL PROTECTED] wrote:
cvs checkout -r imcc1final parrot
I don't know, if this is related, but I get now errors on commit:
cvs server: sticky tag `HEAD' for file `classes/timer.pmc' is not a branch
I did commit some patches an hour before which worked fine. Now I
suddenly get a
# New Ticket Created by Mattia Barbon
# Please include the string: [perl #24930]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24930
Hello,
with this patch calling Parrot_redabc(interp, foo) does not
warn anymore.
# New Ticket Created by Mattia Barbon
# Please include the string: [perl #24931]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24931
Hello,
the important part is the change to config/init/hints/mswin32.pl,
without
cvs server: sticky tag `HEAD' for file `classes/timer.pmc' is
not a branch
do
$ cvs update -A classes/timer.pmc
to remove the sticky tag and try committing again.
The sticky tag gets set when cvs checkout/update is done with
the -r option.
leo
HTH,
arvindh.
This e-mail and any files
On Saturday, January 17, 2004, at 05:53 , Leopold Toetsch wrote:
Gordon Henriksen [EMAIL PROTECTED] wrote:
Other threads than the target could be executing the same chunk of
JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
addresses are
On Saturday, January 17, 2004, at 05:51 , Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
... Also, once the handler is entered we'd have to fix all of patched
locations, which again could be time-consuming for large bytecode.
Please remember: only the current code segment has to be
On Friday, January 16, 2004, at 03:34 , Seiler Thomas wrote:
inet_pton has not yet been implemented in cygwin, but it is being
worked on...
http://win6.jp/Cygwin/
Indeed, but I think there might be other unix-like environments that
(do not yet|will never) provide the inet_pton function.
Mac OS
[EMAIL PROTECTED] (Dave Mitchell) writes:
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole
On Sat, Jan 17, 2004 at 04:58:25PM +, Simon Cozens wrote:
[EMAIL PROTECTED] (Dave Mitchell) writes:
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out
Gordon Henriksen [EMAIL PROTECTED] wrote:
What if control leaves the current code segment before you finish=20
patching it? If an event is being delivered from another thread, this is=20=
Ops, that can leave the code segment have to explicitely check for
events.
Gordon Henriksen
leo
Arvindh Rajesh Tamilmani [EMAIL PROTECTED] wrote:
do
$ cvs update -A classes/timer.pmc
to remove the sticky tag and try committing again.
Ah, yes thanks, that worked.
HTH,
arvindh.
leo
Mattia Barbon [EMAIL PROTECTED] wrote:
with this patch calling Parrot_redabc(interp, foo) does not
warn anymore.
Thanks, applied
Mattia
leo
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Gordon Henriksen [EMAIL PROTECTED] wrote:
What if control leaves the current code segment before you finish
patching it?
Ops that can leave the code segment have to explicitely check for
events.
Then no need to patch invoke*.
If
Leopold Toetsch wrote:
Jonathan Worthington [EMAIL PROTECTED] wrote:
The attached patch fixes a problem in imcc/TestCompiler.pm which was causing
all imcpasm tests to fail on Win32.
Applied, as well as the icu.pl patch.
[ Please provide patches relative to parrot root to simplify applying ]
On Sat, 2004-01-17 at 04:29, Leopold Toetsch wrote:
I've converted this exit() to Parrot_exit() now. If that helps, I'll
change a bunch of other such code too.
Yep, that fixed. Now there are hangs in some of the t/src files. Right
now, it's t/src/sprintf.t at test 2. The backtrace looks
On Jan 17, 2004, at 2:58 AM, Leopold Toetsch wrote:
Damien Neil [EMAIL PROTECTED] wrote:
The JVM is a stack machine. JVM opcodes operate on the stack, not on
main memory. The stack is thread-local. In order for a thread to
operate
on a variable, therefore, it must first copy it from main
On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
Where in the stream would we patch? If not in a loop, you may never
hit
the single patched location again, but still might not end for a very
long time
Same as with prederefed run cores: backward
26 matches
Mail list logo
