Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18106]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18106 >
I think I triggered a bug somewhere in the GC-code bu
Dan Sugalski:
# =item Add source code to segment
#
# This adds a line or more of source code to the bytecode segment.
Optional?
# =item Add AST to segment
#
# This adds the AST for some of the source code to the bytecode segment.
Optional?
# =item Add line number information
#
# This adds li
chromatic:
# On Sun, 27 Oct 2002 08:54:08 -0800, Dan Sugalski wrote:
#
# These two seem highly similar:
#
# > =item Add source code to segment
# >
# > This adds a line or more of source code to the bytecode segment.
#
# > =item Add line number information
# >
# > This adds line number info t
Dan Sugalski wrote on 10/27/02 8.11:
I tried very hard to make sure that there was always a valid
interpreter.
--
When I was working on switching most fprintf calls to PIO, there were so
many functions that didn't take an interpreter that I eventually made
PIO_printf and PIO_eprintf (output to std
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18106]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18106 >
I think I triggered a bug somewhere in the GC-code but I failed to
find it. When doing
On Sun, 27 Oct 2002 08:54:08 -0800, Dan Sugalski wrote:
These two seem highly similar:
> =item Add source code to segment
>
> This adds a line or more of source code to the bytecode segment.
> =item Add line number information
>
> This adds line number info to the bytecode segment, allowing
At 6:34 PM + 10/27/02, Nicholas Clark wrote:
On Sun, Oct 27, 2002 at 11:54:08AM -0500, Dan Sugalski wrote:
The bytecode segments can hold more than just bytecode. They can also
hold the source that corresponds to the generated bytecode, the AST
for the source that corresponds to the genera
At 10:26 AM -0800 10/27/02, Ramesh Ananthakrishnan wrote:
Is there any scheme on to run Native Binaries on
Parrot. In a sort of sandbox. So that you can run
cross platform binaries on it.
Nope, no plan for that. Bytecode's pretty much it for cross-platform
compatibility.
--
On Sun, Oct 27, 2002 at 11:54:08AM -0500, Dan Sugalski wrote:
> The bytecode segments can hold more than just bytecode. They can also
> hold the source that corresponds to the generated bytecode, the AST
> for the source that corresponds to the generated bytecode, the line
> number information for
When looking at the inner loop of mops.pasm by far the most time is used
for accessing the parrot registers.
Some results (-O3 compiled except run_ops_cg.c, Athlon 800, i386/linux):
CVS »micro_ops«
-g (fast_core) 24 117
cgoto_core:
19
205
-j (JIT) 782
So I hacked together a modified core.op
Is there any scheme on to run Native Binaries on
Parrot. In a sort of sandbox. So that you can run
cross platform binaries on it.
Just a thought
cheers,
Ramesh
__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webh
Okay, here's a partial PDD on internal bytecode generation. This is
*very* sketchy--at the moment it's just an enumeration of the
functionality we'll need,as I see it.
Take a look at this, and see where things might be missing or
unclear. Once we've hashed out the desired functionality, I'll ro
At 3:16 PM + 10/27/02, Nicholas Clark wrote:
On Sat, Oct 26, 2002 at 03:17:56PM -0400, Dan Sugalski wrote:
Please note that we're seriously considering moving to either a BSD
??
curious - this is the first I've been aware of this idea, so I wonder who
the "we" is. Or wha
At 1:05 PM +0100 10/27/02, Leopold Toetsch wrote:
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels # Please include the
string: [perl #18097]
# in the subject line of all future correspondence about this
issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18097 >
Than
On Sat, Oct 26, 2002 at 03:17:56PM -0400, Dan Sugalski wrote:
> Please note that we're seriously considering moving to either a BSD
??
curious - this is the first I've been aware of this idea, so I wonder who
the "we" is. Or what the cause for the formal change is?
["formal" b
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18097]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18097 >
Thanks applied.
Though, /me thinks, that we should al
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18098]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18098 >
Thanks, applied.
leo
Leopold Toetsch wrote:
During chasing the GC bugs one of my patches turned off DOD/GC in
string_transcode (which is called from e.g string_compare).
There is no need to keep this as the GC issues seem to be solved now.
I did apply this during #18097.
So the current behaviour matches at least
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
`PackFile_unpack: Bytecode not valid for this interpreter: version mismatch'
Ah, this one. s. "[perl #18072] [PATCH] fingerprinting the PBC" and an
early thread with the keyowrd "fingerprinting". Also mentioned in the
thread
19 matches
Mail list logo
