Am Montag, den 11.08.2008, 07:28 -0700 schrieb Elf: > absolutely not. > > first, why will it be difficult for you to set up a clean build environment?
Because I'll have to rebind parameterize, which is then going to be available to eval, where it could access parameter objects, which where created with the default make-parameter since I do not know how to rebind make-parameter and be sure to do so before any other parameters are set. Also code compiled with the standard implementation would not work correctly anymore, if those shared parameters where passed in. This all looks to me like the box of pandora full of sources of confusion. > second, your patches will flat out not work in default chicken. > > A) why are you sending a patch of the debian rules customised for your > box? Sorry, this was a mistake. I've been interrupted in the middle of editing. > B) you are fundamentally changing the representation of parameters. Really? At least that (supposed to be - modulo bugs I made) all compatible with the old version. It introduces just two more comparison in the value look up. And one more optional parameter to make-parameter. Does this already qualify as a fundamental change? > C) redundant/unnecessary code - you duplicated a case. I can't see that one. > D) inconsistent naming scheme Which one would be better? > E) there are around 300 occurences of parameters in chicken core. many > eggs use large numbers of paramters. have you tested fully, or even > partially, the effects of changing structure? mucking about with > parameters can and will break just about everything. I have tested the implementation. But to which extend should this be done. The new case applies only if there's a shared parameter object and it is called from the modified parameterize. I had preferred to pass some special key, which the user can not produce, but I don't know how to express that in chicken. The standard case will just ignore the additional argument. Against which possible impact should I test? > third, there has been no consensus and very little discussion regarding > parameter models yet, so methinks you may be jumping the gun. if you want > a shared variable between threads, dont make it a parameter. The point is: there is a large code base, which is supposed to run under different Schemes. I'm trying to find the minimal diff. It's already hard enough and I'm a not entitled to break the deployed version at any time. (I just spent 3 days without success trying to figure why this test case http://lists.gnu.org/archive/html/chicken-users/2008-08/msg00029.html fails if and only if the thread hangs on tcp *and* there are two nested condition handlers (while other ways to hang or just one condition handler will work as to be expected). > if you want > a thread-local variable, parametrise it. i dont see why this requires > changing > core structure. All I need: a thread-local variable and a way to set it's default value from a thread, while accessing the thread-local one within parameterize. How should I do that? > -elf > > On Mon, 11 Aug 2008, Jörg F. Wittenberger wrote: > > > Hi all, > > > > since there where no more responses on my last post to this thread, I > > decided that it might be the best to supply a patch to this list, which > > adds a procedure "make-shared-parameter" extending the existing > > make-parameter in a compatible way. The attached diff (against svn > > revision 11597) should have no impact on the standard procedure > > make-parameter and the parameterize macro. However if the parameter is > > a shared parameter, only parameterize will create a local binding for > > that parameter (or the to-be-undocumented interface: call the parameter > > procedure with a second argument). > > > > I'd appreciate if this could make it into the chicken core - otherwise > > it's going to be a pain to set up a clean build environment in my case. > > > > Best regards > > > > /Jörg > > _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
