[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jörg F. Wittenberger
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Sun, 29 Jun 2014 11:57:24 +0200
User-agent: Mozilla/5.0 (X11; Linux armv7l; rv:24.0) Gecko/20100101 Icedove/24.5.0

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

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:

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]