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 branc
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 st
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 fa
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 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*.
I
Mattia Barbon <[EMAIL PROTECTED]> wrote:
> with this patch calling Parrot_redabc(interp, "foo") does not
> warn anymore.
Thanks, applied
> Mattia
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
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
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 ou
[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 wh
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 X
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 b
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 conver
>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 fi
# New Ticket Created by Mattia Barbon
# Please include the string: [perl #24931]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24931 >
Hello,
the important part is the change to config/init/hints/mswin32.pl,
without whic
# New Ticket Created by Mattia Barbon
# Please include the string: [perl #24930]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24930 >
Hello,
with this patch calling Parrot_redabc(interp, "foo") does not
warn anymore.
R
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
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) {
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 -
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/
>
>
> [Interoperability. Integration. Extensibility.]
> Wind
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,
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
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
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 location
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,
26 matches
Mail list logo
