Re: Object freezing
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 its also very likely that you are in a not much better situation afterwards. That's not quite right. You can't reclaim the memory of any object which is reachable from any object with a destructor which has not yet been called. But you're right that some memory can be reclaimed before calling destructors. JEff
Re: [perl #24260] [PATCH] to build under win32
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 sources. We could try to generate an empty unistd.h for Win platforms lacking one, or running a patch removing this line for such platforms. leo
[PS] open patches
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 these patches got applied by myself, and I just forgot then. So lets please for the future try to not forget to mark patches applied/whatever and close after some time[1]. Thanks, leo [1] IIRC must close be done after sending the "applied notice" mail or that would reopen it. PS: I'd rather not do it myself lacking an 24/7 internet connection - I have to pay for my ISDN line per minute. PPS: PS stands for "post scriptum" or "pumpking speaking" :) PPPS: Dunno if Juergen already has sufficient rights to update the patch status (it was some separate step for my acccount) - If not please update these bits in the setup. Thanks again.
Re: Class creation in bytecode
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 message. > > Just a thought, but (add/remove)interface seems a little more > undetstandable... I can see it going either way, but this is shorter and it amuses me some, so it's good enough. :) It only matters for hand-written assembly. > PS-Dan, what happened to you sig? I rather liked it. It only pops up when I'm using Eudora. I've been using Pine for the most part the past few weeks. Probably ought to get it moved over. Dan
Re: Class metadata for PIR/assembly files
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 one it'd at best be a note that the method does exist and perhaps its signature, but not its body. I'd much prefer just leaving it that subs (or methods, I can see having both) in the proper namespace are what gets called, regardless of what's declared. Given how all the languages we're primarily targeting act, that makes the most sense. Dan
Re: Class metadata for PIR/assembly files
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 doesn't matter. Since it seems easier for people to have matching open/close bracket things I went for the paired names. I doubt we'll have any nesting inside the class declaration, though--I can't see any good reason for it. > >Classes, when instantiated, have a backing namespace that's identical to > >the class name. > > Good. > > So do we support :: or . for scope resolution? Or both? ::, I think. I think we decided a while back that the actual, in-stash separator was a null byte, so we could have a language-neutral separator. We can skip that for a bit, though. > >It's OK for the code that handles PIR and assembly to ignore this for the > >moment, at least until the metadata segment is better defined. Which will > >be soon, though I'd rather someone else do the bytecode modification as > >it's been a long time since I've had my hand in there. > > Well we can hide this under PIR. Once PIR is set, we can > start by implementing on the fly class creation, then change > IMCC to emit metadata when the rest is in. That way > HL languages don't have to change later. For now we just have > IMCC emit newclass, etc. and manually construct the classes. Works. I should have the bytecode stuff spec'd today, with at least a rudimentary implementation. Dan
Re: [perl #24260] [PATCH] to build under win32
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. Apologies. -Melvin
Some notes WRT objects and classes
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 ptr [ 1 .. 3 ]like nowempty [ 4 ] classname classname [ 5+ ]class-attribs attributes Using an OrderedHash for the class array would allow named and indexed access to static/class attributes. And a class could probably serve as its own singleton with that layout above. If object attributes happen to be queried by name at runtime, the object array could be an OrderedHash too. Using an OrderedHash addtionally gives named access to the class arrays "standard" members (which might be useful for Pie-Thon - if not properties are used their): class_array ["_parent_array"] = Px#0 ... class_array ["_class_name"] = Py #4 casss_array ["foo"] = Pz #5 class attrib "foo" Just some thoughts, leo
Q: can, callmeth ...
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, "hello" callmeth # or find_method, invoke Not that I would recommend that but I can imagine, that HLL with "all is an object philosophy" would like to call all methods like above. leo
[perl #24267] Inconsistent behaviour of logical or op
# New Ticket Created by Simon Glover # Please include the string: [perl #24267] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24267 > This code: set I0, 10 set I1, 20 or I2, I1, I0 print I2 print "\n" set I1, 0 or I2, I1, I0 print I2 print "\n" end prints: 20 10 which is what the documentation leads me to expect. On the other hand, this code (which is the same as the above, but using PerlInts instead of native ints): new P0, .PerlInt new P1, .PerlInt new P2, .PerlInt set P0, 10 set P1, 20 or P2, P1, P0 print P2 print "\n" set P1, 0 or P2, P1, P0 print P2 print "\n" end prints: 1 1 Moreover, PerlNums behave like PerlInts, while PerlStrings behave like native ints. Clearly there's a bug here, since the behaviour should be consistent; my question is which is the correct behaviour? The documentation suggests the former, but official confirmation of this would be good. Simon
Re: Q: can, callmeth ...
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 (I'm in the middle of this now :) for the method to call for that particular vtable entry if the vtable function is invoked and its supposed to delegate to parrot code. I can see ways of making it all methods and dodging the vtable entirely, but they seem to badly pessimize the default case, so... blech. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: can, callmeth ...
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
similar adjustments, invisible as they may be at the language level.
Philip
-Original Message-
From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:42
To: P6I
Subject: Q: can, callmeth ...
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, "hello"
callmeth
# or find_method, invoke
Not that I would recommend that but I can imagine, that HLL with "all is
an object philosophy" would like to call all methods like above.
leo
This communication together with any attachments transmitted with it ("this E-Mail")
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-Mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are hereby notified that any use, dissemination, forwarding, printing or
copying of this E-Mail is strictly prohibited. Addressees should check this E-mail
for viruses. The Company makes no representations as regards the absence of viruses
in this E-Mail. If you have received this E-Mail in error please notify our ISe
Response Team immediately by telephone on +44 (0)20 8896 5828 or via e-mail at [EMAIL
PROTECTED] Please then immediately delete, erase or otherwise destroy this E-Mail and
any copies of it.
Any opinions expressed in this E-Mail are those of the author and do not necessarily
constitute the views of the Company. Nothing in this E-Mail shall bind the Company in
any contract or obligation.
For the purposes of this E-Mail "the Company" means The Carphone Warehouse Group Plc
and/or any of its subsidiaries.
Please feel free to visit our website: http://www.phonehouse.com
The Carphone Warehouse Group Plc (Registered in England No. 3253714) North Acton
Business Park, Wales Farm Road, London W3 6RS
Re: [PS] open patches
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 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 these patches got applied by myself, and I just forgot then. So lets please for the future try to not forget to mark patches applied/whatever and close after some time[1].
This week's summary
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 ordered destruction work. (Ordered destruction is where the system tries to ensure that 'parent' objects get destroyed before any of their children). Jeff Clites announced that he'd got a partial implementation working. Neither Leo Tötsch nor Jürgen Bömmels were sure that the approach Jeff was taking would be the Right Thing in the long run, proposing instead a more general iterator mechanism. http://xrl.us/x8k Perl 6 Sub calling Bringing the perl6 compiler (in languages/ back to live, Steve Fink has committed a 'rather large' patch which implements a subset of the Apocalypse 6 subroutine signature rules. The implementation is apparently very ad hoc and shouldn't be regarded as the final word. But it looks like a very good start to me. http://xrl.us/x8l Website timeliness Responding to Matt Fowles' observation that the parrot website is rather behind the times, Robert Spier let slip that there would soon be a revised website that will be easy for everyone to send patches to, and which would be much easier to have multiple maintainers of different areas of the site. Of course, there are still a few 'technical chunks' that need to get finished before it's ready to unveil, but it's good to know that work continues in this area. Thanks Robert. http://xrl.us/x8m http://xrl.us/x8n -- Mike Scott's Parrot Wiki Dynamic oplibs Chances are, you've never really needed a "fortytwo" operator, or even a "what_do_you_get_if_you_multiply_six_by_nine" operator, and you certainly don't need them cluttering up the parrot core. Which is why Leo Tötsch has implemented those ops as a dynamically loadable ops library. Admittedly, you're highly unlikely to load this particular ops library, but the underpinning tools for dynamic loading of ops libraries are new and potentially very useful. Rather later in the week, once he'd got dynamic loading of ops working in all the runtime cores, Leo posted an 'intermediate summary' which explains how things work. http://xrl.us/x8o http://xrl.us/x8p Oplips, pmclibs, function libs Dan has been thinking about the problems that can arise with dynamic loading. One issue is that, if you have separate files for each PMC class, opcode library and parrot function library, things get unwieldy very quickly, and if you're not careful you'll exhaust the OS file descriptor pool. Which would be bad. So, he asked for a sanity check before going on to work out a scheme for bundling libraries into larger files. Leo agreed that Dan was talking sense, so I expect we'll be seeing some design in this area soon. http://xrl.us/x8q Instantiating objects It's been a busy week on the parrot front for Dan. On Wednesday he outlined his thinking on instantiating objects, with the aim of getting single inheritance objects up and running. This sparked a good deal of discussion, but nothing was actually agreed. http://xrl.us/x8r Redoing IMCC macros Surprisingly, Jürgen Bömmels opened up a can of worms when he redid IMCC's macro support to use a hash lookup instead of a linear search through an array. This sparked a good deal of discussion about the right scoping, which hash implementation to use, and whether IMCC should be closely entwined with the interpreter. http://xrl.us/x8s Fixed opcode numbering infrastructure Dan checked in a patch to fix opcode numbers for the core ops, deliberately breaking the JIT in the process. Leo wasn't happy. After a bit of back and forth, we now have fixed opcodes, but the implementation isn't quite what Dan originally did. There was also some discussion of how many opcodes really needed to be fixed; after all, in the presence of dynamically loaded oplibs, you can't nail every opcode down. Leo worried that dynamically loaded oplibs don't play well with JIT, and making it work would probably need a total rewrite of the JIT core, but Jürgen didn't think it was all that bad. http://xrl.us/x8t Applying the Pumpking Patch $ patch RESPONSIBLE_PARTIES 6c6 < Release pumpking Steve Fink --- > Release pumpking Leopold Toetsch In other words, Steve Fink has stepped down from the rôle of Parrot Pumpking and handed the his mantle on to Leo "Pumpking Patchmonster" Tötsch. I'm sure I'm not alone in wishing to thank Steve for his sterling work as our release manager. Nor, I'm sure, am I alone in wondering where Leo finds the time.
More fixed number assignments
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 at it? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[OT] Plotz status
(There's a bit about Parrot at the end.) Recently seen on Amir's monitor (pardon the Windows-ness): = C:\Amir\Perl\Parrot\ParrotZ>perl plotz.pl story\minizork.z3 Unimplemented opcode read at 15520 Unimplemented opcode restart at 22205 Unimplemented opcode restore at 22217 Unimplemented opcode save at 22367 Unimplemented opcode input_stream at 22821 Unimplemented opcode output_stream at 22859 C:\Amir\Perl\Parrot\ParrotZ>perl story\minizork.pl MINI-ZORK I: The Great Underground Empire Copyright (c) 1988 Infocom, Inc. All rights reserved. ZORK is a registered trademark of Infocom, Inc. Release 34 / Serial number 871124 West of House You are standing in an open field west of a white house, with a boarded front do or. You could circle the house to the north or south. There is a small mailbox here. >Undefined subroutine &main::unimplemented_read called at story\minizork.pl line 513. = !!! The point here is that: (1) I'm able to translate a Z-code file into a Perl file (2) I'm able to implement enough stuff to get minizork (a smaller, publicly released Zork I) started, (almost) correctly printing out some stuff, up until the famed '>' prompt. (3) There's still a few crucial opcodes I haven't implemented, like the one that reads in and parses a command. I'm excited enough about #1 and #2 that #3 doesn't depress me too much. As you can see from the plotz.pl printout, what I still have left to do is game state and I/O. Which unfortunately happen to be the hard parts, but it turns out I can steal a lot of them from Games::Rezrov. I've implemented some 70 opcodes. Another 6 opcodes gets me minizork. Four more gets me two-thirds of all released Infocom games. Neat! Btw, a quick search on Google Groups tells me I haven't yet mentioned what plotz stands for: Pol(l)y-Lingual Opcode Translation for the Z-machine plotz parses Z-files. It then (in theory) has hooks that allow a coder to write a module that'll output a translation in (almost) whatever language she wants. The plan is that once I get minizork working (which I believe will take me another n weeks, where n is a nybble), I'll start working on PIR output from plotz (which will take another N months, where N is an (unsigned) byte). Then of course I get to start working on the original project behind all of this, which is getting Parrot to run Z-code natively. 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. -Amir __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: [perl #24267] Inconsistent behaviour of logical or op
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
Re: [perl #24267] Inconsistent behaviour of logical or op
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
new P1, .PerlInt
new P2, .PerlNum
set P0, 10.5
set P1, 0
or P2, P1, P0
print P2
print "\n"
end
will now print 10, rather than 10.5 (which is better than the behaviour
before the fix, but which is still not right).
Having done some more nosing around, I see that PerlString doesn't
actually have its own implementation of logical_or; instead, it falls
back on the scalar.pmc version, which does:
void logical_or (PMC* value, PMC* dest) {
if (DYNSELF.get_bool()) {
VTABLE_set_pmc(INTERP, dest, SELF);
}
else {
VTABLE_set_pmc(INTERP, dest, value);
}
}
Is there a good reason why we're not doing the same thing for
PerlInt/Num/Undef?
Simon
Re: [OT] Plotz status
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 switch for parrot :) > -Amir leo
Halloween release
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
[COMMIT] imcc moves out of languages
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 now. -Melvin
Re: [COMMIT] imcc moves out of languages
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 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 now. > > -Melvin >
Re: [COMMIT] imcc moves out of languages
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 more important. -Melvin At 09:45 PM 10/22/2003 -0700, Robert Spier wrote: 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 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 now. > > -Melvin >
Re: [COMMIT] imcc moves out of languages
Robert Spier <[EMAIL PROTECTED]> wrote: [ quoting reordered ] > Melvin Smith wrote: >> >> IMCC has graduated from the parrot/languages/imcc directory to parrot/imcc. Arghh[1] > So much for preserving repository history. Yep. Is the history gone, or are you able to do something for it? > -R [1] There was a lot of discussion on the list, how and why we will move files around. Melvin, please (re)read p6i or perl.perl6.internals
Re: Halloween release
Melvin Smith <[EMAIL PROTECTED]> wrote: > 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. Too much in flux currently, though not only one milestone seem to be near. > -Melvin leo
