Re: [Chicken-hackers] [PATCH] Fix #1133

[Jörg F. Wittenberger]

OK, since Peter mentioned me…

Am 28.06.2014 12:40, schrieb Peter Bex:
> On Sat, Jun 28, 2014 at 12:18:24AM +0400, Oleg Kolosov wrote:
> > Looks like it is mostly setup api that pulls POSIX. Making it optional
> > along with csc and friends will allow us to strip the core much more.
> > And they are hard to port to Windows (native) anyway.
> If I understand correctly, you propose replacing chicken-install with
> cmake, but that's only able to compile things.  Without the setup-api,
> how are egg dependencies specified and how are the eggs downloaded and
> managed?  (ie, listing, installation and removal of the eggs on a
> particular system)

I'm even a fan of not depending on cmake at all. Instead I'd favor a 
pure Scheme based make process. However I found the plt make macro a 
little cumbersome to use, and hard to express generation of and 
dependencies on .import.scm files, I extended it a little and wrote a 
Scheme-language make process for chicken to test it.

Why? a) reduce dependencies b) reduce mental load for developers c) 
Scheme makes some things sooo easy, we could have this make look into 
the module declarations and figure out the dependency hell itself.

This does not solve the configuration according the system. That's where 
I'd like to draw the line: have autoconf, cmake or whatever test system 
capabilities. The build process should not be separate. (Plus: I'd like 
it in Scheme; though that's more the personal taste of mine.)

> > > - I would like to move srfi-18 to an egg as well, only keep the scheduler
> > >    and the internal threading-stuff in library.scm in core.
> > Maybe it makes sense to expose some of that to make it easier to
> > implement stuff like concurrent-native-callbacks?
> Suggestions?  Right now there's already the ##sys#thread stuff that
> srfi-18 itself uses.  I think there's not going to be a whole lot
> of opportunity for exposing more stuff.  If we're going to extract
> srfi-18 into an egg I do agree we need to take a closer look at the
> exact API it exposes.  Right now threads are limited in what objects
> they are able to block on.  If we change that after making an egg it
> will be more difficult.  I think Jerry said he was working on improving
> this.

Yes. And all this time I feel guilty that I don't have the time to 
eventually sit down and pull those modifications over.

Also scheduler.scm mentions ";; This should really use a balanced tree:" 
I'm using LLRB trees for the queues instead.


In fact I recall that there was even a fix, but also I recall that 
forgot to document the problem.

I did re-factor quite some things between the scheduler and srfi-18. And 
I'm all in favor of a smaller scheduler API and alternative threading 
implementations atop (like this:
http://lists.nongnu.org/archive/html/chicken-hackers/2012-05/msg00014.html

Furthermore I'm in favor of a slight modification of the thread 
structure, which would save my code a few allocations and indirections.

Quite a can of worms.

> > We are hooking logging system (extracting file, line number information
> > basically) through user-passes. There are also potential use cases like
> > externally getting module dependency information (sort of like gcc -M
> > options). It is a nice feature to abuse.
> That's a pretty cool hack!
>
> Cheers,
> Peter