On Oct 21, 2003, at 8:11 AM, Juergen Boemmels wrote:
If you think about it: The call to the destructors is done after
free_unused_pobjects completed. The memory of the objects without
destructors is already freed. If you are still in an out of memory
situation when the destructors are run, then
Nick Kostirya [EMAIL PROTECTED] wrote:
[PATCH] to build under win32
1. MS compiler do not support struct with empty body.
Melvin is currently filling the gaps, so I'd rather not mess around with
it.
2. remove unistd.h
This is a problem. The #include is in a generated file and not in our
On Tue, Oct 21, 2003 at 03:01:20PM -0700, Ovid wrote:
--- Tim Bunce [EMAIL PROTECTED] wrote:
I'll look into SQLite.
I'd caution against rushing in any particular direction without some
profiling information to back it up.
Having said that, I'd strongly recommend switching to
On Wed, Oct 22, 2003 at 10:01:26AM +0100, Tim Bunce wrote:
I don't have time in the short term to work on the (albeit fairly
trivial) change to Storable. If someone can do that and get a new
release out then I'll look deeper into the performance issues then.
In reading this thread over the
On Wed, Oct 22, 2003 at 10:35:49AM +0100, Nicholas Clark wrote:
On Wed, Oct 22, 2003 at 10:01:26AM +0100, Tim Bunce wrote:
I don't have time in the short term to work on the (albeit fairly
trivial) change to Storable. If someone can do that and get a new
release out then I'll look deeper
Andrew Savige wrote in perl-qa :
Given the differences in behaviour with taint mode, it seems to me
that for a taint mode test (i.e. one with -wT in its first line)
Test::Harness should run the test twice -- once with taint mode and
once without. Though I suppose there might be a case where
http://www.parrotcode.org/openpatches/ shows a list of open patches
ranging from #801 up to recent ones. Some of them are marked pending or
applied but not closed.
I'd be glad if someone could go through the list and update it so that
the actual state is reflected at that site.
I know, some of
On Tue, 21 Oct 2003, Matt Fowles wrote:
All~
Dan Sugalski wrote:
To add or remove an implemented interface:
adddoes Px, Sy
removedoes Px, Sy
Instantiate, as implemented, is dead. I'm going to nuke it, then use it
for instantiating classes via metadata chunks. That's next
On Tue, 21 Oct 2003, Joseph Ryan wrote:
Will there be a way to specify which methods belong to the class in the
metadata? Or will Method namespaces just have to match class names so
that a lookup can be done?
Hadn't planned on having any particular declaration of methods, no. If
there was
On Tue, 21 Oct 2003, Melvin Smith wrote:
I'm sure ssalc must mean something bad somewhere. Technically
nothing is stopping us from using .end for everything since we
are using a LALR parser and don't need fancy error reporting,
True enough. For machine-generated code it's irrelevant, so it
At 08:49 AM 10/22/2003 +0200, Leopold Toetsch wrote:
Nick Kostirya [EMAIL PROTECTED] wrote:
[PATCH] to build under win32
1. MS compiler do not support struct with empty body.
Melvin is currently filling the gaps, so I'd rather not mess around with
it.
Arg. I'll make sure I don't do that again.
I already mentioned, that the classname PMC is in different slots, which
could have implications on getting at it.
Here are some more thoughts:
Class/Object Array Layout:
Class Object
Arraytype OrderedHash Array
[ 0 ] parent arrayclass
As ParrotObjects and plain PMCs seems to get more and more unified, the
question arises, if all PMC vtables should be invocable via the standard
method invocation for real objects:
new P2, .PerlString
can I0, P2, _set_string_native # = 1
set S0, _set_string_native
set P5, P2
set S5,
# New Ticket Created by Simon Glover
# Please include the string: [perl #24267]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24267
This code:
set I0, 10
set I1, 20
or I2, I1, I0
On Wed, 22 Oct 2003, Leopold Toetsch wrote:
As ParrotObjects and plain PMCs seems to get more and more unified, the
question arises, if all PMC vtables should be invocable via the standard
method invocation for real objects:
Sort of, yes. We're going to define a name for each vtable entry
The Perl 6 Summary of the week ending 20031019
Lumme! Another week, another summary.
Every week (almost) we start with the perl6-internals list, so here
goes.
An Evil task for the interested
Our Glorious Leader, Dan Sugalski, last week asked for volunteers to
work on making
Leo:
HLLs like Smalltalk that treat everything as an object do so only at the
visible HLL level. Underneath in the VM things are optimized into branches
and native representation (in certain circumstances). I don't see any
reason that we wouldn't expect the Smalltalk-Parrot compiler to make
If anyone goes through that list and provides me with a list of needed
updates (in a standardized format), I can do some bulk updates
relatively easily.
-R
Leopold Toetsch wrote:
http://www.parrotcode.org/openpatches/ shows a list of open patches
ranging from #801 up to recent ones. Some of
At 04:39 PM 10/21/2003 -0700, Michael G Schwern wrote:
On Tue, Oct 21, 2003 at 12:34:44PM -0500, Dave Rolsky wrote:
Anyway, my taint mode experience has been that random things break in very
weird ways when using it.
All the more reason to test with it on. :)
--
Michael G Schwern[EMAIL
On Wed, Oct 22, 2003 at 08:17:06AM -0700, Bob Goolsby (bogoolsb) wrote:
Actually, that is an argument for running two sets of tests, one vanilla,
the other Tainted.
And that raises the question Who's bug is it? if something passes the
test package under normal conditions, but fails under
As Leo's just noted in the repository, adding PMC classes to the core
breaks binary compatibility. (And we need a placeholder keyword for
removed ops) This needs fixing as much as the opcode numbering needed
fixing, and should (hopefully) be rather less controvertial.
Anyone care to take a shot
(There's a bit about Parrot at the end.)
Recently seen on Amir's monitor (pardon the Windows-ness):
=
C:\Amir\Perl\Parrot\ParrotZperl plotz.pl story\minizork.z3
Unimplemented opcode read at 15520
Unimplemented opcode restart at 22205
Unimplemented
Simon Glover [EMAIL PROTECTED] wrote:
Clearly there's a bug here, since the behaviour should be consistent;
I have changed the PerlInts to work like all others, thanks
Simon
leo
On Wed, 22 Oct 2003, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
Clearly there's a bug here, since the behaviour should be consistent;
I have changed the PerlInts to work like all others, thanks
I don't think your fix is correct, since:
new P0, .PerlNum
Amir Karger [EMAIL PROTECTED] wrote:
... Of course, by that time, Parrot will
probably be running on nanobots in our red blood cells, so you'll be
able to run Z-code REALLY natively.
Great work and ... hmm not sure 'bout that nanobot stuff, or at least,
I'm waiting for the --secure runmode
I propose a Halloween release. Nothing fancy, just something fun. :)
We should be able to reach some sort of minor milestone to
justify it I'm sure.
-Melvin
IMCC has graduated from the parrot/languages/imcc directory to parrot/imcc.
Please update your trees.
We may still want to move the main up to the parrot directory and
possibly do an include/imcc directory, but I'm not sure.
Test builds on my machine, so I think everything is back to intact for
So much for preserving repository history.
(Dan! Where's the list of things to move?)
-R
At Wed, 22 Oct 2003 22:29:49 -0400,
Melvin Smith wrote:
IMCC has graduated from the parrot/languages/imcc directory to parrot/imcc.
Please update your trees.
We may still want to move the main up
Well, if you want to roll it back I don't mind. I don't
think there were any other commits during my
little hack and slash.
We probably shouldn't worry too much while
still in 0.0.x stage until we at least have a beta
release (or whatever 0.1 is going to be).
Then revision history becomes much
29 matches
Mail list logo