Re: [Chicken-hackers] [Chicken-meisters] Let's have a roadmap, just like the grown-ups

[Felix]

> Plans, also, are one of the few things I can readily help with. My time
> is limited, but in one hour I can come up with more plans than I could
> ever execute by myself in a month :-)

We could need some help with the gazette, Alaric.

>>> I personally don't have any big plans about the core system. What I
>>> thought useful to implement is there, but needs a lot of polishing.
>>> R7RS will come sooner or later. I think CHICKEN should support WG1,
>>> but I'm not keen on putting any work into it.
> 
> I think that's a noble goal, as it's my sincere hope that WG1 scheme
> will lead to practical levels of library interoperability between
> Schemes. This may lead to issues of compatability between Chicken Eggs
> and some form of cross-Scheme library manager - I hope we can resolve
> that by a simple, automated to some degree, way of converting such
> portable libraries into eggs. They'll only depend on each other, SRFIs,
> or the WG1 core, so it shouldn't be too hard to integrate them into the
> egg system.

I doubt that the cross-Scheme library manager will have much impact.
To make it work, it has to be maintained in a centralized manner (even
if physically distributed) and it needs people who actually sit down
and do the work of keeping things in place. Snow, for example, shows
what happens if you just keep things floating in space, without a
central management entity. Just keeping dependencies up to date is a
lot of work, and with the help of salmonella and a lot of tedious
little fiddling we could get the egg-system into a somewhat usable
state. Moreover, portable code libraries don't solve the real-world
problems people have and need libraries for. So I'm quite sceptical
about this. It will just die like so many other attempts.

> We definitely don't want that. We love you, Felix! You've given us
> Chicken, and we need to do what we can to make that be a pleasure for
> you, in exchange for the pleasure and utility it brings us - not a burden.

Thanks, Alaric. I love you too, but get rid of the hat, ok? ;-)

> git allows good workflow here. People can propose patches as "pull
> requests" from their own publicallly-accessible chicken repos, or as
> mailed patches, and a team of "gateway folks" who are qualified to
> reject bad patches can then decide whether to pull them. Linux has a
> system of people in charge of subsystems, who accept patches to their
> subsystem, then "Linux" itself arises from their subsystems being
> merged, as I understand it - so it's possible to make this process
> scalable by spreading it between people.

Actually, I think we should rather slow it down and funnel patches
through chicken-hackers to make sure everybody has a (quick) look.
Linux is an undocumented mess, and Linus merges everything that
remotely looks like a patch, so it is perhaps not the best role
model...

> It'd be good for people to grab bugs they know they can't fix alone, and
> ask Felix (for now) for guidance and tips on where to start. Then,
> slowly, they'll start to understand the parts of the system they work on.

Yes, that would be nice.

>>> - rewrite the scheduler, perhaps rethink the whole threading stuff
>>>   (srfi-18 is complicated and error-prone and particularly uninspired,
>>>   being mainly a port of pthreads/java to Scheme)
>>
>> This will need a good plan and some engineering but definitely solvable.
> 
> If I have some time, I'd kinda like to do this. Schedulers are a bit of
> a Thing of mine. Perhaps I'm a megalomaniac... or perhaps I just wish I
> had a train set as a kid...

You didn't have a train set? Christ - that's serious!

Well, as a matter of fact, you *could* help with the gazette...

> 
> Felix, if you give me a quick rundown of where the scheduler is and what
> its responsibilities and interfaces are (even if that's just pointing me
> to all the places to look in the code) I can:
> 
> 1) Try and become some kind of expert on it, so I can at least guide
> others to where problems might be, for them to fix them
> 
> 2) Try and come up with a design for a new scheduler
> 
> 3) Maybe implement it myself
> 
> How about that as a start?

That's a very generous offer. If you really like to go into that, you
are very welcome. "scheduler.scm" holds the main body of the code and
there is an interrupt handler in "library.scm" (##sys#interrupt-hook)
that is quite important, in addition to the basic primitives for
creating threads. "srfi-18.scm" holds the hreading API and accesses
thread and scheduler data-structures in a very lowlevel manner.  If
you want, study it and ask as many questions as you like.

> 
>> Maybe we should priorise all the points that have been mentioned
>> so far? This will keep us busy all year (the next one too) and it
>> is easy to get lost in details. I would prefer a sequence of small
>> steps in the right direction.
> 
> Shall we put them on a wiki page, so we can order them for priority, and
> ask Felix to attach notes pointing to where to find out more under each?

We should perhaps talk about this (in RL or on IRC). I think putting
up priorities isn't that easy. It might be reasonable that we just do
whatever we enjoy most. Otherwise it'll never get done.

>> Termite comes to mind, this should also be fixed either way. I would
>> forget about native threading and make it easier to talk to processes
>> (local or remote).  Threads will die soon.
> 
> I agree entirely. There may be some scope for running multiple
> independent Chickens as threads within a single process, purely to allow
> some level of zero-copy messaging between them, but that's probably more
> effort than it's worth. A nice Erlang clone would be a better direction
> to go in than threads + mutexes + etc.

Having multiple execution contexts would be nice indeed. On the other
hand it would be quite a piece of annoying and tedious work.

> Heheheh! I think we should buy Felix a nice present, to be honest. To
> say thankyou. I'd put £50 in the pot for that, without batting an
> eyelid. More if I have a chance to save up.

No present. Absolutely not. Because:

> 
>> I would like to concentrate on code. Programming, you know?
> 


cheers,
felix