Re: [Chicken-users] egg announcement: remote-repl

[Elf]

On Tue, 19 Aug 2008, Jörg F. Wittenberger wrote:

> There are IMHO more important things we should concentrate on.  There's
> still

where did this come from?  did you cut off what you wre responding to?
> a) a broken SRFI-34 egg - something easily ignored

easily ignorable, as we have srfi-12, and thats not going to be changing.

> b) a race condition in the scheduler (which's fix I meanwhile fixed wrt.
> to multiple threads waiting for the same fd, though I would not expect
> that to ever happen; but I got tired of reposting) - this one definately
> needs to be handled by the scheduler; it's impossible to overwrite the
> relevant part (at least if the doc's are right [hint]) and absolutely
> necessary if you don't want your progs run havoc when a fd becomes
> invalid for whatever reason.

its not a race condition and your code did not accomplish anything useful.
errors of the type you mentioned are already handled, correctly, in the part
of the code that you ripped out and put something nonsensical in its place.

> c) Sometimes I get my app eating all memory just after a fork and before
> I come to process-execute.  Since I disabled interrupts in this section
> already, I'm sort of lost.  If someone had an idea what the hell that
> one could possibly be...

given that ive never seen of these apps that you are making, its a bit 
difficult to say, really.


> Am Dienstag, den 19.08.2008, 06:55 -0700 schrieb Elf:
>
> > > That's what I have been able to do bevor.  That's not the aim.  I need
> > > to change all timeouts for all thread which are started after the
> > > change.
> >
> > then all you have to do is use the environments egg to make or copy the
> > base env before starting the server, and define an evaler to eval certain
> > expressions in that environment rather than the local.
>
> I'm not at all saying it can't be done without adding code to the
> chicken core.  In fact I'm working with a version, which does what I
> need.

this isnt in chicken core.
it doesnt NEED to be in chicken core, nor is it desirable for it to be in 
chicken core.  hence the term 'environments egg' rather than 'adding useful
but peripheral code to chicken core'. 
if you already had something that did what you needed, why were you asking
if this would do the behaviour that you wanted, as you had the facility but
it didnt do what you wanted?

> All I've been advocating where a few additional lines of code to support
> an additional feature *without* workarounds, *sharing* almost all code
> at the cost of one additional comparison of symbols.

all you have been advocating is ill-advised, poorly thought out changes without
even bothering to learn the system you are tampering with.  if you would 
actually read the documentation and code, and ask if you dont understand
things rather than assuming that we're a bunch of idiots who don't know what
we're doing, perhaps we would not be in this constant frustrating nonsensical
looping debate.

> I fact I'm using environments too, for evalers in special environments.
> But I'd consider it an overkill in that context.

no, you arent.  'evaler' is a keyworded argument to the remote-repl setup 
procs, so unless youre using remote-repl, youre not using evaler in any way
related to what i was saying.

> >   if you would read the docs,
>
> You've got the feeling I did not read docs nor code?
>
> That's not the case.

if you had read the docs, or even read what i had said about 5 times on the 
mailing list in the last 3 days, you would have known that.



-elf
>