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

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

> 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
-- 
http://www.more-magic.net