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
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---
Dan
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 to
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 one
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,
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 Quality
David wrote:
Damian Conway wrote:
NaN is dead.
Except perhaps under a Cuse IEEE 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
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 Cuse IEEE pragma of some kind, in which case it
would be a proper IEEE Norweigian Blue NaN.
which merely redifines the discussion to, how
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
[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,
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 := {
| ^sub is
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 macros are
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
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
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
easy to
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 size.
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.
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
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 missing
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 quite
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 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
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
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
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
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 ops. A
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 up with
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
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 apply it. :)
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 quite there yet
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 section
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, 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):
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 shall I?
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 =
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 bug
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 file
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? Is
the
38 matches
Mail list logo
