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

[Oleg Kolosov]

On 06/29/14 13:57, "Jörg F. Wittenberger" wrote:
> 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)

So far I've settled on generating CMakeLists with predefined macros for
building things and leave setup-api as is for downloading and managing.
Leverage CMake for figuring out system dependent things. I have
experimental implementation which downloads with chicken-install -r,
then builds everything. It is not very user friendly yet but works few
times faster than chicken-install.

It should be straightforward to write some converter for .setup files.

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

There are no problems with generated dependencies in my CMake macros. We
are using them in our Chicken Scheme based application with few external
C libraries, 40+ eggs and 50+ internal modules without major problems. I
even support emitting and using type and inline files automatically. But
I agree that CMake syntax can be quite ugly for non trivial things.

>From the package maintainer point of view idiosyncratic build systems
are the worst offenders of widespread adoption.

I'm currently experimenting with automatic dependency extraction.
Unfortunately, apart from make with gcc -M combination, toolchains do
not expect dependencies jumping into the build graph when the process
already started. Also this breaks parallel compilation. I have some
ideas but not yet figured out how to handle this cleanly.

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

Is there a clean way to offload some work to native threads (pure C)?
Calling back from C triggers minor GC AFAIR, which I think can hurt
performance. Threads should have their own stack making this
unnecessary. Maybe I'm wrong.

-- 
Regards, Oleg