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

[F. Wittenberger]

Hi Elf,

Am Dienstag, den 19.08.2008, 08:35 -0700 schrieb 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?

Please safe both of us from personal attacks.

I'm open to all sorts of grounded suggestion how to get things done.

I'm closed to all advices of costly and risky operations.  There's
little reason to change a few thousand lines of a working code base,
when it's easier to do it in a compatible way.  Especially since I'm
rolling changes into the development network regularly.  If I break it
the code, my phone is going to ring pretty soon.  Eventually I'm simply
not entitled to break it.

> > a) a broken SRFI-34 egg - something easily ignored
> >
> 
> easily ignorable, as we have srfi-12, and thats not going to be changing.

Did you get my point?

It's easier to do SRFI-34 right than changing partially foreign code.

It's a bad advertisement for chicken to provide broken SRFI-34 on it's
website.

But while it does, that's easily ignored *by me* using a working srfi-34
implementation, not the egg.

So what are you advocating?  Send all users who just pick the egg and
get their work done to repeat the debugging?  Change all code out there
to use srfi-12?  I don't get it.

> > 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

Academic question: What is it then?

>  and your code did not accomplish anything useful.

I'm afraid this sounds like a lot of a mouthful.  Sorry.

It's not the first time I run into this issue.  When I did, I reported
the problem to the developer of the System - without a patch, since I
was not able to fix it myself.  It took him merely overnight to fix it.
The next time I ran into the very same trap myself.  Now it's at least
the 3rd time I'm seeing a select-loop running into the issue.

This is nothing, which anyone could take personal.  You shouldn't take
it that way either.  I'm producing bugs for a quarter of a century.  We
all do.

About not accomplishing anything useful: it changes a test case from
failing to not fail and a large, complex program from working for a few
minutes to working for hours (usually, modulo this (c) case).  I do
count this as useful.  After all, it's my mail - including this message
- which depends on the fix.

> errors of the type you mentioned are already handled, correctly,

It appear to me, that I can't find the ground on which your claim is
based.  Maybe it's there, but then please show me the code, which is
supposed to handle the case.  Maybe it can be made to handle it
actually.

I'm not at all sticking to the few characters I typed.  Anything, which
accomplished the same task is ok with me.

Just there is this problem, I found a way to fix it and - as I said -
I'm open to all sorts of grounded discussions.  If it should be handled
elsewhere or different way, fine.  But it ought to be handled.

(As a sidenote: to be really sure, I removed the fix from my code:
join-timeout-exception - but the joined thread runs.

>  in the part
> of the code that you ripped out and put something nonsensical in its place.

off topic, personal attack - or give reasons

> > 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.

I will eventually release it.  But I'll save you and all from diving
into large amounts of code, when it's already down to [compiled with
(disable-interrupts)]:

(let ((pid (process-fork)))
  (if (eqv? pid 0)
    (begin
      (duplicate-fileno tr 0)
      (duplicate-fileno fw 1)

      (close-all-ports-except 0 1 2)

This is a temporary, half baked safety measurement.  Since ##sys#fd-list
is not accessible from outside, I'll forcefully close FD_SIZE fd's
except those in the arg list.  Just to be sure the external program will
be unable to interfere with my fd's.

But somewhere here, the problem arises.  Rarely though.

      (process-execute ....)
    (_exit 0))

> > 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.

so far we know

> it doesnt NEED to be in chicken core,

agreed

>  nor is it desirable for it to be in chicken core.

So (again) *why* is it not desirable?  The claim alone makes a boring
read.

I gave at least a reason, why it would be good to be in chicken core: it
would make chicken more useful.  Not in the core implies overhead and
repeated code.

> 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?

sorry, I'm not a native English speaker.  I'm afraid I did not get that.
So let me try to answer the best I can deduce.

I had some code to port to chicken, which happened to use
make-parameter.  Once ported it did not work as expected.  So I asked
the list thankfully received an answer, which explained to me, that
srfi-39 may be interpreted this or that way.  Once I understood, I found
the (IMHO) best place to add it and proposed the change.

Since then we are discussing.

In the meantime I continued without that change, since it's not
essential, can be done without touching chicken core and *might* be not
interesting to others.  (Very much in contrast to the race above, which
might be rare [it is usually], but there.)

> > 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.
[...]

off topic, personal attack, hardly grounded.  OK?

Please stay calm.  It's hard for me too in this situation.  What do you
attack me for?

> > 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.

I hope you patented "evaler" before releasing the egg!  Otherwise I'm
afraid that I just understood it as a shorthand for an everyday concept.

> 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.

As long as you're repeating that a case is handled, for which I can't
find the code, but produced a test case, which is not handled, I'm
afraid it's not me, who is ignoring the other one.  Right?

your friendly monkey typist

/Jörg