David wrote:
> Damian Conway wrote:
> > NaN is dead.
>
> > Except perhaps under a C pragma of some kind, in which case it
> > would be a proper IEEE Norweigian Blue NaN.
>
> which merely redifines the discussion to, how does the IEEENBNaN
> behave under various cir
Simon just chastised me for talking instead of patching.
Most of the stuff I'm interested in is heavily related to
the implementation of lexicals, so that's where I'm going
to jump in.
There are a number of decisions to make about lexicals
and the current PDD is pretty slim. So, IMHO, the place
t
At 07:27 PM 11/8/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > Gack. Looks like a mis-placed optimization in perl 5. The list of a
> foreach
> > is *supposed* to flatten at loop start and be static. Apparently not. :)
>
>Is anybody keeping a list of things that are *supposed* to be static?
On Thu, Nov 08, 2001 at 04:21:57PM -0800, John Rudd wrote:
> So, does this mean my other heart's desire of operator overloading might
> be coming forth?
Yeah, that was mentioned in Apoc and Exewhatever 3.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quali
At 04:21 PM 11/8/2001 -0800, John Rudd wrote:
>So, does this mean my other heart's desire of operator overloading might
>be coming forth? (I know, I know, here I am, a smalltalker, asking for
>operator overloading ... but, what are the smalltalkers gonna do, take
>away my membership card?)
What,
Dan Sugalski wrote:
> Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> is *supposed* to flatten at loop start and be static. Apparently not. :)
Is anybody keeping a list of things that are *supposed* to be static? Is
the list changing much with Perl 6?
> Care to fil
Michael G Schwern wrote:
>
> On Thu, Nov 08, 2001 at 03:56:59PM -0800, John Rudd wrote:
> > So, I'm reading various things about lots of changes for perl6, and some
> > arcane things going away, and stuff like that.. and I suddenly wondered
> > if one of my favorite features of Perl Objects (the
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Yes, it is a bug. There's an array in list context--it's supposed to be
> flattened before the foreach loop gets evaluated. (And if there are
> multiple arrays in the list it works as you'd expect)
Sorry, I quoted the wrong section. It really isn't a bu
Dan Sugalski wrote:
> [native code regexps] There's a hugely good case for JITting.
Yes, for JITing the regexp engine. That looks like a much easier
problem to solve than JITing all of Parrot.
> If you think about it, the interpreter loop is essentially:
>
>while (code) {
> code = (fun
On Thu, Nov 08, 2001 at 03:56:59PM -0800, John Rudd wrote:
> So, I'm reading various things about lots of changes for perl6, and some
> arcane things going away, and stuff like that.. and I suddenly wondered
> if one of my favorite features of Perl Objects (the one that keeps me
> from migrating t
At 03:56 PM 11/8/2001 -0800, John Rudd wrote:
>I suddenly wondered
>if one of my favorite features of Perl Objects is going away:
>AUTOLOAD.
Only over Damian's dead body... :)
Dan
--"it's like this"---
D
So, I'm reading various things about lots of changes for perl6, and some
arcane things going away, and stuff like that.. and I suddenly wondered
if one of my favorite features of Perl Objects (the one that keeps me
from migrating to tcl or python, cuz I can never find clear information
about whe
At 05:41 PM 11/8/2001 -0500, Sam Tregar wrote:
>On Thu, 8 Nov 2001, Dan Sugalski wrote:
>
> > Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> > is *supposed* to flatten at loop start and be static. Apparently not. :)
> >
> > Care to file the perl 5 bug report, or shal
On Thu, 8 Nov 2001, Brent Dax wrote:
> That doesn't support your argument. The point is that in the statement:
>
> foreach(@array) {
> ...
> }
>
> @array should only be evaluated once, at the beginning of the loop. In
> effect (using := here, but otherwise Perl 5 code)
Sam Tregar
# On Thu, 8 Nov 2001, Dan Sugalski wrote:
#
# > Gack. Looks like a mis-placed optimization in perl 5. The
# list of a foreach
# > is *supposed* to flatten at loop start and be static.
# Apparently not. :)
# >
# > Care to file the perl 5 bug report, or shall I?
#
# It's not a bug. Check
On Thu, 8 Nov 2001, Dan Sugalski wrote:
> Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach
> is *supposed* to flatten at loop start and be static. Apparently not. :)
>
> Care to file the perl 5 bug report, or shall I?
It's not a bug. Check out the "Foreach Loops" sect
At 09:33 PM 11/8/2001 +0100, Benoit Cerrina wrote:
> > At 10:22 AM 11/8/2001 -0700, Nathan Torkington wrote:
> > >I haven't seen much activity surrounding this. I figured there'd be a
> > >flood with everyone writing support for their own favourite data
> > >types. What's up?
> >
> > We're not q
At 07:53 PM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > No it isn't. It can get the integer length of the array and stuff it in a
> > register at the beginning of the loop, or do an integer compare when it
> > needs to, depending on the semantics of the loop.
>
>Wow. Did you just come
At 10:09 AM 11/7/2001 -0500, Jason Gloudon wrote:
>On Tue, Nov 06, 2001 at 05:22:27PM -0500, Dan Sugalski wrote:
>
> > A variable with a numeric value can be taken in one of three ways:
> >
> > *) As an integer. Which means either platform-native or bigint
> > *) As a float. Which means either pla
At 10:20 AM 11/8/2001 +, Simon Cozens wrote:
>On Wed, Nov 07, 2001 at 11:59:47PM -0500, Jeff wrote:
> > +if(string_length($2)>0) {
> > +$1 = string_concat(interpreter, s1, s2, 1);
> > +}
>
>Closer, but I think this check should be done in string_concat
>itself. *Then* I'll appl
At 02:46 AM 11/8/2001 -0600, Dave Goehrig wrote:
>On Wed, Nov 07, 2001 at 06:46:20PM -0500, Ken Fox wrote:
> >
> > JITs help when the VM is focused on lots of small instructions
> > with well-known, static semantics. Perl's use of Parrot is going
> > to be focused almost completely on PMC vtable o
On Thu, Nov 08, 2001 at 09:33:48PM +0100, Benoit Cerrina wrote:
> I understand that PMC are what will make it possible to integrate other
> languages to parrot, I'm really interested in ruby on parrot and would
> appreciate if you mention this and how you see it done in your doc
I don't know enou
On Thu, Nov 08, 2001 at 12:26:55PM -0500, Dan Sugalski wrote:
> I'm about to go missing for a few days and pound on this stuff. I'll make a
> dump or two over the next few days if Simon doesn't beat me to it.
Unlikely, I'm suffering a huge tuit shortage, as my inactivity hereabouts
should be a c
On Thu, Nov 08, 2001 at 12:54:11PM -0500, Jason Gloudon wrote:
> For example, the different between the vtable entries for set_integer and
> get_integer. I was hoping to create a few of the entries, but I don't know what
> is expected of them.
I was just taking my lead from the vtable PDD. I have
> At 10:22 AM 11/8/2001 -0700, Nathan Torkington wrote:
> >I haven't seen much activity surrounding this. I figured there'd be a
> >flood with everyone writing support for their own favourite data
> >types. What's up?
>
> We're not quite there yet with docs and environment, I think.
>
> I'm abou
> On Wed, Nov 07, 2001 at 06:46:20PM -0500, Ken Fox wrote:
> >
> > JITs help when the VM is focused on lots of small instructions
> > with well-known, static semantics. Perl's use of Parrot is going
> > to be focused almost completely on PMC vtable ops. A JIT has
> > no advantage over a threaded
> IMHO, a less dynamic perl is perl no more, though some consideration
> should be made to make it easier to implement the language on virtual
> machines such as the JVM and CLR.
> That said, I'm open to sneak into mono opcode handling that may make it
> easier to run parrot code there, if it is
On Thu, Nov 08, 2001 at 12:26:55PM -0500, Dan Sugalski wrote:
> At 10:22 AM 11/8/2001 -0700, Nathan Torkington wrote:
> >I haven't seen much activity surrounding this. I figured there'd be a
> >flood with everyone writing support for their own favourite data
> >types. What's up?
>
> We're not q
At 10:22 AM 11/8/2001 -0700, Nathan Torkington wrote:
>I haven't seen much activity surrounding this. I figured there'd be a
>flood with everyone writing support for their own favourite data
>types. What's up?
We're not quite there yet with docs and environment, I think.
I'm about to go missin
I haven't seen much activity surrounding this. I figured there'd be a
flood with everyone writing support for their own favourite data
types. What's up?
Nat
"Peter Haworth" <[EMAIL PROTECTED]> writes:
> [Apologies if you see this as a duplicate. I sent the original to perl6-all by
>mistake]
>
> On Thu, 08 Nov 2001 11:10:43 +, Piers Cawley wrote:
>> I keep coming back to the ruby/smalltalk
>> block approach
>>
>> &assert_with_func := {
>>
[Apologies if you see this as a duplicate. I sent the original to perl6-all by mistake]
On Thu, 08 Nov 2001 11:10:43 +, Piers Cawley wrote:
> I keep coming back to the ruby/smalltalk
> block approach
>
> &assert_with_func := {
> | &^sub is constant, $^expected is constant, $^got,
On Wed, Nov 07, 2001 at 06:46:20PM -0500, Ken Fox wrote:
>
> JITs help when the VM is focused on lots of small instructions
> with well-known, static semantics. Perl's use of Parrot is going
> to be focused almost completely on PMC vtable ops. A JIT has
> no advantage over a threaded interpreter.
On 11/08/01 Norbert Bollow wrote:
> BURG means "Bottom-Up Rewrite Grammar"... a way to generate
> optimized code quickly *if* you have plenty of memory available.
Maybe, if < 32 KB for a large method is plenty (about 600 bytes of IL code):
basically all the methods in out corlib are below that si
On 11/07/01 Ken Fox wrote:
> Simon Cozens wrote:
> > ... Mono's work on JIT compilation ... they've got some pretty
> > interesting x86 code generation stuff going on.
>
> Mono is doing some very cool stuff, but it's kind of hard
> to understand at this time. The x86 code generation macros are
>
Okay, so I've been thinking about currying and all that funky stuff
and then a discussion cropped up on perl6-internals about JIT stuff.
And I found myself thinking about:
&assert_with_func := { &^sub($^expected, $^got, @_) }
And it occured to me that it might actually be nice, if we're
expe
On Wed, Nov 07, 2001 at 11:59:47PM -0500, Jeff wrote:
> +if(string_length($2)>0) {
> +$1 = string_concat(interpreter, s1, s2, 1);
> +}
Closer, but I think this check should be done in string_concat
itself. *Then* I'll apply it. :)
--
FAILURE:
When Your Best Just Isn't Good E
Automated smoke report for patch Nov 7 20:00:02 2001 UTC
v0.02 on hpux using cc version B.11.11.02
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
Ken Fox <[EMAIL PROTECTED]> wrote:
> Simon Cozens wrote:
> > ... Mono's work on JIT compilation ... they've got some pretty
> > interesting x86 code generation stuff going on.
>
> Mono is doing some very cool stuff, but it's kind of hard
> to understand at this time. The x86 code generation macro
> There's a more fundamental issue though. After spending time
> looking at the benefits of a JIT and thinking about the "yet
> another switch/goto implementation" conversation, I'm starting
> to think that a JIT will be almost useless for Parrot.
>
> JITs help when the VM is focused on lots of s
hi all. What a nice thread you all had a couple weeks ago under
a subject line I wrote.
Damian Conway wrote:
> NaN is dead.
> Except perhaps under a C pragma of some kind, in which case it
> would be a proper IEEE Norweigian Blue NaN.
which merely redifines the discussion to, how does th
41 matches
Mail list logo
