Re: [Chicken-users] Installing chicken on windows
> On 08 Jul 2016, at 00:48, C K Kashyap wrote: > > Hi all, > > I am very new to Chicken. I've been able to get started with it on my mac > using homebrew. I am not sure about how to get started on windows though. > > What's a good way to install chicken on windows? The binary installer links > shown on the web page seems dated. > > Can I build chicken using VC? > > Is this the right place to download mingw64 - > http://mingw-w64.org/doku.php/start > I could not find a download link. > > I'd appreciate your help very much. > > Regards, > Kashyap > > ___ > Chicken-users mailing list > Chicken-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-users Hi! The simplest way is to install pre-packaged CHICKEN, see https://wiki.call-cc.org/platforms#microsoft-windows- I guess the available binary packages are dated because in 4.10 CHICKEN changed ABI and build requires bootstrapping which is a pain and nobody bothered because Windows is not popular here. No, you can't build it using VC either. A build system requires GNU make and code has some GCC'isms and UNIX'isms. Core can be fixed with a few relatively trivial patches but supporting utilities (chicken-install and friends) can not, so you wont be able to install eggs. I had the patches in my CMake based CHICKEN fork but abandoned it due to lack of public interest. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in csc -deploy on OSX
> On Jul 30, 2015, at 16:41, Ryan Senior wrote: > > I think I have found a bug in the linkage of OSX standalone binaries. I run a > command like: > > csc -deploy nodes-script.scm > > I get a nodes-script directory with two files like I would expect: > > $ ls nodes-script/ > libchicken.dylib nodes-script > > But when I run otool -L on the nodes-script binary, it shows that it's linked > with the system libchicken, not the one included in the nodes-script > directory: > > $ otool -L nodes-script/nodes-script > nodes-script/nodes-script: > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility version 150.0.0, current version 1153.18.0) > /usr/local/lib/libchicken.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1213.0.0) > > Is this a bug? I went through the same process on a Debian VM and found the > binary was linked correctly (i.e. the nodes-script binary was linked to the > local libchicken). > > I have installed chicken via 'brew install chicken', with version info below: > > $ csc -version > (c) 2008-2014, The Chicken Team > (c) 2000-2007, Felix L. Winkelmann > Version 4.9.0.1 (stability/4.9.0) (rev 8b3189b) > macosx-unix-clang-x86-64 [ 64bit manyargs dload ptables ] > bootstrapped 2014-06-07 I've reproduced this in the same environment, but with manually compiled 4.10.0rc4 otool shows: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1153.18.0) @executable_path/libchicken.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) Looks like this was fixed already. — Regards, Oleg Art-System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-announce] CHICKEN 4.10.0 release candidate 4 available
> On Jul 27, 2015, at 15:02, Peter Bex wrote: > > It gets "hardcoded" into chicken-config.h the first time you run make. > If you run make with a different C_compiler later on, it will only use > that C compiler to compile the C files, but "csc" will use the C compiler > from chicken-config.h. The reason behind this probably is so that you > can configure a C compiler which is different from the host compiler, for > example when cross-compiling. > > It sure can be confusing, though :) I've debugged this problem some time ago. I barely remember that there was some issue with test environment itself, not the compiler. But, unfortunately, I forgot what it was exactly. AFAIR my CMake based test suite was able to run all tests just fine, but there was not much interest in including it into the core, so it stuck in "works for me" stage. — Regards, Oleg Art-System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] How to compile chicken scheme to Windows DLL?
On 13 Feb 2015, at 15:44, Ryuho Yokoyama wrote: > > Hello, > > I am attempting to compile the chicken scheme code down to C > and then compile it into a Windows DLL. > > But I can not how to initialize chicken scheme runtime system > in the DllMain function. > > Please someone show how to write a scheme code which produce a Windows DLL > and compile option etc. > > Chicken Ver 3.4.0 > MinGW(mingw-get-inst-20110802.exe) > I did not understood your intention. Assuming that DLLs produced by MinGW gcc is not what you want you can try my https://github.com/bazurbat/chicken-scheme next branch which can produce Windows native DLLs using Visual Studio compiler with the help of CMake. Be careful though as this branch contains a lot of other experimental changes and not supported by the CHICKEN developers. -- Regards, Oleg Art System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Strange behavior of Chicken Scheme interpreter on Windows 7
On 06 Dec 2014, at 13:16, comb...@laposte.net wrote: > > 1. PREFIX looks to be mandatory in Chicken and is an absolute path > 2. I want to package everything in an archive file which will be in different > places on different computers > > Do you think it can work out-of-the-box playing with environment variables? > What will be the restrictions? > > Regards, > Pascal I’ve not followed the thread, but it seems that the environment variable CHICKEN_PREFIX is the thing you are looking for. PREFIX sets the default at compilation time. You may also need to set CHICKEN_REPOSITORY if it is not located at CHICKEN_PREFIX/lib/chicken/. Adding CHICKEN_PREFIX/bin to PATH may also be needed. In short, something like: @echo off set CHICKEN_PREFIX=%CD% set CHICKEN_REPOSITORY=%CHICKEN_PREFIX%\lib\chicken\7 set PATH=%CHICKEN_PREFIX%\bin;%PATH% Save this as setenv.bat in your portable installation dir, cd into it when needed and run setenv.bat. -- Regards, Oleg Art System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Visual Studio is here
On 24 Nov 2014, at 12:44, Peter Bex wrote: > > On Sat, Nov 22, 2014 at 11:42:29PM +0300, Oleg Kolosov wrote: >> Well, merging back into the core will make me happy, but, before that, I >> plan to actually implement the aforementioned features. Right now I have >> only barely working prototypes. You, as an upstream, have strong policies >> and obligations (like maintaining backward compatibility and such) which >> will slow me down. I prefer to rapidly change everything without >> discussions. So, it looks like this will be a real fork for the time being. > > Please remember that we've actually decided to _break_ backwards > compatibility for CHICKEN 5. If there's any time to contribute large > changes to core, it's now! > > Of course we'll still want to review changes, but this is to ensure > quality and avoid introducing bugs, as well as to ensure that more > people are familiar with the new code. At least two core developers > will have looked at the code, which means we reduce the "bus factor" > (i.e., what would happen if one core dev would be hit by a bus?). > Everyone benefits from this: Suppose you lose interest in CHICKEN > or something was to happen to you, who will maintain your changes > if nobody has seen and understood them in detail? Yes, you are right. I’m moving things around mainly to familiarise myself with the code. I’ve received complaints from people I know personally, who would like to contribute, that the existing code base is hard to navigate, so, to make the job easier, I’ve removed and renamed few things, like setup-api, csc and friends, most of the platforms and such. The conversion was pretty mindless, I don’t think this is worthy of contribution. The main benefit from this is that there is no more “cross chicken”: just host and target. So it’s actually possible. > >> The development is completely public, on github, and I don’t mind breaking >> things, maybe this will encourage people who does not want to bother with >> patches and mailing lists to contribute. > > We already have a manpower problem, with not enough people contributing. > Diluting this manpower across two projects is wasteful and hurts *both* > projects. This is not my intention. Considering that commits to the core are quite rare, by putting some action to github I was hoping to make the the project more visible. > But more importantly, I'd really hate to see all your work go to waste. > I've seen it before, and done it myself even: if you just go off on your > own and hack, merging back the work is going to be Very Hard. If you > just send a huge patch bomb to the mailinglist, that will make it > impossible for us to merge it back, not only due to the inevitable merge > conflicts but also because too large patches are hard to digest. Well, actual code changes, not counting moves and renames, are quite small. I’m still not sure how it will work in the end. I guess most of these things will require few tries, so to not waste anyones time I will experiment in my own branches. > Evntually, CHICKEN 5 may evolve beyond the ability to merge back changes > into your branch. The same will happen vice versa. This will ensure > people will need to choose between your branch or ours, which is unfair > and unnecessary. To make this clear: mine - "try you wildest ideas, don’t complain if it eats your cat” (broken builds, merge conflicts); mainline - peer reviewed, stable and time proven. >> The test suite still passes and I have complex production system (thread >> heavy and performance sensitive) which still runs, so I hope the real >> breakage will not go unnoticed. > > How many platforms are you testing on? We have an extensive continuous > integration system (Salmonella), which tests on several platforms. > Writing portable code is hard enough as it is, without this safety net > you're almost guaranteed to break a thing or two without knowing it. Windows 7: (MSVC, MinGW32), MacOS X (Xcode and ninja build), occasionally cross compile for Linux (x86 and MIPS) with the eggs and run on our device. -- Regards, Oleg Art System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ffi howto
On 21 Nov 2014, at 18:48, chicken-us...@shorbaji.com wrote: > > Hello, > > I need some help getting started with ffi. > > I am attempting to bind libuv to scheme code. Hello. You can not just call lambda from foreign code because garbage collector moves those around and the program will eventually crash. You need to declare it as an external function like Richard suggested so it essentially becomes C function. Incidentally, I’m experimenting with adding libuv to CHICKEN too. The idea is to just suspend the thread waiting for a callback and let the scheduler to figure out which lambda to call later. You can look at my early draft on: https://github.com/bazurbat/chicken-scheme/blob/next/src/scheduler/scheduler-uv.scm and accompanying scheduler.c which might give you ideas about FFI. -- Regards, Oleg Art System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Visual Studio is here
On 22 Nov 2014, at 19:07, Peter Bex wrote: > > On Sat, Nov 22, 2014 at 07:01:44PM +0300, Oleg Kolosov wrote: >> Hello! >> >> Considering that Visual Studio 2013 is now essentially free >> (http://www.visualstudio.com/products/visual-studio-community-vs) I’m taking >> the opportunity to announce again that I’m working on a version of CHICKEN >> Scheme which can be compiled with it (with the help of CMake). >> >> There are few other changes not supported by the CHICKEN developers. >> Roughly, the current agenda is: >> >> - make the code more approachable to an occasional contributor >> - replace the scheduler and posix support code with libuv facilities >> - better cross-compilation support >> - source level debugging >> - more usable profiler >> >> You are welcome to follow/fork me on github: >> >> https://github.com/bazurbat/chicken-scheme >> https://github.com/bazurbat/chicken-eggs > > Hello Oleg, > > I applaud your efforts to make CHICKEN work better under Windows. > However, I took a look at your fork and it looks like you're making > various sweeping changes. Do you have a plan for making the merge > back into CHICKEN core, or are you intending to maintain a real fork? > > Cheers, > Peter Well, merging back into the core will make me happy, but, before that, I plan to actually implement the aforementioned features. Right now I have only barely working prototypes. You, as an upstream, have strong policies and obligations (like maintaining backward compatibility and such) which will slow me down. I prefer to rapidly change everything without discussions. So, it looks like this will be a real fork for the time being. The development is completely public, on github, and I don’t mind breaking things, maybe this will encourage people who does not want to bother with patches and mailing lists to contribute. The test suite still passes and I have complex production system (thread heavy and performance sensitive) which still runs, so I hope the real breakage will not go unnoticed. -- Regards, Oleg Art System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Visual Studio is here
Hello! Considering that Visual Studio 2013 is now essentially free (http://www.visualstudio.com/products/visual-studio-community-vs) I’m taking the opportunity to announce again that I’m working on a version of CHICKEN Scheme which can be compiled with it (with the help of CMake). There are few other changes not supported by the CHICKEN developers. Roughly, the current agenda is: - make the code more approachable to an occasional contributor - replace the scheduler and posix support code with libuv facilities - better cross-compilation support - source level debugging - more usable profiler You are welcome to follow/fork me on github: https://github.com/bazurbat/chicken-scheme https://github.com/bazurbat/chicken-eggs -- Regards, Oleg Art System ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Parsing Simple Markup
On 09/20/14 19:19, Yves Cloutier wrote: > Hello, > > I am a new user to Scheme in general and to Chicken in particular, nice > to meet you all. Welcome! > > Scheme is a totally different paradigm that I'm used to, so while I wait > for my books to arrive I will need some hand-holding...hope that's ok. I was in a similar situation few months ago, with the experience in "classic" languages - Scheme looked completely foreign. But it's actually very simple once you get the basic concepts. For learning I personally recommend "The Scheme Programming Language" (http://www.scheme.com/tspl4/) - it contains very nice exercises. The book is somewhat tied to Chez Scheme but many extensions are available in Chicken as well. Also, not often recommended but my favourite is: "An Introduction to Scheme and its Implementation" (ftp://ftp.cs.utexas.edu/pub/garbage/cs345/schintro-v14/schintro_toc.html) - although it's unfinished there are some gems scattered around, especially useful if you are familiar with the C language. > 1) Is the Chicken Scheme manual available for purchase? Online docs are > great but I like to have a hardcopy so that I can read offline. There are http://wiki.call-cc.org/eggref/4/chicken-doc - you can install it for offline use. It will look like http://api.call-cc.org/doc/chicken. > For the most part, a lot of what I want to do is "search and replace", > except for special cases where additioanl processing would be required > to extract command:value pairs. > > The idea is to make typesetting with Groff very simple and intuitive for > any user - not just programmers and hackers. The markup we are working > on is called Typesetting Markup Language (TML). So it would convert > html-like commands and generate a Groff document from it. See also http://en.wikipedia.org/wiki/SXML, http://wiki.call-cc.org/man/4/Unit%20irregex and http://wiki.call-cc.org/eggref/4/fmt for ideas. > In Perl I am able to do most of this with regular expressions, but I'm > hitting my head against the wall when it comes to multiple formatting > commands within a group <...,...,...< > My idea was that I could read a line of text from a file at a time. My > understanding is that the input would be read into an "s-expression" > > And then do something based on what token that is encountered. You can try to first convert this to simple s-expressions like: (bold "text") (indent 5 "text") (bold (smallcap (size 2 "text"))) and then use http://wiki.call-cc.org/eggref/4/matchable egg to generate output. See http://ceaude.twoticketsplease.de/articles/an-introduction-to-lispy-pattern-matching.html for an introduction. I've written very simple recursive s-exp parser using matchable some time ago. I will clean it up and post the link here in a few days for reference. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] A question about library search order
Hello. When writing multi-module application I've found that Chicken searches for extensions in repository only and import libraries in the supplied include-path's additionally. Judging from the sources, this behaviour is intentional. Doesn't it make more sense to always search in user supplied include paths first, and the repository path last, similar to how C compilers search <> includes? Current approach gives problems when I have previous versions of the modules already installed and try to compile a new with changed exports. Chicken seem to use the import libraries from the repository which gives "module unresolved" errors. This forces me to compile and install modules one-by-one which is quite fragile for larger applications (build failed for example, the repository is left with some old and some new modules). There is setup-mode option but it is not scalable for multiple executables needing multiple modules. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] bug in functor implementation
On 08/13/14 15:37, Juergen Lorenz wrote: > Hi all, > > I've found a bug in the functor implementation. > Consider the following trivial example > Hello, sorry for off-topic question, I'm assuming that you are using these. Can you give some real world example? I've thought that functors are pretty obscure feature that nobody is using. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] UTF-8 support in eggs
On 07/09/14 09:00, Alex Shinn wrote: > However, I don't think that's the real problem. The issue as I > understand is that although Chicken has both strings and > bytevectors in the core, historically and for continued simplicity > strings are abused as bytevectors in many cases. ... And this is a pity. But, it looks like there are some movement starting to clean things up in the core. Perhaps this issue could be fixed in the meantime. > The clean way to handle this is to duplicate the useful string > APIs for bytevectors. This could be done without code duplication > with the use of functors, though compiler assistance may be > needed for efficiency (e.g. for inlined procedures). Even without > code duplication there would be an increase in the core library > size, though we could probably move most utilities to external > libraries (how often do you need regexps that operate on binary > data?). Considering Chibi Scheme size numbers from your other mail, I hardly call this a huge price for the benefit received. Even for my specific embedded use cases. > If we could (through functors or in a pinch duplication) bring > the bytevector API up to speed with strings, then the next > step is to identify all such abusers of strings and move them > to bytevectors. Looks like a good plan to me. > The bigger issue from the performance perspective is existing > idioms that use indexes, which can degrade to quadratic behavior > in the worst case no matter how much you optimize (without hacks > that slow down normal usage). So people would have to learn to > take substrings where appropriate to avoid the start/end parameters > to all SRFI 13 functions, or we would need to deprecate SRFI 13 > in favor of a cursor-oriented API (planned for R7RS). Do you have some examples on how to avoid performance degradation and not use string indexes? I've looked briefly into the Chibi string module source, is this the way to go? How about more complex formatting like outputting numbers with padding? I guess these should be handled with something like fmt (or chibi.show). What are performance characteristics of those? I guess again that this depends on "sufficiently smart compiler" to inline things, is it hard to implement? Chicken has inlining support and can generate some "inline files". But, apart from crashes, I was not able get anything measurable from this. Perhaps it works better for some specific code patterns. We are currently using Chicken with utf8 for drawing GUI in immediate mode with some string trimming and padding. We managed to get decent performance for the most cases, but were forced to implement searching and indexing in C. Scheme version, while smaller and simpler, is 2+ times slower. It would be great to use Scheme everywhere. > So as you see the change is contagious. We can update the core > efficiently and easily, but then we have to fix the string abusers, > and then we have to replace existing index-oriented APIs. I personally think it is worth it. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Dbus egg crashes in Chicken 4.9
On 07/03/14 22:49, Shawn Rutledge wrote: > I found that a couple of days ago; try again with the svn trunk. I > will have to make a new release soon. Good to know. I have not tested it yet, because I'm troubleshooting other obscure Chicken related problem and do not want to change used components, just in case. > It's interesting that you are getting some use out of it; does it work > well enough and make sense? What kind of application? We are using dbus for system-wide notifications in an embedded system. Events like "drive mounted", etc. The egg looks flexible and powerful but it is called only occasionally in our current system for legacy compatibility reasons. I guess we will rely on dbus much more in the next version of our product, and I hope this egg will help with this. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] UTF-8 support in eggs
On 07/08/14 16:40, Mario Domenech Goulart wrote: > Hi, > > On Tue, 08 Jul 2014 08:57:43 +0400 Yaroslav Tsarko > wrote: > >> Why don`t just add (use utf8) line explicitly to all the eggs that >> handle strings? That will ultimately fix the problem and will clearly >> indicate that egg performs string manipulations and is capable of >> handling UTF-8 encoding. Or am I missing something? > > That'd be an option. In my opinion, it would probably make things > slightly better, since ASCII characters can be represented by UTF-8 in a > single byte. > > On the other hand, we risk breaking eggs that operate on latin1 text. > UTF-8 support may also affect performance-sensitive code. > > Best wishes. > Mario > IMO just enable utf8 by default and let them break. Is it's not 80's anymore, latin1 only software should die. We did few tests some time ago and they showed that tackling this from Scheme side does not make worthy difference. Using pure C is much better. Perhaps utf8 egg could enjoy some yet to be written (or found in third party libraries) low level support from the core, so we can have the best of the both worlds. For specific use cases (backward compatibility, logging or minimizing runtime size for example) it should be possible to disable multi-byte encoding handling (i.e. current behaviour) by using compilation option or a feature declaration. We have a demanding application and embedded environment with not quite fast MIPS CPU, I can help with testing and profiling things if you are worried about performance problems. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Re: Active Windows users poll
On 06/17/14 17:48, Pedro Melendez wrote: > I would vote for that too. Some eggs might be a little tricky to port > though. I remember having troubles with a networking egg on cygwin. > > Can't wait to see this :) > > > On Tue, Jun 17, 2014 at 2:39 AM, Yaroslav Tsarko > mailto:eriktsa...@googlemail.com>> wrote: > > > > > Original Message > Subject: Re: [Chicken-users] Active Windows users poll > Date: Mon, 16 Jun 2014 14:52:40 +0200 > From: Richard <mailto:plui...@freeshell.de> > To: Yaroslav Tsarko > <mailto:eriktsa...@googlemail.com> > > > > Hello Oleg, > > I too would greatly welcome a Window build. Thank you > > On 06/16/14 13:24, Yaroslav Tsarko wrote: > > Hi Oleg! > > > > Those are great news! > > > > I am very interested in this project since native Windows build is > > preferable when you work on Windows > > rather than mingw tricks. This will greatly shorten Chicken dependency > > list for Windows - one don`t need to install mingw stuff to build > > Chicken with eggs on Windows and use platform tools instead. > > > > On 15.06.2014 01:21, Oleg Kolosov wrote: > >> Hello All! > >> > >> I'm working on new build system for Chicken, based on CMake which, > >> besides more configurability and faster build times, can offer native > >> Windows and MacOSX support with Visual Studio, XCode and other IDEs > >> integration. I also can make installer with few eggs bundled and such. > >> > >> The system already allows seamless integration with CMake projects and > >> tested on Linux. But doing full Windows port is more involved > >> unfortunately. > >> > >> So, if anybody interested in native Windows port of Chicken, give > >> your vote. Thanks to all who replied! This certainly encourages the development. Whether it will be accepted by the Chicken developers is still a big question, there are still a lot of issues which needs resolving. But I will continue to work on this anyway for solving our company internal needs. I occasionally put the changes on github: https://github.com/bazurbat/chicken-scheme and https://github.com/bazurbat/cmake-modules. The support for integrating Chicken with existing CMake projects is quite solid already. If you are interested in early access or testing feel free to contact me directly. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Dbus egg crashes in Chicken 4.9
Hello. After upgrading to Chicken 4.9 our application started to crash in dbus egg. The culprit was found in changed semantics of the assoc and friends: it now checks that the supplied argument is a list. The attached patch fixes the problem. I've not checked if there are similar problems somewhere else. -- Regards, Oleg diff -ru dbus.orig/dbus.scm dbus/dbus.scm --- dbus.orig/dbus.scm 2014-06-19 15:02:24.0 +0400 +++ dbus/dbus.scm 2014-06-19 15:10:17.998005481 +0400 @@ -272,7 +272,7 @@ (define (tassq tree . keys) (let ([key-list (if (pair? (car keys)) (car keys) keys)]) (let loop ([rem-keys key-list][subtree tree]) -(if (null? rem-keys) +(if (or (not subtree) (null? rem-keys)) subtree (loop (cdr rem-keys) (let ([pr (assq (car rem-keys) subtree)]) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Can chicken itself be "deployed"?
On 06/16/14 20:20, Matt Welland wrote: > I have some tough install situations and having a "deployed" version of > chicken itself would be great. > > Specifically I need to install to an area from a vm via sshfs but cannot > write directly as the user that the files ultimately need to be owned > by. Don't ask. It is stupid and it sucks. Anyhow, I can work around this > but it occurred to me that a chicken install that could be moved to any > directory would be really cool and might solve my problem. Is it possible? > Hello. I don't fully understand limitations of your environment, but here are few suggestions: You can compile Chicken yourself, set PREFIX=$HOME/some/location (this is not necessary, just easier to have everything in one directory), make install, grab it from there, copy to target machine (for ex. /some/location, export CHICKEN_PREFIX=/some/location environment, export PATH=/some/location/bin:$PATH. But, if you can not write, you will not be able to install extensions on the target machine. But you can set environment variables on your working machine the same way, do chicken-install, and copy the files over again. If you do development and need more persistent installation (maybe some additional software or something), you can try cross compile as per http://wiki.call-cc.org/man/4/Cross%20development. Process scm files with the resulting "cross chicken", link with shared libchicken from "target chicken" and deploy the result. Use chicken-install from the "cross chicken" to install extensions, it puts them in both trees. The initial setup can be a little messy but works fine in practise. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] How to install eggs in $HOME?
On 06/15/14 13:28, Manfred Lotz wrote: > Hi there, > I was playing a bit with Chicken Scheme and was unable to install an > egg. > > chicken is installed as rpm package chicken in fedora 20. > > Now when doing, e.g. >chicken-install numbers > I get a permission denied: > cp: cannot create regular file ‘/usr/lib64/chicken/6/numbers.so’: > Permission denied > > > I could run chicken-install with sudo but I do want to have only stuff > in /usr/lib64 which is installed by using the system's package manager. > > Question: Could I point chicken to a directory in $HOME where my egg > installations could go to? > # exact path is irrelevant as long as you can write to it mkdir -p $HOME/.local/lib/chicken chicken-install -init $HOME/.local/lib/chicken export CHICKEN_REPOSITORY=$HOME/.local/lib/chicken chicken-install numbers Add "export CHICKEN_REPOSITORY ..." command to .bashrc or kde env or so to persist. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Active Windows users poll
Hello All! I'm working on new build system for Chicken, based on CMake which, besides more configurability and faster build times, can offer native Windows and MacOSX support with Visual Studio, XCode and other IDEs integration. I also can make installer with few eggs bundled and such. The system already allows seamless integration with CMake projects and tested on Linux. But doing full Windows port is more involved unfortunately. So, if anybody interested in native Windows port of Chicken, give your vote. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Compiling Chicken-compiled-to-C file.c does not link
On 06/12/14 20:40, Nikos Vasilakis wrote: > I want to go "the C way" only because I want to later compile the > generated C code for a different ISA (ALPHA). For semi-automatic "C way" you can try my work in progress CMake macros: https://github.com/bazurbat/cmake-modules The project contains somewhat contrived examples in tests directory. It supports cross-compilation but, currently, completely undocumented. Also, I've just added basic support for compiling executables with statically linked Chicken library. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Portable installs broken?
On 04/06/14 19:55, Daniel Leslie wrote: > I'm trying to create a 'portable' distribution of chicken and am > running into a simple issue. Basically, the built-in library search > path isn't always valid, and csc and csi don't appear to pay attention > to LD_LIBRARY_PATH. > > Thus, the following: > > bin $ ./csi -n > > CHICKEN > > Error: (string-append) bad argument type - not a string: #f > > bin $ echo "(display \"Hello world\")" | ./csc - -o foo > > Error: (string-append) bad argument type - not a string: #f > > Call history: > > (##core#begin (display "Hello world")) > (display "Hello world")<-- > > Error: shell command terminated with non-zero exit status 17920: > bin/chicken - -output-file foo.c > > Alright, so with csi and csc we can get around this by explicitly > providing a -include-path parameter at the command line. But what of > installing eggs? Chicken-install takes no such parameter, and > invocations of csc from setup scripts are not mutable to accept the > parameter. > > It seems to me that the easy fix would be to import a path from some > environment variable by default. Does such an environment variable > exist already? > > -Dan > > > > ___ > Chicken-users mailing list > Chicken-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-users csc uses definitions from chicken-config.h which is generated at build time. Some of those can be modified with environment variables. This can be quite inconvenient. I'm currently working on CMake based solution which does not depend on csc. It handles parallel builds, separate build folders, cross compilation, etc. Check https://github.com/bazurbat/cmake-modules/blob/master/cmake/ChickenUse.cmake and example usage in tests/chicken to see how chicken command line is constructed. Maybe this will help you. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake build support
On 02/11/14 12:49, Peter Bex wrote: > Now, about the CMake build: Let me start by saying I'm extremely > sceptical about doing this because of CHICKEN's history with CMake. > Furthermore, *if* we do this I put down the same hard requirement that > Felix put down when I refactored the GNU Make build: The build *must* > work and be tested on *all* supported platforms before we switch. > If people object to having CMake, we must consider their reasons as well. > > The build scripts which I can see look very clean, though, so it may be > worth the switch. I am trying to grok the CMakeLists.txt; could you > explain where "chicken_wrap_sources" and "chicken_add_source" are coming > from, for example? I quickly scanned the sources but couldn't find its > definition. > > If this is some implicit "function" (what do they call these?) from > CMake, where can I find out about it in the documentation? > > I don't see any code to take care of any of the non-"standard" build > flags (ie, anything aside the least common UNIX denominator). > Does CMake take care of these things? And what about the prefixing > and suffixing of the binaries that are built (PROGRAM_PREFIX and > PROGRAM_SUFFIX), which is used for cross-compilation? > Does cross-compilation work at all? Currently I'm trying to provide alternative build system for common platforms, it does not conflict with Makefiles in any way. With out of tree CMake build you can even have both simultaneously. This is how I actually test things. CMake handles many platform-specific things, looking at current Make rules it should not be much trouble to provide few options for non standard flags. I can add Linux, Windows and maybe Mac OSX support myself. All supporting macros and functions included by toplevel CMakeLists.txt are in /cmake folder. Cross-compilation is the first major goal, but it is not ready yet. I've added some prefix/suffix and installation handling. Procedure for testing (linux only so far): git clone https://github.com/bazurbat/chicken-scheme/tree/cmake-build mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/chicken .. # or "cmake -GNinja " for really fast build, needs http://martine.github.io/ninja/ cmake --build . --target install # or ninja install export CHICKEN_PREFIX=$HOME/opt/chicken $HOME/opt/chicken/bin/csi -n -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake build support
On 02/11/14 01:07, Matt Welland wrote: > Hi Oleg, > > What is the purpose of switching to cmake? Can the transition be done > without adding another dependency to building for mingw-msys? > > I guess my concern is that even if cmake is an improvement over make > that the impact can still be negative on the community. > > For me the interesting platforms for chicken are: > > Linux (several generations in current use). > Android (admittedly this is in my dreams :)) > Windows mingw-msys > > When you are done can I expect that my builds for these platforms will > be as easy as they are today? > > I missed the discussion of this on the chicken lists so my appologies > if this has been hashed to death but in my opinion open source > projects are very vunerable to pertubations and I really want to see > chicken thriving, not just surviving. A change like this alienating > even a single strong developer can hurt. Hopefully the developers are > already on board with your vision in this. Hi! There was not any discussion, I've decided to try first, discuss later. Consider this thread the initial request for comments. I maintain build system for projects at my workplace, we are cross-compiling for embedded platform, desktop, there are plans for mobile, and dealing with Chicken (with eggs and dependencies) as projects grow becomes really painful. So this is partially internal, and partially personal project. I'm trying to implement CMake based scripts alongside current system. Ideally, it should be completely optional. Current goals are: fix few annoyances in building cross Chicken with eggs, a way to generate configurable self-contained executables, native Windows build (with installer). All this might take a long time. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] CMake build support
Hello All. I am happy to inform you that I have achieved some success converting Chicken build system from Makefiles to CMake. This initial work is a proof of concept and still very ugly and incomplete, but certainly will be improved. I've created a fork of Chicken on https://github.com/bazurbat/chicken-scheme/tree/cmake-build, so anyone interested can track progress and make requests there. If you have proposals or suggestions for the new build system, let's discuss. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-iup - progressing nicely but have problem with canvas-draw
On 02/04/14 19:13, John Cowan wrote: > Peter Bex scripsit: > >> This looks very useful indeed. Is the documentation for CMake better >> nowadays? I seem to recall that was the main reason we dropped CMake, >> because nobody besides one person understood it well enough to maintain >> the build. > That was part of it. In addition, CMake was unstable -- we were > constantly changing our build process to cope with new and incompatible > versions of CMake (also a problem with autotools) -- and it wasn't truly > able to cope with our meta-circular build process, and that had to be > kludged around. IMO, depending on GNU make only is the Right Thing for > us: it is rock solid, and if we have to deal with each port separately > to some degree, so what? There are not hundreds of targets these days > that are of practical interest. We use CMake for moderately complex project with heavy mix of Chicken, C and various external dependencies. Transition from Make was pain but I can't remember major problems with the setup. On the plus side, once you have custom modules for hard parts the usage for not initiated is quite straightforward. Cross-compilation and keeping few build configurations around is much easier. I'm not proposing reconsidering CMake for building Chicken itself, just sharing experience. Maybe I'll try to look into this. > What do you think of my idea of dropping even GNU make for MSVC support > and just compiling everything with a batch file? One thing I note is > that MSVC's C compiler is C89 only; do we have dependencies on post-C89 > syntax either in Chicken itself (which presumably could be worked around) > or in the generated code? This may actually simplify things for distribution tarballs, but dropping build system altogether might bring major pain for developers of the Chicken itself. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-iup - progressing nicely but have problem with canvas-draw
On 02/04/14 12:08, Peter Bex wrote: > Hi Oleg, > > This looks very useful indeed. Is the documentation for CMake better > nowadays? I seem to recall that was the main reason we dropped CMake, > because nobody besides one person understood it well enough to maintain > the build. I don't know how it was back then but current CMake documentation is not very good either IMHO. Maybe this is due to it's many features and general complexity. Unfortunately, it is relatively widespread, well known and supports generating projects for various IDEs which is the way many users prefer nowadays. I'm developing these modules to ease integration of Chicken into existing projects. I consider this the "lesser evil", i.e. it works for not too complex cases, and I hope will be useful to somebody. I've added some documentation to the FindChicken module and will be happy to answer any questions regarding it's usage. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-iup - progressing nicely but have problem with canvas-draw
On 02/03/14 21:53, Mario Domenech Goulart wrote: > I don't know. Unless the installer drags a C toolchain as a runtime > dependency, I don't see how it would make CHICKEN more interesting on > Windows for developers (unless you consider "csi runs" satisfying > enough). Hi, regarding "csi runs" you might find my CMake module (https://github.com/bazurbat/cmake-modules) interesting. It's at early stage, but covers my use cases. Suggestions, feature requests are welcomed BTW. -- Regards, Oleg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
