Re: Include paths with chicken-install
Hello Christoph, you can set the environment variable CSC_OPTIONS before invoking chicken-install / csc. Probably you will need something like CSC_OPTIONS="-I$PREFIX/include/iup -L$PREFIX/lib" 🤔 Ciao, Thomas Am Mi., 25. Sept. 2024 um 10:04 Uhr schrieb Christoph Lange < christ...@clange.de>: > Hej! > > I'm trying to install iup, but `chicken-install` fails for missing > iup.h. I do have it, but in `iup/iup.h`, so I assume I should somehow > tweak the include paths. > > I didn't find anything about it though in the `chicken-install` > documentation. Or overlooked it :-\ There surely is a way -- what do I > do? > > > Best > /christoph > > -- > Christoph Lange > Lotsarnas Väg 8 > 430 83 Vrångö > >
Re: Question about how to check a symbol is bound
Hello, if you are looking for record introspection capabilities, I would recommend looking into SRFI-99[1], which combines static structure definition and dynamic reflection APIs. You're example could look like this: (import (chicken format) srfi-42 srfi-99) (define-record-type egg-info make-egg-info egg-info? name author desc) (define (print-record/fields r) (define rtd (record-rtd r)) (do-ec (: f (rtd-field-names rtd)) (format #t "~a: ~a~%" f ((rtd-accessor rtd f) r (print-record/fields (make-egg-info "F-operator" "Kon Lovett" "Shift/Reset Control Operators")) Ciao, Thomas -- [1]: https://srfi.schemers.org/srfi-99/srfi-99.html Am Fr., 23. Juni 2023 um 10:03 Uhr schrieb Pan Xie : > #+begin_quote > Perhaps if you can explain why you need to know if a symbol is bound or > unbound, we might be able to help you better achieve your goal. > #+end_quote > > > For example, if I want to do things shown in following codes, it is useful > to get the > interned symbols from their names and also get their bound procedures: > > (define-record egg-info > name author desc) > > (define (show-egg-info egg) > (define (symbol-value sym) > (##sys#slot sym 0)) > > (define (getter field-name) > (symbol-value >(string->symbol > (format #f "egg-info-~a" > field-name > > (let ((fields '(name author desc))) > (for-each >(lambda (f) > (format #t "~a: ~a~%" > f > ((getter f) egg))) >fields))) > > (show-egg-info (make-egg-info > "F-operator" > "Kon Lovett" > "Shift/Reset Control Operators")) > > I think it is a very common idiom in languages from Lisp family. So it is > important to know > how to check symbol is bound and get its value. Every scheme > implementation means for > business seriously should have the ability. > > Thanks > Pan > > > On 6/23/23 15:40, Peter Bex wrote: > > On Fri, Jun 23, 2023 at 03:32:38PM +0800, Pan wrote: > >> Ah, that make sense. It seems I can just use the '##sys#slot' procedure > to > >> accomplish all that tasks. > > Please don't use ##sys#slot unless you know what you're doing - the > > procedure is unsafe and will cause segmentation faults when used on > > non-block objects. Anything that starts with ##sys# or ##core# etc > > is intentionally undocumented because it's not meant for user code. > > > >> Would you please elaborate about the "transformed > >> name"? I see there are codes reference symbols like "##sys#slot" or > >> "scheme#list", but I can't find document describe them. Is there any > >> document I can look into? More specifically, how can I transfer "list" > to > >> "scheme#list"? Is there procedure can do that? > > scheme#list is the fully qualified symbol that means it's the "list" > > procedure from the "scheme" module. If you do "(import scheme)" and then > > just use "list" without prefix, it will get rewritten under the hood. > > > > Again, this is an implementation detail and not meant to be used > > directly. > > > > Perhaps if you can explain why you need to know if a symbol is bound or > > unbound, we might be able to help you better achieve your goal. > > > > Cheers, > > Peter > >
Re: Botan bindings
Hello, the bindings include generic constructors for a high level hash function and symmetric cipher interface. You can specify any algorithm Botan supports in symbolic form. I did not include bindings for the low-level ECB-only cipher interface (seems of limited use from a high-level language) nor for format-preserving encryption (difficult to formulate an efficient binding). Ciao, Thomas C. elf schrieb am So., 11. Juni 2023, 05:55: > Thanks! I'll try to look into it and run some tests and speed comparisons > in about a week. (Lots of weddings right now, so it's unlikely i can do > anything earlier than that.) Have you made bindings for all the hashes and > block ciphers? > > -elf > > On 11 June 2023 02:59:23 GMT+03:00, Thomas Chust > wrote: > >Hello, > > > >Botan [1] is a pretty nice cryptographic library that I use from time to > >time. Its documentation page on language bindings mentions that a CHICKEN > >binding is "wanted", so I thought: Why not ☺ > > > >You can find the code for the new egg here: > > > > https://chust.org/repos/chicken-botan > > > >Documentation is still minimal, but one can easily refer to the Botan > >documentation itself. Before adding the egg to the coop, I would like to > >write more tests and give you all a chance to play with the code. > > > >So feedback is welcome! > > > >Ciao, > >Thomas C. > > > >
Botan bindings
Hello, Botan [1] is a pretty nice cryptographic library that I use from time to time. Its documentation page on language bindings mentions that a CHICKEN binding is "wanted", so I thought: Why not ☺ You can find the code for the new egg here: https://chust.org/repos/chicken-botan Documentation is still minimal, but one can easily refer to the Botan documentation itself. Before adding the egg to the coop, I would like to write more tests and give you all a chance to play with the code. So feedback is welcome! Ciao, Thomas C. -- [1]: https://botan.randombit.net/
Re: Need GUI (again), gauging interest in an alternative approach.
Hello, wxWidgets seems to be slowly dying these days. Support for anything else than the classic desktop platforms is virtually non-existent and even things like subpixel scaling support are flaky at best. Creating bindings for a large C++ codebase like wxWidgets also seems like a major endeavour. Even the "official" wxPython bindings are often years out of sync with current versions of wxWidgets 🤔 That said, if your target are classic desktop platforms and you like to write code in C++, wxWidgets is still a solid option for a UI toolkit! In particular, the API stability is great, which can't be said about the big competitor Qt, where even a patchlevel version number change often brings breaking API or behaviour changes that take at lot of effort to adapt to. Ciao, Thomas C. Am Do., 23. März 2023 um 13:07 Uhr schrieb elf : > Perhaps something more like wx would be better? Excellent cross-platform > support, including all necessary support structures, and iirc it can give > you lower-level graphics access too? Plus, of course, there are already > bindings for a large num of languages, and a guide to writing new bindings, > so... > > -elf > > > On 23 March 2023 13:43:10 GMT+02:00, Matt Welland > wrote: > >> Tk is great, no doubt about it. I still miss Eric Gallesio's STk. The >> reasons I decided against tk include: >> >>1. Clunky 1980's look and feel. (i) >>2. No IOS or Android support. (ii) >>3. I seemed to fight the widget layout model a lot when I used it. >>(iii) >>4. Two of the projects I'm starting are more game than normal app, >>including plans to have a VR view. >> >> (i) has been addressed with the latest tk, including themes apparently. >> (ii) it does appear possible to use tk on android but there is no touch >> support as best I can tell. >> (iii) Godot seems somewhat similar to IUP with hboxes, vboxes etc. >> hopefully easier for me to learn. >> >> #2 is a big concern but #4 is the deciding factor. I really need >> something that works and where I can reuse what I learn in many projects. >> I'd strongly prefer to use 100% Chicken but I also need to get things done >> and if I have to learn and use gd script for some of my projects I'll deal >> with it. I am also starting to see the value of a well done gui designer. >> >> What I want is a button in Godot that switches out gd script for Chicken >> Scheme. That would be an awesome tool! I'll settle for doing the >> communications, logic and other heavy lifting in a Chicken program and bolt >> on Godot for the user interface (via tcp for now). >> >> Just my $0.02 >> >> On Wed, Mar 22, 2023 at 11:37 PM elf wrote: >> >>> Erm, what's wrong with the tk bindings, which should work everywhere >>> already? >>> >>> -elf >>> >>> On 23 March 2023 02:36:43 GMT+02:00, Matt Welland < >>> mattrwell...@gmail.com> wrote: >>> >That would be great Thomas. For my part, I'll start working on my >>> project >>> >using what I can, learning Godot along the way. When you get to working >>> on >>> >this please let me know how I can help. >>> > >>> >Regarding the approach, I like the tooling to generate a loadable module >>> >idea. I figure leverage as much of Godot as a tool as possible. >>> > >>> >Thanks. >>> > >>> >On Wed, Mar 22, 2023 at 12:27 PM Thomas Chust >>> >wrote: >>> > >>> >> Hello, >>> >> >>> >> a combination of CHICKEN and Godot sounds very interesting! I've been >>> >> meaning to experiment more with that engine for a while, and with >>> Godot 4.0 >>> >> just out the door the time is probably perfect to try out the new >>> extension >>> >> APIs. >>> >> >>> >> I'm not completely sure how the CHICKEN/Godot hybrid should look like >>> and >>> >> suspect that embedding Godot in a CHICKEN egg would at least be >>> cumbersome. >>> >> Maybe some kind of tooling to streamline the task of rolling CHICKEN >>> code >>> >> into a single loadable module for Godot to use would be most >>> promising 🤔 >>> >> >>> >> I think I've just found a project for the upcoming CHICKEN summer >>> workshop >>> >> 😁 >>> >> >>> >> Ciao, >>> >> Thomas C. >>> >> >>> >> >>> >> Am Mi
Re: Need GUI (again), gauging interest in an alternative approach.
Hello, nothing is "wrong" with Tk, I guess — different UI toolkits just have different strength 🤷 Combining Tcl/Tk with CHICKEN is a complex deployment scenario, and I think it works best on desktop platforms with nice package managers. If that's what you are targetting, the Tcl/Tk look and feel system works for you, and all the widgets you need are there, it's a great option! Ciao, Thomas C. Am Do., 23. März 2023 um 04:38 Uhr schrieb elf : > Erm, what's wrong with the tk bindings, which should work everywhere > already? > > -elf > > On 23 March 2023 02:36:43 GMT+02:00, Matt Welland > wrote: > >That would be great Thomas. For my part, I'll start working on my project > >using what I can, learning Godot along the way. When you get to working on > >this please let me know how I can help. > > > >Regarding the approach, I like the tooling to generate a loadable module > >idea. I figure leverage as much of Godot as a tool as possible. > > > >Thanks. > > > >On Wed, Mar 22, 2023 at 12:27 PM Thomas Chust > >wrote: > > > >> Hello, > >> > >> a combination of CHICKEN and Godot sounds very interesting! I've been > >> meaning to experiment more with that engine for a while, and with Godot > 4.0 > >> just out the door the time is probably perfect to try out the new > extension > >> APIs. > >> > >> I'm not completely sure how the CHICKEN/Godot hybrid should look like > and > >> suspect that embedding Godot in a CHICKEN egg would at least be > cumbersome. > >> Maybe some kind of tooling to streamline the task of rolling CHICKEN > code > >> into a single loadable module for Godot to use would be most promising > 🤔 > >> > >> I think I've just found a project for the upcoming CHICKEN summer > workshop > >> 😁 > >> > >> Ciao, > >> Thomas C. > >> > >> > >> Am Mi., 22. März 2023 um 15:28 Uhr schrieb Matt Welland < > >> mattrwell...@gmail.com>: > >> > >>> I've been using IUP with Chicken for years. I really enjoy using it > >>> (thanks Thomas!). But, here we are, over 10 years later and IUP is > still > >>> not available as an official Debian package and it is a burden to > deploy. > >>> It is also still not supported on Mac. > >>> > >>> So, I'm scouting around (again) for alternatives and I'm starting to > lean > >>> towards using Godot for my next project. Godot + Chicken scheme that > is. > >>> I'm hoping that I can deploy to mac, Linux and Windows and maybe even > >>> android without too much pain. > >>> > >>> Here is an article that makes the case for using Godot for graphical > user > >>> interfaces: > >>> > >>> > >>> > https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b > >>> > >>> I can achieve what I need with any one of three approaches: > >>> > >>> 1. Godot <==> chicken executable, where the connection could be tcp, > http > >>> or similar. > >>> > >>> 2. Godot <==> chicken .so file > >>> > >>> 3. Chicken <==> godot egg > >>> > >>> I don't have time or expertise to do an egg without help. Before I > start > >>> working using option 1 or 2 I wanted to ask the chicken community if > there > >>> was interest in collaborating on creating a godot egg. > >>> > >>> Thanks! > >>> > >>> NOTE: If hypergiant had a widget library with a decent text widget > (line > >>> wrapping, copy/paste to the OS etc.) I'd have considered it. Raylib was > >>> also interesting and it's text support might have been adequate but > the egg > >>> was never published and seems abandoned. > >>> > >>> > >>> -- > >>> Complexity is your enemy. Any fool can make something complicated. > >>> It is hard to keep things simple. - Richard Branson. > >>> > >> > > > >
Re: Need GUI (again), gauging interest in an alternative approach.
Hello, a combination of CHICKEN and Godot sounds very interesting! I've been meaning to experiment more with that engine for a while, and with Godot 4.0 just out the door the time is probably perfect to try out the new extension APIs. I'm not completely sure how the CHICKEN/Godot hybrid should look like and suspect that embedding Godot in a CHICKEN egg would at least be cumbersome. Maybe some kind of tooling to streamline the task of rolling CHICKEN code into a single loadable module for Godot to use would be most promising 🤔 I think I've just found a project for the upcoming CHICKEN summer workshop 😁 Ciao, Thomas C. Am Mi., 22. März 2023 um 15:28 Uhr schrieb Matt Welland < mattrwell...@gmail.com>: > I've been using IUP with Chicken for years. I really enjoy using it > (thanks Thomas!). But, here we are, over 10 years later and IUP is still > not available as an official Debian package and it is a burden to deploy. > It is also still not supported on Mac. > > So, I'm scouting around (again) for alternatives and I'm starting to lean > towards using Godot for my next project. Godot + Chicken scheme that is. > I'm hoping that I can deploy to mac, Linux and Windows and maybe even > android without too much pain. > > Here is an article that makes the case for using Godot for graphical user > interfaces: > > > https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b > > I can achieve what I need with any one of three approaches: > > 1. Godot <==> chicken executable, where the connection could be tcp, http > or similar. > > 2. Godot <==> chicken .so file > > 3. Chicken <==> godot egg > > I don't have time or expertise to do an egg without help. Before I start > working using option 1 or 2 I wanted to ask the chicken community if there > was interest in collaborating on creating a godot egg. > > Thanks! > > NOTE: If hypergiant had a widget library with a decent text widget (line > wrapping, copy/paste to the OS etc.) I'd have considered it. Raylib was > also interesting and it's text support might have been adequate but the egg > was never published and seems abandoned. > > > -- > Complexity is your enemy. Any fool can make something complicated. > It is hard to keep things simple. - Richard Branson. >
Re: How best to get a default result from sqlite3, or to use or not use first-result?
Hello Matt, it may be a bit of an oversight that no such procedure exists in the SQLite3 egg, but you could define something like this: (define (one-result/default default db sql . parameters) (call-with-temporary-statements (lambda (stmt) (apply bind-parameters! stmt parameters) (if (step! stmt) (column-data stmt 0) default)) db sql)) [untested, and leaving the usual "overloads" for statement objects vs. SQL source as an exercise to the reader 😉] Ciao, Thomas Am Mi., 8. Juni 2022 um 20:10 Uhr schrieb Matt Welland : > The problem: retrieve one value from a query, if there is no matching > row return a default. > > Method 1: use for-each-row, overwrite the default with found values > Method 2: use first-result, on exception return the default > Method 3: use fold-row (wasn't an option when I first wrote the code) > > My question is, which of these is the "right" way to do what I want? Is > there another, better, way? Note that method #2 has problems in my > program but it might be due to my using chicken 4.10 (for now). > > ==additional details== > > Method 1, for-each-row, was my original approach and seemed to work > fine. > > Then, in the midst of a major rewrite I tried to use first-result. It > seemed odd to me to use an exception this way but I assumed (wrongly?) > it was a fancy software engineery way to do things since the sqlite3 > egg did not provide any direct way to do what I want. > > However I hit a strange scalability issue with database locks happening > only a few hours into a run. After a lot of fruitless debug and on a > hunch, I replaced the first-result with a for-each-row and now am able > to run ten of thousands of tests over many hours (still not perfect, > work progresses). > > I plan to replace use of for-each-row with something like: > > (define (get-id db name default) > (fold-row (lambda (row) > (car row)) > #f > db "SELECT id FROM tests WHERE testname=?" name)) > > Thanks. > > >
Re: Blobs and GC
Am Sa., 10. Juli 2021 um 15:15 Uhr schrieb Aydar Zarifullin < aydar...@gmail.com>: > Hello everyone, I have a few questions: Is it safe to pass a blob created > in scheme to C functions? Will the garbage collector move it in memory? Is > there any guarantee that the garbage collector won't move it in the middle > of a C function? Is the situation the same with bytevectors? > Hello Aydar, the answer to each of these questions is "yes", I believe ☺ To pass the contents of a non-immediate Scheme object to to a C function through the FFI, use the type [nonnull-]scheme-pointer. Unless it is a SRFI-4 vector you want to pass, in that case you need to use a type specific for the vector type in question. Since CHICKEN is essentially single-threaded, as far as the operating system is concerned, once you pass control to a C function through the FFI, no Scheme code or CHICKEN support code is running in the background, hence a pointer to the inside of a scheme object stays stable during *one* foreign function call, but not necessarily *across multiple* foreign function calls. So the long answer to your first question is really that it depends on what the C function is doing with the pointer: If the function accesses something at the pointer address and then returns, all is well. If the pointer is remembered somewhere and used later on during another foreign function call, that is not safe. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb.
Re: [ANN] CHICKEN 5.2.0 release candidate 2 available
On Sun, 16 Feb 2020 09:10:46 +0100 Peter Bex wrote: > [...] > The second release candidate for CHICKEN 5.2.0 is now available for > download: > [...] > If you can, please let us know the following information about the > environment on which you test the RC: > [...] Hello, my results trying to run the new release candidate are as follows: Operating system: Linux Mint 18.3 (based on Ubuntu 16.04) Hardware platform: x86-64 C Compiler: GCC 9.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: partially The list of successfully installed eggs is attached. I ran into trouble with two of my own eggs: - iup installs only partially. It looks like the modules forms in the egg descriptor are no longer additive, which breaks the conditional compilation logic and leads to missing import libraries. I'm not sure if this is intentional, but it is annoying and I have no idea how to circumvent it. - elliptic-curves installs, but doesn't work. The code uses matchable to destructure record instances and none of those statements match any of the records, possibly because the record tag symbols are now prefixed with the declaring module name. However, simply adding the module-prefix#... to each of the match statements doesn't fix the problem either. Ciao, Thomas -- Any large-scale human cooperation — whether a modern state, a medieval church, an ancient city or an archaic tribe — is rooted in common myths that exist only in people's collective imagination. -- Yuval Noah Harari, "Sapiens" address-info version: 1.0.5 amb . version: 3.0.0 canvas-draw . version: 1.1.2 check-errors version: 3.1.1 compile-file .. version: 1.3 condition-utils . version: 2.1.0 fmt .. version: 0.8.11.2 foreigners version: 1.5 gochan .. version: 5.2.8 iset .. version: 2.2 lmdb version: 1.0.3 matchable . version: 1.1 miscmacros version: 1.0 modular-arithmetic .. version: 1.0.3 monocypher .. version: 1.0.0 nanomsg ... version: 1.0.0.6 object-evict version: 0.1.1 optimism version: 0.1.0 protobuf version: 1.2.2 queues version: 0.1 regex . version: 2.0 sql-null .. version: 2.0 sqlite3 . version: 3.7.2 srfi-1 .. version: 0.5.1 srfi-13 ... version: 0.3 srfi-14 . version: 0.2.1 srfi-18 . version: 0.1.5 srfi-42 .. version: 1.76 srfi-69 . version: 0.4.1 srfi-99 . version: 1.4.5 stty .. version: 0.3 synch ... version: 3.2.2 test .. version: 1.1 tweetnacl ... version: 1.4.2 utf8 version: 3.6.2 webview . version: 1.0.1 zmq ... version: 0.2
Re: Compilation Issues of IUP Egg in Chicken 5
On Thu, 16 Jan 2020 16:09:15 -0700 Jeff Moon wrote: > Found an issue while trying to install the IUP egg on chicken 5. The "-D > disable-iup-web" or "-feature disable-iup-web" does not seem to be > disabling the web portion of the module. When it get's installed, since we > don't have the webkit modules available, it ends up bombing: > [...] Hello Jeff, I'm pretty sure that defining disable-iup-web should disable the compilation of the iupweb bindings, but it didn't disable linking all the IUP libraries – the addition of cond-expand clauses to .egg files was originally not possible, so for a non-standard set of modules you had to edit the .egg file by hand. Since it is now possible to include the necessary conditionals in the egg file I have added them in version 1.9.4. Hopefully this will fix your problem :-) Ciao, Thomas -- A conscience, noted Liriel, could be as irrational as it was inconvenient. -- Elaine Cunningham, "Windwalker"
Re: [ANN] CHICKEN 5.2.0 release candidate available
On Sun, 12 Jan 2020 13:29:06 +0100 Peter Bex wrote: > [...] > We are happy to announce the first release candidate of the upcoming > CHICKEN 5.2.0. > [...] > Please give it a test and report your findings to the mailing list. > [...] Hello, Operating system: Linux Mint 18.3 (based on Ubuntu 16.04) Hardware platform: x86-64 C Compiler: GCC 9.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes The list of installed eggs is attached to this message, `chicken-install -test ...` reported no errors. Ciao, Thomas -- Any large-scale human cooperation — whether a modern state, a medieval church, an ancient city or an archaic tribe — is rooted in common myths that exist only in people's collective imagination. -- Yuval Noah Harari, "Sapiens" address-info version: 1.0.5 amb . version: 3.0.0 canvas-draw . version: 1.1.2 check-errors version: 3.1.1 compile-file .. version: 1.3 condition-utils . version: 2.1.0 elliptic-curves . version: 1.0.3 fmt .. version: 0.8.11.2 foreigners version: 1.5 gochan .. version: 5.2.8 iset .. version: 2.2 iup . version: 1.9.3 lmdb version: 1.0.2 matchable . version: 1.0 miscmacros version: 1.0 modular-arithmetic .. version: 1.0.3 nanomsg ... version: 1.0.0.6 object-evict version: 0.1.1 optimism version: 0.1.0 protobuf version: 1.2.2 queues version: 0.1 regex . version: 2.0 sql-null .. version: 2.0 sqlite3 . version: 3.7.2 srfi-1 .. version: 0.5.1 srfi-13 ... version: 0.3 srfi-14 . version: 0.2.1 srfi-18 . version: 0.1.5 srfi-42 .. version: 1.76 srfi-69 . version: 0.4.1 srfi-99 . version: 1.4.5 synch ... version: 3.2.1 test .. version: 1.1 tweetnacl ... version: 1.4.2 utf8 version: 3.6.2 webview . version: 1.0.1
Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available
On Sat, 8 Jun 2019 15:07:34 +0200 Peter Bex wrote: > [...] > CHICKEN 5.1.0rc1 is now available at this location: > https://code.call-cc.org/dev-snapshots/2019/06/08/chicken-5.1.0rc1.tar.gz > [...] > Please give it a test and report your findings to the mailing list. > [...] Hello, testing the release candidate was successful in my environment :-) Operating system: Linux Mint 18.3 (Ubuntu 16.04 LTS derivative) Hardware platform: x86-64 C Compiler: GCC 9.1.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes The protobuf egg required another patch to work correctly with the changes regarding keywords and symbols, but that was a quick fix and a new version should soon be available for installation. Ciao, Thomas -- Time only waits for black holes. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] list of more than 2 elements is pair?
On Mon, 10 Dec 2018 11:48:56 + Paul Sika wrote: > [...] > I am trying a scheme tutorial using the chicken repl and i see that > (pair? '(1 2 3)) yields true. > is this normal ? > [...] Hello Paul, yes, this is perfectly normal: Every non-empty list satisfies the pair? predicate because lists are linked chains of cons cells. The expression '(1 2 3) can also be represented by the the following more verbose notation, which matches its in-memory structure more closely: '(1 . (2 . (3 . ( Everything represented by '(X . Y) or produced by (cons X Y) will satisfy pair?. I hope this helps :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. pgpOUkRfrNXO9.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Is Android not unix?
On Mon, 19 Nov 2018 13:19:10 +0300 Kristian Lein-Mathisen wrote: > [...] > I was trying tweetnacl on Termux on Android 9 and ran into this problem: > [...] Hello, a new version of tweetnacl (v1.4.1) should soon be available. Since I replaced the system-specific code dealing with entropy sources using the new portable random-bytes function from (chicken random), cond-expand is no longer necessary and these Android troubles should hopefully vanish into thin air :-) Ciao, Thomas -- Life is not a battle to win but a melody to sing. -- Amit Ray pgpY8CmkDtZMK.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-install package integrity/signing
Hello, implementing package signatures is technically not such a big deal (see the experimental example script here: https://paste.call-cc.org/paste?id=b5f6d4cce329d48d64eefbe0922b64aebb16a9e5 :-) But we need to decide who should be responsible for signatures and which keys should be trusted by the package manager. The simplest solution would probably be to have one trusted signing key and signatures applied automatically by the package server. However, this is not the most secure solution. The best guarantees for authenticity of the egg code would be given by signatures from the original package authors, however implementing that may require a significant infrastructural overhead to maintain up-to-date lists of current keys and which eggs they are allowed to sign. Ciao, Thomas -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer pgptNwZxw9kKf.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] openssl egg patch for default root certs
On Sun, 11 Nov 2018 23:35:08 -0600 Jim Ursetto wrote: > [...] > If you can find a better way I welcome it. My only request is that existing > eggs (particularly ones that call openssl through http-client) are able to > pull in the system default certs without changes to the eggs. It’s mainly > that a lot of eggs depend on openssl, whether advisedly or not. > > I know Kooda patched openssl on Chicken 5 to default to a certificate > authority file on macosx but it’s not valid for general use (neither the OS > nor homebrew uses this location — his patch doesn’t work on my box). And, the > default cert directory you use is not valid on RedHat (which stores certs in > various places under /etc/pki/tls), only Debian. > [...] Hello, during the CHICKEN hackathon I tweaked the openssl code a bit, trying to improve the handling of verification roots. You can set (ssl-default-certificate-authorities #t) (ssl-default-certificate-authority-directory #t) which is also the default now, to load verification roots from wherever OpenSSL thinks fit, or you can set the parameters to #f to disable verification by default, or you can set them to file / directory paths. @zbigniew: Check out the trunk version of openssl (r36870), perhaps it suits your needs :-) @wasamasa: Perhaps a new release of the egg is in order in the near future :-) Ciao, Thomas -- The greatest victory is that which requires no battle. -- Sun Tzu, "The Art of War" ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Is Android not unix?
On Mon, 19 Nov 2018 13:19:10 +0300 Kristian Lein-Mathisen wrote: > [...] > I was trying tweetnacl on Termux on Android 9 and ran into this problem: > > u0_a191@localhost ~/p/chicken-5.0.0> > csi -R tweetnacl -p '(make-symmetric-sign-key)' > > Error: (read-u8vector) bad argument type - not a port: #f > > > This happens because tweetnacl creates its current-entropy-port using > cond-expand with unix, windows or else, the latter which is yielding the #f > error above. > [...] Hello, interesting, I would have thought that Android would qualify as a unixoid system since it has a Linux kernel! If there is some other feature identifier I should use that would indicate the system likely supports /dev/random, please let me know so I can adapt the tweetnacl code. Anyway, as a workaround to get tweetnacl running, you can simply do (current-entropy-port (open-input-file "/dev/random")) by hand. I hope that helps :-) Ciao, Thomas -- Time only waits for black holes. pgpURM2wMZJF9.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CHICKEN 5.0.0 release candidate 4 available
On Mon, 29 Oct 2018 18:14:31 +0100 Peter Bex wrote: > [...] > The fourth release candidate for CHICKEN 5.0.0 is now available for > download: > > https://code.call-cc.org/dev-snapshots/2018/10/29/chicken-5.0.0rc4.tar.gz > [...] > If you can, please let us know the following information about the > environment on which you test the RC: > Hello, finally got around to testing the latest release candidate: Operating system:Linux Mint 18.3 / Ubuntu 16.04 Hardware platform: x86-64 C Compiler: GCC 8.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes Ciao, Thomas -- No woman should marry before she has slain her tenth man. -- Drow Proverb pgp7s_S1OdBe1.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Right-click default menu under Chicken-Scheme
On Fri, 2 Nov 2018 11:25:15 -0700 Ritika Agrawal wrote: > [...] > My team was working on enabling iup:matrix for one of our tools. We noticed > with the Chicken scheme code, we see a default menu on right-click menu. > This default menu is not observed with equivalent Lua code. Can you please > let us know what we can do to suppress this menu-item. > [...] Hello, probably this additional feature is added by the iupmatrixex library. To disable use of that library, pass #f for the second optional argument of the matrix constructor, as documented here: https://chust.org/repos/scheme-iup/doc/trunk/api/controls.wiki#matrix Ciao, Thomas -- Wenn *das* die Lösung sein soll, dann will ich mein Problem zurück! pgpdoJhqa3982.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CHICKEN 5.0.0 release candidate 3 available
On Mon, 8 Oct 2018 22:18:06 +0200 Peter Bex wrote: > [...] > The third release candidate for CHICKEN 5.0.0 is now available for > download: > [...] > Please give this new release candidate a try and report your findings > to the mailing list. Here's a suggested test procedure: > > $ make PLATFORM= PREFIX= install check > $ /bin/chicken-install -test awful > > If you can, please let us know the following information about the > environment on which you test the RC: > [...] Hello, the new release candidate seems to work fine for me :-) Operating system: Linux Mint 18.3 / Ubuntu 16.04 LTS Hardware platform: x86-64 C Compiler: GCC 8.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes, installed and passing its tests: address-info version: 1.0.2 amb . version: 3.0.0 check-errors version: 3.1.1 compile-file .. version: 0.1 condition-utils . version: 2.1.0 elliptic-curves . version: 1.0.3 fmt .. version: 0.8.11.1 foreigners version: 1.5 gochan .. version: 5.2.8 iset .. version: 2.0 lmdb version: 1.0.0 matchable . version: 1.0 miscmacros version: 1.0 modular-arithmetic .. version: 1.0.3 nanomsg ... version: 1.0.0.6 object-evict .. version: 0.1 optimism version: 0.1.0 protobuf version: 1.2.0 queues version: 0.1 regex . version: 2.0 sql-null .. version: 2.0 sqlite3 . version: 3.7.2 srfi-1 version: 0.5 srfi-13 ... version: 0.2 srfi-14 ... version: 0.2 srfi-18 ... version: 0.1 srfi-42 .. version: 1.75 srfi-69 ... version: 0.3 srfi-99 . version: 1.4.5 synch ... version: 3.0.2 test .. version: 1.0 tweetnacl ... version: 1.4.0 utf8 version: 3.5.0 webview . version: 1.0.0 Ciao, Thomas -- We live in a society absolutely dependent on science and technology and yet have cleverly arranged things so that almost no one understands science and technology. That's a clear prescription for disaster. -- Carl Sagan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Understanding Chicken 5 build scripts.
On 12 Sep 2018 19:28:25 +0200 Jörg F. Wittenberger wrote: > [...] > since I learned how CHICKEN 5's chicken-install creates platform specific > build scripts, I wonder: why? > [...] Hello, it seems to me this approach could come in handy when you want to execute build steps on different hosts in complicated cross-compilation scenarios. But I'm not sure how well this is supported. Ciao, Thomas -- I think that in the nuclear world the true enemy can't be destroyed. [...] In my humble opinion, in the nuclear world the true enemy is war itself. -- Cmdr. Hunter from the movie "Crimson Tide" ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] CHICKEN 5.0.0 release candidate 2 available
On Sun, 9 Sep 2018 14:30:12 +0200 Peter Bex wrote: > [...] > If you can, please let us know the following information about the > environment on which you test the RC: > [...] Operating system:Linux Mint 18.3 (based on Ubuntu 16.04) Hardware platform: x86-64 C Compiler: GCC 8.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes Ciao, Thomas -- An altruist is simply a merchant who has yet to name his price. -- Romulan Proverb ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 17:20:09 -0400 John Cowan wrote: > On Wed, Aug 29, 2018 at 4:21 PM wrote: > > > > I don't see the motivation for installing files outside of the chicken > > installation > > tree, so it is not clear to me what you want to achieve with this. > > > > From what I understand (which may be wrong) it's so that chicken-install > can put a > file in a place expected by some external library. > [...] Hello, that is precisely the use case I have in mind, yes. Also, on my machine I consider the entire /opt/chicken prefix to be my "chicken installation tree", and I don't want to put anything outside of that, but I do want to put things inside in any location that appears right, not just one of three fixed paths ;-) Ciao, Thomas -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 14:17:08 +0200 felix.winkelm...@bevuta.com wrote: > > [...] > > I can't say that I like this design decision, but I guess I'll have to > > live with it. If this is unsupported, it also feels strange that > > the .egg format allows specification of multiple import libraries per > > extension at all – the provider side of the picture, when you write a > > library with multiple modules, is supported, but the consumer side, > > when you try to use it, is suddenly not supported any longer. > > I'm not sure what you mean, some example would be helpful here. > [...] Hello Felix, hmm, I was under the impression that we could now declare multiple (modules ...) in an (extension ...) but there was no way to access them because (import ...) would always try to load both the import library and the extension of the same name. However, I just realized that my old default approach of doing (require-library ...) first and (import ...) later still seems to work fine. Only when commpiling such code, CHICKEN will always complain that the extensions with the same names as the modules do not exist, but that's a minor nuisance. So never mind that stupid question ;-) Ciao, Thomas -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 14:09:01 +0200 felix.winkelm...@bevuta.com wrote: > > [...] > > multiple sets of files may already be possible with multiple component > > forms in the .egg, but installation into any nested subdirectories relative > > to the CHICKEN installation prefix is currently not possible. > > > > For example, some include files provided with the protocol buffers egg > > would technically have to be stored in certain subdirectories of the C > > include path (/extend/protobuf/...) for the protocol buffer > > compiler to pick them up correctly. Currently I have to move those files > > around manually after installation. > > Can you supply me with a sample .egg file that specifies > the case you'd like to have supported? > [...] Hello Felix, you could take a look at protobuf.egg in the CHICKEN 5 branch[1]. There you will find a clause that reads: (c-include extend/protobuf (files "extend/protobuf/bigint.proto" "extend/protobuf/chicken.proto")) What I would like is to install these files as /include/extend/protobuf/bigint.proto /include/extend/protobuf/chicken.proto what actually happens is that these files are installed as /include/chicken/bigint.proto /include/chicken/chicken.proto but the .egg-info file lists /include/chicken/extend/protobuf/bigint.proto /include/chicken/extend/protobuf/chicken.proto The inconsistency between the installation script and the .egg-info file is probably a bug. Additionally I propose that the (destination ...) form should be made relative to the default target directory and create all specified subdirectories as necessary, then I could just add a (destination "../extend/protobuf") to the c-include form above and be happy. At least this would make a lot more sense than the current behaviour where a relative path in the destination form is relative to the source directory where the egg is built, and the correct absolute path for the destination can never be determined correctly at the time the .egg file is written. Ciao, Thomas -- [1]: http://chust.org/repos/chicken-protobuf/doc/chicken-5/protobuf.egg -- I think that in the nuclear world the true enemy can't be destroyed. [...] In my humble opinion, in the nuclear world the true enemy is war itself. -- Cmdr. Hunter from the movie "Crimson Tide" ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 10:57:54 +0200 felix.winkelm...@bevuta.com wrote: > > As far as I understand the question (probably not really), a simple way to > > do this is to (foreign-declare "#include \"foo.c\"") and add foo.h to the > > source-dependencies of the file (see for example the simple-sha1 and > > simple-md5 eggs, they do this). No need for any special handling. > > > > Of course it means your C files get a lot larger, and you don't benefit > > from reduced compilation times from separate compilation. > > That's right, this will work in many cases. On the other hand, foo.c > will be compiled in the environment that chicken.h defines, including > all macro and type definitions, which may pollute what foo.c expects > to be seen. "Reparing" the environment may range from difficult to > impossible should foo.c have name clashes with anything defined > in chicken.h. Moreover, foo.c may need special compilation flags > that are not compatible with CHICKEN-generated source code. > [...] Hello, I would argue that mashing together C compilation units using brute-force #include is almost never the right thing to do and will rarely work correctly, for the reasons Felix pointed out, unless the code has specifically been written to function in the environment provided by the other header files. C is designed to use a number of separate files to manage the global state of preprocessor and compiler! Ciao, Thomas -- Intelligence may only be the second oldest profession in the world, but it is more immoral and there are more amateurs practicing it than the oldest one. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Some questions about CHICKEN 5 eggs and modules
On Tue, 28 Aug 2018 20:40:33 +0200 felix.winkelm...@bevuta.com wrote: > [...] > I'll try to address some of your questions. > [...] Hello, thanks for taking the time to reply :-) > [...] > > - Some eggs install one extension library containing several modules. The > > new > > CHICKEN module system always tries to load a library named the same as the > > module upon import. Is it no longer possible to separate library loading > > and > > module import? How can one consume those "compound" libraries now? > > To simplify the confusion related to "require-extension", "use", etc. > "import" does now both loading and import in one step. "Compound" libraries > [...] must be done manually and is not directly supported by the new > system. > [...] > The underlying machinery is still the same, but in the interest of making > things simpler for the user, the high-level view that can be specified in > egg files provides fewer options. > [...] I can't say that I like this design decision, but I guess I'll have to live with it. If this is unsupported, it also feels strange that the .egg format allows specification of multiple import libraries per extension at all – the provider side of the picture, when you write a library with multiple modules, is supported, but the consumer side, when you try to use it, is suddenly not supported any longer. You also suggest that separating load and import is possible when done "manually", but I couldn't find any information on how one would approach that. Could you elaborate this "manual" approach a little bit? > > [...] > > - If an (extension ...) form in an .egg file lists modules that have a > > composite name, such as (foo bar), the egg installation process then tries > > to > > pass the literal "(foo bar)" as a component of the import library name to > > the > > compiler and it appears in the generated install script. Is this a bug or > > is it > > intentional? It seems inconsistent with the name mangling using "." between > > module name components that is applied elsewhere. > > This is a bug. Compound names should be canonicalized using "." syntax > when they appear in user forms. If you can provide a simple example, we can > try to address this. > [...] $ cat foobar.scm (module (foo bar) (hello) (import scheme) (define (hello) (display "Hello world!") (newline)) ) $ cat foobar.egg ((components (extension foobar (modules (foo bar) $ chicken-install -n building foobar [...] /opt/chicken/bin/csc -setup-mode -s -host -I /home/murphy/foobar -C -I/home/murphy/foobar -O2 -d0 /home/murphy/foobar/(foo bar).import.scm -o /home/murphy/foobar/(foo bar).import.so csc: file `/home/murphy/foobar/(foo bar).import.scm' does not exist Error: shell command terminated with nonzero exit code 16384 "sh /home/murphy/foobar/foobar.build.sh" > > [...] > > - How can I compile multiple source files, for example one scheme file and > > several C files, into an extension library in an .egg file? As far as I can > > see, the only way to do that is a custom build script, but that has > > problems of > > its own. In particular it is nearly impossible to do this right in the case > > of > > static linking, where CHICKEN seems to expect a single object file output > > (yes, > > ELF object files can be merged, but that's a pain in the rear). > > Yes, use a custom build script. I'm working on a way to handle the case of > separate > ..c files that need to be linked. Due to how we support static linking this > is > not trivial. > [...] How about producing .a / .lib files instead of .o files for static linkage – wouldn't that simplify including multiple compilation units? Thanks again for the useful feedback! Ciao, Thomas -- Liebe ist die beste Geisteskrankheit, die man sich wünschen kann. -- Lisa Eckhart ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules
Hello,
multiple sets of files may already be possible with multiple component forms in
the .egg, but installation into any nested subdirectories relative to the
CHICKEN installation prefix is currently not possible.
For example, some include files provided with the protocol buffers egg would
technically have to be stored in certain subdirectories of the C include path
(/extend/protobuf/...) for the protocol buffer compiler to pick them
up correctly. Currently I have to move those files around manually after
installation.
Ciao,
Thomas
On Tue, 28 Aug 2018 14:24:47 -0700 Ivan Raikov wrote:
> Yes, exactly, the issue is installing multiple sets of files in
> different subdirectories of PREFIX/{include,share}. It would be very
> useful for "c-include" as well as "data" components.
> Thanks,
>
> -Ivan
> On Tue, Aug 28, 2018 at 1:07 PM wrote:
> >
> > > I have a couple of eggs that generate and compile code similar to the
> > > way chicken-crunch works. These eggs would install header or source
> > > files that are required for the compilation process. Some of these
> > > source files belong to distinct functional modules that are organized
> > > in subdirectories. In CHICKEN 4, it was possible to install these
> > > files to corresponding subdirectories of CHICKEN_PREFIX/share/chicken,
> > > thus preserving the logical structure. In CHICKEN 5, this is currently
> > > not possible, but I think it would be a very convenient feature. We
> > > can of course define our own conventions and install the additional
> > > files into subdirectories of $HOME, but it makes more sense to me to
> > > keep them in the CHICKEN directory hierarchy. I hope this makes sense.
> >
> > So the basic problem is to install multiple sets of files, in separate
> > steps? I think for "scheme-include" components this should be possible,
> > but (as far as I can see) this is not currently possible for "c-include"
> > components (but could be added).
> >
> >
> > felix
> >
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
--
Life is not a battle to win but a melody to sing.
-- Amit Ray
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Crash in SRFI-69 eq?-hash
On Mon, 27 Aug 2018 21:23:16 +0200 ko...@upyum.com wrote: > [...] > This has been fixed in SRFI-69 0.3, hope it works fine for you now! > [...] Hello, thanks a lot, it works like a charm and allowed me to release a new version of the protocol buffers egg :-) Ciao, Thomas -- An altruist is simply a merchant who has yet to name his price. -- Romulan Proverb ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Some questions about CHICKEN 5 eggs and modules
Hello, playing with the new CHICKEN 5 module system and egg format raised a couple of questions in my head – perhaps someone on this list can provide a few answers :-) - Some eggs install one extension library containing several modules. The new CHICKEN module system always tries to load a library named the same as the module upon import. Is it no longer possible to separate library loading and module import? How can one consume those "compound" libraries now? - If an (extension ...) form in an .egg file lists modules that have a composite name, such as (foo bar), the egg installation process then tries to pass the literal "(foo bar)" as a component of the import library name to the compiler and it appears in the generated install script. Is this a bug or is it intentional? It seems inconsistent with the name mangling using "." between module name components that is applied elsewhere. - How can I specify compiler flags and native library dependencies specific to certain target platforms in an .egg file? As far as I can see, the only way to do that is a custom build script, but that has problems of its own. - How can I compile multiple source files, for example one scheme file and several C files, into an extension library in an .egg file? As far as I can see, the only way to do that is a custom build script, but that has problems of its own. In particular it is nearly impossible to do this right in the case of static linking, where CHICKEN seems to expect a single object file output (yes, ELF object files can be merged, but that's a pain in the rear). - When I specify a custom build script for an extension library in an .egg file, it is used to compile both the extension library and the import libraries. Frequently, some special build flags are required for the extension library to include / link to native code, but not for the import library. Implementing special logic in the build script to differentiate these cases is clumsy and error prone. Is there a better way to handle that situation? - Is there a clean way to install C and Scheme include files somewhere else than the default place from an .egg file? It seems to be possible to specify absolute target paths, but that is pretty much useless since the prefix of the CHICKEN installation is not known at the time the .egg file is written. Also, specifying relative *source* paths for include files doesn't even work, if they have subdirectory components, because the files get installed in the top level target directories but their full relative paths get entered into the .egg-info files. An equivalent to custom build scripts doesn't seem to exist for file deployment either. Any helpful insight would be appreciated! Ciao, Thomas -- Intelligence may only be the second oldest profession in the world, but it is more immoral and there are more amateurs practicing it than the oldest one. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Crash in SRFI-69 eq?-hash
On Sun, 19 Aug 2018 14:08:38 +0200 ko...@upyum.com wrote: > [...] > I checked the code and, for number types, only fixnums and flonums are > explicitely handled, other numeric types trigger an incorrect recursion. > > It seems we forgot to add support for the new numeric types to srfi-69 > when we introduced them. > [...] Hello, thanks for taking the time to look into this! Your explanation makes a lot of sense, I also suspected the newly added numeric tower support in core may have broken some low-level type-specific logic. I just didn't understand enough of the magic around ##sys#object->uid, for which I couldn't immediately find any definition in the CHICKEN source, to get a firm grasp of how the default hash functions in srfi-69 work at all. For the moment being I have implemented a hackish workaround using (define %eq?-hash (foreign-lambda* int ([scheme-object v] [int bound]) "C_returnintptr_t) v) >> C_FIXNUM_SHIFT) % bound);")) which is probably terribly incorrect in case the garbage collector moves objects around, but memory load seems low enough and table lifetimes short enough in my use case for this to work momentarily %-] Ciao, Thomas -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Crash in SRFI-69 eq?-hash
On Sun, 19 Aug 2018 10:25:44 +0100 Chris Vine wrote: > On Sun, 19 Aug 2018 03:40:26 +0200 > Thomas Chust wrote: > > [...] > > Then I realized that eq?-hash simply cannot be called on certain types > > of objects: > > [...] > > $ csi > > CHICKEN > > (c) 2008-2018, The CHICKEN Team > > (c) 2000-2007, Felix L. Winkelmann > > Version 5.0.0rc1 (prerelease) (rev 9d480412) > > linux-unix-gnu-x86-64 [ 64bit dload ptables ] > > > > #;1> (import srfi-69) > > ; loading /opt/chicken/lib/chicken/9/srfi-69.import.so ... > > ; loading /opt/chicken/lib/chicken/9/srfi-69.so ... > > #;2> (eq?-hash 2/3) > > [panic] out of memory - heap has reached its maximum size - execution > > terminated > > [...] > > It probably shouldn't crash, but since '(eq? 2 2)' is allowed to evaluate > to #f, depending on the implementation, does it matter that much? (Maybe > crashing is better than a hash function silently failing to produce a > workable hash.) > [...] Hello, this matters a lot: For one I have an application where it is crucial to be able to identify if the exact same object is passed more than once into certain functions and to be able to detect cyclic data structures – eq? and eq?-hash are supposed to be applicable to precisely that situation. Secondly, and maybe even more importantly, the implementation of eq?-hash in the srfi-69 egg seems to be based on that for eqv?-hash and equal?-hash in the case of non-immediate data objects: $ csi -R srfi-69 -p '(eqv?-hash 2/3)' [panic] out of memory - heap has reached its maximum size - execution terminated [...] $ csi -R srfi-69 -p '(equal?-hash 2+3i)' [panic] out of memory - heap has reached its maximum size - execution terminated [...] In other words, none of the hash functions offered by the srfi-69 egg are usable at all! And lastly, a hash function that goes with a certain equality predicate should always be applicable to the entire domain of the equality predicate to be of any practical value. Ciao, Thomas -- No woman should marry before she has slain her tenth man. -- Drow Proverb ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Crash in SRFI-69 eq?-hash
Hello, while trying to port some code from CHICKEN 4 to CHICKEN 5 I have just spent several hours tracking down a crash to a call of hash-table-ref/default for a table which happened to use eq? as the comparison function and was loaded with various types of objects as keys. Then I realized that eq?-hash simply cannot be called on certain types of objects: $ chicken-status [...] srfi-69 ... version: 0.2 [...] $ csi CHICKEN (c) 2008-2018, The CHICKEN Team (c) 2000-2007, Felix L. Winkelmann Version 5.0.0rc1 (prerelease) (rev 9d480412) linux-unix-gnu-x86-64 [ 64bit dload ptables ] #;1> (import srfi-69) ; loading /opt/chicken/lib/chicken/9/srfi-69.import.so ... ; loading /opt/chicken/lib/chicken/9/srfi-69.so ... #;2> (eq?-hash 2/3) [panic] out of memory - heap has reached its maximum size - execution terminated Apart from fractions, complex numbers also seem to trigger the crash reliably. Since I don't see any obvious reason why hashing by object identity should be impossible for certain values, I consider this a serious bug :-/ Ciao, Thomas -- The greatest victory is that which requires no battle. -- Sun Tzu, "The Art of War" pgprDuOC891ZE.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] CHICKEN 5.0.0 release candidate 1 available
On Sat, 11 Aug 2018 11:43:58 +0200 Peter Bex wrote: > [...] > After many years of development, we are happy to announce the first > release candidate of the upcoming CHICKEN 5.0.0. This represents the > largest change in CHICKEN since the 4.0.0 release. > [...] Hello, thanks for all the hard work, it's good to see CHICKEN 5.0 getting close to completion :-) > [...] > If you can, please let us know the following information about the > environment you tested the RC tarball on: > [...] Operating system: Linux Mint 18.3 Hardware platform: x86-64 C Compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) Installation works?: yes Tests work?: yes Installation of eggs works?: yes Ciao, Thomas -- We live in a society absolutely dependent on science and technology and yet have cleverly arranged things so that almost no one understands science and technology. That's a clear prescription for disaster. -- Carl Sagan pgpYkIgQed8_p.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] case - should that even work?
On Sun, 15 Jul 2018 20:36:41 +0200 Martin Schneeweis
wrote:
> [...]
> please can someone explain to me why the following even works?
>
> (define sym 'b)
>
> (case sym
> ('a "an 'a'")
> ('b "a 'b'")
> ('c "a 'c'")
> (else "something else")) ; -> a 'b'
> [...]
> I know the r5rs document just says "Each _should_ have the
> form (( ...) ...)
> [...]
Hello,
contrary to what you assume, these clauses *are* actually in the form specified
by the standard :-D
The apostrophe is a *reader* macro, so before the compiler or interpreter ever
gets to see that code, 'a is transformed to (quote a), 'b to (quote b) and 'c
to (quote c). These three forms are obviously lists with two elements and
represent case descriptors matching the symbols quote or a, quote or b and
quote or c respectively.
Try setting sym to 'quote and see what happens!
Ciao,
Thomas
--
The greatest victory is that which requires no battle.
-- Sun Tzu, "The Art of War"
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken + IUP precompiled bundle for Raspbian (ARM) available.
On Mon, 9 Jul 2018 10:44:05 -0700 Matt Welland wrote: > [...] > However the IUP egg uses ffcall which doesn't work on GNURoot, presumably > because it is a chroot environment. > [...] Hello, to me it seems more likely that some security feature such as non-executable stack interferes with ffcall. That library is old and I should really replace it with libffi in the IUP egg at some point – the problem is just that libffi has a far more complicated API :-/ Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. pgp8FFEaHckgL.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Reason to Celebrate
Dear friends, hopefully you're all doing well! I have reason to celebrate: It has taken me some years, but I eventually defended my PhD thesis last winter and just now the bureaucratic followup is completed – I hold the official doctorate degree in my hands. Since this feels at least as good as birthday and christmas together, I'd like to invite you to join me for a party (if you are interested and happen to be near Munich, Germany) :-D You can find an electronic survey at https://dudle.inf.tu-dresden.de/lw4cqmfv/ to determine a convenient common date for a little evening reception sometime in August/September, and I'll organize a venue somewhere central in Munich. If you and/or someone you know would like to join, let me know the number of persons and a contact address by e-mail or through the survey not later than 22nd of July. I'll send every interested party another message once a date and venue have been found. Kind regards, Thomas -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer pgpk0tb4dknBM.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] CHICKEN 4.13.0 release candidate available
On Tue, 5 Dec 2017 20:52:11 +0100 Peter Bex wrote: > [...] > If you can, please let us know the following information about the > environment you tested the RC tarball on: > [...] Hello, some results from the systems I use: Operating system: FreeBSD 12.0-CURRENT Hardware platform: amd64 C Compiler: FreeBSD clang version 4.0.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes Operating system: FreeBSD 12.0-CURRENT Hardware platform: amd64 C Compiler: gcc5 (FreeBSD Ports Collection) 5.4.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes Operating system: Linux Mint 17.3 / Ubuntu 14.04 / Linux 3.19.0-80-generic Hardware platform: amd64 C Compiler: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 Installation works?: yes Tests work?: yes Installation of eggs works?: yes Operating system: Linux Mint 17.3 / Ubuntu 14.04 / Linux 3.19.0-80-generic Hardware platform: i686 C Compiler: i686-w64-mingw32-gcc (GCC) 4.8.2 Installation works?: no (compiler error: alloca.h: No such file or directory) Tests work?: no Installation of eggs works?: no Operating system: ReactOS 0.4.6 Hardware platform: i686 C Compiler: Digital Mars Compiler Version 8.42n Installation works?: no (compiler error: unistd.h is not for Windows use) Tests work?: no Installation of eggs works?: no Operating system: ReactOS 0.4.6 Hardware platform: i686 C Compiler: gcc (tdm-1) 4.9.2 Installation works?: yes Tests work?: no (compiler error: (get) bad argument type - not a symbol: 0.0) Installation of eggs works?: no (compiler error: (get) bad argument type - not a symbol: 0.0) Apparently the build result using the MinGW tool chain on ReactOS has some problem in the reader: > csi -p + 0.0 All in all it doesn't look too bad, though ;-) Ciao, Thomas -- Wenn man Menschen das Ehrlichsein beibringen will, muß man erst allen Menschen beibringen die Wahrheit hören zu können. pgpIzt42wIGsZ.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken hacking
Hello, this sounds like a fun idea. I could probably participate at any of the suggested dates, but so far I also have no idea how to get there other than by teleportation ;-) Ciao, Thomas On 2017-03-15 13:16, Juergen Lorenz wrote: > Hi all, > > last year, in Nuremberg, I asked some of you, what you thought about the > next meeting in the deep Lower Saxonian province. To be more precise, in > 29471 Gartow/Elbe. Only in October at weekends 6.-8., 13.-15. and > 20.-22.10 we could hire the "Haus im Wald", see > > bernstorff.de/ferienwohnungen/haus-im-wald-rucksmoor > > It could accomodate 16 persons, and the price is EUR 396,- per night, > plus EUR 200,- for cleenup after the meeting, i.e. ca. EUR 50,- per > person for the weekend. > > There is only one serious problem with this location: How to get there. > The nearest places you could reach comfortably per train ar Uelzen, > Lueneburg, Salzwedel or Wittenberge. From there you must have a car. > > The people from abroad could fly to Hannover, meet there, hire a car and > drive to Gartow. The others might agree to meet at any place and drive > together to Gartow. I can't help with this. > > If you think, this problem is solvable and if you are interested in this > proposal, let me know and tell me your prefered date. Since the house is > very popular, I should hire it soon. I personally prefer the first date. > > I've only the eMail adresses of some of you (see this mail header). So > please inform the other people, who might be interested to join us. > > Cheers > > Juergen > > PS: If some equipment is needed besides wlan, we must provide it ourselfs. > -- Es würde viel weniger Böses auf Erden geben, wenn das Böse niemals im Namen des Guten getan werden könnte. -- Marie von Ebner-Eschenbach signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] numbers egg depends on libstdc++ and some questions
On 2017-02-25 10:12, Vasilij Schneidermann wrote: > [...] >> 1) Why does the numbers egg use libstdc++ ? Just curious. > > This is most likely due to Windows not really giving you a C compiler or > runtime. MSVCRT is actually a C++ runtime with loads of extern "C". > cl.exe is actually a C++ compiler covering a subset of C. > [...] Hello, while this picture of the Microsoft Visual C toolchain's properties may be accurate, it is most likely irrelevant to the problem described by the OP. The original message explicitly mentioned that MinGW was being used and that a GCC runtime library was needed, so the compiler in question would have to be the GCC version shipping with MinGW rather than MSVC. This GCC compiler uses GNU C and C++ libraries. There should not be any implicit compile-time or run-time dependencies on any component of the MSVC toolchain or libraries in this scenario. (In fact, it can even be difficult to introduce explicit dependencies from code compiled by MinGW GCC on libraries compiled by MSVC or vice versa). The GNU C library shipping with MinGW depends only on the Windows kernel interface DLLs and certainly not on the GNU C++ library shipping with MinGW. I can only speculate as to why the numbers code has a dependency on the C++ standard library under MinGW. Perhaps some math routines are hiding in that library -- if I remember correctly there is no libm*.dll in MinGW. Ciao, Thomas -- Es würde viel weniger Böses auf Erden geben, wenn das Böse niemals im Namen des Guten getan werden könnte. -- Marie von Ebner-Eschenbach signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg: sodium
On 2017-02-25 13:39, Caolan McMahon wrote: > [...] > The egg is a work in progress, but it already has a few useful procedures. > [...] Hello, in case you are missing some procedures, perhaps the source code of the tweetnacl egg may help as a template -- the tweetnacl egg includes the C backend code it uses, but the APIs of tweetnacl and libsodium are virtually identical. (The only notable difference that comes to my mind right now is that the tweetnacl egg provides the source of randomness externally while libsodium has its own internal routines). Ciao, Thomas -- Es würde viel weniger Böses auf Erden geben, wenn das Böse niemals im Namen des Guten getan werden könnte. -- Marie von Ebner-Eschenbach signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Compiling a shared library from swig interface
On 2016-10-22 13:16, spalis wrote: > [...] > Error: (load) unable to load compiled module - ./example.so: undefined > symbol: _ZTV6Square: "./example.so" > [...] Hello, well, binutils tells us that $ c++filt _ZTV6Square vtable for Square So the shared object you built apparently does not link correctly against the C++ backend code you want to wrap. You may have to add some linker flags to the CHICKEN compiler command line to pull in necessary external libraries. You may also want to pass the --no-undefined option to the GNU linker when building the shared object (using csc ... -L -Wl,--no-undefined ...), which will instruct the linker to report this kind of error rather than deferring its detection to runtime :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Compiling multiple modules into a single executable
On 2016-10-16 23:13, Josh Barrett wrote: > [...] > Can you generate a .import without compiling your module? > [...] Hello Josh, as far as I know, the .import.scm files are always generated as a side effect of compiling a source file. However, it may be possible to discard the primary results of compilation and reuse the import libraries for a second compiler run, although this is not the intended approach. You could also avoid the need for import libraries and unit declarations by translating all your scheme code as a single compilation unit. Simply concatenating all the files containing the module forms and compiling the result should work. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Compiling multiple modules into a single executable
On 2016-10-16 22:52, Josh Barrett wrote: > [...] > $ csc -c foo.scm bar.scm > > Syntax error (import): cannot import from undefined module > --- > As I understand it, this should work, but it obviously doesn't. Does > anybody know why? > [...] Hello, this cannot work because the compiler cannot find the necessary import libraries. Try compiling the two files separately and emitting import libraries like this: $ csc -c foo.scm -J $ csc -c bar.scm -J You can then link to a main program in a separate step, like this: $ cat main.scm (declare (uses bar)) (import bar) (baz) $ csc foo.o bar.o main.scm -o foobar $ ./foobar quuxbaz Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] iup egg seems to be incompatible with the latest release of iup
On 2016-09-29 19:12, Jeff Moon wrote: > [...] > I recently decided to try and get onto the latest version of IUP (3.19.1) > and it appears that the IUP developers have changed the name of or removed > one of the header files between 3.17 and 3.19.1. The missing file is > include/iup_pplot.h. > [...] Hello Jeff, that may well be. If I recall correctly, the pplot widget has been deprecated for a while and there are two alternatives available, namely plot and mglplot. > [...] > This is causing the iup egg to be unable to build when linked with the new > versions of IUP. > [...] Not quite. You can configure what optional libraries the IUP egg should bind. Just compile with -D disable-iup-pplot and this particular problem should vanish together with the bindings for the pplot widget :-) > [...] > I'm hoping that the developer of the iup egg is on the list and can maybe > take a look. > [...] /me takes a confused look around I hope the configuration flag I mentioned helps, otherwise let me know and I'll see whether I can get my egg to compile again somehow ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] canvas-draw and colors
On 2016-07-16 21:31, Matt Welland wrote: > [...] > (define (vg:rgb->number r g b #!key (a 0)) (u32vector-ref > (blob->u32vector (u8vector->blob (list->u8vector (list a r g b 0)) > [...] Hello, this snippet seems somewhat sub-optimal to say the least. Apart from being needlessly complicated, it may also be wrong because its result depends on the endianness of the host platform. I would suggest to simply use bitwise arithmetic: (bitwise-ior (arithmetic-shift a 24) (arithmetic-shift r 16) (arithmetic-shift g 8) b) Or perhaps just normal arithmetic replacing bitwise-ior by + and arithmetic-shift by (lambda (x n) (* x (expt 2 n))). This is probably no less efficient, as the result is going to be a bignum anyway. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] extension loading in sqlite3 egg
On 2016-06-07 21:08, Kristian Lein-Mathisen wrote: > [...] > Thank you very much, Thomas! Works great for my purposes. Any chance of > giving this a new tag for release? > [...] Hello Kristian, I'll take your positive response as a successful test result and just add a tag to the sqlite3 egg ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] extension loading in sqlite3 egg
On 2016-05-24 11:25, Kristian Lein-Mathisen wrote: > [...] > In the sqlite3 command-line, this works fine. The solution was to enable > extension loading which is not allowed by default: > https://www.sqlite.org/c3ref/enable_load_extension.html > > However, this Sqlite3 function isn't available in the egg. > [...] Hello, I have added an enable-load-extension! procedure to the trunk version of the sqlite3 egg. In addition to what your patch did, I added some boilerplate error checking code, which can't hurt, and a feature flag to turn the procedure into a stub, in case someone wants to compile the egg with an old or otherwise restricted version of SQLite3. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] strange IUP canvas behavior - mouse clicks returning bad value
On 2015-10-16 11:40, Matt Welland wrote: > [...] > this is failing on Ubuntu 15.04 but working ok on sles11. > [...] Hello, are the systems in question running on the same architecture? Do they have the same word size? My gut feeling says that the problem looks suspiciously like some calling convention or data type conversion issue. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] iup cells draw callback
On 2015-10-15 04:04, Martin DeMello wrote: > [...] > it looks like the cb-draw callback has format "iiC", which doesn't > match the sigil regex. I take it that means callbacks with a Canvas* > argument are unsupported in chicken-iup? > [...] Hello Martin, that is correct, however support is trivial to add: Add the #\C character to the regular expression for callback signatures, add a case for #\C typed arguments in the dispatcher that treats them identically to #\v typed arguments, use pointer->canvas from the canvas-draw egg in your callback code to add the right type tags to the raw pointer. I think that the #\C signature character has been introduced recently in IUP. Anyway, I added the necessary marshalling code as outlined above to the iup egg, it is available in the trunk version of the code. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Q] Can I make port on byte array?
On 2015-10-07 03:04, Sungjin Chun wrote: > [...] > In Common Lisp, I can make a stream on byte array and can write > values on them, in Scheme, I think the equivalent stuff is port and > I'd like to write values on byte array using port. > [...] Hello, it sounds like you are looking for something like call-with-output-string. The resulting string can be converted with string->blob, blob->u8vector, ... Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Incorrectly linked binaries with chicken-install -deploy
On 2015-08-14 04:43, Ryan Senior wrote: > Does anyone have stand-alone application deployments working via > chicken-install? I'm running into an issue where the binaries for my > executables are in place, but they are linked to the system libchicken. > [...] Hello, the libchicken.so.* is a dynamic library and dynamic libraries are linked, well, dynamically ;-) This means, which library is actually loaded when the dependent program or library is loaded can vary depending on several parameters. If you wanted to play safe, you could include a -Wl,-rpath,'$ORIGIN' in CSC_OPTIONS while running chicken-install or even put "-L" "-Wl,-rpath,$ORIGIN" in the compiler options in your build script. You should also ensure that the libchicken.so.* is actually present alongside your compiled binaries, of course, but that can be done by simply copying it there. This may be necessary, because the dynamic linker of Linux performs a rather convoluted search for dynamic libraries in a number of directories, picking the first one that it finds: (1) The linker examines the executable (and already loaded libraries) and looks for a DT_RPATH ELF section attribute. If that attribute is present and no DT_RUNPATH attribute is also present, the linker will search the directories specified in that attribute. (2) The linker examines the LD_LIBRARY_PATH environment variable. Unless the executable in question is setuid or setgid, all directories specified in that variable are searched. (3) The linker examines the executable (and already loaded libraries) and looks for the DT_RUNPATH ELF section attribute. If this attribute is present, the linker searches the directories specified there. (4) Unless the executable in question was linked with some magic flags to disable default library locations, the linker now consults a system wide cache (/etc/ld.so.cache) and eventually may resort to searching some core system default directories like /lib for the library. When you call ldd on a binary, that binary is actually loaded, its initialization code, if any, is executed, and the dynamic linker is asked to report all the dependencies that it loaded, too. Thus what ldd reports may, for example, be different from what is actually happening at the runtime of your program, if you apply ldd to a dynamic library without a DT_RUNPATH attribute but link your actual host program with a DT_RUNPATH attribute. I suspect that is precisely what happens, because, if I'm not mistaken, csc -deploy links the executable with a -rpath linker flag (or something equivalent) while chicken-install doesn't do that. To see what DT_RPATH and DT_RUNPATH attributes are set in your libraries and executables, or to modify them, you can use the utility program chrpath. I hope that helps :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken works great on Debian noroot on android - any suggestions for best path for graphics?
On 2015-07-25 19:54, Matt Welland wrote: > On Sat, Jul 25, 2015 at 2:28 AM, Jörg F. Wittenberger wrote: >> >> >> This assessment is surprising to me. Maybe I did not yet run into the >> issues? >> >> For a couple of days I've been trying this out. On debian/ARM. >> [...] > > Ah, I'll give it a try. For some reason I thought it didn't work. > [...] Hello, recently there was a message on this mailing list [1] which described problems running the ffcall library on an armhf platform. That report also left the impression with me that ffcall and consequently IUP would not work on Android devices, but I haven't investigated this further. Ciao, Thomas -- [1] https://lists.nongnu.org/archive/html/chicken-users/2015-06/msg00050.html -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] openssl egg segfauls: ##sys#expand-home-path
On 2015-05-21 09:18, Kristian Lein-Mathisen wrote: > I see, that sounds sensible. Could you apply the no-home-path-expansion > patch and fix it upstream, so that openssl will work on 4.9.01? > [...] Hello, I just checked and apparently the home path expansion stuff is still in place in released versions of chicken: My installation of CHICKEN reports Version 4.9.0.1 (stability/4.9.0) (rev 8b3189b) and it has ##sys#expand-home-path and does automatic home path expansion for standard I/O procedures such as open-input-file :-/ There is commit 4f91e654f04254ba1039e327460e643fefbf5e36 in CHICKEN's Git repository that gets rid of this cruft, but it's not included in any released source tarball, as far as I can tell. I have removed the uses of ##sys#expand-home-path from the trunk version of the OpenSSL egg, but I think it doesn't make sense to tag a release at the moment. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] openssl egg segfauls: ##sys#expand-home-path
On 2015-05-19 13:35, Kristian Lein-Mathisen wrote: > [...] > It's been way too long! I'm running CHICKEN 4.9.0.1 and the openssl-egg > segfaults at ssl-load-certificate-chain! and friends. > > I have two patches/suggestions: > - remove home path expansion > - use the pathname-expand egg > [...] Hello, the only reason this functionality was included in the first place, was that CHICKEN's standard I/O procedures used to perform automatic home directory expansion, so I wanted the OpenSSL egg to behave similarly. If I'm not mistaken, the standard I/O procedures no longer do home directory expansion by default. I think it would make sense to also remove this functionality from the OpenSSL egg. If needed, one could always make use of the pathname-expand egg explicitly, which would make the intent clearer. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] find-library only tests static libs on Windows?
On 2015-05-05 02:08, Matt Gushee wrote: > [...] > But I'm wondering why I needed to do that. Is there some reason why it > would be a bad idea, or would not work, for find-library to test DLLs as > well as static libs? > [...] Hello, while I am no expert on windows linkage madness, my understanding is that you are not really supposed to link directly against a DLL, but rather against a static import library that knows how to interface with the DLL. While some compilers can magically synthesize an import library given only a DLL and the right external function declarations, that is not necessarily reliable and correct and should only be used as a last resort when an import library is not available and cannot be compiled from source. That said, it usually does just work, especially if the DLL was translated with the same compiler supporting magic imports. I'm unsure whether the library detection code in the canvas-draw.setup file should be changed. Perhaps the behaviour of find-library should even be adapted in general, depending on the host compiler's capabilities. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Updating the zmq egg
On 2015-03-06 02:00, Matt Gushee wrote:
> [...]
> Another issue with message length is whether there should be a default
> value. There is a Scheme function that generates a buffer for both
> sending and receiving functions.
> [...]
Hello,
for sending, I wouldn't allocate a separate buffer but just pass a
pointer to the contents of a string or blob and the length of the
container to the C function.
For receiving, however, there is no way to know how large the buffer
must be without also knowing the application level protocol. Since
CHICKEN is a high level language, I would try to avoid choosing an
arbitrary buffer size or even forcing the programmer to specify some
specific buffer size, since this could lead to memory overflow errors.
I would recommend to use the zmq_msg_init and zmq_msg_recv functions to
receive a message of arbitrary length and leave the allocation problems
to 0MQ, then you can extract the actual data and its length from the
message object using zmq_msg_data and zmq_msg_size. This approach is
somewhat less efficient than receiving into a prepared buffer, but it is
much easier to implement correctly.
For efficiency, you could provide an alternative API where the
programmer passes in a buffer and optional length that would receive the
message, but that API should definitely perform bounds checking.
Everything could be wrapped into a binding like this (beware, this code
snippet is completely untested):
(define (zmq-recv sock #!optional buf ofs len)
(if buf
(let* ((ofs (or ofs 0))
(len
(cond
((string? buf)
(let ((len (or len (- (string-length buf) ofs
(assert (and (<= 0 ofs)
(< (+ ofs len) (string-length buf
len))
((blob? buf)
(let ((len (or len (- (blob-size buf) ofs
(assert (and (<= 0 ofs)
(< (+ ofs len) (blob-size buf
len))
(else
(error 'zmq-recv "unknown buffer type")
(if (negative?
((foreign-lambda* int ((c-pointer sock)
(scheme-pointer buf)
(size_t ofs) (size_t len)
(int flags))
"C_return(zmq_recv("
" sock, ((char *)buf) + (ptrdiff_t)ofs, len"
"));")
sock buf ofs len 0))
(error 'zmq-recv "receive failed")
buf))
(let ((msg
(make-blob (foreign-value "sizeof(zmq_msg_t)" size_t
(if (negative?
((foreign-lambda int "zmq_msg_init" scheme-pointer) msg))
(error 'zmq-recv "failed to initialize message")
(set-finalizer!
msg (foreign-lambda int "zmq_msg_close" scheme-pointer)))
(if (negative?
((foreign-lambda int "zmq_msg_recv"
scheme-pointer scheme-pointer int)
msg socket 0))
(error 'zmq-recv "receive failed")
(let* ((len
((foreign-lambda size_t "zmq_msg_size"
scheme-object)
msg))
(buf (make-blob len)))
(move-memory!
((foreign-lambda c-pointer "zmq_msg_data" scheme-object)
msg)
buf len)
buf)
I hope this helps :-)
Ciao,
Thomas
--
When C++ is your hammer, every problem looks like your thumb.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] malloc'd memory
On 2015-01-25 23:21, Alexej Magura wrote: > If I have a function that returns a malloc'd pointer, or that needs to > have a buffer malloc'd, is it more idiomatic to (1) malloc and free in > the caller function (which is C's idiom, IIRC), or (2) malloc it in C > and then just return the pointer for free'ing by Chicken once the caller > function is done with the pointer? > [...] Hello, the best integration with CHICKEN's memory management would be achieved by allocating through CHICKEN's library, for example as blobs, passing the pointer to some foreign initialization function and relying on garbage collection to free the memory. However, the C library should then not rely on fixed memory positions of those objects. A common idiom for C libraries is to provide both allocation and deallocation functions. To integrate this with CHICKEN's automatic memory management, it would be necessary to attach finalizers calling the deallocators to pointers returned from the allocators. However, this can cause resource problems if the allocated objects are very large, while the CHICKEN garbage collector only sees the small pointers. Additional caveats apply if the allocated objects need to be globally reachable both from CHICKEN code and foreign code. Providing allocators but no deallocators from a C library and requiring the caller to use the standard free function to dispose resources is a bad idea, because this can cause linkage problems in some situations. For example, depending on the chosen runtime library and linkage model, dynamic libraries under Windows may have a separate heap and a separate copy of the malloc and free functions distinct from that of the calling executable; in that case, passing a pointer malloced in the library to free in the calling executable will cause invalid memory accesses. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] SRFI-99 - What is a variant type?
On Mon, 15 Dec 2014, Bahman Movaqar wrote: Reading the docs on SRFI-99 [1], I need some help understanding what is a "variant type". Would someone please pass me a relevant link to read? Hello, a variant type is the same as an extensible tagged union type. Some documentation about this functionality of the SRFI-99 egg can be found at http://www.chust.org/fossils/srfi-99/wiki?name=variant+types. You can define an abstract base type and a set of derived type cases using a shorthand syntax with the egg. I remember faintly that I used the same nomenclature as some library from the Racket programming language ecosystem, but I can't seem to find it any longer. Many functional computer languages allow the definition of variant types and support the deconstruction of values of those types using pattern matching. The variant type functionality in the SRFI-99 egg allows just that for Scheme as well. However, the variant types defined using the egg are open in the sense that new type cases can be added to them independently of the original definition. Whether that is a good or a bad thing depends on the situation but it seems to fit in more nicely with the dynamic nature of Scheme and with the way SRFI-99 works. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Difference in behaviour with code compiled with csc and code run with csi.
On Sat, 6 Dec 2014, Joe Python wrote: I was experimenting with a coroutine example which i got from the c2 website. see link below for code. http://paste.call-cc.org/paste?id=cf4489b9de4820b330dc34371ea3b73a18115a4b#a0 I get the expected output when I run the code using csi [...] However when i run the executable which i compiled with csc, i get [...] unexpected output. [...] Hello Joe, this seems to have something to do with the fact that the toplevel behaves slightly differently in compiled and interpreted code. While the toplevel expressions of each compilation unit essentially form a single procedure body, the toplevel expressions fed to the interpreter are processed independently. This can make a difference when capturing the continuation of a toplevel expression. Furthermore, the control flow in your code is probably not what you expect it and want it to be: Your coroutine constructor arranges for the continuation of the *first* coroutine invocation to be captured and used for returns of *every* yield statement. You can easily verify the combined effect of these phenomena by inserting some print statements around the coroutine invocations at the end of your program. In the interpreted case, the captured continuation incidentally returns control to the surrounding read eval loop, however in the compiled case the captured continuation returns you to the place in the program between the first an second explicit coroutine invocation, effectively constructing an endless loop around the second invocation. A quick fix for the problem would be to actually use the new return continuations returned by the yield expressions upon re-entry into the coroutine: Simply replace every call of (yield WHATEVER) in your coroutine body by (set! yield (yield WHATEVER)) and the program will behave identically (and correctly, I might add) in compiled and interpreted mode. If you find that solution inelegant, you might want to encapsulate this behaviour of yield into a macro or use parameters to implement a global yield procedure instead. I hope this helps :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Q] How can I convert this lisp(SBCL) macro to chicken scheme?
On Fri, 7 Nov 2014, Moritz Heidkamp wrote: NeXT writes: Thank you, what I miss from clojure is its uniform or homoiconic(?) style of sequence accessing; so one does not have to check current sequence is whether list or vector or others. I'd like to create macro or something for this. :-) This is called a generic interface, it has nothing to do with homoiconicity. For CHICKEN, the sequences egg[1] offers something like this. [...] Hello, the SRFI-42 eager comprehensions also go in that direction and are also available as an egg for chicken. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Linking object files without additional source
On Sat, 1 Nov 2014, Richard wrote: [...] That is not how you link objects files. You could create an archive for this purpose using: ar rc foreign-interfaces.a sources/foreign-interfaces/fastcgi.o sources/foreign-interfaces/sqlite.o [...] Hello, if your linker supports that, it may also be possible to recombine multiple objects into a single relocatable output. With GNU ld you could do ld --relocatable \ sources/foreign-interfaces/fastcgi.o \ sources/foreign-interfaces/sqlite.o \ -o foreign-interfaces.o However, the CHICKEN compiler driver only directly supports linking things together into dynamic libraries or executables. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Tue, 28 Oct 2014, Florian Zumbiehl wrote:
[...]
I am not sure I understand what you mean--you never can protect against a
client that doesn't want to protect the session, they always could just
publish the session key, or the decrypted data, or whatever. The protection
should always focus on third parties that try to undermine the security.
[...]
Hello,
that's right, but you can also try to protect against a client that tries
to obtain information from the server side to which it isn't entitled.
However, selecting different cipher will help less there than selecting
better versions of the protocol.
[...]
I don't see any serious security problems with the default. If the
configuration of the peer isn't braindead, that will negotiate a reasonably
secure cipher suite, the default connected to itself will negotiate
ECDHE-RSA-AES256-GCM-SHA384 (if the necessary server-side initialization
for ECDHE cipher suites has been done),
[...]
Implementing the necessary server-side setup for the "normal" and
elliptic-curve-based Diffie-Hellman schemes is high up on my priority list
for the OpenSSL egg, too.
[...]
plus you could argue that RC4 is
actually still more secure than CBC modes with TLS < 1.1 due to BEAST,
unless both sides implement 1/n-1 splitting or the application protocol can
not be used to perform the attack.
[...]
Hmm, RC4 in its original form has a pretty large bias. Do you know if the
SSL variant throws away the head of the random stream, which would reduce
the predictability of the PRNG?
Anyway, CTR-based encryption modes with authentication like GCM, CCM, EAX
and the like are probably fine if the underlying block cipher is strong.
[...]
I don't think anyone groks the OpenSSL API ;-), but as far as I could tell,
roughly this should do the right thing (well, it's obviously taken from a
server, but the principle should be applicable in the general case):
[...]
Huh, interesting. The documentation of OpenSSL that I have installed
doesn't mention those TLSv1_{1,2}_{server,client}_method functions
anywhere, but they are declared in the header files. I must have
overlooked them. Apparently, closely studying the headers files and trying
to divine the meaning of the functions without documentation is still the
way to go if you want to perform any useful operation with OpenSSL %-]
Somehow I'm tempted to start from scratch with a binding to GnuTLS or
another library that has decent documentation ;-)
Ciao,
Thomas
--
When C++ is your hammer, every problem looks like your thumb.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Tue, 28 Oct 2014, Florian Zumbiehl wrote: [...] Regarding specific improvements: [procedure] (ssl-make-client-context* #!key ((protocol ) 'tls) ((cipher-list ) "HIGH") ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Creates a new client context. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified and switches server certificate verification on by default. I'm not convinced HIGH is actually a sensible default selection (it includes ADH cipher suites, for example), or that cipher limitation is even all that important security-wise: If the handshake is not compromised, the parties should not ever select anything braindead unless one side explicitly prefers that and/or doesn't support anything better. [...] Hello, well, if I understand some of the problems with SSL/TLS in the past years correctly, the fact that a specifically engineered client could force a brain-dead cipher suite selection actually posed a problem several times. But you are certainly right about the non-authenticated schemes, maybe setting the default to "HIGH:!aNULL" makes more sense? [...] Selecting ciphers for specific security properties can be sensible, but it's difficult to find a generally applicable default that's both highly secure and widely compatible. [...] I think the idea here is to set some defaults that are reasonably secure, even if that means less compatible. If you want to transmit top-secret data you will need something entirely different from SSL/TLS, anyway; and if you don't care about security you can use the old API ;-) [...] As for protocol version selection, it would be a good idea to be able to select multiple protocol versions for compatibility with various servers that might not all be able to speak the same version, I guess TLS1.0 and greater is a reasonable default for the time being. Also, I guess it would be good to be able to explicitly select "or higher" so code specifying that will automatically support newer TLS versions as they become available. [...] I agree, however the only easy to use presets in the OpenSSL library are SSLv2, SSLv3, TLS or any of them selected automatically. The latter has been the default so far, but that means the vulnerable SSLv3 can be selected, too. Judging by the documentation I'm not even sure whether TLS means TLS 1.0 or TLS in any supported version. It would be great if someone who really groks the OpenSSL API could help out here! [...] As for certificates, it would be totally great if one could also specify the certificate itself directly, without the need to put it into a file, just in case you feel like implementing that ... ;-) [...] Hmm, I remember that was somehow difficult back when I first implemented the old API. I don't recall the reason and I'll just look into it again. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Mon, 27 Oct 2014, Andy Bennett wrote: [...] I'd be glad if some of you could test this out and tell me what you think about it :-) Can you give some tips for how to test this from a spiffy applications? I usually just pass in ssl-accept instead of tcp-accept. [...] Hello, actually I have very little experience with spiffy, but if it can use ssl-accept, it must use ssl-listen somewhere and that's the point that would need to be adapted. Judging by Spiffy's documentation in the Wiki you could do something like this: (define ear (ssl-listen* hostname: "localhost" port: 44344 certificate: "my-server-cert.pem" private-key: "my-server-key.pem")) (accept-loop ear ssl-accept) Beware, this snippet of code is completely untested! Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Thomas Chust wrote: [...] So I would like to poll for opinions from people on this list concerning this situation. Do you think the default options in the OpenSSL egg should be "hardened"? Do you think more options should be introduced? Is compatibility with the rest of the internet a concern at all? ;-) [...] Hello, judging by the responses you wrote, there seems to be an interest in more secure defaults indeed. I looked over the OpenSSL egg API again to see how it could be improved with better default options and figured that some additional constructor parameters would be useful but there were already too many optional parameters in my opinion. Therefore I took another route: The existing procedures keep their current defaults, but there is a new set of object constructors that uses only keyword arguments and configures things in a more secure way by default. The latest SVN trunk of the OpenSSL egg includes the following additions: [parameter] ssl-default-certificate-authority-directory Holds the default directory with acceptable certificate authorities. [procedure] (ssl-make-client-context* #!key ((protocol ) 'tls) ((cipher-list ) "HIGH") ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Creates a new client context. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified and switches server certificate verification on by default. [procedure] (ssl-connect* #!key (hostname ) (port ) ((protocol ) 'tls) ((cipher-list ) "HIGH") ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Connects to a server using the same defaults as ssl-make-client-context* [procedure] (ssl-listen* #!key (hostname ) ((port ) #f) ((backlog ) 4) ((protocol ) 'tls) ((cipher-list ) "HIGH") (certificate ) (private-key ) ((private-key-rsa? ) #t) ((private-key-asn1? ) #f)) ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Creates a listener. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified but doesn't switch client certificate verification on by default. Advertises the certificates loaded via the certificate-authorities argument to the client. I'd be glad if some of you could test this out and tell me what you think about it :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] file-separator, path-separator
On Sun, 26 Oct 2014, Sascha Ziemann wrote: [...] what is the Chicken equivalent of Java's File.separator [...] and File.pathSeparator: [...] Hello Sascha, as far as I know, the CHICKEN core library doesn't provide equivalent definitions and the code you included in your mail to define those variables looks fine to me. However, there is an egg for file path manipulations which defines the parameters you are looking for as well as several procedures for the analysis and synthesis of path strings: http://wiki.call-cc.org/eggref/4/filepath Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Florian Zumbiehl wrote: [...] I just wanted to point out that we still have a bunch of patches lying around that among other things implement security improvements: openssl: add support for TLS 1.1 and 1.2 openssl: add functions ssl-set-reneg-legacy-server-connect!, ssl-set-no-compression!, and ssl-set-cipher-list! openssl: add support for fetching the first finished message of the connection openssl: add ssl-connect-fd [...] Hello Florian, thanks for the heads up, I had totally forgotten about these patches. Can they be found somewhere online? I'd like to take a look again, perhaps they aren't that hard to incorporate. Incidentally I just added a ssl-set-cipher-list! to the trunk of the egg as well, since I thought this would really be useful to strengthen security. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Sascha Ziemann wrote: [...] I think it is a good idea to make TLS the default. [...] I think it is sufficient to enable SSL with a parameter or environment variable. I propose: I_DONT_CARE_ABOUT_SECURITY=yes [...] ... and there I was thinking that was implicit in the use of SSL/TLS in the first place ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Andy Bennett wrote: [...] Having said that, I'm not sure which clients on which operating systems are SSL 3.0 only. [...] Hello Andy, if I understand the situation correctly, almost nobody uses SSLv3 since it was quickly superseded by the newer TLS variants. But the initial connection setup is similar between SSLv2 and SSLv3, while for TLS it is entirely different and usually one uses the SSLv2 variant with additional information that TLS is supported, if the other endpoint also supports TLS, the protocol will then be upgraded. You can tell OpenSSL to support only SSLv2, only SSLv3, only TLS or all three variants together. But you cannot specifically exclude SSLv3 and still allow SSLv2 and TLS. [...] Have you seen this article by Google about TLS_FALLBACK_SCSV? [...] Yes. Whether that security measure is supported depends on the version of the underlying SSL library, I think it is incorporated in OpenSSL 1.0.1j. I'm unsure whether anything special needs to be done to activate the feature. Personally, I think the big mess of SSL/TLS protocol versions, extension features and cipher suites is so hideously complex by now that there will always be some more hidden vulnerabilities %-] For anything truly security critical I would try to use an alternative protocol with a less convoluted design and with stronger default crypto algorithms. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] OpenSSL egg option defaults poll
Hello, Mario Domenech Goulart raised the issue that the OpenSSL egg by default creates connections that can use any of the SSLv2, SSLv3 or TLSv1.x protocols, depending on the capabilities of the remote peer. This default is not particularly secure, especially when considering the recently published exploits for the obsolete SSLv3 protocol. Changing the default behaviour of the OpenSSL egg to TLS protocol only would prevent any real or potential issues with the legacy protocols. However, many SSL implementations apparently use SSLv2 handshakes with extensions for the sake of compatibility and with the changed default the OpenSSL egg would probably reject many valid connection attempts as a server and not be able to connect to some old servers as a client. Other standard settings for the OpenSSL egg also err on the side of compatibility rather than security. For example, certificate verification is not enabled by default and the set of acceptable stream ciphers cannot even be modified, which is probably a bad idea for any serious security critical application. So I would like to poll for opinions from people on this list concerning this situation. Do you think the default options in the OpenSSL egg should be "hardened"? Do you think more options should be introduced? Is compatibility with the rest of the internet a concern at all? ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a C-API to a chicken library
On Fri, 2014-05-09 at 16:56 +0200, Isak Andersson wrote: > [...] > Basically I want to define a C API (because that's easy to call from > all languages) that will be used on many platforms > (ios, android, winrt, windows, osx etc). > [...] Hello Isak, what you want to do should indeed be possible to achieve using define-external. However, CHICKEN's runtime system needs to be initialized and the top-level Scheme code needs to be run before you can call back into scheme. > [...] > So what I did was that I created a simple test with the following > source code: > https://gist.github.com/BitPuffin/f8ad6fa6f43327a84611 > [...] Make the following changes: * Replace the call of CHICKEN_initialize in src/init.c by CHICKEN_run(C_toplevel). This will ensure that the runtime system is initialized *and* all top-level Scheme code that may do further initialization work has been executed once. * Add (return-to-host) to the end of src/itest.scm. This will ensure that the call to CHICKEN_run actually returns after all initialization work has been completed. Then your code should work as expected :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] lambda's in a hash table
On 2014-04-05 01:54, Claude Marinier wrote: > [...] > I would like to have the compiler do some of this for me. I probably > cannot write a literal hash table but I expected to be able to write a > literal association list. I have tried this but it does not work. > [...] > (define a-list > `( > (dot . ,(lambda () (display "dot\n"))) > (dash . ,(lambda () (display "dash\n"))) > )) > [...] Hello, what you have written down here is not a literal list, but a quasiquotation, which is just syntactic sugar that expands to an expression dynamically constructing a list. Nevertheless, the program you posted works just fine as it is. The only problem I can see with it is that nothing visible happens because > [...] > (let ((func-dot (hash-table-ref dict 'dot)) > (func-dash (hash-table-ref dict 'dash))) > func-dot > func-dash) > [...] doesn't call the two procedures. To actually run the procedures, you would have to write something like (let ((func-dot (hash-table-ref dict 'dot)) (func-dash (hash-table-ref dict 'dash))) (func-dot) (func-dash)) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Question about (use numbers)
On 2014-03-02 17:20, Daniel Carrera wrote: > On 2 March 2014 17:00, Matt Gushee wrote: >>> [...] >>> Does this mean that I am loading the module wrong? >>> [...] >> No. The numbers egg redefines all the standard arithmetic 'operators' >> [...] > Ok. Does this also mean that there is no way to suppress these messages > (without also suppressing a similar message if I accidentally redefine > something I shouldn't)? > [...] Hello, as far as I know there is no good way to suppress some of these messages in the interpreter, but when compiling modular code you can use selective imports, for example adding an (except ...) clause to the scheme and/or chicken modules for those standard bindings you are later going to redefine. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] assigning scheme object to foreign pointer
On 2013-12-16 00:59, pluijzer wrote: > [...] > I am using a C-library that lets you assign user data to objects via a void > pointer. > I would like to assign a scheme object to this pointer, but as I understand I > cannot use > 'object->pointer' for this, as the garbage collector might move the object. > [...] Hello, check out CHICKEN_new_gc_root and friends [1]. These functions can be used to manage mutable cells that can hold references to Scheme objects and are taken into account by the garbage collector. Ciao, Thomas -- [1] http://wiki.call-cc.org/man/4/Embedding#chicken_new_gc_root -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] assigning scheme object to foreign pointer
On 2013-12-16 00:59, pluijzer wrote: > [...] > I am using a C-library that lets you assign user data to objects via a void > pointer. > I would like to assign a scheme object to this pointer, but as I understand I > cannot use > 'object->pointer' for this, as the garbage collector might move the object. > [...] Hello, check out CHICKEN_new_gc_root and friends [1]. These functions can be used to manage mutable cells that can hold references to Scheme objects and are taken into account by the garbage collector. Ciao, Thomas -- [1] http://wiki.call-cc.org/man/4/Embedding#chicken_new_gc_root -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 12:34, Felix wrote: > From: Thomas Chust >> [...] >> So what about allocating locally and not returning an object but passing >> it to a Scheme callback from inside a foreign-safe-lambda? Is that ok or >> can it happen that the callback stores this object away but never copies >> it into the second generation heap? > > That can indeed happen. > [...] Hello, interesting! In that case the documentation for foreign-safe-lambda should really be changed, I think. But I wonder how that could happen. C_callback basically has to run a minor garbage collection to unwind the stack before returning to the context enclosing the callback. Hence the only way I can imagine a value escaping the garbage collection is if the context enclosing the callback does a C_alloc but forgets to do a C_callback_adjust_stack and passes some stack allocated object into the callback. Then the garbage collector might think that this object lives in permanent storage and ignore it. Is this reasoning correct? Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 12:19, Felix wrote: > From: Thomas Chust >> [...] >> when I first saw that code I thought that this must be incorrect, too. >> Then I checked the CHICKEN documentation for foreign-safe-lambda and read: >> >> "This is similar to foreign-lambda, but also allows the called >>function to call Scheme functions and allocate Scheme data-objects." >> > > The part about allocation is wrong, I'd say. > [...] Hello, thank you for the clarification :-) So what about allocating locally and not returning an object but passing it to a Scheme callback from inside a foreign-safe-lambda? Is that ok or can it happen that the callback stores this object away but never copies it into the second generation heap? Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 12:13, Kristian Lein-Mathisen wrote: > [...] > I didn't know foreign-lambda were the one that had to do > the CPS-conversion. Does that mean there is a small performance overhead > when using foreign-lambda as opposed to just foreign-primitive? > [...] Hello, the overhead is roughly one return instruction and one unconditional branch instruction. I would assume that is negligible on a modern CPU. At least, if you're worried about overhead in that order of magnitude, you should probably write your code in hand-optimized assembler with the CPU tuning manual on your lap, painstakingly tracking the state of your processor's pipeline through your code and arranging the instructions to never waste an idle cycle in any of the CPU subsystems, rather than relying on one of those pesky compilers that do the wrong thing all the time ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-06 11:46, Kristian Lein-Mathisen wrote: > [...] > From what I understand, this is exactly what foreign-primitive does: > wraps C_return in a CPS, keeping the stack-allocation alive. > [...] Hello, well, kind of. Since compiled CHICKEN code is fully CPS transformed you don't wrap something in a CPS context, you wrap anything that isn't natively in CPS with a function that calls it and passes the result to the values continuation. foreign-lambda and friends create such wrappers, foreign-primitive doesn't create a wrapper, it just expects the code to be in CPS style, which means that the code may never return at all. C_return is, in that case, just syntactic sugar for invoking the values continuation. Since the code in a foreign-primitive never returns, things allocated in the nursery (ie. on the stack) live on "forever", or rather until the next minor garbage collection comes around, transfers anything that's still referenced into the second generation heap and throws away the nursery (ie. almost the entire stack). Therefore foreign-primitive can do allocation in the nursery, but foreign-lambda can't. However, foreign-lambda could still allocate directly in the second generation heap or transfer nursery-allocated values directly into the heap upon return before the stack context is destroyed. The question is whether such magic is present for foreign-safe-lambda, as the documentation may indicate, or whether that is not the case, as Felix has indicated with his earlier message :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-05 23:36, Felix wrote: > From: Dan Leslie >> [...] >> Basically, use C_alloc to allocate the memory required to host both >> the List structure and the data it is to contain, then use the C_list >> macro to patch it all together. > > Note that this code is not correct: C_alloc allocates on the C stack and the > data will be invalid once the function returns (Sorry). If this works, then > it is just coincidental! > [...] Hello, when I first saw that code I thought that this must be incorrect, too. Then I checked the CHICKEN documentation for foreign-safe-lambda and read: "This is similar to foreign-lambda, but also allows the called function to call Scheme functions and allocate Scheme data-objects." Now I'm confused. Of course C_alloc allocates on the stack and of course this can likely break if a function just returns some pointer to stack allocated data. However C_return could magically copy the return value to the second generation heap or similar trickery to actually make foreign-safe-lambda and C_alloc interoperate correctly or one could perhaps use a special call ABI to prevent stack corruption upon return from a foreign-safe-lambda and salvage stack allocated objects. Is any such strategy actually implemented? But maybe the documentation is just misleading and wanted to say something about temporary allocation for the lifetime of the function instead. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-05 20:11, Peter Bex wrote: > On Wed, Jun 05, 2013 at 07:57:49PM +0200, Thomas Chust wrote: >> >> but it's trivial to detect cyclic lists during the traversal using >> either a set of seen elements or just two iteration pointers travelling >> at different speeds. > > In C that's rather painful. Note that the OP was asking specifically > for a C_listp macro. > [...] Hello, well, I think that two iteration pointers are trivial even in C, but that may be a matter of taste :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken C interface
On 2013-06-05 19:50, Peter Bex wrote: > [...] > There is no C_listp predicate because you can't directly check an > object for being a list; you must check whether it's > C_SCHEME_END_OF_LIST (then it is a list). Otherwise, if it's a pair > you take its cdr and loop. If it's something else, it's not a list. > > Because this is a potentially heavy operation (and cyclic lists may > even cause an endless loop), I guess it's been decided not to provide > a predicate procedure for this, > [...] Hello, but it's trivial to detect cyclic lists during the traversal using either a set of seen elements or just two iteration pointers travelling at different speeds. The only problematic structures are truly infinite lists without periodicity, but those are impossible with eager data structures like the standard Scheme lists. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Protocol Buffers for CHICKEN
On 2013-05-30 22:32, Felix wrote: > [...] > Very good - thanks a lot! I'll give this a try. Should we simply replace > the serialization or do you think it would make sense to let the user > choose a serialization mechanism for suspensions? > [...] Hello Felix, I'm not sure the suspension egg needs a dependency on a serializer at all. It would still serve its purpose if continuation-suspend and continuation-resume passed around the native continuation objects and let the client do the serialization. And configurability is almost always a good thing :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Protocol Buffers for CHICKEN
On 2013-05-29 14:36, Felix wrote: >> [...] >> Continuations should work, too, but it is non-trivial to construct a >> continuation that doesn't close over all sorts of crazy stuff like the >> input ports from which the interpreter reads library files etc. Fiddling >> around with green threads to delimit the continuations and using the >> facilities to inject "external dependencies" into the serialization >> context of protobuf should do the job, though. > > Well, ports for example will never be fully serializable (with the > exception of "standard" ports). Have you seen "suspensions"? > > https://wiki.call-cc.org/eggref/4/suspension > > They currently use "s11n" but "protobuf" would be the better > mechanism. > [...] Hello Felix, yes, I'm aware of suspension and the magic going on inside that egg is precisely what I referred to by "fiddling around with green threads". In fact, protobuf can easily act as a drop-in replacement for s11n and I just verified that it does work just fine with suspensions! So I can say with more confidence now that continuation serialization through protobuf is functional. Apply the attached patch to the the suspension egg, install it and see for yourself :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. === modified file 'suspension.meta' --- suspension.meta 2011-03-25 14:05:18 + +++ suspension.meta 2013-05-29 13:58:20 + @@ -2,7 +2,7 @@ ( (synopsis "Serialized limited continuations") - (needs s11n) + (needs protobuf) (category lang-exts) (license "BSD") (author "felix") === modified file 'suspension.scm' --- suspension.scm 2010-08-16 14:49:14 + +++ suspension.scm 2013-05-29 13:59:01 + @@ -1,13 +1,13 @@ suspension.scm +(require-library srfi-18 protobuf) (module suspension (with-limited-continuation continuation-drop continuation-suspend continuation-resume) - (import scheme chicken ports) - -(use srfi-18 s11n) + (import scheme chicken ports srfi-18 + (only protobuf-generic serialize deserialize)) (declare (disable-interrupts)) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Protocol Buffers for CHICKEN
On 2013-05-29 13:11, Felix wrote: > From: Thomas Chust >> [...] >> during the CHICKEN spring thing in Cologne I started to work on a new >> egg [1] implementing the protocol buffer [2] serialization format, which >> is now in a usable and tested state. >> >> If you don't need or want to use a specific schema for your data, you >> can use the protobuf egg as a generic serialization solution that >> produces platform-independent binary representations of (almost) any >> CHICKEN values: > > Whoa! Incredible! Finally a decent serialization library. Is > closure/continuation-serialization reliable? I did some simple stupid > tests and at least serializing a continuation in csi produced an error > due to a not-serializable port (which is understandable). > [...] Hello Felix, closure serialization definitely works, I have tried round tripping compiled and interpreted procedures with and without surrounding context through serialize and deserialize and they are still functional after reading them back in. Continuations should work, too, but it is non-trivial to construct a continuation that doesn't close over all sorts of crazy stuff like the input ports from which the interpreter reads library files etc. Fiddling around with green threads to delimit the continuations and using the facilities to inject "external dependencies" into the serialization context of protobuf should do the job, though. Cheers, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Protocol Buffers for CHICKEN
On 2013-05-29 00:32, Dan Leslie wrote: > [...] > I wonder if this would be useful for storing data in a posix shared > memory block... > [...] Hello Dan, that is certainly possible, you would just combine serialize and call-with-output-string to obtain data you can copy into a shared buffer and call-with-input-string plus deserialize to extract the stored value on the receiving side. However, shared memory between processes or threads on the same machine has the advantage that one can place data in native formats in there without having to care about endianness issues etc. So perhaps object-evict and friends would be more efficient in this case. The protobuf serialization could be quite useful for distributed computing applications. Combining serialization of thunks with network transport and some cryptographic authentication scheme yields you could quickly construct a secure remote compute job submission server or a distributed map reduce network, for example. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Protocol Buffers for CHICKEN
Hello, during the CHICKEN spring thing in Cologne I started to work on a new egg [1] implementing the protocol buffer [2] serialization format, which is now in a usable and tested state. If you don't need or want to use a specific schema for your data, you can use the protobuf egg as a generic serialization solution that produces platform-independent binary representations of (almost) any CHICKEN values: $ cat source.scm (require-library protobuf) (import protobuf-generic) (serialize (lambda (x) (print (* 2 x $ csi -s source.scm >lambda.pbf $ cat sink.scm (require-library protobuf) (import protobuf-generic) ((deserialize) 42) $ csi -s sink.scm protoc --proto_path=. person.proto --decode=person.Person id: 42 name: "Jane Doe" Deserialization is just as simple with a call to (deserialize person). The protobuf messages are represented as SRFI-99 records in CHICKEN that can be manipulated as usual. Enumeration values are represented as symbols. If you're interested, check the egg documentation for advanced features and give the library a try :-) Ciao, Thomas -- [1] https://wiki.call-cc.org/eggref/4/protobuf [2] http://protobuf.googlecode.com/ -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Best way to share memory between C and Chicken
On 2013-05-05 13:54, Felix wrote: > [...] > SRFI-4 vectors live in the normal, heap that is subject to garbage > collection, > [...] > But note that the SRFI-4 constructors accept an optional argument > which specifies that the vector should be allocated in static, > non-GC'd memory. > [...] Ah, cool. That's probably the perfect solution for large numeric arrays! Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Best way to share memory between C and Chicken
On 2013-05-04 00:26, Ivan Raikov wrote: > [...] > I really strongly advise _against_ using SRFI-4 vectors for 4G files, > as I have experienced serious performance issues even with vectors of a > few million elements. > [...] Hello, would that be related to the fact that CHICKEN has a copying garbage collector or are there other hidden performance implications of SRFI-4 vectors? Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Best way to share memory between C and Chicken
On 2013-05-03 20:04, Pedro Melendez wrote: > [...] > I am developing a prototype of a server that would serve 3D seismic > images across the network. > [...] Hello Pedro, it's nice to see I'm not the only geophysicist who likes to use Scheme :-) > [...] > Giving the size of the file, I want to share the memory space between C > and Chicken and avoid copying values between areas. Is that even > possible? > [...] Both CHICKEN's blobs and SRFI-4 homogeneous vectors can be converted to native pointers to their data contents through the FFI. As a silly example, this will allocate a big array of floating point numbers, set one of the array elements using native code and read it bacl from Scheme: (use srfi-4) (define big-array (make-f64vector (expt 2 20))) (define set-some-element! (foreign-lambda* void ((nonnull-f64vector v)) "v[1024] = 42.23;")) (set-some-element! big-array) (display (f64vector-ref big-array 1024)) (newline) If your data is not a homogeneous numeric array, you could use blobs instead. If you absolutely have to allocate unmanaged memory on the C side an pass pointers there back to Scheme rather than creating managed Scheme objects and passing pointers to their contents to the C code, take a look at CHICKEN's lolevel unit. CHICKEN Scheme can also deal with raw native pointers to a certain degree! Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken as extension language
On Wed, 29 Aug 2012, Pippo Sbardella wrote: [...] Btw, it took me some time to find your links starting from: http://wiki.call-cc.org/man/4/The%20User%27s%20Manual I think that a comprehensive "toc page" would help. [...] Hello Pippo, the wiki containing CHICKEN's manual has a full text search: http://wiki.call-cc.org/search-help And there is chickadee, another browser for the documentation of CHICKEN and all eggs: http://api.call-cc.org/doc/ Of course neither of those can replace a nice index page in a printed manual, but for an online resource a good search function is even better :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. smime.p7s Description: S/MIME Cryptographic Signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken as extension language
Hello, you may want to check the documentation on embedding CHICKEN into other applications: http://wiki.call-cc.org/man/4/Embedding To make the embedded CHICKEN interpreter useful, you may have to expose functions from CHICKEN to the hosting application, which is easily accomplished using define-external: http://wiki.call-cc.org/man/4/Callbacks#define-external And the other way around, you may have to expose functions from the hosting application to CHICKEN, which is equally possible using the various foreign-* forms: http://wiki.call-cc.org/man/4/Accessing%20external%20objects If these pieces of documentation leave you with any open questions, don't hesitate to ask for specific advice on this list :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. smime.p7s Description: S/MIME Cryptographic Signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] scheme student perplexed by failures ...
On Sat, 11 Aug 2012, john saylor wrote: [...] and here is my propsed solution: define js-reverse (lambda (ls) ((reverse-rec ls '() [...] Hello John, your code above lacks an opening paranthesis before the define and it has an extraneous pair of parentheses around the call to reverse-rec. [...] (define js-reverse-rec (lambda (asc dsc) ((if (null? asc) dsc ;(js-reverse-rec (cdr asc) (list dsc (car asc))) (js-reverse-rec (cdr asc) (cons (car asc) dsc)) [...] Again, there is an extraneous pair of parentheses around the use of the if syntax. In Scheme, parentheses are relevant syntax that indicate uses of syntax or calls to procedures. The expression ((reverse-rec ls '())) means "Call reverse-rec with the arguments ls and '(), then call the result with no arguments." Since the results of reverse-rec and of the conditional in js-reverse-rec are not procedures but lists, these extra calls you programmed cause the type errors you see. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. smime.p7s Description: S/MIME Cryptographic Signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Printing procedures returned from call/cc
On Tue, 31 Jul 2012, Jeronimo Pellegrini wrote: [...] I was wondering why this happens in Chicken (recent checkout from git): (let ((lst (call/cc (lambda (x) (print 'something) (call/cc (lambda (y) (list x y))) (print lst) (print (eq? (car lst) (cadr lst))) (print (eqv? (car lst) (cadr lst))) ==> (# #) #f #f The procedures returned are different continuations (and of course they are certainly not eq? or eqv?). [...] Hello, this is really strange! Since the second lambda expression is in tail position with respect to the first, the two continuations x and y are actually equivalent, so at first I was less surprised by their printed representation than by the results of the equality predicates. But then I tried to wrap some other function call around the inner invocation of call-with-current-continuation -- and the two continuation procedures still had the same printed representation. I guess one just cannot rely on intuition in this case ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. smime.p7s Description: S/MIME Cryptographic Signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] IUP
Andy Bennett wrote: > [...] > ...there doesn't seem to be a libwebkit for Debian Wheezy: only a gtk > version so I tried to disable all the web stuff in the iup.setup file. > [...] Hello Andy, the GTK+ WebKit library is probably the right one unless you built IUP against Motif instead of GTK+. But you can also simply disable the WebKit binding by passing -feature disable-iup-web to chicken-install. > [...] > Having done that and got a completed build I tried again: > > - > #;1> (use iup) > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/iup.import.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/iup-base.import.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/lolevel.import.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/srfi-42.import.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/irregex.import.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/iup-controls.import.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/iup-dialogs.import.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/iup.so ... > ; loading /usr/local/chicken-4.7.0/lib/chicken/6/srfi-42.so ... > Segmentation fault > - > [...] Hmm, that probably means that initialization code of the IUP binding or the IUP library itself is crashing since the SEGV apparently occurs at some point after the SRFI-42 support library is loaded which is triggered by a require-library call at the head of iup.scm. However, without some information about the exact location of the crash and your environment it's hard to say anything more than that :-( You might try to disable more of the optional IUP modules using -feature switches during the build and see whether that prevents triggering the bug. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Can't install Spock
Дмитрий wrote: > [...] > ""\usr\local\bin\csc"" -feature compiling-extension -setup-mode-S -O3 > -d0 -feature standalone chicken-spock.scm -o chicken-spock > "chicken-spock" -library-path spock -optimize -library -o library.js > cat config.js runtime.js library.js > spock/spock-runtime.js > ""\usr\local\bin\csc"" -feature compiling-extension -setup-mode-S -O3 > -d0 -feature standalone chicken-spock.scm -o chicken-spock > [...] Hello, this output indicates that the Spock compiler is actually built and runs without crashing but the build system still tries to recompile the executable after it has already been built and eventually gives up. My guess is that this has something to do with Windows file naming conventions: Probably the generated executable is named "chicken-spock.exe" but the build system expects to find a target called "chicken-spock" without any extension, which simply doesn't appear no matter how often the executable is recompiled ;-) This can likely be worked around manually without too much trouble. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problems with rationals
On Mon, 2012-04-09 at 21:00 +0100, Mark Carter wrote: > Is this a bug in chicken? > (rational? 6/10) => #f > > Also > (* 1.0 5/2) > produces > Error: (*) bad argument type: 5/2 > [...] Hello, this looks strange. While CHICKEN does not support exact fractions out of the box, reading a number in fractional notation should simply issue a warning and return a floating point number. Also, when I apply the rational? predicate from CHICKEN's core library to a floating point number I get the answer #t: $ csi -n CHICKEN (c)2008-2011 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.7.4 (rev ad149e7) linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] compiled 2012-02-07 on hd-t1179cl (Linux) #;1> (rational? 5/2) Warning: cannot represent exact fraction - coerced to flonum: "5/2" #t #;2> (* 1.0 5/2) Warning: cannot represent exact fraction - coerced to flonum: "5/2" 2.5 One way I can reproduce your problems is by loading but not importing the numbers extension library, which adds support for arbitrary precision arithmetic and exact fractions to CHICKEN: $ csi -n [...] #;1> (require-library numbers) ; loading /usr/lib/chicken/6/numbers.so ... #;2> (rational? 5/2) #f #;3> (* 1.0 5/2) Error: (*) bad argument type: 5/2 Call history: (* 1.0 5/2) (* 1.0 5/2) <-- This, however, is a misuse of the numbers library. The problem here is that by loading the library the standard reader of CHICKEN is modified. The fractional number notation then produces objects not understood by CHICKEN's core libraries and to work with them you also have to import the versions of arithmetic operators and numerical predicates that are provided by the numbers library. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-install doesn't install compiled submodules
On Sun, 2012-03-25 at 15:46 +0200, Christian Kellermann wrote:
> [...]
> (define import-libraries
> `("iup.import.so"
> "iup-base.import.scm" "iup-controls.import.scm"
> "iup-dialogs.import.scm"
> ,@(cond-expand
>
>
> So you are explicitly giving it .scm files to install. Or am I
> misreading the code?
> [...]
Oops, you're right! Somehow I managed to overlook the cdr of that
list :-(
I'll fix the script immediately.
Ciao,
Thomas
--
When C++ is your hammer, every problem looks like your thumb.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
