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 _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
