Juergen Boemmels wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
It might be even possible to dump the jitted code. This would increase
the startup. Then strip the bytecode to reduce the size of the file
and TADA: Yet another new binary format.
When you then are able to to get the same mem
Dan Sugalski wrote:
At 8:39 PM + 1/23/03, Dave Mitchell wrote:
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
This is the way the bytecode currently works, and we will *not* switch
to any bytecode format that doesn't at least allow the
Dan Sugalski wrote:
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.
I'm pretty new to this, so I apolo
Dan Sugalski wrote:
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 p
On Friday 24 January 2003 04:43, Dan Sugalski wrote:
> 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
Leopold Toetsch wrote:
I'm currently simplifying the whole packfile routines. It still does
read the old format, but the compat code is centralized now in one place.
Registered types are consecutively numbered, unknown types still get
unpacked or dumped:
typedef enum {
PF_DIR_SEG,
P
In debugging a regex problem, I gradually whittled a test case down to
the following code. It does roughly:
@a = ('aaa', 'ac');
$x = $a[0];
print $x;
$x = substr("aaacacaaba", 3, 3); # "cac"
$y = $a[0]
print $y;
and prints out
aaa
cac
So the substr is somehow modifying the first eleme
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote:
> How many mmap's can $arch have for one program and for all?
> Could we hit some limits here, if every module loaded gets (and stays)
> mmap()ed.
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linu
From: Nicholas Clark [mailto:[EMAIL PROTECTED]]
> On Thu, Jan 23, 2003 at 10:23:22AM +, Leon Brocard wrote:
>
> > 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/ Which is useful, as they let
At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote:
On Friday 24 January 2003 04:43, Dan Sugalski wrote:
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. An
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote:
How many mmap's can $arch have for one program and for all?
Could we hit some limits here, if every module loaded gets (and stays)
mmap()ed.
I just wrote a quick C program that suc
On Fri, 24 Jan 2003 12:26:10 -0500, Dan Sugalski wrote:
>At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote:
>>On Friday 24 January 2003 04:43, Dan Sugalski wrote:
>>> I just gave a run of examples/assembly/mops_p.pasm, getting some
>>> performance numbers. Here's an interesting timing.
>>>
>>>
At 12:17 PM -0600 1/24/03, Bruce Gray wrote:
On Fri, 24 Jan 2003 12:26:10 -0500, Dan Sugalski wrote:
At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote:
On Friday 24 January 2003 04:43, Dan Sugalski wrote:
I just gave a run of examples/assembly/mops_p.pasm, getting some
performance numbers.
Steve Fink wrote:
In debugging a regex problem, I gradually whittled a test case down to
the following code. It does roughly:
@a = ('aaa', 'ac');
$x = $a[0];
print $x;
$x = substr("aaacacaaba", 3, 3); # "cac"
$y = $a[0]
print $y;
and prints out
aaa
cac
This is my illegal speed hack
Dan Sugalski wrote:
At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote:
CG vs JIT (running with non jitted opcdes) wins CG, always.
Ah, OK. No function preambles/postambles in the CG case. Hrm, time to go
learn PPC assembly, I guess... :)
Ne need to have a deep understanding of $arch's as
Dan Sugalski wrote:
> At 12:17 PM -0600 1/24/03, Bruce Gray wrote:
> >
> >IBM hosts a tutorial on Linux PowerPC assembly, with links to
> >instruction set, ABI, and optimization:
> >http://www-106.ibm.com/developerworks/linux/library/l-ppc/
>
> Yow! Cool, thanks!
Also of interest may be:
http://
At 8:14 PM +0100 1/24/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote:
CG vs JIT (running with non jitted opcdes) wins CG, always.
Ah, OK. No function preambles/postambles in the CG case. Hrm, time
to go learn PPC assembly, I guess... :)
Dan Sugalski wrote:
At 8:14 PM +0100 1/24/03, Leopold Toetsch wrote:
Of course, you should know, how to prepare arguments for function
Heh, I'm not worried--it certainly won't be the first assembly language
I've learned. :)
I knew that.
Just a matter of getting the time to do it, whi
On Friday, January 24, 2003, at 10:10 AM, Brent Dax wrote:
# 1 .. $a
# 1 .. $a : 2
# $a .. $b
# $a .. $b : 2
# $a .. $b : $c
# 1 .. 10 : $c
# 2.5 .. 10.0 : 0.5
To my knowledge, these are all fine.
Thanks, you're right. I was confusing the 'lazy' discussion with
--- Piers Cawley <[EMAIL PROTECTED]> 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 {
> strfti
On Thursday, January 23, 2003, at 02:24 PM, Brent Dax wrote:
I suspect that the prototype for '..' is like this:
So the 'step' use of colon may _only_ be used in conjunction with a
"ranged" list, e.g. C<..>, correct? In _any_ other context, it means
something else.
In looking at A3, I also
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:
Okay, I think I remembered the problem. Assume the following:
list bar(int);
Michael Lazzaro:
# On Thursday, January 23, 2003, at 02:24 PM, Brent Dax wrote:
# > I suspect that the prototype for '..' is like this:
#
# So the 'step' use of colon may _only_ be used in conjunction with a
# "ranged" list, e.g. C<..>, correct? In _any_ other context, it means
# something els
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 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:
>
> Okay, I think I reme
Dan Sugalski:
# 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:
#
# Okay, I think I remembered the problem. Assume
On Fri, Jan 24, 2003 at 10:02:13AM -0800, Austin Hastings wrote:
> --- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > 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 multid
On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley wrote:
> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> > I'm not a Lisp enthusiast, by and large, but I think he makes some
> > interesting observations on language design. Take a look if you're
> > feeling adventurous...
>
>
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> Okay, I think I remembered the problem. Assume the following:
>
> list bar(int); # bar takes an int, returns a list
> scalar bar(int); # bar takes an int, returns a scalar
>
> and also assume the following:
>
> xyzzy(scalar); # xyz
Garrett Goebel:
# Brent Dax wrote:
# >
# > This is also a problem with using want().
# >
# > If we don't provide wants_scalar/wants_list, someone will
# > build it with want(), so we might as well try to address
# > it. I suggest that want() return a special value when
# > the calling context is
At 10:02 AM -0800 1/24/03, Austin Hastings wrote:
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
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
On Fri, Jan 24, 2003 at 10:15:48AM -0800, Brent Dax wrote:
> Dan Sugalski:
> # Okay, I think I remembered the problem. Assume the following:
> #
> # list bar(int); # bar takes an int, returns a list
> # scalar bar(int); # bar takes an int, returns a scalar
> #
> # and also assume the f
From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Garrett Goebel:
> # Brent Dax wrote:
> # >
> # > This is also a problem with using want().
> # >
> # > If we don't provide wants_scalar/wants_list, someone will
> # > build it with want(), so we might as well try to address
> # > it. I suggest that wan
Garrett Goebel:
# From: Brent Dax [mailto:[EMAIL PROTECTED]]
# > Actually, I was thinking C, though a junction of all
# > the possible contexts might be good too. Remember, want()
# > is more than just scalar/array now.
#
# sure, sure...
#
# I was ambiguously referring back to Dan's example, we
Dan Sugalski wrote:
> There's also the fun of:
>
> Dog bar(int);
> Cat bar(int);
>
> and
>
> xyzzy(Dog);
> xyzzy(Cat);
>
> with the call of:
>
> xyzzy(bar(1));
>
> Just one of the many brain-benders that I'm glad Larry has to deal
> with, not me. (Though this may be one
> The problem with cons/car/cdr is that they're fundemental operations.
> Graham *has* learned from perl, and is receptive to the idea that
> fundemental operators should be huffman encoded (lambda -> fn). It
> would be easy to simply rename car/cdr to first/rest, but that loses
> the huffman natu
On Fri, Jan 24, 2003 at 01:00:26PM -0500, Tanton Gibbs wrote:
> > The problem with cons/car/cdr is that they're fundemental operations.
> > Graham *has* learned from perl, and is receptive to the idea that
> > fundemental operators should be huffman encoded (lambda -> fn). It
> > would be easy to
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> I suggest that we might require a special property to say "dispatch
> on return value", which would give us a place to put in some
> information to resolve conflicts.
In keeping with the notion of "a language for good programmers," I
think that the ver
Adam Turoff <[EMAIL PROTECTED]> writes:
> On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley wrote:
>> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
>> > I'm not a Lisp enthusiast, by and large, but I think he makes some
>> > interesting observations on language design. Take a l
> Strange. I think parameters to subroutines are in list
> context unless stated otherwise.
>
> -Scott
I agree. Do we miss something ?
Murat
On Thu, Jan 23, 2003 at 02:48:38PM -0800, Brent Dax wrote:
> Are you expecting to have chunk type determined by order? If so, what
> will you do if a future restructuring means you either don't need chunk
> type X or you need a new, highly incompatible version? Will you leave
> in an "empty" gho
On Thu, Jan 23, 2003 at 12:11:20AM -0500, Dan Sugalski wrote:
> Every sub doesn't have to fit in a single segment, though. There may
> well be a half-zillion subs in any one segment. (Though one segment
> per sub does give us some interesting possibilities for GCing unused
> code)
For an inter
41 matches
Mail list logo
