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
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: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 (
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'
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
--- 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
--- 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
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
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
--- 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
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: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
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
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
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
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
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
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 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
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: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 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 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 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
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
--- 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
> 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
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
--- 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 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.
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
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
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
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 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
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, 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:
> > :-) 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
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 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
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
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... :)
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 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
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:
# 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
47 matches
Mail list logo
