On Sat, 26 Oct 2002, Leopold Toetsch wrote:
I committed a new multiarray.pmc, now based on list.c. It's not totally
finished yet (the clone codes needs some polishing to call the init_pmc
method) and needs a lot more tests.
But I hate failing tests ...
leo
Well done Leo you beat
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18139]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18139
Found yet another bug in sprintf: The code insists on prepending at
least one
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote:
Dan Sugalski wrote:
I'm currently leaning against it only because it doesn't ultimately help
the JIT. What we have now is wildly cool and damn useful (and has anyone
heard from Daniel lately, BTW?) but there's room for more
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #18141]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18141
due to a bug in config/auto/stackdir.pl, Configure.pl
was unable to determine
Josef Hook wrote:
Well done Leo you beat me to it, :-) i got finished last weekend with my
version of marray with underlying list.
If I had known, that i will rewrite it, I'd dropped a note - sorry for
work duplication. But it took an hour or so and I thought, just commit
early so that
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #18142]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18142
Attached is a (big) patch that implements Parrot_destroy.
Test results with
Dan Sugalski [EMAIL PROTECTED] writes:
Well, on thinking a bit about this, there's no reason that we have to
worry--it's perfectly OK for us to declare, unconditionally, that
segment 0 is always bytecode, 1 line number info, and so on, with
everything after position X (for some value of X)
Nicholas Clark wrote:
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote:
But then you end up with a messier two level register spillage problem at
compile time, don't you?
Yes.
...Which values to spill from fast to slow registers,
and which values to spill further from slow
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18144]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18144
In order to do some debugging with PackFiles I had resurrected
pdump. It now uses
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18139]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18139
Thanks, applied
leo
Dan Wrote,
This came up a while back in regards to GCC. Someone was working on a
front (or back, I don't recall) end to gcc to dump out the internal
representation of source as XML for some damn thing or other.
I am working on something like that, there are 2-3 other similar
projects. I am
On Mon, 28 Oct 2002, Josh Wilmes wrote:
If patch [perl #18127] goes in, we can dodge this bullet a while longer :)
Agreed. But since we can't dodge it forever, this seemed as good a place
to try it as any. (Particularly if your patch goes in, then I can't
possibly break anything :-).
--
Andy Dougherty wrote:
but I'm unsure what to put for link_exe_out for each of the three
compilers mentioned in config/init/hints/mswin32.pl, nor for the
compilers used under OS/2 and VMS.
config/init/hints/mswin32.pl already defines what you need. is called
'ld_out' (also see my recent patch
On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote:
+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr +
PARROT_PTR_ALIGNMENT)
When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped
during stack scanning by incrementing cur_var_ptr by sizeof(size_t) *
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18144]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18144
Thanks, applied - with little modifications.
On Tue, 29 Oct 2002, Aldo Calpini wrote:
Andy Dougherty wrote:
but I'm unsure what to put for link_exe_out for each of the three
compilers mentioned in config/init/hints/mswin32.pl, nor for the
compilers used under OS/2 and VMS.
config/init/hints/mswin32.pl already defines what you
Matthew Zimmerman (via RT) wrote:
# New Ticket Created by Matthew Zimmerman
# Please include the string: [perl #18131]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18131
Thanks applied + printing of fingerprint.
Jason Gloudon wrote:
On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote:
+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr +
PARROT_PTR_ALIGNMENT)
When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped
during stack scanning by incrementing cur_var_ptr by
At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote:
Jason Gloudon wrote:
On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote:
+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr +
PARROT_PTR_ALIGNMENT)
When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are
skipped
At 8:40 AM -0800 10/28/02, chromatic wrote:
On Sunday 27 October 2002 23:27, Brent Dax wrote:
Appearances are deceiving--the first adds some (unparsed?) source code,
the second adds information on file and line numbers, probably based on
offset into the bytecode.
Similar in terms of
Jason Gloudon wrote:
ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips
exactly PARROT_PTR_ALIGNMENT bytes.
I did modify your patch slightly
- reversed directions (top-down is probably more common)
- increment by sizeof(void*)
This boost life.pasm gens from 270 -
Dan Sugalski wrote:
At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote:
... Can we really
have e.g. odd aligned PMCs on stack? I don't think so. Or am I still
missing something?
There was some indication back when this was first implemented that the
i386, at least when running windows, could
At 4:57 PM +0100 10/29/02, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote:
... Can we really
have e.g. odd aligned PMCs on stack? I don't think so. Or am I
still missing something?
There was some indication back when this was first implemented
[EMAIL PROTECTED]:
# Well, on thinking a bit about this, there's no reason that
# we have to
# worry--it's perfectly OK for us to declare, unconditionally, that
# segment 0 is always bytecode, 1 line number info, and so on, with
# everything after position X (for some value of X) left up
Here's my proposal for stage one: This patch is intended to define
explicitly what the different compiler and linker commands and flags
are, what they are supposed to mean, and how they are to be used.
Does this set of variables look sufficient for everyone, and are the
definitions clear? If
On Tue, 29 Oct 2002, Andy Dougherty wrote:
Here's my proposal for stage one: This patch is intended to define
explicitly what the different compiler and linker commands and flags
are, what they are supposed to mean, and how they are to be used.
Does this set of variables look sufficient
At 11:46 AM +0100 10/29/02, Juergen Boemmels wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
Well, on thinking a bit about this, there's no reason that we have to
worry--it's perfectly OK for us to declare, unconditionally, that
segment 0 is always bytecode, 1 line number info, and so on, with
On Tue, 2002-10-29 at 11:48, Brent Dax wrote:
[EMAIL PROTECTED]:
# Well, on thinking a bit about this, there's no reason that
# we have to
# worry--it's perfectly OK for us to declare, unconditionally, that
# segment 0 is always bytecode, 1 line number info, and so on, with
#
On Monday 28 October 2002 13:02, Dan Sugalski wrote:
At 1:08 PM -0800 10/27/02, chromatic wrote:
Is there an underlying function used to add arbitrary (Unicode text)
metadata to the bytecode?
Arbitrary metadata? Nope, no plans for that. While I can see it as a
useful thing (though it
Dan Sugalski wrote:
Leopold Toetsch wrote:
Can we really have e.g. odd aligned PMCs on stack?
the specs are available *somewhere*, and we should see
about digging them up and getting a final answer one way
or another.
A gold mine of cpu specs:
On Tue, Oct 29, 2002 at 05:18:53AM -0800, James Michael DuPont wrote:
The gcc interface project has been offically restarted.
http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html
Congratulations. I think it's an important project.
Tim.
On Aug-08, Peter Gibbs wrote:
# New Ticket Created by Peter Gibbs
# Please include the string: [perl #16077]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16077
Attached patch implements Dan's new 'assign
32 matches
Mail list logo
