Re: Almost, but not quite, there
On Thu, 23 Oct 2003, Simon Glover wrote: > > On Thu, 23 Oct 2003, Dan Sugalski wrote: > > > At 4:43 PM -0400 10/23/03, Dan Sugalski wrote: > > >And I could certainly do with some help at this point. > > > > > >Parrot is *almost* put back together. There's some weird linking problem > > >that's keeping parrot from working out as it should, and I've not been > > >able to track it down. If anyone feels like syncing up and giving it a > > >shot, I'd not mind it at all. > > > > And now we're fine, and even test good with the JIT. Woohoo! > > > > Time to thump it some and see what I missed. > > Well, I've just stumbled across one problem: if you run Configure > with --ask, then it won't accept its own default list of ops files. > The problem is this bit of config/inter/ops.pl: I applied a variant that should be a bit more robust for cross-platform use. Thanks for the catch. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: IMCC, classes & metadata
On Thu, 23 Oct 2003, Melvin Smith wrote: > I'm working on getting class syntax added to PIR. > > It appears IMCC's way of emitting instructions as it collects compilation > was a mistake (mine) and isn't going to work for metadata that needs to > be initialized first. > > Basically all metadata has to be collected before any code can be emitted. > I was thinking of generating an _init routine that creates the classes, > so we have several possibilities. Requiring the metadata be in the stream before the code that uses it doesn't seem particularly onerous, so I'm OK with it. (I would, I think, like to avoid a multi-pass assembler... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: IMCC, classes & metadata
At 08:36 AM 10/24/2003 +0200, Leopold Toetsch wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: > Basically all metadata has to be collected before any code can be emitted. > I was thinking of generating an _init routine that creates the classes, > so we have several possibilities. Why? A class definition should AFAIK end up in the constant table as a class PMC specifying the inheritance and attributes. So a .class directive is from parsing POV a constant definition, like a string constant. True, but something has to change. Either the loader has to know how to load a class (long term solution) or I have to write an _init routine. I was aiming for a short term kludge to get classes working. Freeze/thaw can break my kludge whenever it is done. (Unless you have a secret patch ready) We have to rearange all imcc globals anyway - there can't be globals or multi-threading will break horribly. Well, Bison C++ parsers are reentrant by default *pokes Dan* :) -Melvin
Re: Object freezing
On Tue, 21 Oct 2003 13:20:34 -0400 (EDT), Dan Sugalski wrote: > On Tue, 21 Oct 2003, Jeff Clites wrote: > > 2) I don't see it as a huge problem that serialization code could end > > up creating additional objects if called from a destroy() method. > > User code may, parrot may not. The reasons are twofold--while parrot will > let you shoot yourself in the foot, it provides the gun, not the foot. > It should also be possible for carefully written destroy methods to > serialize but not eat any headers or memory. (I can see this being the > case in some embedded applications or systems) If we make it so freezing > is not a guaranteed possibility at destroy time then this can't happen and > it lessens the utility of the system some. > > We can, if we choose, loosen the restriction later if sufficient reason is > presented. Can't really tighten it, though, so for now... -- Peter Haworth [EMAIL PROTECTED] "But do not program in COBOL if you can avoid it." -- "The Tao of Programming"
Re: Object freezing
On Tue, 21 Oct 2003 11:39:38 -0400 (EDT), Dan Sugalski wrote: > On Tue, 21 Oct 2003, Juergen Boemmels wrote: > > This is a question of what is allowed at destruction time. You don't > > want to allow memory allocation, but allow freezing. That gets hard, > > because you need at least allocate the STRING where you want to put your > > frozen stream. > > It's more a question of what we we require the engine to do, vs what user > code is allowed to do. A user program is allowed to write code that can > fail at destroy time, however the infrastructure we provide (including, in > this case, freezing--while I don't like it there's no choice) can't fail > that way. It's the reason the DOD and GC systems don't allocate memory (or > didn't--they shouldn't) when they run. The engine's not allowed to have > failure modes in critical sections. How can you serialise without using any extra memory? Even if you stream the serialised data directly to disk one byte at a time (which could fail just as easily as allocating memory to hold the serialised data in memory), serialisation of anything more complex than a native type is inherently recursive. Either you use up call stack space recursing over the PMCs, or you need an explicitly manage a stack/queue of PMCs not yet serialised. Have I missed some wonder of modern computing, or just something so obvious I can't see it? -- Peter Haworth [EMAIL PROTECTED] "What's so unpleasant about being drunk?" "You ask a glass of water." -- Douglas Adams, HHGTTG
Re: Object freezing
On Fri, 24 Oct 2003, Peter Haworth wrote: > On Tue, 21 Oct 2003 11:39:38 -0400 (EDT), Dan Sugalski wrote: > > On Tue, 21 Oct 2003, Juergen Boemmels wrote: > > > This is a question of what is allowed at destruction time. You don't > > > want to allow memory allocation, but allow freezing. That gets hard, > > > because you need at least allocate the STRING where you want to put your > > > frozen stream. > > > > It's more a question of what we we require the engine to do, vs what user > > code is allowed to do. A user program is allowed to write code that can > > fail at destroy time, however the infrastructure we provide (including, in > > this case, freezing--while I don't like it there's no choice) can't fail > > that way. It's the reason the DOD and GC systems don't allocate memory (or > > didn't--they shouldn't) when they run. The engine's not allowed to have > > failure modes in critical sections. > > How can you serialise without using any extra memory? Even if you stream the > serialised data directly to disk one byte at a time (which could fail just > as easily as allocating memory to hold the serialised data in memory), > serialisation of anything more complex than a native type is inherently > recursive. Either you use up call stack space recursing over the PMCs, or > you need an explicitly manage a stack/queue of PMCs not yet serialised. > > Have I missed some wonder of modern computing, or just something so obvious > I can't see it? The latter. :) We avoid extra memory usage in a destroy-time traversal for freezing the same way we avoid it for DOD--make sure that the memory we need is available to the traversal system in advance. This is one of the reasons I wanted to use the next_for_gc pointer in the PMCs to build the traversal chain, as the memory's already allocated and we wouldn't need to expand the PMCs any. It is certainly possible that the mechanism the user code chooses to use to freeze will exhaust some resource--disk space, RAM, bandwidth allotment, Universal electron supply, or something of the sort. That's fine, it's user code and is allowed to fail like that. We, on the other hand, have to make sure that we don't fail as part of the traversal. It's a pain, sure, but there are a number of applications where worst-case behaviour guarantees are required. I don't know that Parrot will ever be seriously used in an embedded application or semi-embedded application (like a Palm device) but enough folks have made noise about it that I'm trying not to make it impossible. I do realize that we're making some of our normal-case resource usages higher in exchange for a better guaranteed worst case, but at the moment I think that's worthwhile. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: IMCC, classes & metadata
Melvin Smith <[EMAIL PROTECTED]> wrote: > At 08:36 AM 10/24/2003 +0200, Leopold Toetsch wrote: >> >>Why? A class definition should AFAIK end up in the constant table as a >>class PMC specifying the inheritance and attributes. So a .class >>directive is from parsing POV a constant definition, like a string >>constant. > I was aiming for a short term kludge to get classes working. Freeze/thaw > can break my kludge whenever it is done. (Unless you have a secret > patch ready) Have a look, what I did with constant Subs. They are "serialized" as plain text and unpacked from that. I real short term hack, but working and doing, what's intendend to be done :) >>We have to rearange all imcc globals anyway - there can't be globals or >>multi-threading will break horribly. > Well, Bison C++ parsers are reentrant by default *pokes Dan* :) Its not a problem of the parser alone (which in the meantime BTW has an interpreter argument), all the other globals like the SymReg hash. Please imagin whats goin' on, when two threads start compiling PIR code. > -Melvin leo
Ignore (was Re: Object freezing)
On Fri, 24 Oct 2003 17:33:17 +0100, Peter Haworth wrote: > [stuff he didn't mean to send] Sorry. Looks like I hit Send instead of Cancel. -- Peter Haworth [EMAIL PROTECTED] "this system is slightly less secure than putting your IP address and root password in big letters in a 30-second Superbowl commercial. (Though I may be wrong--it's possible I'm underestimating the danger)" -- Dan Sugalski
[perl #24289] [PATCH] Make parrot/languages/Makefile happy
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #24289] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24289 > Hi, after the promotion of 'languages/imcc' I was checking languages/Makefile. I encoutered two problems, which caused failures of the build and test procedure. 'make all' failed at the target 'cola'. The reason was a 'cd ../imcc; make'. 'make test' failed at 'perl6.test'. For some reason 'perl/t/harness' returns an error 29, at least on my Linux notebook. I added a patch, which doesn't fix anything. They changes just evade these problems. CU, Bernhard -- attachment 1 -- url: http://rt.perl.org/rt2/attach/66471/49666/c49520/languages_makefile.patch languages_makefile.patch Description: languages_makefile.patch
[COMMIT] PIR changes
For those not on the cvs-commit list.. Added newsub and newclosure to PIR. Hides some implementation detail and allows IMCC to take advantage of the newsub opcode which is much more efficient than new/set_addr combination. This makes PIR orthogonal between new and newsub. Example: PIR PASM --- P0 = newsub ::= newsub, P0, .Sub, P0 = newclosure ::= newsub, P0, .Closure, This doesn't support all the variations, including continuations, the rest will come shortly. -Melvin
