Re: incremental collector and finalization
Jeff Clites [EMAIL PROTECTED] wrote: I was reading over you incremental GC posts from about a month ago, and read the referenced paper--quite nice work you've done in implementing the ideas there. I have one question: What about finalizers? I may have just missed it, but it would seem that calling finalizers would require another sweep over the items newly resident on the free list (the left-over items in the from-space), which would (unfortunately) take time proportional to the number of freed object. BUT, a nifty thing would be to actually delay finalization until an object is about to be re-used off of the free list. That is, treat ecru items as only-maybe free, and as they are pulled off of the free list for re-use, check to see if a finalizer needed to be called and if so, call it and move on to the next item on the free list (as the first one may now be referenced, and should be marked grey). This would allow finalization to be treated incrementally, at the cost of it happening later than it would otherwise (which I think is fine). What about things that need timely destruction? Jonathan But maybe this is what you had in mind already. This doesn't give ordered finalization, but that may be okay. JEff
Re: No Autoconf, dammit!
According to Larry Wall: On Sat, Sep 18, 2004 at 12:27:36PM -0700, Jeff Clites wrote: : Ha, I'm sure it could probably be done, but of course most of what : the shell does it invoke other programs, so in the common case it still : wouldn't give you portability to non-Unix-like platforms. Just translate it to a language that has most of Unix semantics built-in. :-) Unless I've lost the thread of this discussion, that won't work. Microparrot can't be built with e.g. a call to readlink(), because the (non-)existence of readlink() is exactly the kind of thing that must be probed for. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] I don't really think it is a question of bright people and dumb people, but rather people who can see the game they're playing and those who can't. -- Joe Cosby
Re: Problems Re-Implementing Parrot Forth
Dan Sugalski wrote: The only real option here is to maintain your own stack and leave its PMC in one of the registers. Should we move the user stack out of the interpreter context? leo
Re: incremental collector and finalization
Jeff Clites wrote: Hi Leo: I was reading over you incremental GC posts from about a month ago, and read the referenced paper--quite nice work you've done in implementing the ideas there. I have one question: What about finalizers? I may have just missed it, but it would seem that calling finalizers would require another sweep over the items newly resident on the free list (the left-over items in the from-space), which would (unfortunately) take time proportional to the number of freed object. I think that the destroy and finalize actions should get separated, the latter would be a new vtable. The Cdestroy vtable is responsible for freeing system resources like malloced memory. Cfinalize should do more highlevel destruction like closing DB connections. Objects that have finalizers would need special handling (as well as objects that need timely destruction). We could probably allocate such objects from a special PMC pool, so that we don't have to sweep over all PMCs. There is of course still the problem of ordered finalization and destruction. leo
Re: __init not being magically called?
William Coleda wrote: Didn't __init used to get magically called when you new'd a class? It is called. See t/pmc/object-meths.t. Is it in the correct namespace? leo
Re: No Autoconf, dammit!
On Mon, Sep 20, 2004 at 08:36:04AM -0400, Chip Salzenberg wrote: : According to Larry Wall: : On Sat, Sep 18, 2004 at 12:27:36PM -0700, Jeff Clites wrote: : : Ha, I'm sure it could probably be done, but of course most of what : : the shell does it invoke other programs, so in the common case it still : : wouldn't give you portability to non-Unix-like platforms. : : Just translate it to a language that has most of Unix semantics built-in. :-) : : Unless I've lost the thread of this discussion, that won't work. : Microparrot can't be built with e.g. a call to readlink(), because the : (non-)existence of readlink() is exactly the kind of thing that must : be probed for. Sorry, I've obviously been overusing smileys lately. Tell you what, I'll start putting two smileys when I'm really joking. :-) :-) Larry
Re: __init not being magically called?
Yup. See languages/tcl/lib/tclword.imc (in namespace TclWord). Called by languages/tcl/lib/parse.imc (in namespace _Tcl). Without the explicit call to init, it's not being called (as a debug print in TclWord's __init shows for me.) (And, since the initialization of the object isn't done, future use of the object barfs, and my test suite dies.) Though, someone else on the list said that it WAS working for them, with or without. Again, I'm on OS X 10.3 here, if that matters. A. This is just a symptom of something else, as parrot's test suite is failing that test for me. Let's try this again... (make realclean;perl Configure.pl; make; make test). Ok. Parrot is now passing 100%. Removing my explicit call to __init... and I also pass 100%. (Note to self, don't use make -j) Regards. On Mon, Sep 20, 2004 at 02:41:10PM +0200, Leopold Toetsch wrote: William Coleda wrote: Didn't __init used to get magically called when you new'd a class? It is called. See t/pmc/object-meths.t. Is it in the correct namespace? leo
[perl #31643] [PATCH] target 'dynclasses' in root makefile
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #31643] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31643 Hi, this patch adds the targets 'dynclasses' and 'dynclasses-clean' to 'parrot/Makefile'. The new targets are just proxies for the appropriate targets in 'parrot/dynclasses/Makefile', CU, Bernhard -- /* [EMAIL PROTECTED] */ GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ make_dynclasses_20040920.patch Description: Binary data
[perl #31644] [TODO] Encoding mangling on input and output
# New Ticket Created by Dan Sugalski # Please include the string: [perl #31644] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31644 Right now we don't do any string encoding twiddling when doing IO. We also store all our strings internally as either iso-8859-1 for strings with only 8-bit codepoints, UTF-16 for strings with all codepoints less than 64k, and UTF-32 for the rest. This is fine, but most files want all UTF-8 or UTF-16. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Python bytecode volunteers...
Well, we were shooting for an end-of-August release, but needless to say that's not happened. Both Leo and my translators were reasonably near completion, and need to be pushed that final bit of the way. Neither of us have the time, so... Anyone want to take a shot? Leo's builds faster code but mine's a bit clearer, and both could be mined for ideas for a third, completely different one. (Or you could go the IronPython route and reimplement the parser, which works too) Anyone care to take a shot? Should be informative, regardless of how far you get. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
mod_parrot 0.0
i've just uploaded the mod_parrot source: http://www.smashing.org/mod_parrot/dist/mod_parrot-0.0.tar.gz this initial release allows you to register a parrot content handler and encapsulates apache's request_rec structure in a parrot object. unlike the original version, the current mod_parrot uses NCI exclusively -- no new PMCs or opcodes. that's really all it does right now, but in all honesty, getting to this stage should be the hardest part. here's an example of a simple handler: httpd.conf: ParrotInit /path/to/ModParrot/init.pbc ParrotLoad /path/to/my/handler.pbc Location /parrot/squawk SetHandler parrot-code ParrotHandler MyApp /Location handler.imc: .namespace [ 'MyApp' ] .sub _handler .local pmc r load_bytecode '/path/to/lib/Apache/RequestRec.pbc' find_type $I0, 'Apache::RequestRec' r = new $I0 r.'puts'(You said ) $S0 = r.'args'( ) r.'puts'($S0) r.'puts'(\n) .end this is just a start, but it's already a very convincing demonstration of how far parrot has come since the original mod_parrot. what i'd like to see when this is done is HLLs making use of the interfaces and classes provided by mod_parrot to implement mod_perl, mod_python, etc. this way we can write the Apache layer once instead of once for each language. i'm very interested in people's thoughts on this. enjoy! -jeff
[perl #31646] [TODO] Compile/eval/whatever system a bit of a muddle
# New Ticket Created by Dan Sugalski # Please include the string: [perl #31646] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31646 We need to clean up the docs and pmcs for compilation, dynamic compiler modules, and the associated pmcs (eval, compiler, and so on). -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Compile op and building compilers
Okay, this is coming up again and I want to get it nailed down. Current semantics, as defined: $Px = compreg $Sy returns a compiler for language $Sy. compreg $Sx, $Py defines $Py as the compiler for language $Sx. $Px = compile $Py, $Sz uses compiler $Py (from a compreg call) to compile the source $Sz and return a sub $Px for it. That sub may then be invoked as need be, stuffed in a namespace, or whatever. That's fine, it works, woohoo and all. (Though I'm not sure the same-name-swapped-args compreg for finding and registering's a good idea. Or, rather, I think it's a bad idea, my fault, we should fix) Now, the issue is how to actually build a compiler. Right now a compiler is a simple thing -- it's a method hanging off the __invoke vtable slot of the PMC. I'm not sure I like that, as it seems really, really hackish. Hacks are inevitable, of course, but it seems a bit early for that. (We ought to at least wait until we do a beta freeze...) On the other hand it does make a certain amount of sense -- it's a compilation subroutine we're getting, so we ought to invoke it, and I can certainly live with that. Time to weigh in with opinions, questions, and whatnot. There's not much reason to JFDI and make the decisions final, so weigh away and we'll just nail it all down on wednesday. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Namespaces...
Okay, I'm back from last week's workshop and digging through mail. Once I finish reading the namespace threads, I'll rework the proposal and we can give it a good thrashing, then implement it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #31649] [TODO] Win32 - Automatically Export Symbols
# New Ticket Created by Will Coleda # Please include the string: [perl #31649] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31649 Annotate the declarations with something like PARROT_API Parrot_some_func and define PARROT_API, eg for cl, as #ifdef PARROT_EXPORTS #define PARROT_API __declspec(dllexport) #else #define PARROT_API __declspec(dllimport) #endif and be compiled with PARROT_EXPORTS defined. At least cl will then know to automatically export the symbol, without additional module-definition file (.def).
[perl #31650] [TODO] Win32 - Event Model
# New Ticket Created by Will Coleda # Please include the string: [perl #31650] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31650 Leo says: Parrot on unixish systems is running two threads: the event thread handles all kind of events (timers, notifications, signals). The IO thread converts signals to events and is intended to run async I/O (which would arrive as signals too). This scheme isn't carved in stone, but it will look somehow like that. Win32 is internally already event based and a lot of these events like a SIGINT (program termination signal) are messages in Win32. So I think that Win32 needs a message loop that handles this kind of stuff. WRT threading there are emulation layers for POSIX threads, but I doubt that these are as efficient as Win32 functions. (Disclaimer: I really don't know much about Win32).
[perl #31651] [TODO] Win32 - Threads, Events, Signals, Sockets
# New Ticket Created by Will Coleda # Please include the string: [perl #31651] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31651 (No details. This comes from TODO.win32)
[perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003
# New Ticket Created by Will Coleda # Please include the string: [perl #31652] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31652 Provide setup and build instructions for Microsoft Visual C++ Toolkit 2003 (http://msdn.microsoft.com/visualc/vctoolkit2003).
