chicken-hackers
[Top][All Lists]
Advanced

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

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


From: Oleg Kolosov
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Sat, 28 Jun 2014 00:18:24 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 06/27/14 18:41, Felix Winkelmann wrote:
>> Depending on how large the subset of procedures is we could perhaps pull
>> a simplified version of them into core and optimise that to hell, and
>> excise the slow remaining crap from core and move it to an egg (we
>> already have some duplication like foldl vs fold and string-intersperse
>> vs string-join).  But I'm really not sure, I'd have to investigate.
> 
> That might be a good idea. Some of the SRFI-procedures are more
> general than we need.

Sounds like candidates for "lolevel subset" APIs. There are also a room
for leveraging Chicken close relationship with C when optimizing code.
We have some bottlenecks where Scheme is "too high level" but using its
C API directly is too troublesome. It would be nice to have some more
low level stuff conveniently exposed to Scheme side.

>>> Take windows into the equation and things get even worse. POSIX is not
>>> the most ideal API "standard", but at least it is something one can
>>> start with, even if Windows support is somewhat painful.
>>
>> Hehehe, "somewhat" :)  But you're right, most of what POSIX offers is
>> valuable and needs to be deeply integrated in core in order to provide
>> good support so it makes sense.  Still, I like the idea of having only
>> completely portable stuff in core, so that programmers know that if it's
>> in core, it's going to work everywhere.  That can save a lot of headaches
>> when porting an application to Windows, or CHICKEN to a completely new
>> platform.

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.

I have an experimental CMake based Chicken branch where these are not
needed. Basically, the agenda is to use CMake to detect as much as it
can during compilation, generate bigger chicken-config.h, and get rid of
the most platform specific stuff in the core. Write dumb versions of
csc, chicken-install, etc. which just generate CMakeLists with
predefined macros to provide smooth migration path.

Does it sounds worthwhile?

> I would propose something like this:
> 
> - identify stuff that's not used in core and move that to eggs, for example:
> 
>   memory-mapped files
>   binary-search (this screams out to be implemented as a functor)
>   queues
>   ... much more, of possible ...
> 
> - Completely restructure all library units (extras, data-structures, files,
>   ports, lolevel, posix, utils). tcp and foreign stay as they are.
> 
> - irregex is used in core and will benefit from as much core-support as
>   it can get, so leave it as it is, as well.
> 
> - re-implement/copy stuff from SRFI-1/13/14 for internal use only,
>   move the rest into eggs.
> 
> - 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? I briefly investigated
the possibility to integrate it with libuv event loop and the internals
looked quite nasty.

> - srfi-69 can go to an egg. It is only used in chicken-profile, and
>   can be done using internal (symbol) hash-tables.
> 
> - I think srfi-4 can be eggified, too.
> 
> - Provide wrapper eggs for all the library units that are gone
>   (extras, ports, files, data-structures).
> 
> - I'm not sure about posix. Perhaps split this into higher-level
>   modules (eggify, if not needed in core) and keep a lower-level
>   interface in core.
> 
> - Use modules for the compiler. It is not used externally (well,
>   with the exception of user-passes, which nobody uses, I guess)
>   and would need some restructuring as well. But this may be a
>   first attempt at using modules internally.

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.

> 
> Does this make sense? 
> 

Looks like great plan overall.

-- 
Regards, Oleg



reply via email to

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