Re: [perl #19349] [PATCH] mark PMCs - take #2
At 1:50 PM + 12/22/02, Leopold Toetsch (via RT) wrote: Here is another approach, to finally unify the marking routines: - next_for_GC remains what it is - instead of current_end_of_list and a return value, mark_used() uuses a file static mark_ptr. As we don't have recursive DOD runs, this ought to be safe. Nope. Threads. Two interpreters can be DODing at the same time. Static variables aren't tenable for much of anything with threads... :( -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19232] [PATCH] UINTVAL_SIZE is not defined
On Wed, 18 Dec 2002 09:19:46 +, Nicholas Clark wrote: >Is the tendra compiler free? I've tried to find it before, but couldn't >manage to get a functional download URL. Note: all the info below is summarized from the project web pages; I have no personal experience with TenDRA. The original TenDRA project (sponsored by DERA) became defunct in 1998. Patryk Zadarnowski has a copy of the original web pages, but the download links are broken: http://www.cse.unsw.edu.au/~patrykz/TenDRA/ tendra.org now hosts a (very active) revival of the TenDRA compiler, derived from the last DERA-sponsored release. All the code is open-source, but all their new work is BSD-platform specific. Just this month, they switched to a build system that should allow re-porting to Linux. http://www.tendra.org/ They have links to their last 6 weeks of CVS snapshots. Also, they have links to the 1998 DERA version that was missing from Patryk's copy. This version supported Linux, and several other platforms. http://www.tendra.org/download/ The Debian project has the 1998 DERA version pre-packaged: http://packages.debian.org/stable/devel/tendra.html http://packages.debian.org/stable/doc/tendra-doc.html http://packages.debian.org/unstable/devel/tendra.html -- Hope this helps, Bruce Gray
Re: [perl #19356] [PATCH] creating string_destroy()
At 9:42 PM + 12/22/02, [EMAIL PROTECTED] (via RT) wrote: This patch creates a new function string_destroy(), as described in docs/strings.pod, and motivated by TODO item grep docs/strings.pod for unimplemented functions and implement them Hrm, we need to fix that file. strings shouldn't have destroy methods, as they're not active enough to warrant it. That was, IIRC, in there because we thought we may need to free the memory or something of the sort. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19349] [PATCH] mark PMCs - take #2
On Mon, Dec 23, 2002 at 01:37:18PM -0500, Dan Sugalski wrote: > At 1:50 PM + 12/22/02, Leopold Toetsch (via RT) wrote: > >Here is another approach, to finally unify the marking routines: > >- next_for_GC remains what it is > >- instead of current_end_of_list and a return value, mark_used() uuses > > a file static mark_ptr. As we don't have recursive DOD runs, this > > ought to be safe. > > Nope. Threads. Two interpreters can be DODing at the same time. > Static variables aren't tenable for much of anything with threads... > :( Unless protected by a mutex. I have now read the programming POSIX threads book. I take it that makes me a fully qualified l33t threads d00d who knows everything. How much of a speed impact could it be to serialise DOD runs between threads? Presumably 1 thread doing a DOD run could actually manage to free up enough memory to make both happy? Nicholas Clark
Re: Tcl, Mark II
At 3:13 PM -0500 12/22/02, Will Coleda wrote: I recently (re) posted my stab at tcl. I quickly realized that I was very out of date with the current development path. Here's a copy that works with (nearly) cvs latest, and switches to imcc as the output instead of directly to pasm. Cool. As I know very little about Tcl... how much of it is implemented with this? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19349] [PATCH] mark PMCs - take #2
At 8:57 PM + 12/23/02, Nicholas Clark wrote: On Mon, Dec 23, 2002 at 01:37:18PM -0500, Dan Sugalski wrote: At 1:50 PM + 12/22/02, Leopold Toetsch (via RT) wrote: >Here is another approach, to finally unify the marking routines: >- next_for_GC remains what it is >- instead of current_end_of_list and a return value, mark_used() uuses > a file static mark_ptr. As we don't have recursive DOD runs, this > ought to be safe. Nope. Threads. Two interpreters can be DODing at the same time. Static variables aren't tenable for much of anything with threads... :( Unless protected by a mutex. I have now read the programming POSIX threads book. I take it that makes me a fully qualified l33t threads d00d who knows everything. How much of a speed impact could it be to serialise DOD runs between threads? Presumably 1 thread doing a DOD run could actually manage to free up enough memory to make both happy? If the interpreters are reasonably separate, then one won't affect the other, except in cases where the system has exhausted the memory available to the process, so there's not a huge reason to do this. Also, it is a choke point. Since the interpreters are generally separate, the better place for this is in the interpreter structure. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tcl, Mark II
Dan Sugalski wrote: At 3:13 PM -0500 12/22/02, Will Coleda wrote: I recently (re) posted my stab at tcl. I quickly realized that I was very out of date with the current development path. Here's a copy that works with (nearly) cvs latest, and switches to imcc as the output instead of directly to pasm. Cool. As I know very little about Tcl... how much of it is implemented with this? Ahem. That's actually rather embarrasing. =-) 4 commands currently work, out of a base set of several dozen (some of which have many subcommands). Right now, set, append, puts, and exit. =-) I had basically done the parser months ago and ran out of tuits. The parser is fairly complete, however, and handles all (I think) of tcl's syntax. (Parsing is the hard part. Defining more commands should be a simple matter of programming.) I recently gained momentum, and with imcc, I should be able to do quite a bit more. My general plan currently is: 1. Move everything but the parser into imcc. (right now I still am manually emitting imcc when a command is done parsing, rather than simply defining all the builtin commands in imcc and call'ing it.) 2. Write two PMCs, one for scalars, one for arrays. (perhaps one for lists, but I doubt it.). I can't just use strings (well, I am now, but I can't continue much longer), and the generic scalar PMC doesn't let me do things like "2" + 1. 3. Implement the rest of the easy commands. 4. Move the parser into imcc instead of perl. 5. The rest of the hard bits. ... Though the list is subject to change. Guess I'll have to churn another version out now that I've actually got Dan's attention. =-) -- Will "Coke" Coleda
