Dan Sugalski:
# Since it looks like it's time to extend the packfile format and the
# in-memory bytecode layout, this would be the time to start discussing
# metadata. What sorts of metadata do people think are useful to have
# in either the packfile (on disk) or in the bytecode (in memory).
I
Steve Fink wrote:
I'm confused by nci.pmc's mark() routine. It calls pobject_lives() on
the ->cache.struct_val pointer. But in set_string_keyed(), that seems
to be set to a pointer to a function, which is definitely not a PObj*.
Yes, that's right.
The ->data field, on the other hand, appear
Dan Sugalski wrote:
Okay, since this has all come up, here's the scoop from a design
perspective.
Hard stuff did meet my printer at midnight, reading it onscreen twice
didn't help ;-)
First:
Definition #0: A bytecode segment is a sequence of code, which is loaded
into memory with no execut
Benjamin Stuhl wrote:
At 03:00 PM 1/22/2003 -0500, you wrote:
... Although,
all this would seem to suggest that we'd need/want a special-purpose
allocator for bytecode segments, since every sub has to fit within
precisely
one segment (and I know _I'd_ like to keep bytecode segments on their
Dan Sugalski sent the following bits through the ether:
> Also, I know that we do have people scattered all over the world, but
> if someone wants to try and get a list of who's where, we may find
> it's worth it to get groups of people together. (I don't, after all,
> have to be involved... :)
Steve Fink wrote:
I'm confused by nci.pmc's mark() routine.
Ok, nci's mark() is gone.
But - what confuses me - this patch needs a "make progclean" for changes
to take effect. Without default_mark gets called, because I don't know
where, something isn't recompiled.
Argh: pmc->vtable->init o
On Thu, Jan 23, 2003 at 10:23:22AM +, Leon Brocard wrote:
> Latitude:
> Longitude:
You forgot altitude. A proper ICBM block needs altitude :-)
> Useful resources for finding your longitude, latitude:
If you're in the UK you can get lat and long conversions from
http://www.streetmap.co.uk/
Wh
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start discussing
> metadata. What sorts of metadata do people think are useful to have
> in either the packfile (o
Hello,
after quite a long time away from keyboard and fighting through a huge
backlog of mail I'm (hopefully) back again.
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start d
If memory serves me right, Erik Bågfors wrote:
> > :-) Python basically requires that each step in the process be
> > overridable. (1. look up attribute 2. call attribute, at least in
> > `callmethod's case).
would this be more of what you need ?
obj.__dict__["foo"].__call__();
/me again shows
On Thu, 2003-01-23 at 15:46, Gopal V wrote:
> > Ruby needs to call the missing_method method (if I remember correctly).
> > So if "foo" doesn't exist, it would be good to be able to override
> > callmethods behavior and make it call missing_method.
>
> like I said , the compiler designer can put
If memory serves me right, Erik Bågfors wrote:
> But if I write a library in ruby that depends on the missing_method
> method it will not be usable from other languages, since those languages
> doesn't call missing_method if the method they try to call doesn't
> exist.
Hmm... that's twisting lang
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
>
> > Since it looks like it's time to extend the packfile format and the
>
> > in-memory bytecode layout, this would be the time to start
> discussing
> > metadata. What sorts of metadata do peop
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 t
> 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 s
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> > My current idea for the in memory format of the bytecode is this:
>
> I would strongly urge any file-based byte-code format to arranged
> in such a way that it (or most of it) can
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Okay, since this has all come up, here's the scoop from a design perspective.
>
> First, the branch opcodes (branch, bsr, and the conditionals) are all
> meant for movement within a segment of bytecode. They are *not*
> supposed to leave a segment. To do
At 10:29 PM -0800 1/22/03, James Michael DuPont wrote:
You will probably think that this is overkill for parrot,
Why yes, yes I do. On the other hand, when we hand people bazookas to
deal with their fly problems, we often find they start in on the
elephant problems as well.
The proposal in ge
At 10:10 PM +0530 1/23/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
But if I write a library in ruby that depends on the missing_method
method it will not be usable from other languages, since those languages
doesn't call missing_method if the method they try to call does
At 12:10 AM -0800 1/23/03, Brent Dax wrote:
Dan Sugalski:
# Since it looks like it's time to extend the packfile format and the
# in-memory bytecode layout, this would be the time to start discussing
# metadata. What sorts of metadata do people think are useful to have
# in either the packfile (on
At 8:42 AM +0100 1/23/03, Erik Bågfors wrote:
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> >But who knows, maybe it could be made modular enough (i.e., more
>
At 1:46 PM -0500 1/22/03, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
>But who knows, maybe it could be made modular enough (i.e., more
>interface-oriented?) to allow the best of both worlds -
At 8:16 PM +0530 1/23/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
> Ruby needs to call the missing_method method (if I remember correctly).
So if "foo" doesn't exist, it would be good to be able to override
callmethods behavior and make it call missing_method.
like I sa
Dave Mitchell <[EMAIL PROTECTED]> writes:
> On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> > My current idea for the in memory format of the bytecode is this:
>
> I would strongly urge any file-based byte-code format to arranged
> in such a way that it (or most of it) can sim
At 10:31 PM +0100 1/23/03, Juergen Boemmels wrote:
Dave Mitchell <[EMAIL PROTECTED]> writes:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
Dan Sugalski <[EMAIL PROTECTED]> writes:
> >This might be possible if the byteorder, wordsize, defaultencoding
> >etc. are the same in the file on disk and the host.
>
> Which will generally be the case, I expect. Tell a sysadmin that they
> can reduce the memory footprint of mod_parrot by 50% by
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# >Dan Sugalski:
# ># Since it looks like it's time to extend the packfile
# format and the #
# >in-memory bytecode layout, this would be the time to start
# discussing #
# >metadata. What sorts of metadata do people think are useful
At 8:39 PM + 1/23/03, Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply
At 11:48 AM -0800 1/23/03, chromatic wrote:
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are us
--- Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hello,
>
> after quite a long time away from keyboard and fighting through a
> huge
> backlog of mail I'm (hopefully) back again.
>
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > Since it looks like it's time to extend the packfile format and
At 2:48 PM -0800 1/23/03, Brent Dax wrote:
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# >Dan Sugalski:
# ># Since it looks like it's time to extend the packfile
# format and the #
# >in-memory bytecode layout, this would be the time to start
# discussing #
# >metadata. What sorts
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Dan Sugalski:
> # At 12:10 AM -0800 1/23/03, Brent Dax wrote:
> # >Dan Sugalski:
> # ># Since it looks like it's time to extend the packfile
> # format and the #
> # >in-memory bytecode layout, this would be the time to start
> # discussing #
> # >met
Michael Lazzaro writes:
>
> Think, think. What do these things have in common?
>
> # known from A4
>
> for @a, sub ($x) {...} # primitive spelling
> for @a -> $x {...} # pointy sub, looks great
>
> map {...} @a # old-style map syntax
>
At 11:02 AM -0800 1/23/03, Michael Lazzaro wrote:
Yes, no doubt so, and good point. I think I should make it clear
that my speculation on somehow unifying C and C is _not_
an attempt to gut A4, because I like A4 quite a lot. I'm just
thinking out loud about how we could _extend_ A4 in one par
Here's something that I'm still confused about.
We have:
print STDOUT : $a;
as indirect object syntax. The colon means "STDOUT is the object we're
operating on." It works everywhere. We also have
for 1..10 : 2 {...}
in which the colon indicates a step operation. The above will iter
On Wednesday, January 22, 2003, at 07:40 PM, Thomas A. Boyer wrote:
I have a strong suspicion that this possibility was carefully
considered by {LW, DC, ...} (that's set notation, not a code block :)
before the Apocalypse 4 "pointy sub" syntax (and the for-loop syntax
using it) was promulgate
Thomas A. Boyer writes:
> Michael Lazzaro wrote:
> > *Now*, what to do about the fantastic magic that pointy-sub provides?
> > The _spectacular_ win would be if we could just recognize an optional
> > parameter list as part of a block.
> >
> > map @a : ($a,$b) {...} # params + closure
On Wednesday, January 22, 2003, at 11:42 AM, Kwindla Hultman Kramer
wrote:
Michael Lazzaro writes:
And it provides a very visual way to define any pipe-like algorithm,
in
either direction:
$in -> lex -> parse -> codify -> optimize -> $out; # L2R
$out <- optimize <- codify <- parse
Michael Lazzaro:
# Here's something that I'm still confused about.
#
# We have:
#
# print STDOUT : $a;
Presumably you forgot the $ on that STDOUT.
# as indirect object syntax. The colon means "STDOUT is the
# object we're
# operating on." It works everywhere. We also have
#
# for
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Brent Dax <[EMAIL PROTECTED]> wrote:
> > Except that none of the other ones exist in Perl 6. :^)
>
Thinking about this some more, and considering the desirability of lazy
evaluation, I think incremental execution might be the right way.
(Al
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
anal
Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have in
either the packfile (on disk) or in the bytecode (in memory).
I'
At 7:23 AM +0100 1/24/03, Leopold Toetsch wrote:
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (
I just gave a run of examples/assembly/mops_p.pasm, getting some
performance numbers. Here's an interesting timing.
no jit: 24.9 seconds
with jit: 33.6 seconds
This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86.
Someone care to check it out and poke around a bit?
--
In my quest to eliminate as many explicit conditionals from my code as
possible, I found myself wondering if Perl 6's multidispatch mechanism
would allow one to write:
sub gmttime ( $time = time() ) is in_scalar_context {
strftime( $perls_default_time_format, $time );
}
sub gmttime
At 7:30 AM + 1/24/03, Piers Cawley wrote:
In my quest to eliminate as many explicit conditionals from my code as
possible, I found myself wondering if Perl 6's multidispatch mechanism
would allow one to write:
sub gmttime ( $time = time() ) is in_scalar_context {
strftime( $perls_def
47 matches
Mail list logo
