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

[Christian Kellermann]

* felix winkelmann <address@hidden> [110907 11:22]:
> This touches on the subject of a general development
> roadmap or "strategy", which is probably a good thing to have, as long
> as we don't become too dogmatic about it.

Yes a plan is a good thing. Having inspiration behind the plan is better.
Following a plan without inspiration is the way of the robot.
 
> 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 also need to hack less
> on the stuff, seriously.  I'll become a mindless and depressed
> maintenance zombie if I continue like this. You and the other chicken
> hackers need to get know the core system and compiler more thoroughly
> and there should be more commits from others. This needs some sort of
> "process" (the patch review offered by ckeen recently is one possible
> approach - slow, but thorough and it is IMHO vital to inform all core
> developers of changes that take place, otherwise confusion will arise
> and code-quality suffer. We had this already once). CRs also will help
> to avoid (some) unneeded breakage.

Yes maintenance sucks, and most bugs are more or less easy, *if*
you know how things fit together. That's the reason why you are
doing the fixes on your own and at this speed. I do hope that I
will have enough will to just grab one of these bug reports and
solve them.

> Things that need cleaning up, IMO (in no particular order):
> 
> - use modules to structure the compiler (the most high-level code in the
>   core system)
> - cleanup the chicken-install/setup-[api|download] mess
> - remove and deprecate useless and obsolete stuff (does anybody need
>   locatives?)

Actually it seems that a lot of people use these for the FFI. Maybe
because they lack better knowledge or misleading docs.

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

> 
> Things that are still open or might be suitable goals:
> 
> - fix remaining bugs in module-system and expander
> - extract lolevel, srfi-69 and possibly more (srfi-18?) from the core
>   system (this will need discussion, but I'd like to rip everything out
>   that isn't needed by the basic chicken tools)
> - refactor library functions to give more opportunity for specialization
> - tune library units like srfi-1/13/14
> - this also might be the opportunity to enhance the test-suite to
>   contain tests for as much functionality as possible and to generally
>   give more structure to the tests
> - do some heavy performance-tuning on irregex
> - some fallback mechanism to handle compatibility issues
>   (eggification of core units, deprecation, renaming, etc.) - what this
>   means isn't clear to me, but we still should think about it
> - many things I've forgotten, but I'm sure you'll tell me

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.

> Another issue is native threading. I've seen repeated requests for it.
> I think nobody is really doing himself a service using native threads,
> it has mostly "hype"-value. On the other hand, CHICKEN doesn't offer
> any help with interfacing to threaded code or taking advantage of
> multiple cores for computationally intensive applications. The basic
> execution model does not allow for separate native Scheme threads, but
> at least we could offer multiple, complete execution contexts (which
> will heavily slow down everything, but could be made a build-time
> option and will make it easier to embed) or some sort of built-in
> efficient IPC device. Or something else.

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.

> Also, I've noticed (or think I have noticed) that users get lost in
> the number of available eggs. Tagging, ranking or some other sort of
> "meta"-view of the egg library might be something to think about.

Yes I have been asked about this today as well. But it is so easy
to get lost in details. Maybe we should split those "easy" parts
up into stuff for potential newbies that can ask a "mentor" about
stuff? I know that everyone wants to do the cool and easy stuff but
if we take our list of priorities and look at it we may see some
things that are solvable by someone else and that may be the beginning
of a long....bikeshed on chicken-users...

> 
> BTW, completely unrelated: since Mr Kuhn appears to have forgotten
> about us, why don't we simply ask for donations, without trying first
> to find a suitable umbrella organization or project? I mean, there are
> a lot of users (relatively speaking), some of them happy, which surely
> would like to support us. If we keep things transparent, I don't see a
> reason why we don't just slap a "Donate!" button on our web-site and
> ask for money. Things like SBCL's recent crowdsourcing event show that
> the simple approach might not necessarily the worst. Perhaps that is a
> naive point of view, I don't know.

Ah Mr Kuhn. Ivan, did you tell him good bye already? I've lost track
about this and you probably too.  As for donations I would say yeah,
just ask people. I once thought that transparency might be an issue
but now I am not so sure. Let's put up the donation button and pour
all money into Marios and Alaric's server budgets until they cry
for help because they drown in money.

Why no transparency? Because I see a donation as a gift. Usually
as a person giving a gift I want to show appreciation for something
with the hope of giving pleasure and support through the gift. So
screw the transparency process, say thanks to the donor and use it
as "we" see fit. Alaric too for keeping up kitten-technologies.

If we need rules let's make 'em up as we go.

And if mario goes to lunch with his wife with the money or Alaric's
kids get a new bike that is also fine with me. If anyone else has
continuous expenses and I have not taken note of it please forgive
my ignorance and enlighten me.

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

Kind regards,

Christian

-- 
Who can (make) the muddy water (clear)? Let it be still, and it will
gradually become clear. Who can secure the condition of rest? Let
movement go on, and the condition of rest will gradually arise.
 -- Lao Tse.