Re: Guaranteed object destruction (was Re: Meta-design)
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 05:55 PM 12/7/00 +, Piers Cawley wrote: > >Dan Sugalski <[EMAIL PROTECTED]> writes: > > > I think I'd just as soon always call DESTROY in a predicable manner > > > and not do *anything* perlish at GC time. If nothing else it means > > > that we don't have to worry about having a valid perl context handy > > > when the GC runs. (Since threading the thing is a possibility we > > > might run into issues otherwise) > > > >So objects that get caught up in a circular reference chain don't get > >their DESTROYs called? I'm not sure I'd be up for that. In fact, I'm > >sure I *wouldn't* be up for that. Or are we gonna still need 'use > >WeakRef'? > > The problem there is that there's no good deterministic way to catch that short > of doing a full mark and sweep (or something similar) each time we toss a pad > that's got references in it. I suppose we could track pad references and > variable references separately and do a quick walk through things when we trash > a referring variable or pad, but I can see that getting expensive. Maybe. (On > the other hand, if it's correct...) I wasn't arguing for doing a full mark & sweep at every block end. I was saying that we may still need to call DESTROY at mark & sweep time even if most DESTROYable objects get DESTROYed in a simple refcount phase at block end. (Having noted that we only need to do that kind of thing for blessed refs). This would tend to imply that we should keep WeakRefs lying around so that concientious programmers with circular data structures that they want to be DESTROYed immediately can arrange things so that can happen. -- Piers
Re: Supporting architectures without native C support (was Re: Meta-design)
On Sat, Dec 09, 2000 at 05:06:27AM -0500, [EMAIL PROTECTED] wrote: > > Because the Python folks didn't have a problem basing JPython off of > > CPython. > > Actually, this one isn't a good comparison. Python is substantially easier > to parse, and, is a much simpler language. I like Perl because it is more > complicated, but that also comes with a burden that we design its > implementation more carefully. > > Larry worked for a summer trying to mold the C implementation of Perl into a > JVM port. I have spent substantially more time than that on it than that. > It's a hard problem. I'll be happy to send you chapters of my Master's > Thesis that I am finishing up this month, that is making the detailed > arguments as to why it is a hard problem. Yes please. > I believe the difficult that we've had porting perl5 to the JVM is a bug in > perl5's design. I am trying to encourage people to fix that bug in perl6. OK! -- May the best description of competition prevail. (via, but not speaking for Deutsche Bank)
Re: Supporting architectures without native C support (was Re: Meta-design)
On Mon, Dec 11, 2000 at 08:18:05AM -0500, Joshua N Pritikin wrote: > On Sat, Dec 09, 2000 at 05:06:27AM -0500, [EMAIL PROTECTED] wrote: > > > Because the Python folks didn't have a problem basing JPython off of > > > CPython. > > > > Actually, this one isn't a good comparison. Python is substantially easier > > to parse, and, is a much simpler language. I like Perl because it is more > > complicated, but that also comes with a burden that we design its > > implementation more carefully. > > > > Larry worked for a summer trying to mold the C implementation of Perl into a > > JVM port. I have spent substantially more time than that on it than that. > > It's a hard problem. I'll be happy to send you chapters of my Master's > > Thesis that I am finishing up this month, that is making the detailed > > arguments as to why it is a hard problem. > > Yes please. Yes, *PLEASE*. Some hard data is always nice, even when (or especially when) it's unpleasant to hear. > > I believe the difficult that we've had porting perl5 to the JVM is a bug in > > perl5's design. I am trying to encourage people to fix that bug in perl6. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Supporting architectures without native C support (was Re: Meta-design)
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: [Re: Giving data about why it's hard to use B:: to port to the JVM] > Yes, *PLEASE*. Some hard data is always nice, even when (or especially > when) it's unpleasant to hear. I won't have "hard numbers", as it is always completely possible that some clever hacker could find a way that I couldn't. What I will do is document what I tried, why it isn't easy, and what would have to change to make it easy. It's always a subjective process when you try to make the case that something is "hard to do", from a programming point a view, given that the Turing indicated that it can be done by a program in polynomial time. There is not a definitive way to "prove" coming up with that polynomial time algorithm is hard. ;) -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
