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
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
> Strange. I think parameters to subroutines are in list
> context unless stated otherwise.
>
> -Scott
I agree. Do we miss something ?
Murat
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
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
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 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://
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
--- 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
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
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
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
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.
> 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
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
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
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
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
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
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
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
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.
>>>
>>>
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...
>
>
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
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
--- 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
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
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
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 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);
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
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
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
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
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
--- 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 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
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
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:
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
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
41 matches
Mail list logo
