At 4:58 AM +0530 1/4/03, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
language-level "we're object-oriented dammit!" objects, not the
lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
reference-style objects and non-reference values.
At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
On Sat, 2003-01-04 at 00:28, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
> language-level "we're object-oriented dammit!" objects, not the
> lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
Done.
--Josh
At 22:57 on 12/31/2002 GMT, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Currently Parrot is picking up Perl's C compiler flags. Perl is quite
> deliberately attempting to set -fno-strict-aliasing, to stop gcc using
> ANSI's aliasing rules to infer possible optimisations; optimisatio
Applied both, thanks.
--Josh
At 19:11 on 12/31/2002 GMT, Nicholas Clark (via RT)
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Nicholas Clark
> # Please include the string: [perl #19630]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2
On Jan-02, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >On Dec-31, Leopold Toetsch wrote:
>
>
> >>I think, it moves the problems just around with a lot of overhead. E.g.
> >>cloning a PerlArray of 10^6 entries would need 1000 generations
>
> >I don't understand. The outer clone belongs to
Dan Sugalski wrote:
At 1:34 PM +0100 1/3/03, Leopold Toetsch wrote:
1) parrot compiled -O3 (classes/Makefile is br0ken, doesn't get CFLAGS
from Configure) - but unoptimized is still faster then perl5 :-)
Odd. Not on my system. Might be a x86/PPC issue.
I must have overlooked -O3 in clas
Dan Sugalski wrote:
At 5:46 PM +0100 1/3/03, Leopold Toetsch wrote:
Leopold Toetsch wrote:
[ this is Mr. f'up myself again ]
You've a *long* way to go to get that title. (It's mine, and you can't
have it! :)
Oh, sorry for misusing your prenome ;)
This test is with a 10% smaller PMC giv
At 5:46 PM +0100 1/3/03, Leopold Toetsch wrote:
Leopold Toetsch wrote:
[ this is Mr. f'up myself again ]
You've a *long* way to go to get that title. (It's mine, and you
can't have it! :)
$ time parrot -j stress.pbc
real0m0.849s
By reducing the amount of DOD runs I now have:
$ time pa
At 1:34 PM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower,
which is a Bad Thing.
1)
On Tue, Dec 31, 2002 at 06:32:42PM -0800, Steve Fink wrote:
> On Dec-31, Jerome Vouillon wrote:
> > The temporary objects could be stored in a stack, which is popped when
> > leaving the current function (both with normal exits and longjmp).
> > This should make it a lot less likely to forget the u
--- James Michael DuPont <[EMAIL PROTECTED]> wrote:
> Hi There!
> [SECTION PACKDUMP]
> make packdump.exe
> packdump.c: In function `PackFile_Constant_dump':
> packdump.c:111: structure has no member named `flags'
> make: *** [packdump.o] Error 1
>
> I have commented that out for now :
>
Hi There!
My name is Mike, and I have decided to pick up on the parrot again. You
seem to be making good progress, let me help you test this thing and
build some interfaces to other programs.
Can someone tell me if anyone uses packdump from cvs? is that an
equivalent to ildasm in dotnet? It seems
On Sat, 2003-01-04 at 00:28, Gopal V wrote:
> If memory serves me right, Dan Sugalski wrote:
> > language-level "we're object-oriented dammit!" objects, not the
> > lower-level stuff we're currently working with) should/will behave.
>
> yay ! ... finally !
The moment we've all been waiting for :
If memory serves me right, Dan Sugalski wrote:
> language-level "we're object-oriented dammit!" objects, not the
> lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
> reference-style objects and non-reference values.
How large can a non-reference value be
Leopold Toetsch wrote:
[ this is Mr. f'up myself again ]
$ time parrot -j stress.pbc
real0m0.849s
By reducing the amount of DOD runs I now have:
$ time parrot -j stress.pbc
A total of 9 DOD runs were made
real0m0.708s
But this still could go faster:
$ parrot -j stress.pbc # w/o pm
Aldo Calpini wrote:
I was the proposer. I have written an Iterator PMC back in the ol'
0.0.8 days, but then I was distracted and never finished my work.
I will try to reimplement my addition to 0.0.9 and submit a patch
ASAP (probably after 07 jan ;-).
Thanks, great.
cheers,
Aldo
leo
Leopold Toetsch wrote:
[ another f'up myself ]
stress2 results:
$ time perl examples/benchmarks/stress2.pl
real0m2.430s
user0m2.410s
sys 0m0.020s
$ time parrot stress2.pbc
real0m1.854s
user0m1.710s
sys 0m0.140s
$ time parrot -j stress2.pbc
real0m1.460s
user0m
Leopold Toetsch wrote:
$ time parrot stress.pbc
real0m0.508s
Sorry, due to some lack of coffee, I ran a version, where DOD was
blocked in buildarray.
Here are updated numbers:
$ time perl examples/benchmarks/stress.pl
real0m0.786s
user0m0.590s
sys 0m0.200s
$ time parrot -
Dan Sugalski wrote:
At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
First, the resource system falls down hard when doing lots of
allocations with no deallocations. It gets exponentially slower,
which is a Bad Thing.
1) parrot compiled -O3 (classes/Makefile is br0ken,
Leopold Toetsch wrote:
> There is a nextkey_keyed mentioned in pdd02_vtables.pod, which would
> almost be all to implement aggregate iterators. Missing is IMHO how to
> reset (start) an iteration.
> Also not too long ago, there was some proposal WRT an iterator class.
I was the proposer. I have
20 matches
Mail list logo
