Re: Using block compilation with compilation units
Hello Robert, you are right, you can not directly call procedures from modules/units compiled with -block. A trick I used to "export" procedures was to have two compilation units (I used modules for both). One, the "hook", defining and exporting top level bindings, which is not compiled in block mode and a second "implementer", which imports from hook and used `set!` to assign the bindings. Other modules only import hook. (Gotcha: Be sure to force initialization of the implementer before any other use of those bindings.) I'm curious how much this loop-hopping would benefit you. One nice side effect it has: changing the import list of the implementer module will no longer require a re-compile of modules using the hook. Am Mon, 27 Dec 2021 00:39:37 -0330 schrieb Robert Coffey : > Hello, > > I am trying to figure out how block compilation works, as I would > like to build > my project with -O5 if possible, but I'm having issues getting my > project to build with block compilation. > > It appears calling procedures defined in other compilation units > causes segmentation violations, which aligns with "toplevel bindings > are not seen by > eval and unused toplevel bindings are removed" as stated in the > manual, but this > leaves me unsure about how (or if you can) split a program into > compilation units while using block compilation. > > Do I need to use modules in order to have access to procedures in > other "units", or is there a way to use compilation units? > > Thanks, > Robert Coffey
Re: How to share knowledge about known bugs?
see towards the end of the message, what I men with "block lists": I mean some piece of (shared) machine readable source code listing the limitations, or rather the attribute. Like '(thread-safe yes) maybe even as part of the egg file (the license is already there, which would allow to filter for, say, "GPL compatible" or "GPL free"). It's a lot of work to figure all these things out of either source or documentation. The idea: maybe we can somehow share the results. Best Jörg Am Wed, 01 Dec 2021 21:23:21 +0100 schrieb Mario Domenech Goulart : > Hi Jörg and all, > > On Wed, 1 Dec 2021 10:30:44 +0100 "Jörg F. Wittenberger" > wrote: > > > one in a while I wonder how to handle a list of eggs not suitable > > for certain situations due to some undocumented internals. > > I think a first step would be removing the "un" prefix from > "undocumented". :-) > > > Examples like "egg used global variables" vs. "application uses egg > > from multiple threads" come to mind. > > > > Or the case with the "synch" egg, which, last time I checked, > > combined dynamic-wind and mutex use in a flawed way defeating the > > locking purpose.[1] > > > > So far I don't have a good idea how this could be dealt with. Guess > > some kind of configurable/selectable blocklist would be in order. > > After all global variables are OK if you know there is only one > > thread or you know about them and ensure proper locking. > > > > Important I'd find that the lists and reason of listing should be > > shared somehow. After all this is about learning undocumented > > things/facts/risks. > > Usually we have sections in egg documentation about assumptions, known > bugs, limitations, caveats etc. The documentation is in our wiki. > Everyone can make contributions to improve the quality of egg > documentation, including mentioning caveats. > > Ideally bugs should be fixed, of course. When they are discovered, > they should be at least reported (e.g., https://bugs.call-cc.org or > whatever issue tracker egg authors use). > > I'm not completely sure I understand what you mean by "block list". I > think the best we can do is document issues, really, and leave it up > to users to decide whether the issues are relevant for their use > cases or not. > > All the best. > Mario
How to share knowledge about known bugs?
Hi Jeff and all of you, one in a while I wonder how to handle a list of eggs not suitable for certain situations due to some undocumented internals. Examples like "egg used global variables" vs. "application uses egg from multiple threads" come to mind. Or the case with the "synch" egg, which, last time I checked, combined dynamic-wind and mutex use in a flawed way defeating the locking purpose.[1] So far I don't have a good idea how this could be dealt with. Guess some kind of configurable/selectable blocklist would be in order. After all global variables are OK if you know there is only one thread or you know about them and ensure proper locking. Important I'd find that the lists and reason of listing should be shared somehow. After all this is about learning undocumented things/facts/risks. Best /Jörg [1] See this thread for details: https://lists.nongnu.org/archive/html/chicken-users/2020-11/msg9.html Test code attached here: https://lists.nongnu.org/archive/html/chicken-users/2020-11/msg00028.html Am Tue, 30 Nov 2021 11:42:12 -0700 schrieb Jeff Moon : > I have some automated chicken builds that install some select eggs, > and I'm starting to see errors when building the "synch" egg. It > complains about the undefined module "synch-object". I replicated > this on a fresh install of Ubuntu 20.10 with chicken 5.2.0 installed > from apt, chicken-install sync fails with the same error. > Thanks, > Jeff
Re: Performance question concerning chicken flonum vs "foreign flonum"
Hi Christian, this might be a case of "never trust a statistics you did not falsify yourself". Not bothering to speculate about explanations, I tend to ask how stable the results are wrt. larger N's, repetition etc. IMHO the results are too close for a call. Roughly this looks like 91% memory usage (minor gc's) going along of 85% runtime. Ergo: GC takes time. My first guess: There may be allocation going on in the FFI accounting for the increased memory usage. I'm in no way competent to actually confirm or rule out that hypothesis. Please take my whole assessment with a grain of salt; just a fist guess. Am Thu, 04 Nov 2021 16:46:50 +0100 (CET) schrieb : > Dear All, > > I am currently experimenting with Chicken Scheme and I would like to > ask about the following situation: I am comparing a "pure" Scheme > fused-multiply-add (fma) using chicken.flonum against C99's fma via > chicken.foreign. Here is my test code: > > fma-test.scm > > (import (chicken flonum) (chicken foreign) srfi-4) > > (foreign-declare "#include ") > > ;; FMA via nested fp+ and fp* from chicken-flonum > (define (scm-fma x y z) > (fp+ z (fp* x y))) > > ;; FMA via C99 function through chicken-foreign > (define c99-fma (foreign-lambda double "fma" double double double)) > > ;; Test function for FMAs > (define (dot fma a b) > (do [(idx 0 (add1 idx)) >(dim (f64vector-length a)) >(ret 0.0 (fma (f64vector-ref a idx) (f64vector-ref b idx) > ret))] ((= idx dim) ret))) > > ;; Test vector dimension > (define dim 200) > > ;; Test vector 1 > (define a (make-f64vector dim 1.2345)) > > ;; Test vector 2 > (define b (make-f64vector dim 0.9876)) > > ;; Test repetitions > (define N 200) > > ;; Test scm-dot > (time (do [(n 0 (add1 n))] > ((= n N)) > (dot scm-fma a b))) > > ;; Test fma-dot > (time (do [(n 0 (add1 n))] > ((= n N)) > (dot c99-fma a b))) > > ;eof > > Runnnig this code as follows: > > csc -O5 fma-test.scm && ./fma-test > > yields the results in: > > 7.558s CPU time, 0/225861 GCs (major/minor), maximum live heap: 30.78 > MiB 8.839s CPU time, 0/256410 GCs (major/minor), maximum live heap: > 30.78 MiB > > Now I wonder why C's single function (instruction) is slower than two > Scheme functions calls. I have four potential explanations: > > 1. chicken.foreign needs to do some type conversion for each argument > and return value which accounts for the extra time. If so could this > be avoided by type declarations somehow? > > 2. chicken.flonum does something to make fpX calls very fast. If so > can this be done for the foreign fma, too? > > 3. I am using chicken.foreign inefficiently, but I think srfi-144 is > using it similarly. > > 4. This is an effect only on my machine? > > It would be great to get some help or explanation with this issue. > > Here is my setup: > > CHICKEN Scheme 5.2.0 > gcc 10.3.0 > Ubuntu 20.04 > AMD Ryzen 5 4500U with 16GB > > Thank you very much > > Christian >
Re: [ANN] CHICKEN 5.3.0 release candidate available
Hi Ariela, sorry, my bad. Looks like I got side tracked and never returned to complete the release after merging the patch. Hope it works now. (Can't test myself currently.) /Jörg Am Fri, 13 Aug 2021 07:35:14 +0200 schrieb Mario Domenech Goulart : > Hi Ariela, > > On Thu, 12 Aug 2021 21:44:11 -0300 Ariela Wenner > wrote: > > > Hi all, I seem to be running into a weird issue with this rc when > > trying to install the pigeon-hole egg (might happen with other eggs > > too, I tested a bunch and it only happened with pigeon-hole though). > > > > Link to log output: > > https://paste.call-cc.org/paste?id=96c654c6b97cd5268c6006e19c78739e19bbde42 > > > > Operating system: Debian testing and Debian stable > > Hardware platform: x86-64 > > C Compiler: GCC 10.2.1 > > Installation works?: yes > > Tests work?: yes > > Installation of eggs works?: almost! > > > > Anyone else? > > pigeon-hole broke with b175ce65 in the chicken-core repository: > http://salmonella-linux-x86.call-cc.org/master/clang/linux/x86/2021/04/12/yesterday-diff/ > > A patch has been submitted > (https://github.com/0-8-15/pigeon-hole/pull/3) but a new version has > not been released. > > In summary: it's an issue with pigeon-hole. > > All the best. > Mario
Re: Some questions about concurrency (mostly)
Am Sun, 8 Nov 2020 02:17:58 + schrieb Chris Vine : > I wonder therefore why you think that this renders the proposed > with-lock function inappropriate, if that is what you were implying? > Perhaps you weren't and were making some other point. Macros for > handling resources such as mutex invoking dynamic-wind are > commonplace. Sorry, short on time. Two experiments for you kind consideration in the appended `test.scm` Best /Jörg ;; experiment 1 (define x (make-mutex)) (thread-start! (make-thread (lambda () (dynamic-wind (lambda () (mutex-lock! x)) (lambda () (raise 2)) (lambda () (mutex-unlock! x)) (mutex-state x) (mutex-lock! x) ;; experiment 2 (define (current-dynamic-extent) ;; a stripped down version of srfi-154 ;; ;; Note: any unlucky combination of call/cc, e.g., from exception ;; handlers exception handler might result in an obfuscated version ;; of this: ((call-with-current-continuation (lambda (unit) ((lambda (d) (lambda () d)) (lambda (thunk) (call-with-current-continuation (lambda (k) (unit (lambda () (call-with-values thunk k))) (define (dynamic f #!optional (dynamic-extent #f)) (let ((fixed (if dynamic-extent dynamic-extent (current-dynamic-extent (lambda args (fixed (lambda () (apply f args)) ;; Here we go (define (with-mutex m t) (dynamic-wind (lambda () (mutex-lock! m)) t (lambda () (mutex-unlock! m (define x (make-mutex)) (mutex-specific-set! x #t) (define invert-x! (dynamic (lambda () (with-mutex x (lambda () (mutex-specific-set! x (not (mutex-specific x (display (with-mutex x (lambda () (let ((before (mutex-specific x))) (invert-x!) ;; I bet you'd expect this to block, don't you? (eq? before (mutex-specific x))
Re: Some questions about concurrency (mostly)
Am Fri, 06 Nov 2020 17:48:26 +0100 schrieb felix.winkelm...@bevuta.com: > > I'm not doing any call/cc or non-local exit shenanigans, but the > > code uses srfi-18 threads and does I/O over TCP. As I understand > > it, srfi-18 is implemented using continuations. Will that cause > > problems with my with-lock function? I'm thinking that a thread > > that has aquired the lock in the before-thunk and running the main > > thunk might hang waiting for I/O; will that cause it to exit the > > dynamic environment, run the after-thunk and release the lock? > > Each thread has its own dynamic-wind chain, so unless you start > threads in the before/after threads, you should be fine. As I wrote before: beware of subtile interference between a) srfi-18 and exception handling regarding the `abandoned` state of the mutex or even better b) srfi-154's idea of a `current-dynamic-extent`. Both are great ways to create showcases how to confuse code, which calls mutex-(un)lock! from within `dynamic-wind`-installed handlers. I'd LOVE to be able to tag procedures to be "dynamic-wind-safe" to the extent that calling them from such a context raises an exception! Having though more in the past hours about this - actually frequently recurring issue, which I, admittedly got personally wrong for several years - I'd even take back my recommendation to EVER call `mutex-unlock!` from unwind-handlers. Just figure out in the handler whether or not to handle the exception and defer `mutex-unlock!` until after the exception handler completed (or don't call it if the handler re-raises the exception). This topic is labeled: "dragons ahead" for me. Just consider `mutex-`* operations NOT safe to be called from `dynamic-wind` "before" and "after" thunks.
Re: Some questions about concurrency (mostly)
Am Thu, 05 Nov 2020 23:22:09 +0100 schrieb Fredrik Appelberg : > 3. I'm new to dynamic-wind. If I wanted to create a general form for >executing a thunk protected by a mutex, would this be a good idea? > > (define (with-lock mutex thunk) >(dynamic-wind >(lambda () (mutex-lock! mutex)) >thunk >(lambda () (mutex-unlock! mutex) > >I read somewhere that the before- and after-guards might execute >multiple times, but then again I'm not really sure under what >circumstances so I might be way off. This approach is bound to fail badly. It works just as long as there are a) no exceptions raised in `thunk` b) no code, not even in a library does any `call/cc`. Including `call/cc` hidden in exception handlers (srfi-12, srfi-34 etc.) NEVER DO THIS! You need this: (define with-lock mutex thunk (handle-exceptions exn (begin find out whether you can safely unlock the mutex or clean up the damage done by partially updating the resource (mutex-unlock! mutex) ;; if appropriate either `(raise exn)` or return some value) (mutex-lock! mutex) modify resource (mutex-unlock! mutex)))
Re: Multi-platform app development options for chicken?
Hi Matt, this is what I currently do to this end: Since a while I'm using lambdanative. It makes it easy for me to build APKs. Supports iOS too, though I never tried. I make a Chicken build for it (not avail upstream but I'll make it avail if anyone would like it). Chicken running in a pthread talking to the Gambit pthread from lambdanative via abstract socket. To make it easier to control native Android GUI elements, I ported the original JScheme (and very slightly extended it, e.g., to enable contructors to dispatch on argument types)[1]. The only thing I'm currently really, really missing is a way to have select(2)able fd's for pthread-to-pthread communication under Windows. My verdict: great it all you need is to quickly glue some GUI together. However: IUp is much more capable, but also harder to use. Complex user interfaces I rather do as Web applications. The server in Chicken on the loopback interface the GUI part (on Android) is the webkit widget from Android, controled via LNjScheme. (On Linux/Windows it starts a Webbrowser. iOS I did not tryso far.) Best /Jörg [1]: https://github.com/part-cw/lambdanative/tree/master/apps/DemoAndroidLNjScheme On Sun, 19 Jan 2020 11:57:26 -0700 Matt Welland wrote: > Currently I've got windows and Linux covered and I'm very happy with > the Chicken+IUP combo (although getting that to work on old platforms > with Chicken 5 is a challenge). However I need to try again for > Android. The SDL build worked and has great potential for games but > not so much for regular apps. > > My thought is to learn Javascript and ramp up on something like > Native ( https://www.nativescript.org) which begs the question, is it > feasible to use Chicken as part of a Native app such that the core of > the app is Chicken and the interface is Javascript/Native? > > I'm looking for opinions and comments from Chicken users as to how you > would approach this problem. > > Thanks. > -- > Complexity is your enemy. Any fool can make something complicated. > It is hard to keep things simple. - Richard Branson.
Re: [Chicken-users] memory monitoring and leak debugging? (should the advice be in a web page?)
Hello Daniel, welcome here. Since CHICKEN compiles into C, all the tools you are used with C to use are still there. Personally I'm not a fan of fancy debuggers, since most of the things I write tend to depend on external (network) events. I'd welcome tips how to automate those jobs using better tools than printing log messages. Memory use in code mixing C and CHICKEN Scheme can be hairy. I tend to recommend to abstain from calling back from C into Scheme until you know what you are doing. http://wiki.call-cc.org/man/5/C%20interface#notes Otherwise I used to run my code under valgrind, which helped me a lot to catch some errors. Best Regards /Jörg Am Tue, 6 Aug 2019 10:37:06 -0500 schrieb Daniel Ortmann : > Hello all, > I am new to Chicken Scheme and experimenting with binding scheme to a > C scanner built with Flex. The results are fast but I feel the need > to monitor memory use and watch for leaks. > > The only relevant thing I find on call-cc.org is this url: > http://wiki.call-cc.org/chicken-for-emacs-lisp-programmers#tooling > > What are your experiences, tools, and practices with debugging mixed > Scheme + C code? ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Build issue: is there a shortcut?
Hi all, while cross compiling I wonder: this builds (in my case) a lot of binaries which have a path compiled in into the development environment. These are essentially useless. They just take my time to compile and waste space on the SSD. Probably there is a target for `make` to use instead of the default, which would just build the (static) library and *.import.scm files I need on the host system. Just which one I haven't been able to figure out. Which one is it? Thanks to much. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] csc -embedded seems to be broken
Hi, I tried to use the -embedded switch with csc as per manual "Embedding.html". This fails with "multiple definition of `main'". Compiling with csc -t and manually deleting `C_main_entry_point` seems to fix the issue. Is there any better way? Best Regards /Jörg (Using CHICKEN 4 in this case, as I'll need it only with C4 for the foreseeable future.) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] CHICKEN 5.1.0 has been released
Dear CHICKENers, On Jun 18 2019, Peter Bex wrote: The other important new features are the new cond-expand, c-object and object forms in .egg files. The last two forms did not make it into the documentation yet, did they? Congratulations and thanks for all the work which went into it. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Issue when linking statically
On Jan 28 2019, Evan Hanson wrote: Hi Jörg, Rather than (csc-options ...) you might try (linkage static): http://wiki.call-cc.org/man/5/Egg%20specification%20format#linkage This claims "This property only makes sense for extension libraries." whereas the snippet came from the .egg file for the resulting program. /Jörg Evan On 2019-01-28 14:07, Jörg F. Wittenberger wrote: Hi all, trying link a CHICKEN 5 program against the openssl egg fails badly for me. In the egg file I have openssl among the dependencies and (component-options (csc-options -static -v ) (link-options -L "-pthread -l:libssl.a -l:libcrypto.a" )) This links successfully, but when the resulting executable is started with -:d I see: ; loading /home/u/chickens/5.0.0/lib/chicken/9/openssl.import.so ... [debug] entering openssl... which looks as if I have to ship the file - which would be bad. In fact I have another module, which I wrote, which too does not like to be linked statically. So in fact I wonder what could have gone wrong. Thanks so much /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Issue when linking statically
Hi all, trying link a CHICKEN 5 program against the openssl egg fails badly for me. In the egg file I have openssl among the dependencies and (component-options (csc-options -static -v ) (link-options -L "-pthread -l:libssl.a -l:libcrypto.a" )) This links successfully, but when the resulting executable is started with -:d I see: ; loading /home/u/chickens/5.0.0/lib/chicken/9/openssl.import.so ... [debug] entering openssl... which looks as if I have to ship the file - which would be bad. In fact I have another module, which I wrote, which too does not like to be linked statically. So in fact I wonder what could have gone wrong. Thanks so much /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Peeking N characters in string ports
Hi David, On Jan 11 2019, David Ireland wrote: Hi there, I'm reading from a (string) port and have a need to peek 2 characters inside without actually reading off the port (read-char). I believe procedures such as unread-char seen in other Schemes would solve my problem however, this isn't available in Chicken it seems. I do not recall that I ever used unread-char ever. I roughly recall that it usually can only "un-read" a single character. But that might be wrong. Would anyone have any suggestions? If you really need such a thing, my only suggestion would be to look into http://wiki.call-cc.org/man/5/Module%20(chicken%20port) make-input-port combined with make-concatenated-port and some tricks could do the trick. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] two more eggs ported
Hi all, Moritz especially attached two eggs spiffy-uri-match and uri-match which I just ported over to C5. Best Regards /Jörg chicken-egg-uri-match.tar.gz Description: chicken-egg-uri-match.tar.gz chicken-egg-spiffy-uri-match.tar.gz Description: chicken-egg-spiffy-uri-match.tar.gz ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] new egg: simple-timer
Thanks Mario, I tagged a better version. Best /Jörg On Nov 24 2018, Mario Domenech Goulart wrote: Hi Jörg, On 24 Nov 2018 21:59:08 +0100 Jörg F. Wittenberger wrote: I packages a new new: simple-timer https://raw.githubusercontent.com/0-8-15/simple-timer/master/simple-timer.release-info This is intended as the one-stop shopping for low level plumping of the background threads every other egg needs to put at the core's timeout queue. (Either because it needs roughly correct time signals or evade false deadlock detection.) I hope this could help with is the hell of reasoning about the timeout queue in an application using several such eggs at the same time: At least the boring timeouts are under a single umbrella. Right now it is just the code the `forcible` egg uses under the hood so far. (Which would be the first candidate to switch. ;-) Thanks. It looks like the egg doesn't specify a test dependency on the test egg, which is used by the test suite: Error: (import) during expansion of (import ...) - cannot import from undefined module: test All the best. Mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] new egg: simple-timer
Hi all, I packages a new new: simple-timer https://raw.githubusercontent.com/0-8-15/simple-timer/master/simple-timer.release-info This is intended as the one-stop shopping for low level plumping of the background threads every other egg needs to put at the core's timeout queue. (Either because it needs roughly correct time signals or evade false deadlock detection.) I hope this could help with is the hell of reasoning about the timeout queue in an application using several such eggs at the same time: At least the boring timeouts are under a single umbrella. Right now it is just the code the `forcible` egg uses under the hood so far. (Which would be the first candidate to switch. ;-) Best Regards /Jörg ___ 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
Operating system: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64 GNU/Linux Hardware platform: x86-64 C Compiler: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 Installation works: yes Tests work: yes Installation of eggs works: yes /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] http-client: distinguishing between responses 301 and 302
On Oct 18 2018, John Cowan wrote:
The difference between 301 and 302 is primarily relevant to crawlers and
caches. I agree that it needs to exist, but not clear that a
general-purpose client needs to expose it. Can you explain your use case
more clearly? Thanks.
John, to me this does not look as if Norman was using the http-client for a
general purpose client. But more like a dev/testing tool.
Anyway. I'm looking into http-client with similar worries. Ages ago I wrote
some http client+server code (using rscheme at that time) which is since
used in a rather unusual setting: It is used to replicate incoming requests
to a network of machines each hosting many state machines (a.k.a.
communication sequential processes, a.k.a. agents) in byzantine fault
tolerant replication. (Things are always implemented in LISP first. Smart
contracts too. ;-)
Now I want to replace that mess I wrote over 15 years ago with an
alternative implementation I don't have to maintain alone. http-client
comes to mind.
Looking closer I don't like to install exception handlers in order to
handle the http status. That might be a matter of taste.
Then, when replicating a request, the same payload is send to several
receivers. I'd like to not repeat the serialization process. However in
order to account for different bandwidth to certain peers, there is the
need to half way synchronize the delivery of the last byte(s) of each
stream until at least the majority of the peers has received all of the
request.
Things I'd like to do with http-client. But it looks complicated.
So maybe the high level interface of http-client is simply not the one
Norman wants to use.
Best
/Jörg
On Thu, Oct 18, 2018 at 1:20 PM Norman Gray wrote:
Greetings.
In http-client, is there any way of distinguishing between server
responses 301 and 302?
In test code, I want to confirm that a server is responding with the
correct redirection code, but can't quite get there.
If I make a request using call-with-input-request and the server
produces a redirection, then the client code follows the redirection.
If I parameterise that with (parameterize ((max-redirect-depth 0)) ...),
then the client library doesn't follow the redirection but instead
raises (exn http redirect-depth-exceeded). That's almost there, except
that the exception doesn't contain information about _which_
redirection, 301 or 302, prompted it. Using (condition->list), I get
redirect-depth-exceeded: e=#
list=(
(exn (arguments ("http://localhost:8081/host/;))
(message "Maximum number of redirects exceeded")
(location send-request))
(http)
(redirect-depth-exceeded
(request #)
(new-uri #)
(uri #)))
The documentation for call-with-input-request* doesn't suggest that it
behaves differently from call-with-input-request in this respect. And
although call-with-response mentions the possibility of redirects, and
multiple calls to 'reader', it doesn't suggest that the reader procedure
has any access to the response headers.
Is there any other way of getting this status code, or do I feel an
enhancement request coming on?
Possibly better than this handling of redirect-depth-exceeded would be a
parameter follow-redirects? which defaults to #t, or having
call-with-input-request return normally (ie, without the exception) in
the particular case that max-redirect-depth is 0.
I'm using Chicken 4, but as far as I can see, the Chicken 5 http-client
is identical in this behaviour.
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Q] Are there any performance-wise differences between Chicken 5 and Chicken 4?
On Oct 11 2018, Sungjin Chun wrote: Hi, it seems that Chicken 5 will be released soon or else :-) I'd like to know whether there's any performance enhancement in Chicken 5 compared to Chicken 4. Thanks in advance. So far I measured only very specific workloads. Unfortunately those did not exactly benefit from the improvements which went into Chicken 5. I would at least not expect a general performance enhancement. PS) I'd like to port my library to Chicken scheme (for fun) and the library is located at https://bitbucket.org/chunsj/th/ . Mostly, this library uses FFI If most of your runtime is going to be spent in foreign libraries anyway, the performance difference of the Chicken layer is likely to be irrelevant. However if you're about to do math in Chicken than 4 vs. 5 is going to be a difference like day and night. 5 has full numeric tower with arbitrary precision and complex numbers etc. --- Chicken 4 doesn't. to the underlying libTH and libTHNN from torch. Are there any reference on writing FFI code in Chicken scheme? Let's say, I originally came to like Chicken for it's FFI. It's easy with the information from the manual. http://wiki.call-cc.org/man/5/Interface%20to%20external%20functions%20and%20variables It's tricky anyway. I'd suggest to have a look into eggs source code which link to other libraries. I'd recommend the "iup" egg, if I had to make a pick (which is certainly unjust and just a "start reading here"). When you struggle, just come back. You'll be welcome. Cheers /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken on Windows 10 - Was: [ANN] CHICKEN 5.0.0 release candidate 2 available
Thanks Kristian, problem solved: Operating system: MINGW64_NT-10.0 Hardware platform: x86-64 C Compiler: gcc.exe (Rev1, Built by MSYS2 project) 8.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes Surprisingly the pathname issue went away. I guess this is already documented in the README "disguised" as "Cygwin will not be able to find the chicken shared libraries until Windows is rebooted". Thanks again for all the work which went into CHICKEN. /Jörg On Sep 17 2018, Kristian Lein-Mathisen wrote: Hi Jorg, If I'm not mistaken, the Readme mentions says that you have to specify a PREFIX for Windows builds. I'm guilty os trying the same "shortcut". And obs: use forward slashes and include the drive letter and colon! I don't know what's happing with the absolute-pathname trouble - I never ran into that issue. Could the generated absolute pathnames be wrong due to the same issue? K. On Sat, Sep 15, 2018, 15:26 Jörg F. Wittenberger < joerg.wittenber...@softeyes.net> wrote: Hi Kristian, I don't have the Windows machine close. I'm not perfectly sure, but I should not have specify a PREFIX at all. My intention was first and foremost to test that a default installation done by a windows novice using hints from the wiki works. Surprisingly this went well up to the compile. The first issue I ran in could likely go away using your suggestion. The second I'm afraid will not. The generated build scripts just do not work on my system. As I'm a windows novice using msys2 first time, I'm cautious to actually assign the blame. My guess is that the windows cmd.exe should eventually execute the build scripts. If that's true than it does not work because, wait for it, my cmd.exe does not accept the command when it is given with path. It wants to do the lookup itself. At least that's what it looks alike. I changed the "@echo off" to "@echo on" and it perfectly works until there is this '/usr/local/bin/chicken-do' ... if I replace this with just chicken-do it starts... just to break down when it tries to execute csc the same way. Anything I could do to track this down? Best /Jörg On Sep 14 2018, Kristian Lein-Mathisen wrote: >Hi Joerg, > > I was trying C5rc1 on win10 i few weeks ago and had to do some > tweaking to get it working og msys2 (which was surprisingly > comfortable to use). > > I also had a problem with chicken-install not downloading anything at > first. The symptom became clearer when I did chicken-install > -update-db. I realised I wasn't using an absolute path for PREFIX when > invoking make. > Doing something like make PLATFORM=mingw-msys PREFIX=C:/c5/ solved the > issue, maybe you've run into the same problem? > > I never tried to change the defaults, so this may be completely > unrelated. K. > >On Wed, Sep 12, 2018, 16:15 Jörg F. Wittenberger < >joerg.wittenber...@softeyes.net> wrote: > >> Hi all, >> >> who is running chicken on Windows 10 here? How do you manage? I'm not >> sold to msys; I just tried first time and failed miserably. >> >> Any idea how to do a better setup (for chicken 5 release candidates) >> welcome. >> >> >> Maybe we can fix the support for msys2 nevertheless; >> So far I found two issues on Windows 10 + msys2 + mingw-w64: >> >> 1. chicken-install does not pick up the contents of setup.defaults by >> itself. >> >>Workaround: chicken-install -defaults >> /usr/local/share/chicken/setup.defaults >> >>-- which is saying: give the defaults from the installation on the >> command line again. >>-- This does the download and generates the build scripts >> (*.build.bat) >> >> 2. Using "start" to open a window running cmd.exe I found that I can >> not call chicken-do using the full path. As it is in the PATH variable I >> tried to copy the invocation line with only the path leading to >> chicken-do removed. >> >>This leads to: >>/usr/local/bin/csc -host -D compiling-extension -J -s -setup-mode >> -I C:\msys64\home\... ... so >>creating subprocess failed >> >> Best >> >> /Jörg >> >> >> On Sep 12 2018, Jörg F. Wittenberger wrote: >> >> >On Sun, Sep 09, 2018 at 02:30:12PM +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: MINGW64_NT-10.0 >> >Hardware platform: x86-64 >> >C Compiler: gcc.exe (Rev1, Built by MSYS2 project) 8.2.0 >> >Installation works?: yes >> >Tests work?: yes >> >Installation of eggs works?: no >> > >
Re: [Chicken-users] Chicken on Windows 10 - Was: [ANN] CHICKEN 5.0.0 release candidate 2 available
Hi Kristian, I don't have the Windows machine close. I'm not perfectly sure, but I should not have specify a PREFIX at all. My intention was first and foremost to test that a default installation done by a windows novice using hints from the wiki works. Surprisingly this went well up to the compile. The first issue I ran in could likely go away using your suggestion. The second I'm afraid will not. The generated build scripts just do not work on my system. As I'm a windows novice using msys2 first time, I'm cautious to actually assign the blame. My guess is that the windows cmd.exe should eventually execute the build scripts. If that's true than it does not work because, wait for it, my cmd.exe does not accept the command when it is given with path. It wants to do the lookup itself. At least that's what it looks alike. I changed the "@echo off" to "@echo on" and it perfectly works until there is this '/usr/local/bin/chicken-do' ... if I replace this with just chicken-do it starts... just to break down when it tries to execute csc the same way. Anything I could do to track this down? Best /Jörg On Sep 14 2018, Kristian Lein-Mathisen wrote: Hi Joerg, I was trying C5rc1 on win10 i few weeks ago and had to do some tweaking to get it working og msys2 (which was surprisingly comfortable to use). I also had a problem with chicken-install not downloading anything at first. The symptom became clearer when I did chicken-install -update-db. I realised I wasn't using an absolute path for PREFIX when invoking make. Doing something like make PLATFORM=mingw-msys PREFIX=C:/c5/ solved the issue, maybe you've run into the same problem? I never tried to change the defaults, so this may be completely unrelated. K. On Wed, Sep 12, 2018, 16:15 Jörg F. Wittenberger < joerg.wittenber...@softeyes.net> wrote: Hi all, who is running chicken on Windows 10 here? How do you manage? I'm not sold to msys; I just tried first time and failed miserably. Any idea how to do a better setup (for chicken 5 release candidates) welcome. Maybe we can fix the support for msys2 nevertheless; So far I found two issues on Windows 10 + msys2 + mingw-w64: 1. chicken-install does not pick up the contents of setup.defaults by itself. Workaround: chicken-install -defaults /usr/local/share/chicken/setup.defaults -- which is saying: give the defaults from the installation on the command line again. -- This does the download and generates the build scripts (*.build.bat) 2. Using "start" to open a window running cmd.exe I found that I can not call chicken-do using the full path. As it is in the PATH variable I tried to copy the invocation line with only the path leading to chicken-do removed. This leads to: /usr/local/bin/csc -host -D compiling-extension -J -s -setup-mode -I C:\msys64\home\... ... so creating subprocess failed Best /Jörg On Sep 12 2018, Jörg F. Wittenberger wrote: >On Sun, Sep 09, 2018 at 02:30:12PM +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: MINGW64_NT-10.0 >Hardware platform: x86-64 >C Compiler: gcc.exe (Rev1, Built by MSYS2 project) 8.2.0 >Installation works?: yes >Tests work?: yes >Installation of eggs works?: no > >Installation of eggs fails like this (for all eggs; immediately): > >$ chicken-install.exe pastiche > >Error: extension or version not found: "pastiche" ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Understanding Chicken 5 build scripts.
Hi, since I learned how CHICKEN 5's chicken-install creates platform specific build scripts, I wonder: why? This looks to me like asking for trouble. (Incompatible interpreters, quotation issues etc.) Intuitively I'd rather chosen build upon the PLT make macro and scsh-process and avoid dependencies on external interpreters as much as I could. Hence there must be some advantage to it I fail to see. Which one? Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken on Windows 10 - Was: [ANN] CHICKEN 5.0.0 release candidate 2 available
Hi all, who is running chicken on Windows 10 here? How do you manage? I'm not sold to msys; I just tried first time and failed miserably. Any idea how to do a better setup (for chicken 5 release candidates) welcome. Maybe we can fix the support for msys2 nevertheless; So far I found two issues on Windows 10 + msys2 + mingw-w64: 1. chicken-install does not pick up the contents of setup.defaults by itself. Workaround: chicken-install -defaults /usr/local/share/chicken/setup.defaults -- which is saying: give the defaults from the installation on the command line again. -- This does the download and generates the build scripts (*.build.bat) 2. Using "start" to open a window running cmd.exe I found that I can not call chicken-do using the full path. As it is in the PATH variable I tried to copy the invocation line with only the path leading to chicken-do removed. This leads to: /usr/local/bin/csc -host -D compiling-extension -J -s -setup-mode -I C:\msys64\home\... ... so creating subprocess failed Best /Jörg On Sep 12 2018, Jörg F. Wittenberger wrote: On Sun, Sep 09, 2018 at 02:30:12PM +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: MINGW64_NT-10.0 Hardware platform: x86-64 C Compiler: gcc.exe (Rev1, Built by MSYS2 project) 8.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: no Installation of eggs fails like this (for all eggs; immediately): $ chicken-install.exe pastiche Error: extension or version not found: "pastiche" ___ 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, Sep 09, 2018 at 02:30:12PM +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: MINGW64_NT-10.0 Hardware platform: x86-64 C Compiler: gcc.exe (Rev1, Built by MSYS2 project) 8.2.0 Installation works?: yes Tests work?: yes Installation of eggs works?: no Installation of eggs fails like this (for all eggs; immediately): $ chicken-install.exe pastiche Error: extension or version not found: "pastiche" Cheers, /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] functor support (C5)
Hi all, I tried to package an egg exporting a functor. for reference here: https://github.com/0-8-15/ldif-sexpr `include` is literally copied to the .import.scm file The actual code of the functor is in its own file, which is included here https://github.com/0-8-15/ldif-sexpr/blob/master/ldif-core.scm around line 33. This results in the include directive ending up compiled into the import library. Importing and instancing the functor will work if, and only if, the named file is found. Along whatever search path whatever content is found. Intuitively I'd say this defeats the idea of compiling the import library in the first place. BTW: Did anything change about the line number information with Chicken 5? If so, I would have to re-check. Last time, maybe about a year ago when I tried Chicken 4 functor instances where a pain in the butt when it comes to error messages. Line numbers pertaining to errors within functors where always be given as the line of the functor instantiation. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] porting eggs experiences and questions
Hi all, in the meantime I understood why chicken-install would not install dependencies: chicken-install -n While messing around I did not want the egg in the current directory to be installed. Just the dependencies. Apparently chicken-install passes the -n switch down to the dependencies it need to install. Those are then not installed, which makes chicken-install barf at the depending eggs. Maybe it makes more sense to have the -n switch only in effect for the egg in the current directory while still installing dependencies. Best /Jörg On Aug 17 2018, Jörg F. Wittenberger wrote: * Observation: chicken-install does not install dependencies This is just odd: The .egg file contains (dependencies srfi-18); chicken-install did the download but not install it. So compilation failed until I manually did chicken-install srfi-18 That's weird. We don't observe this behavior on any of the automated tests (http://tests.call-cc.org). It is. But it seems consistent in my setup. I tried: `chicken-install srfi-13`: this did the download for srfi-14 compiled and failed to install srfi-13. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-34 egg
Thank you Mario, Should be fixed now. Best /Jörg On Aug 20 2018, Mario Domenech Goulart wrote: Hi Jörg, On Sun, 19 Aug 2018 09:21:42 +0200 Mario Domenech Goulart wrote: On 17 Aug 2018 20:40:02 +0200 Jörg F. Wittenberger wrote: there is an srfi-34 egg here https://raw.githubusercontent.com/0-8-15/srfi-34/master/srfi-34.release-info https://github.com/0-8-15/srfi-34 which compiles for me with both chicken 4 and chicken 5. Could go to the coop if it is done well. Thanks Jörg. Your egg has been added to the coop. It looks like the tags and the references in the .release-info file are inconsistent. .release-info references a 0.6 tag, but the only tag in the repository is 0.7. Please, fix this. All the best. Mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] http-client help needed with basic authorization
On Aug 20 2018, Peter Bex wrote:
On Mon, Aug 20, 2018 at 02:47:25PM +0200, Jörg F. Wittenberger wrote:
I'm trying to use the http-client to talk to a Jira installation.
Without much success.
Jira is documented to support Basic authentication. However it defaults
to and advertices OAuth. For the case at hand, a script reading some
data, it OAuth looks like wasteful overhead.
The idea is to supply an "Authorization" header right with the request.
http-client comes with built-in basic auth support. Just put a username
and password in the URL's authorization component.
That's what I tried first. :-/
Any hints welcome.
So far I have this:
(define (insightc-query!2 uri . more)
(define (basic-auth username pw)
(string-append
"Basic "
(basic-auth-param-subunparser `((username . ,username) (password .
,pw
#;`#(Basic ((username . ,username) (password . ,pw)))
#;`#(Basic (,(basic-auth-param-subunparser `((username . ,username)
(password . ,pw)
)
(let* ((uri (update-uri uri host: "localhost" port: 7070 path: (append
(uri-path uri) more)))
(username "jwi")
(pw (call-with-input-file ".password" read))
(hdr (headers `((authorization ,(basic-auth username pw)
(req (make-request uri: uri headers: hdr)))
(call-with-response req (lambda (x) #f) insightc-response-handler)))
Error: (unparse-headers) could not unparse "Authorization" header
(#("Basic and... ...=" Error: (unparse-headers) could not unparse
"Authorization" header (#("Basic and... ...="
Call history:
intarweb.scm:724: ##sys#print
If you want to pass a raw string through the request unparser, convert it
to a blob. Then it will be taken as-is, iirc.
Ah, great, that might do the trick. Will try tomorrow.
Cheers,
Peter
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-128 - almost
Thanks Mario, at the end of the day your suggestion will solve the development time considerations I have. Except for the "check the download process" part. Though actually rolling those out over a test network looks like a bookkeeping hell. Brings me to a downside of C5 I'm seeing so far: I now need to tell it where it should maintain its cache. I wonder how I could maintain a consistent overwrite for setup.defaults for all the receipes in a yocto build. Plus where goes this new cache? Best /Jörg On Aug 19 2018, Mario Domenech Goulart wrote: On Sat, 18 Aug 2018 15:57:52 +0300 megane wrote: Hi Jörg, Jörg F. Wittenberger writes: [...] Brings back the question: how would I tell chicken to temporarily consult other locations for egg distributions? E.g. I'd like to use chicken-install in a fresh location outside the source directory of the egg to check that the whole download picks the correct files and all of them. Or maybe I just want to install an egg I deem not good enough to release. Maybe you're looking for a custom entry in share/chicken/setup.defaults. Maybe something like: (server (location "/path/to/my/eggs") (transport local)) Actually just $ echo "(location $EGGS_DIR)" >> $PREFIX/share/chicken/setup.defaults should be enough. Where EGGS_DIR is the directory where directories containing egg source code can be found and $PREFIX is the CHICKEN installation prefix (what you provided as argument to PREFIX when compiling CHICKEN). If the egg you try to install (or its dependencies) cannot be found in $EGGS_DIR, chicken-install will fall back to the `server' configuration in setup.defaults (which defaults to the primary egg server). All the best. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-128 - almost
The release-info worried me too - TLD; super simple: if nothing else changes, it should work as before. To add it to the C5 coop send a note to the list that https://raw.githubusercontent.com/ThatGeoGuy/srfi-128/master/srfi-128.release-info it ready to go there. Best /Jörg On Aug 18 2018, Jeremy Steward wrote: On 08/18/2018 06:12 AM, Jörg F. Wittenberger wrote: On Aug 18 2018, Jeremy Steward wrote: Hey Joerg, I'm the maintainer for that egg. I know; we talked about that before as I had packaged the same srfi under the name of "comparators" before. Ah, right. Now I remember :) I'd be happy to review the pull request, but just haven't had time. I can look it over tomorrow if necessary to get things merged in properly. I did not want to be pushy. It's just a nice example of a situation where I'd like to consult alternative sources than those baked into chicken-install. No worries, I needed to get on this (and several other eggs). I've reviewed the PR, and tested with both CHICKEN 4.12.0 and 5.0.0rc1, and it all seems to be in working order. I've merged the PR and we should be good to go. Couple of questions in general though: * How does updating the .release-info file work now, if you want to support CHICKEN 4 and 5 at the same time? * What do I need to do to add SRFI 128 to the coop? Regards, ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New C5 eggs: llrb-syntax
Done. Reference removed. On Aug 19 2018, Mario Domenech Goulart wrote: On Sun, 19 Aug 2018 09:23:19 +0200 Mario Domenech Goulart wrote: On 18 Aug 2018 20:17:00 +0200 Jörg F. Wittenberger wrote: nothing changed, just ported https://raw.githubusercontent.com/0-8-15/llrb-syntax/master/llrb-syntax.release-info Thanks, Jörg. Your egg has been added to the coop. I just noticed the .release-info file for llrb-syntax references a tag which is not in the repository (0.1). Please, either push the tag or remove the reference to it from the .release-info file. All the best. Mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] http-client help needed with basic authorization
I'm trying to use the http-client to talk to a Jira installation.
Without much success.
Jira is documented to support Basic authentication. However it defaults to
and advertices OAuth. For the case at hand, a script reading some data, it
OAuth looks like wasteful overhead.
The idea is to supply an "Authorization" header right with the request.
Any hints welcome.
So far I have this:
(define (insightc-query!2 uri . more)
(define (basic-auth username pw)
(string-append
"Basic "
(basic-auth-param-subunparser `((username . ,username) (password .
,pw
#;`#(Basic ((username . ,username) (password . ,pw)))
#;`#(Basic (,(basic-auth-param-subunparser `((username . ,username)
(password . ,pw)
)
(let* ((uri (update-uri uri host: "localhost" port: 7070 path: (append
(uri-path uri) more)))
(username "jwi")
(pw (call-with-input-file ".password" read))
(hdr (headers `((authorization ,(basic-auth username pw)
(req (make-request uri: uri headers: hdr)))
(call-with-response req (lambda (x) #f) insightc-response-handler)))
Error: (unparse-headers) could not unparse "Authorization" header (#("Basic
and... ...=" Error: (unparse-headers) could not unparse "Authorization"
header (#("Basic and... ...="
Call history:
intarweb.scm:724: ##sys#print
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New C5 egg: sqlite3pth
I'm amazed that this was actually portable to chicken 5 with so little effort. https://raw.githubusercontent.com/0-8-15/sqlite3pth/master/sqlite3pth.release-info Caveat: this depends on 1. llrb-tree, which waits for srfi-128 2. srfi-34 which I'm afraid may not really be maintained. For the time being there is the srfi-34 I ported to chicken 5 here: https://raw.githubusercontent.com/0-8-15/srfi-34/master/srfi-34.release-info Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New C5 egg: llrb-tree
llrb-tree is also supposed to be ready to go. But this one depends on srfi-128 which in in the queue. https://raw.githubusercontent.com/0-8-15/llrb-tree/master/llrb-tree.release-info Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New C5 eggs: llrb-syntax
nothing changed, just ported https://raw.githubusercontent.com/0-8-15/llrb-syntax/master/llrb-syntax.release-info Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New C5 egg: pthreads
pthreads appears to work too https://raw.githubusercontent.com/0-8-15/pthreads/master/pthreads.release-info ... ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New C5 egg: pigeon-hole
This could go to the C5-coop https://raw.githubusercontent.com/0-8-15/pigeon-hole/master/pigeon-hole.release-info ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-128 - almost
This looks pretty close. Where do I learn what I can put into setup.defaults? Looks like it could do the job I want. What I don't want: a local copy of the to-be-installed egg to begin with. What I want: chicken-install installing eggs almost like normal. For eggs being overwritten however, I'd want it to go through the complete download process, just using the location from the other release-info. Great if a hand full of overwrites could sit in a single file like setup.defaults. On Aug 18 2018, megane wrote: Hi Jörg, Jörg F. Wittenberger writes: [...] Brings back the question: how would I tell chicken to temporarily consult other locations for egg distributions? E.g. I'd like to use chicken-install in a fresh location outside the source directory of the egg to check that the whole download picks the correct files and all of them. Or maybe I just want to install an egg I deem not good enough to release. Maybe you're looking for a custom entry in share/chicken/setup.defaults. Maybe something like: (server (location "/path/to/my/eggs") (transport local)) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-128 - almost
On Aug 18 2018, Jeremy Steward wrote: Hey Joerg, I'm the maintainer for that egg. I know; we talked about that before as I had packaged the same srfi under the name of "comparators" before. I'd be happy to review the pull request, but just haven't had time. I can look it over tomorrow if necessary to get things merged in properly. I did not want to be pushy. It's just a nice example of a situation where I'd like to consult alternative sources than those baked into chicken-install. Anybody having a good suggestion? Best /Jörg Regards, On August 17, 2018 11:44:17 AM MDT, "Jörg F. Wittenberger" wrote: Let's try an example. I forked the srfi-128 repo here and ported it to chicken 5 https://github.com/0-8-15/srfi-128 The .release-info still points upstream where the pull request went. This appears to install and work. Brings back the question: how would I tell chicken to temporarily consult other locations for egg distributions? E.g. I'd like to use chicken-install in a fresh location outside the source directory of the egg to check that the whole download picks the correct files and all of them. Or maybe I just want to install an egg I deem not good enough to release. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] srfi-34 egg
there is an srfi-34 egg here https://raw.githubusercontent.com/0-8-15/srfi-34/master/srfi-34.release-info https://github.com/0-8-15/srfi-34 which compiles for me with both chicken 4 and chicken 5. Could go to the coop if it is done well. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] C5 Type declaration issue
This is an instance of an error I'm getting frequently: /home/u/c5/bin/csc -setup-mode -static -I /home/u/traces/srfi-128 -emit-link-file /home/u/traces/srfi-128/srfi-128.link -host -D compiling-extension -c -unit srfi-128 -D compiling-static-extension -C -I/home/u/traces/srfi-128 -O3 -d2 /home/u/traces/srfi-128/srfi-128.scm -o /home/u/traces/srfi-128/srfi-128.static.o Warning: at toplevel: assignment of value of type `(procedure srfi-128#make-comparator (* * * *) (struct srfi-128#comparator))' to toplevel variable `srfi-128#make-comparator' does not match declared type `(procedure srfi-128#make-comparator ((or true (procedure :type-test: (*) boolean)) (or true (procedure :comparison-test: (* *) boolean)) (or false (procedure :comparison-test: (* *) boolean)) (or false (procedure :hash-function: (*) fixnum))) (struct comparator))' The relevant code excerpt from https://github.com/0-8-15/srfi-128 file comperators/comperators.scm: (define-type :comparator: (struct comparator)) (define-type :type-test: (procedure (*) boolean)) (define-type :comparison-test: (procedure (* *) boolean)) (define-type :hash-code: fixnum) (define-type :hash-function: (procedure (*) :hash-code:)) (: make-comparator ((or true :type-test:) (or true :comparison-test:) (or false :comparison-test:) (or false :hash-function:) --> :comparator:)) (define (make-comparator type-test equality ordering hash) ... How to deal with this? Thanks /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] srfi-128 - almost
Let's try an example. I forked the srfi-128 repo here and ported it to chicken 5 https://github.com/0-8-15/srfi-128 The .release-info still points upstream where the pull request went. This appears to install and work. Brings back the question: how would I tell chicken to temporarily consult other locations for egg distributions? E.g. I'd like to use chicken-install in a fresh location outside the source directory of the egg to check that the whole download picks the correct files and all of them. Or maybe I just want to install an egg I deem not good enough to release. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] porting eggs experiences and questions
Thanks Mario and Kristian for your responses.
On Aug 17 2018, Mario Domenech Goulart wrote:
I'm maintaining all my eggs in the same repo, same branch, same
.release-info file and same versioning scheme for both CHICKEN 4 and 5.
That's what I'd want.
In my experience, that's not difficult.
once you know what you're doing ;-)
* Observation: chicken-install does not install dependencies
This is just odd: The .egg file contains (dependencies srfi-18);
chicken-install did the download but not install it. So compilation
failed until I manually did
chicken-install srfi-18
That's weird. We don't observe this behavior on any of the automated
tests (http://tests.call-cc.org).
It is. But it seems consistent in my setup.
I tried: `chicken-install srfi-13`: this did the download for srfi-14
compiled and failed to install srfi-13.
Next I did `chicken-install srfi-14` and it installed from the download
cache. Then chicken-install srfi-13 succeeded.
Maybe I'm using a weired setup? In order to not confuse c4 and c5 I have no
chicken in my default path. I cleaned up the $PREFIX ("~/c5") and installed
c5rc1 there. Then I added ~/c5/bin to $PATH.
* chicken-install -n -test
Fails. One needs to actually install first, then run the test.
Better at least warn that we test the installed version, not the
current one. (I recall this bite me before.)
Best: just load the version from the working directory.
I think this pretty much depends on how tests are implemented. If they
import things assuming that the eggs are installed, you have to install
them before running tests. Or you can hack your tests to load/import
the code from the source directory.
What's your recommended way to load/import from the source directory?
Thanks
/Jörg
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] porting eggs experiences and questions
Hi, I just ported a first egg. (Pigeon-hole, "simple" mailbox with capacity constraint flow control and no timeouts.) * Question: what's about the .release-info This https://wiki.call-cc.org/porting-c4-to-c5 was helpful, but does not mention the release process. How would I mark a release for C5? Any thought on how to have both a C4 and C5 version in the same repo? I'll have to support C4 for quite a while. Now I wonder how best reorganize the code to work for both. * Observation: chicken-install does not install dependencies This is just odd: The .egg file contains (dependencies srfi-18); chicken-install did the download but not install it. So compilation failed until I manually did chicken-install srfi-18 * chicken-install -n -test Fails. One needs to actually install first, then run the test. Better at least warn that we test the installed version, not the current one. (I recall this bite me before.) Best: just load the version from the working directory. Thanks for all the work which went into C5. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-5
On Aug 17 2018, Juergen Lorenz wrote: Hi all, I've just begun to port my eggs to chicken-5. It's much simpler than I thought. The reorganisation of the libraries and egg installation system is great. I wish to thank the members of the chicken-team for their excellent job. Well done, guys! One question remains: The .egg file doesn't contain any hints for how to compile an egg. How does the installer decide, what flags to use? That's to be found here: https://wiki.call-cc.org/man/5/Egg%20specification%20format#csc-options Cheers Juergen ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] odd compiler messages on program structure errors
Hello Claude, On Oct 7 2017, Claude Marinier wrote: Good afternoon, Things are good. Great to hear. ... I either get "unterminated list" or "unexpected list terminator: #\)". I realize too late that I should have made a copy of the failing code. Sorry. So, should we be concerned about this? Yes we should. I some way or another. Unbalanced parenthesis however are a very basic syntx violation in any LISP. Adding in that the syntax is extensible, it is exceptionally hard to do something reasonable about the situation. Some favor "readable LISP" like SRFI's 110 and 119 - both of which infer missing list terminators from changes in intentiation. But many LISPers use emacs and - having been burned by the phenomenom early in their carrers - developed a habbit to always insert/delete them in corresponding pairs and have their editor indent automatically. Once accustomed to this style, they often prefer this over manually figuring out how much text they actually need to mark for edits. In the end of the day, misplaced delimiters happen. They are nasty. I'm among those who accepted the occational pain. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Passing in a scheme function into C to be called later
On Jul 18 2017, David Astels wrote: I'm integrating the Paho C MQTT client code with chicken. The publish stuff works fine; it's just straight-up calling C functions. Subscribing is puzzling me and I assume someone has encountered a similar situation at some point. I need to be able to pass a scheme function to a call to a C function. It then gets stored and is needs to be called by the message received callback (a C function). Any thoughts? Dave Did you come across the "Callbacks" section in the manual already? http://wiki.call-cc.org/man/4/Callbacks To me it looks as this should answer your question, does it? Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] srfi-34 egg
Hi Ben et al, I found it not paying nice (possibly not playing nice _anymore_) with the native exceptions chicken provides. The fix is simple, add these two lines to srfi-34 module: (use (prefix srfi-34 s34:)) (mutate-procedure! with-exception-handler (lambda (forget-it) s34:with-exception-handler)) Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg LDIF
Thank you Caolan. Well spotted.
Should be fixed now.
On Apr 19 2017, Caolan McMahon wrote:
Jörg, I think you have a typo in the first line:
(repo git "git://github.com/0-0-15/{egg-name}.git")
Should that be 0-8-15 to match your username (instead of 0-0-15)?
Caolan
Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> writes:
Hi,
there's a new egg:
Read/write LDIF, LDAP search strings and related data formats. (RFCs
2849, 4514, 2254)
https://raw.githubusercontent.com/0-8-15/ldif-sexpr/master/ldif-sexpr.release-info
Best
/Jörg
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New egg LDIF
Hi, there's a new egg: Read/write LDIF, LDAP search strings and related data formats. (RFCs 2849, 4514, 2254) https://raw.githubusercontent.com/0-8-15/ldif-sexpr/master/ldif-sexpr.release-info Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Using numbers correctly. How?
Hi all, I'm trying to use scsh-process pass bignums arguments. Unfortunately scsh-process's maybe->string does not recognize them as number?s and bails out. I can work around this easily, just use ->string at the invocation point. I'd rather like to fix the root cause and not work around. But how? Best /Jörg .. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Missing functions in Chicken IUP?
Am 21.04.2016 um 01:53 schrieb Matt Welland: > We are trying to create a popup menu for a matrix in IUP and the > documentation mentions IupPopup and IupShowXY but I don't see associated > functions under IUP. Am I missing something? Those are subsumed into "show" (in file iup-base.scm). If the keyword parameter "modal?" is passed a #t then it uses IupPopup, otherwise IupShowXY. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] on ticket 1231
Hi all,
while this patch does fix two bugs in the old code, it introduces a new one.
I'm in the middle of expanding the test case and will soon post a new
patch. (The difference to the patch I attached to ticket 1231 is only
one line - iff I don't find more.)
To make it easier for the reviewers to grok the code, I'll put more
comments into the test case.
For the curious attached my current version of the test.
Best
/Jörg
Am 23.01.2016 um 13:19 schrieb Peter Bex:
> On Fri, Jan 22, 2016 at 07:42:09PM +0100, Jörg F. Wittenberger wrote:
>> Hi all,
>>
>> there is a problem I have with ticket 1231.
>> http://bugs.call-cc.org/ticket/1231
>>
>> In short: I'd love to see the patch applied. (Or learn about issues it
>> causes.)
>
> I hadn't forgotten about the patch, I just didn't get around to it yet,
> and to be honest, I don't really grok this part of the code.
>
> The patch looks good as far as I can see (but like I said, I don't 100%
> grok this code), and I really like the test case, which is clean and
> simple. The test case is what boosted my confidence in it, so I've went
> ahead and signed it off (with a slight reformatting and rewording of the
> commit message, and an update to NEWS). I've attached it.
>
> Whoever pushes this, please also apply this to the CHICKEN 5 srfi-18 egg.
>
> Cheers,
> Peter
>
mutex-test.scm
(require-extension srfi-18)
(define test-has-failed #f)
(define (test-error x . more)
(set! test-has-failed #t)
(apply print x more))
(define (test-exit x)
(set! test-has-failed #t)
x)
#| The mutex data structure.
Slot Type Meaning
1 * name
2 (or boolean (struct thread))
3 (list-of (struct thread)) waiting thread
4 booleanabandoned
5 booleanlocked
|#
(define-record-printer (mutex x out)
(format out ""
(mutex-name x)
(if (##sys#slot x 5) "LOCKED" "FREE")
(if (##sys#slot x 4) "/ABANDONED" "")
(mutex-state x)
(##sys#slot x 3)
))
(define (dbg l v)
(format (current-error-port) "D ~a: ~a\n" l v) v)
(define mux1 (make-mutex 'test-lock-fail-with-timeout))
(mutex-lock! mux1)
(define owner1 (mutex-state mux1))
(thread-join!
(thread-start!
(lambda ()
(assert (eq? (mutex-lock! mux1 0.1) #f))
(when
(memq (current-thread) (##sys#slot mux1 3))
(print "Got " mux1 " found this thread still waiting!\n")
(test-exit 1))
(when
(not (eq? (mutex-state mux1) owner1))
(print "Got " mux1 " state " (mutex-state mux1) " expected " owner1 "\n")
(test-exit 1)
;;
; Make a locked mutex
(define mux (make-mutex 'foo))
(mutex-lock! mux #f #f)
;; Have a thread waiting for it.
(define t1
(thread-start!
(lambda ()
(mutex-lock! mux #f #f)
(when (not (eq? (mutex-state mux) 'not-owned))
(print "Got " mux " state " (mutex-state mux) " expected " 'not-owned "\n")
(test-exit 1)
;; Give it time to actually wait.
(thread-yield!)
;; Let it lock the mux
(mutex-unlock! mux)
(thread-yield!)
(or (eq? (mutex-state mux) 'not-owned)
(test-error "Expected 'not-owned got " (mutex-state mux) mux))
(set! t1
(thread-start!
(lambda ()
(mutex-lock! mux)
(when (not (eq? (mutex-state mux) (current-thread)))
(print "Got " mux " state " (mutex-state mux) " expected " (current-thread) "\n")
(test-exit 1)
(mutex-unlock! mux)
(thread-yield!)
;; check that it is properly abandoned
(when (not (handle-exceptions ex (abandoned-mutex-exception? ex) (and (mutex-lock! mux #f) #f)))
(print "Abandoned Mutex not abandoned " mux "\n")
(test-exit 1))
(mutex-unlock! mux)
(mutex-lock! mux)
(when (not (eq? (mutex-state mux) (current-thread)))
(print "Got " mux " state " (mutex-state mux) " expected " (current-thread) "\n")
(test-exit 1))
(cond-expand (dribble
(define-for-syntax count 0)
(define-syntax trail
(lambda (form r c) ; doesn't bother much with renaming
(let ((loc (cadr form))
(expr (caddr form)))
(set! count (add1 count))
`(,(r 'begin)
(print "(" ,count ") " ,loc ": " ',expr ": get: " (##sys#slot get-mutex 5) ", put: " (##sys#slot put-mutex 5))
(let ((xxx ,expr))
(print " (" ,count ") " ,loc ": " ',expr ": get: " (##sys#slot get-mutex 5) ", put: " (##sys#slot put-mutex 5))
xxx) )
(else (define-syntax trail (syntax-rules () ((_ loc expr) expr)
(define (tprint . x)
(printf "~a " (current-milliseconds))
(apply
[Chicken-users] problem compiling master
Hi, I just recompiled "master" on the raspberrypi. Took forever as expected. But does not work. chicken-install complains about setup-download not avail. How would I figure out what went wrong? Thanks so much /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] PS: problem compiling master
Maybe I should add that the installation updated
setup-download.{import.so, so}
in /usr/local/lib/chcken/8 as expected.
Am 26.01.2016 um 17:59 schrieb Jörg F. Wittenberger:
> Hi,
>
> I just recompiled "master" on the raspberrypi. Took forever as
> expected. But does not work.
>
> chicken-install complains about setup-download not avail.
>
> How would I figure out what went wrong?
>
> Thanks so much
>
> /Jörg
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] PS: problem compiling master
Am 26.01.2016 um 19:24 schrieb Peter Bex:
> On Tue, Jan 26, 2016 at 06:10:18PM +0100, Jörg F. Wittenberger wrote:
>> Maybe I should add that the installation updated
>> setup-download.{import.so, so}
>> in /usr/local/lib/chcken/8 as expected.
>
> Did you fetch master which includes ad5f74dce9e9b5?
yes.
> This fixed a bug in chicken-install -init which caused it
> to not install properly.
>
> I'm not sure if that is what affected you (usually when
> installing it shouldn't), but it might be.
>
> If it takes such a long time it's probably a good idea
> to first test on a faster machine,
Not really avail here.
> or take a look at the
> latest Salmonella runs, and use that specific, known good,
> revision. After all, master is a development version which
> is prone to breaking (though we try hard to avoid it through
> our review process).
I know.
OK. So I better go back before ad5f74dce9e9b5 and try again?
Good to know. Thanks. (Will come back if that does not help.)
>
> Cheers,
> Peter
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] PS: problem compiling master
Am 26.01.2016 um 19:37 schrieb Peter Bex:
> On Tue, Jan 26, 2016 at 07:28:42PM +0100, Jörg F. Wittenberger wrote:
>> Am 26.01.2016 um 19:24 schrieb Peter Bex:
>>> On Tue, Jan 26, 2016 at 06:10:18PM +0100, Jörg F. Wittenberger wrote:
>>>> Maybe I should add that the installation updated
>>>> setup-download.{import.so, so}
>>>> in /usr/local/lib/chcken/8 as expected.
>>>
>>> Did you fetch master which includes ad5f74dce9e9b5?
>>
>> yes.
>
> In that case, stop your recompilation now; it's useless, see below.
Sh*t! I just have to finish that f* project. The re-install was "just
in case". F*
>>> or take a look at the
>>> latest Salmonella runs, and use that specific, known good,
>>> revision. After all, master is a development version which
>>> is prone to breaking (though we try hard to avoid it through
>>> our review process).
>>
>> I know.
>>
>> OK. So I better go back before ad5f74dce9e9b5 and try again?
>
> You already had this commit, and the only additional commit on
> master is one update to the manual, which is just text, no code.
>
> Can you tell us exactly what you did with chicken-install? Any
> particular flags or environment variables?
I did nothing at all.
I tried a recompile from a copy of the latest dir which compiled on my
desktop (which is a "utilite" - no longer supported by Debian and stuck
on updates - f* anyway). Trying any "use whatever" fails (except for
things coming with chicken-core).
Basically nothing is working anymore. (Plus some strange health issue
of mine, which takes the last never I ever had.)
I'm running into all sorts of problem. In between these messages I
tried "make dist" from my last build on the desktop and recompile that
one: "no rule to make debugger-client.scm needed by debugger-client.c"
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] PS: problem compiling master
Am 26.01.2016 um 20:12 schrieb Peter Bex: > On Tue, Jan 26, 2016 at 07:51:49PM +0100, Jörg F. Wittenberger wrote: >>> Can you tell us exactly what you did with chicken-install? Any >>> particular flags or environment variables? >> >> I did nothing at all. > > Without full output and exact command line we can only *guess* at what > went wrong. > >> I tried a recompile from a copy of the latest dir which compiled on my >> desktop (which is a "utilite" - no longer supported by Debian and stuck >> on updates - f* anyway). Trying any "use whatever" fails (except for >> things coming with chicken-core). > > Yeah, one of CHICKEN's strengths is that it has no dependencies, so you > can make it work even on old systems. :-/ If I only could... > >> Basically nothing is working anymore. (Plus some strange health issue >> of mine, which takes the last never I ever had.) > > :( > >> I'm running into all sorts of problem. In between these messages I >> tried "make dist" from my last build on the desktop and recompile that >> one: "no rule to make debugger-client.scm needed by debugger-client.c" > > This sounds like you have some stale files from an earlier build lying > around. Try git clean -f before building to make sure everything from > before is completely gone. OK, will try that next. Git is so great. After having learned that it is the best version control system to shoot myself into the foot (having used most since RCS - SCCS I only read about...) I'm still a bit shy to rely on it. But git has even more options than "ls" so it must be great. "git clean -f" who sent me this one: https://xkcd.com/1597/ ? Probably some Peter. ;-) Right now this xkcd solution "git checkout 5b27c626dcd" is trying to di it's best. Seems to work longer than before. But maybe I'm just not as attentive. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] PS: problem compiling master
OK, great relieve!
git checkout 5b27c626dcd00e7ee4
did at least restore the old functionality (plus pass the mutex-test.scm
from the patch I posted today)
Thanks for the hint about ad5f74dce9e9b - this have saved my day!
Cheers
/Jörg
Am 26.01.2016 um 19:24 schrieb Peter Bex:
> On Tue, Jan 26, 2016 at 06:10:18PM +0100, Jörg F. Wittenberger wrote:
>> Maybe I should add that the installation updated
>> setup-download.{import.so, so}
>> in /usr/local/lib/chcken/8 as expected.
>
> Did you fetch master which includes ad5f74dce9e9b5?
>
> This fixed a bug in chicken-install -init which caused it
> to not install properly.
>
> I'm not sure if that is what affected you (usually when
> installing it shouldn't), but it might be.
>
> If it takes such a long time it's probably a good idea
> to first test on a faster machine, or take a look at the
> latest Salmonella runs, and use that specific, known good,
> revision. After all, master is a development version which
> is prone to breaking (though we try hard to avoid it through
> our review process).
>
> Cheers,
> Peter
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] on ticket 1231
Hi all, there is a problem I have with ticket 1231. http://bugs.call-cc.org/ticket/1231 In short: I'd love to see the patch applied. (Or learn about issues it causes.) Long story: The pigeon-hole egg I recently published looks internally somewhat like the "rewrite it using condition-variables" the source of the mailbox egg suggests. (Ignoring here that it allows for flow control to avoid a fast sender bringing down the whole system by blowing up memory consumption.) Right now the development version (according to the measurements I've been able to create - you know "benchmarks", they always lie) is roughly on par on performance with the mailbox egg. That is: WHEN using `(mutex-lock! #f #f)`. I hesitate to release this code, because I don't want to cause trouble. The released version works around the srfi-18 incompatibility at the cost of ~20% performance loss. Too bad to be ignored. Best /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Documentation for pthreads egg
Am 20.01.2016 um 22:38 schrieb Joe Python: > Where can i get the html docs for the pthreads egg? http://wiki.call-cc.org/eggref/4/pthreads > A link to it would be appreciated. Guess you knew the link before. ;-) I just added some content. > Thank you, > - Jo ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A question regarding "hidden" eggs
Am 20.01.2016 um 10:38 schrieb Kristian Lein-Mathisen: > Hi Jörg, > > I think I may have bumped into similar needs now and again. I suppose one > way of solving this is to clone the henrietta-cache and run this on your > local server. However, I feel that's a little overkill if you just want a > work-in-progress egg to be available with any chicken-install. > > I tried to set up my /usr/local/share/chicken/setup.defaults so that > chicken-install would first try my ~/prj/eggs/ folder, and then use the > server if that doesn't work. I never managed to set it up like that, > though, and I can't recall what went wrong. Would this approach solve your > problems though, Jörg? This addresses another need of mine, which I have not figured out how to solve well. Yes, I'd too like to know how I could configure a local chicken install to ask some self-maintained repository before consulting the official repo. (Though this repo would have to be on the net somewhere, not on the local file system.) But this solves only half the issue. That way I can share code via chicken-install with others who configure their chicken to look for my source. The other one is that in those eggs included in the official coop, I sometimes need temporary work around missing code sequences. I could always literally include them, but that makes a bad source code. I'd rather like to use a "glue-egg". > > K. > > On Mon, Jan 18, 2016 at 2:22 PM, Jörg F. Wittenberger < > joerg.wittenber...@softeyes.net> wrote: > >> Am 18.01.2016 um 14:13 schrieb Christian Kellermann: >>> * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160116 19:35]: >>>> Hi, >>>> >>>> I feel the need to have some space to stash away temporary glue code. >>>> >>> >>> Is this about code you want to be able to chicken-install but noone >>> else should see it? >> >> Precisely. >> >>>> Ideally the current version of it is always empty and not of interest to >>>> anyone. As documentation always lags behind, it is empty with high >>>> probability. However development is not ideal. >>> >>> I don't understand this. >> >> I have some code to be ripped out of context and made available as eggs. >> This code is well tested and comes with dependencies to things I would >> ideally rather replace with code from other eggs. For transition and >> backward compatibility, I want to import some things from the "hidden" >> code. >> >> So it's all deprecated code right from the beginning. >> >>>> Not listing as in being marked as "(hidden)" in the meta file is >>>> apparently what I want. >>> >>> That does not make sense to me, if people can install it but should >>> not use it, what is it good for? >> >> Sure use it. But not only indirect. It should be outright clear and >> obvious that nothing implemented there is supposed to stay and be >> supported in future versions. Nothing will be documented for re-use. I >> don't want anybody to build anything at it an then complain when I >> eventually got around to remove something. >> >>> >>> If it is some code that your published eggs rely on, it will be public >>> in a way. Listing it in an egg index or hide it then does not make a >>> lot of a difference to me. >>> >>> But maybe I misunderstand what you really want to get done. >>> >>> Cheers, >>> >>> Christian >>> >>> >>> -- >>> May you be peaceful, may you live in safety, may you be free from >>> suffering, and may you live with ease. >>> >> >> >> ___ >> Chicken-users mailing list >> Chicken-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/chicken-users >> > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new eggs, pthreads and sqlite3pth
Nah, I did not forget to add that file. Those modifications killed the -emit-type-file from compile. Sure this was still on my machine... Tagged version 0.2.3. salmonella eat it after removing the file. Am 20.01.2016 um 01:16 schrieb Mario Domenech Goulart: > Hello Jörg, > > On Mon, 18 Jan 2016 18:20:50 +0100 Jörg F. Wittenberger > <joerg.wittenber...@softeyes.net> wrote: > >> Done. >> >> sqlite3pth now includes a slightly old version of sqlite3 (3.9.2). >> Should compile with chicken-install. Bonus: basic tests added. > > Nice. Thanks for improving it. > > Installation still fails, though: > >cp: cannot stat 'sqlite3pth.types': No such file or directory > > Maybe you forgot to add this file to the repo? > > Best wishes. > Mario > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] ANN: new egg pigeon-hole
Hi, another egg for the coop: pigeon-hole a pigeon-hole is like a mailbox constrained by capacity. https://raw.githubusercontent.com/0-8-15/pigeon-hole /master/pthreads.release-info Documentation currently only github: https://github.com/0-8-15/pigeon-hole Cheers /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new eggs, pthreads and sqlite3pth
sorry, did not understand what you meant I've been trying to say: it installs manually, just use chicken-install -r and supply a symlink to a sqlite3 build. Then call chicken-install. Let's see how to make it install automatically. Am 18.01.2016 um 14:08 schrieb Christian Kellermann: > * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160118 13:41]: >> OK, if that's the way to go, I'll mimic the pattern from sql-de-lite. >> I just though this would be too much overhead. I was concerned to put >> useless load on the test infrastructure. > > Well at the moment it does not even install, so the test itself is useless(?) > > Kind regards, > > Christian > > -- > May you be peaceful, may you live in safety, may you be free from > suffering, and may you live with ease. > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A question regarding "hidden" eggs
Am 18.01.2016 um 14:13 schrieb Christian Kellermann: > * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160116 19:35]: >> Hi, >> >> I feel the need to have some space to stash away temporary glue code. >> > > Is this about code you want to be able to chicken-install but noone > else should see it? Precisely. >> Ideally the current version of it is always empty and not of interest to >> anyone. As documentation always lags behind, it is empty with high >> probability. However development is not ideal. > > I don't understand this. I have some code to be ripped out of context and made available as eggs. This code is well tested and comes with dependencies to things I would ideally rather replace with code from other eggs. For transition and backward compatibility, I want to import some things from the "hidden" code. So it's all deprecated code right from the beginning. >> Not listing as in being marked as "(hidden)" in the meta file is >> apparently what I want. > > That does not make sense to me, if people can install it but should > not use it, what is it good for? Sure use it. But not only indirect. It should be outright clear and obvious that nothing implemented there is supposed to stay and be supported in future versions. Nothing will be documented for re-use. I don't want anybody to build anything at it an then complain when I eventually got around to remove something. > > If it is some code that your published eggs rely on, it will be public > in a way. Listing it in an egg index or hide it then does not make a > lot of a difference to me. > > But maybe I misunderstand what you really want to get done. > > Cheers, > > Christian > > > -- > May you be peaceful, may you live in safety, may you be free from > suffering, and may you live with ease. > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new eggs, pthreads and sqlite3pth
Done. sqlite3pth now includes a slightly old version of sqlite3 (3.9.2). Should compile with chicken-install. Bonus: basic tests added. Am 18.01.2016 um 13:36 schrieb Christian Kellermann: > * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160118 13:31]: ... > If you rely on a specific version why not bundle it with the egg and > build it? The sql-de-lite egg does so, when no system installation can > be found. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new eggs, pthreads and sqlite3pth
OK, if that's the way to go, I'll mimic the pattern from sql-de-lite. I just though this would be too much overhead. I was concerned to put useless load on the test infrastructure. Am 18.01.2016 um 13:36 schrieb Christian Kellermann: > * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160118 13:31]: >> Am 17.01.2016 um 17:06 schrieb Mario Domenech Goulart: >>... >> As I know there is at least some interest to try this out, maybe you >> could add it anyway. Well figure out how to best make it install out of >> the box then. > > If you rely on a specific version why not bundle it with the egg and > build it? The sql-de-lite egg does so, when no system installation can > be found. > > Kind regards, > > Christian > > -- > May you be peaceful, may you live in safety, may you be free from > suffering, and may you live with ease. > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new eggs, pthreads and sqlite3pth
Am 17.01.2016 um 17:06 schrieb Mario Domenech Goulart:
> Hello Jörg,
> sqlite3pth's installation fails, so I haven't added it yet:
Yeah. That's a known documented limitation.
https://github.com/0-8-15/sqlite3pth
"""(Sorry for this. For this. I can not rely on system installed sqlite
but must be sure to have the exact version. Otherwise the hashes of the
resulting database content will not match and replication break. Patches
for this are very welcome.)"""
I'd greatly welcome suggestions how to overcome this. What can be done
in the .setup file? Or should I include a full build of sqlite3 just to
make the automatic installation work? That looks like an overkill to me.
So far I settled with the idea that this egg would require a manual
download and a symlink to a sqlite3 build (as documented).
As I know there is at least some interest to try this out, maybe you
could add it anyway. Well figure out how to best make it install out of
the box then.
Thanks
/Jörg
>
> $ chicken-install
> retrieving ...
> checking platform for `sqlite3pth' ...
> checking dependencies for `sqlite3pth' ...
> install order:
> ("sqlite3pth")
> installing sqlite3pth: ...
> changing current directory to .
> '/home/mario/local/chicken-4.9.0.1/bin/csi' -bnq -setup-mode -e
> "(require-library setup-api)" -e "(import setup-api)" -e
> "(setup-error-handling)" -e "(extension-name-and-version '(\"sqlite3pth\"
> \"\"))" 'sqlite3pth.setup'
> '/home/mario/local/chicken-4.9.0.1/bin/csc' -feature compiling-extension
> -setup-mode-s -O3 -d2 -J -emit-type-file sqlite3pth.types sqlite3pth.scm
> sqlite/sqlite3.o -L -pthread
> csc: file `sqlite/sqlite3.o' does not exist
>
> Error: shell command failed with nonzero exit status 16384:
>
> '/home/mario/local/chicken-4.9.0.1/bin/csc' -feature compiling-extension
> -setup-mode-s -O3 -d2 -J -emit-type-file sqlite3pth.types sqlite3pth.scm
> sqlite/sqlite3.o -L -pthread
>
>
> Error: shell command terminated with nonzero exit code
> 17920
> "'/home/mario/local/chicken-4.9.0.1/bin/csi' -bnq -setup-mode -e
> \"(require-libr...
>
>
> Best wishes.
> Mario
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: new eggs, pthreads and sqlite3pth
Thanks! Yes. Done. Am 17.01.2016 um 15:17 schrieb Mario Domenech Goulart: > Hi Jörg, ... >> Release-infos: >> >> https://raw.githubusercontent.com/0-8-15/pthreads/master/pthreads.release-info >> >> https://raw.githubusercontent.com/0-8-15/sqlite3pth/master/sqlite3pth.release-info > > The repositories don't have the tags referenced by .release-info files > (forgot to push --tags?) > > Best wishes. > Mario > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] ANN: new eggs, pthreads and sqlite3pth
Hi all, two new eggs for the coop. Beware: requires recent chicken from git master to run reliably. pthreads: maintains a pool of pthreads sqlite3pth: yet another sqlite3 driver. Offloads sqlite queries to pthreads. Supports sqlite3 VFS to call back to chicken for blocks. Documentation is currently only at github: https://github.com/0-8-15/sqlite3pth not very interesting, just a dependency for the former: https://github.com/0-8-15/sqlite3pth Release-infos: https://raw.githubusercontent.com/0-8-15/pthreads/master/pthreads.release-info https://raw.githubusercontent.com/0-8-15/sqlite3pth/master/sqlite3pth.release-info Have fun /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] A question regarding "hidden" eggs
Hi, I feel the need to have some space to stash away temporary glue code. Ideally the current version of it is always empty and not of interest to anyone. As documentation always lags behind, it is empty with high probability. However development is not ideal. Not listing as in being marked as "(hidden)" in the meta file is apparently what I want. Q: Would creating an egg at https://github.com/0-8-15/9-3 and informing @Mario be the way to go? Thanks /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] SRFI-1 egg
I always was sooo keen to write something nobody needs. ;-) And as if the uselessness wasn't enough, I'm even cross-posting this message to chicken-hackers! Here another egg for the coop: http://askemos.org/chicken-eggs/srfi-1.release-info tarball: http://askemos.org/chicken-eggs/srfi-1.srfi-1-1.0.0.tar.gz Why? Because there is some ongoing effort to drop srfi-1 from CHICKEN core and I already went to the hassle to do most of the eggification labor for an unrelated reason. Issues: * There needs to be at least one more version because we need to drop the "egg-" prefix. * @Mario: how should we list this? Right now nobody wants to know about it, except for those working on dropping srfi-1 from core. * This comes under the name of "srfi-1" but installs as "egg-srfi-1". chicken-install naturally handles this when called from within the directory. No idea how badly it might break when it downloads "srfi-1" but does not find a "srfi-1.meta" inside the tarball. * @Mario: I tried it under the intended name "srfi-1". This kills salmonella during install: Installing.. Error: string buffer full: # * When installed under the name of "srfi-1" it installs but does not work (and requires re-installation of chicken to fix): #;1> (use srfi-1) ; loading /home/u/build/test//lib/chicken/8/srfi-1.import.so ... ; loading /home/u/build/test//lib/chicken/8/chicken.import.so ... ; loading library srfi-1 ... #;2> (xcons 1 2) Error: unbound variable: srfi-1#xcons ((Sure it works under the name "egg-srfi-1".)) /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Need help to figure out where this strange performance impact is coming from
Am 13.01.2016 um 21:46 schrieb Christian Kellermann: > * Christian Kellermann <ck...@pestilenz.org> [160113 21:44]: >> * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160113 12:38]: >>> yesterday I found that simply having a (use mailbox) in some code had a >>> huge impact (more than a factor of 3) at the performance of the >>> resulting executable. Without using the mailbox stuff at all. >>> >>> Meanwhile I figured out that this has nothing at all to do with the >>> mailbox egg. But _all_ with the use of srfi-1. >> >> Hm which OS and architecture are you running this on? On my OpenBSD >> amd64 system the two versions do fluctuate but are indistinguishable >> when run a couple hundred times. Really?! Commenting out this (use srfi-1) does not make a difference there? Strange! I just double-checked with chicken rev 022dce82 (master built yesterday). (Before I used rev 274e7afa.) Additionally I tried now chicken 4.10.1 built from the tarball distributed from call-cc.org. (I moved the installed version out of the way for this test.) All the same result: slowdown of roughly 4x (160:40). OS: Debian stretch, ARMv7 Processor rev 10 Another try: Raspberry Pi, Raspberian. Similar results, about 60:20 >> I have used CHICKEN Version 4.10.1 (rev f36c19c) and compiled with >> default options. Used default option this time. (But see source - contains some declarations). > Also -O5 does not make any difference. Same here. Same strange slowdown. Anybody else having another platform to try on? An ARM-related problem? ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Need help to figure out where this strange performance impact is coming from
Tried that too: on AMD64 (Debian) chicken 4.10.1 from tarball does NOT give any difference. But even if it may be an ARM related problem: how is it even possible??! Am 14.01.2016 um 11:10 schrieb Jörg F. Wittenberger: > Am 13.01.2016 um 21:46 schrieb Christian Kellermann: >> * Christian Kellermann <ck...@pestilenz.org> [160113 21:44]: >>> * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160113 12:38]: >>>> yesterday I found that simply having a (use mailbox) in some code had a >>>> huge impact (more than a factor of 3) at the performance of the >>>> resulting executable. Without using the mailbox stuff at all. >>>> >>>> Meanwhile I figured out that this has nothing at all to do with the >>>> mailbox egg. But _all_ with the use of srfi-1. >>> >>> Hm which OS and architecture are you running this on? On my OpenBSD >>> amd64 system the two versions do fluctuate but are indistinguishable >>> when run a couple hundred times. > > Really?! Commenting out this (use srfi-1) does not make a difference > there? Strange! > > I just double-checked with chicken rev 022dce82 (master built > yesterday). (Before I used rev 274e7afa.) > > Additionally I tried now chicken 4.10.1 built from the tarball > distributed from call-cc.org. (I moved the installed version out of the > way for this test.) > > All the same result: slowdown of roughly 4x (160:40). > > OS: Debian stretch, ARMv7 Processor rev 10 > > Another try: Raspberry Pi, Raspberian. Similar results, about 60:20 > >>> I have used CHICKEN Version 4.10.1 (rev f36c19c) and compiled with >>> default options. > > Used default option this time. (But see source - contains some > declarations). > >> Also -O5 does not make any difference. > > Same here. Same strange slowdown. > > Anybody else having another platform to try on? An ARM-related problem? > > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Need help to figure out where this strange performance impact is coming from
WEIRD!! Still somebody having another architecture available is needed to track this further down. However I got more infos to share: Wild guess: this may be some alignment problem. It does _not_ have to do with anything to do with srfi-1. It just needs to have *enough* exports in the program. The story so far: Profiling with srfi-1 pulled inline did reveal no calls to srfi-1. Turned the inlined srfi-1 into a module with no exports -> slow down. Export * -> full speed. Binary search cutting the export list -> slow down when less then 17 bindings exported. Does not matter which 17 bindings. Rewrote the test to not import "extras" -> still fast. Removed the "(use extras)" -> slow down. Use random egg exporting many bindings instead -> fast again. Weird. Am 14.01.2016 um 12:12 schrieb Christian Kellermann: > * Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> [160114 11:30]: >> Tried that too: on AMD64 (Debian) chicken 4.10.1 from tarball does NOT >> give any difference. >> >> But even if it may be an ARM related problem: how is it even possible??! > > So next let's isolate whether it's the architecture (ARM > vs. world)type or the word size (32bit vs 64bit). Can anyone with a > 32bit system try that please? > > Thanks, > > Christian > > -- > May you be peaceful, may you live in safety, may you be free from > suffering, and may you live with ease. > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] need suggestion when eggifying srfi-1
Hi all, as I accidentally had a reason to touch srfi-1 and make a module out of it, I went on to complete it's eggification. Mostly that is. Two questions: a) the category should probably be "lang-exts", correct? b) I'm pretty sure salmonella will complain and the rest being confused if I simply name it "srfi-1" as I'd prefer out of principle. So how should I name it? "lipro", "olin-shivers-list-processing-aka-srfi-1" ;-) Thanks /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] SRFI-1 egg
Sadly it's not on any documentation page. Could have saved me some quite time if I had known. (Not only the packaging, also while debugging the strange issue about "not enough top level binding to take the fast path" -- whatever that one is actually caused by.) How would I find out? Am 14.01.2016 um 19:13 schrieb Mario Domenech Goulart: > Hi Jörg, > > On Thu, 14 Jan 2016 19:01:33 +0100 Jörg F. Wittenberger > <joerg.wittenber...@softeyes.net> wrote: > >> I always was sooo keen to write something nobody needs. ;-) >> >> And as if the uselessness wasn't enough, I'm even cross-posting this >> message to chicken-hackers! >> >> Here another egg for the coop: >> >> http://askemos.org/chicken-eggs/srfi-1.release-info >> tarball: >> http://askemos.org/chicken-eggs/srfi-1.srfi-1-1.0.0.tar.gz >> >> >> Why? Because there is some ongoing effort to drop srfi-1 from CHICKEN >> core and I already went to the hassle to do most of the eggification >> labor for an unrelated reason. > > Actually, srfi-1 has been removed from the core in the chicken-5 branch > and is an egg in the SVN repo (see release/5/srfi-1). There is no plan > to remove srfi-1 from CHICKEN 4 core, as far as I can tell. > > Best wishes. > Mario > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Need help to figure out where this strange performance impact is coming from
Hi Chickeneers, yesterday I found that simply having a (use mailbox) in some code had a huge impact (more than a factor of 3) at the performance of the resulting executable. Without using the mailbox stuff at all. Meanwhile I figured out that this has nothing at all to do with the mailbox egg. But _all_ with the use of srfi-1. But how is this possible? Attached some test code. As I ran into it from mailbox I prepared a stripped down version of it to play with. Towards the end of the file there is a (use srfi-1) which makes all the difference. So far I found (compiling the code with -O5 but similar things happen with less aggressive optimization): a) Using chicken 4.9.1 there is absolutely no difference. Using srfi-1 or not I get roughly 100 messages passed per ms on my machine. (But I have to include the forced gc; see comment in the code.) b) A slightly different version which avoids allocations in the queue runs without the forced gc and yields about 160 ms^-1 on chicken 4.9.1 Again no difference whether or not I (use srfi-1) anywhere. Now the interesting bits: c) On master (built almost two weeks ago) I get - when (use srfi-1) is included - about 180 ms^-1. Those ~5% faster sound about right to me. d) Comment out the (use srfi-1) at line 163 and it goes down to about _50_ per millisecond! e) The same happens for the alternative, allocation free version (not attached), which uses vectors instead of pairs. Speculating: The code I wrote has nothing to do with the difference. But I'm confused. Neither scheduler.scm nor srfi-18 seem to have any dependency on srfi-1. Also srfi-1 seems not to overwrite any global bindings. Should we simply always (use srfi-1) if we also (use srfi-18). Looks like a workaround, but not like the right thing to do. How could I boil this down to the real reason? Best /Jörg (declare ;;(unit mailbox) ;; requirements (disable-interrupts) ;; promises (strict-types) (usual-integrations) (no-procedure-checks-for-usual-bindings) (inline) (local) (no-bound-checks) (no-procedure-checks-for-usual-bindings) (bound-to-procedure ##sys#schedule ##sys#current-exception-handler) (always-bound ##sys#current-thread) ) (module mailbox3 ( make-mailbox mailbox? mailbox-empty? mailbox-send! mailbox-receive! ) (import scheme extras srfi-18) (import (except chicken add1 sub1)) (: mailbox? (* --> boolean : (struct ))) (define-record-type (internal-make-mailbox condition head tail pred) mailbox? (condition %mailbox-condition) (head %mailbox-head %mailbox-head-set!) (tail %mailbox-tail %mailbox-tail-set!) (pred mailbox-predicate)) (cond-expand (never (define-inline (mailbox-condition mb) (%mailbox-condition mb)) (define-inline (mailbox-head mb) (%mailbox-head mb)) (define-inline (mailbox-head-set! mb v) (%mailbox-head-set! mb v)) (define-inline (mailbox-tail mb) (%mailbox-tail mb)) (define-inline (mailbox-tail-set! mb v) (%mailbox-tail-set! mb v))) (else (define-inline (mailbox-condition mb) (##sys#slot mb 1)) (define-inline (mailbox-head mb) (##sys#slot mb 2)) (define-inline (mailbox-head-set! mb v) (##sys#setslot mb 2 v)) (define-inline (mailbox-tail mb) (##sys#slot mb 3)) (define-inline (mailbox-tail-set! mb v) (##sys#setslot mb 3 v)) )) (: make-mailbox (* --> (struct ))) (define (make-mailbox name) (let ((x (cons #f '( (internal-make-mailbox (make-condition-variable name) x x #f))) (: mailbox-empty? ((struct ) --> boolean)) (define (mailbox-empty? mb) (null? (cdr (mailbox-head mb (: mailbox-number-of-items ((struct ) -> fixnum)) (define (mailbox-number-of-items mb) (length (cdr (mailbox-head mb (define-inline (%dequeue-message mb) (mailbox-head-set! mb (##sys#slot #;cdr (mailbox-head mb) 1)) (##sys#slot #;car (mailbox-head mb) 0)) (: mailbox-send! ((struct ) * -> undefined)) (define (mailbox-send! mailbox obj) (let ((p (cons obj '( (##sys#setslot #;set-cdr! (mailbox-tail mailbox) 1 p) (mailbox-tail-set! mailbox p)) #;(condition-variable-signal! (mailbox-condition mailbox)) (let ((x (mailbox-condition mailbox))) (if (thread? x) (thread-resume! x))) ) (: mailbox-receive! ((struct ) -> *)) (define (mailbox-receive! mailbox) ;;(dbg "receive-message! ~a ~a ~a" (current-thread) (mailbox-name mailbox) (##sys#slot (mailbox-condition mailbox) 2)) (let loop () (if (null? (##sys#slot (mailbox-head mailbox) 1)) (begin (##sys#setslot mailbox 1 ##sys#current-thread) (thread-suspend! ##sys#current-thread) (##sys#setslot mailbox 1 #f) (loop)) (let ((obj (%dequeue-message mailbox))) obj ) ;; module mailbox (module test (test-run) (import scheme chicken srfi-18 extras) (import mailbox3) ;;(include "bench.scm") ;;-- (define mb (make-mailbox 'm0)) (define turns 100) (define tw (make-thread (lambda () (do ((i 0 (add1 i))) ((= i turns)) (mailbox-send! mb i) ;; Must be active for my
Re: [Chicken-users] Need help to figure out where this strange performance impact is coming from
Hi Dan & chicken-hackers, thanks for your reply. I'm really curious how to explain these findings. Complying with your suggestion, I'm sending this time to chicken-hackers this time too. I've been hoping enough of them would read chicken-users too. For reference to those who missed the initial posting, the message (with attachment) is here: http://lists.nongnu.org/archive/html/chicken-users/2016-01/msg00033.html Am 13.01.2016 um 18:32 schrieb Dan Leslie: > IIRC, there's been ongoing efforts to remove SRFI-1 from core; which may > explain your observations regarding Master. I'm aware of that and checked the relevant git history before I posted. After all that's been my first guess too. But my digging did not yield any hints. Looks like this is going on in it's own branch. Another wild guess of mine was "maybe specializations?". That's why the (use srfi-1) is close to the end of the file. (Even though I'm not completely sure that's enough.) > Perhaps you should consider asking Chicken Hackers? > > -Dan > > Original Message > From: Jörg F. Wittenberger > Sent: Wednesday, January 13, 2016 3:38 AM > To: chicken-users > Subject: [Chicken-users] Need help to figure out where this strange > performance impact is coming from > > Hi Chickeneers, > > yesterday I found that simply having a (use mailbox) in some code had a > huge impact (more than a factor of 3) at the performance of the > resulting executable. Without using the mailbox stuff at all. > > Meanwhile I figured out that this has nothing at all to do with the > mailbox egg. But _all_ with the use of srfi-1. > > But how is this possible? > > Attached some test code. As I ran into it from mailbox I prepared a > stripped down version of it to play with. Towards the end of the file > there is a (use srfi-1) which makes all the difference. > > So far I found (compiling the code with -O5 but similar things happen > with less aggressive optimization): > > a) Using chicken 4.9.1 there is absolutely no difference. Using srfi-1 > or not I get roughly 100 messages passed per ms on my machine. (But I > have to include the forced gc; see comment in the code.) > > b) A slightly different version which avoids allocations in the queue > runs without the forced gc and yields about 160 ms^-1 on chicken 4.9.1 > Again no difference whether or not I (use srfi-1) anywhere. > > Now the interesting bits: > > c) On master (built almost two weeks ago) I get - when (use srfi-1) is > included - about 180 ms^-1. Those ~5% faster sound about right to me. > > d) Comment out the (use srfi-1) at line 163 and it goes down to about > _50_ per millisecond! > > e) The same happens for the alternative, allocation free version (not > attached), which uses vectors instead of pairs. > > > Speculating: The code I wrote has nothing to do with the difference. > > But I'm confused. Neither scheduler.scm nor srfi-18 seem to have any > dependency on srfi-1. Also srfi-1 seems not to overwrite any global > bindings. > > Should we simply always (use srfi-1) if we also (use srfi-18). Looks > like a workaround, but not like the right thing to do. > > How could I boil this down to the real reason? > > Best > > /Jörg > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] ANN: new egg "forcible"
Hi all, there is a new egg "forcible" to be added to the coop: http://askemos.org/chicken-eggs/forcible.release-info documentation at http://wiki.call-cc.org/eggref/4/forcible It was born out of frustration that `delay` (and srfi-45 `lazy`) will actually evaluate the expression multiple times (if either the evaluation is still running while forced from another thread or run into an exception). Thus lazy algorithms are actually not that lazy. This one makes sure evaluation happens just once. This is essentially srfi-45 for use in conjunction with srfi-18 plus some more synchronization primitives: * `future` and `lazy-future`, which are like "delay" but the expression is evaluated in it's own thread, whereby lazy-future does not start the thread immediately, `demand` will start such a thread but not `force` the result. `force` will start and join the thread. * `force` is extended to accept an optional second argument, an exception handler. Thus you don't need to wrap the call to `force` if you need to catch those exceptions. * `expectable` creates a promise and a procedure to fulfil it. Feedback welcome. Best Regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Eggs metafile needs another property - doesn't it?
Hi all, I need to specify a certain - not yet available - version of chicken itself as the minimum requirement for an egg to work for real. (((Backgground: Hacking away on this RPi gpio egg I created a version which exacerbates an issue I fixed the other day - see ticket 1232. To improve at the real-time behavior there is a real-time thread doing nothing but wait for signal delivery. – Is there a better way to do this??? – Now signals are more or less sure to arrive _not_ at the chicken thread, which will mess up the memory management.))) As this is not the only egg not working for older chicken versions I guess we should have a property like `min-chicken-version` to make sure users do not get trapped. Any thoughts? Best Regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] another egg
Hi all, for the time being (as we shall not have yet another gpio egg). There is a 1.1.0 version of the raspberry-pi-gpio-small egg now here: http://askemos.org/chicken-eggs/raspberry-pi-gpio-small.release-info latest source here: http://askemos.org/chicken-eggs/raspberry-pi-gpio-small/raspberry-pi-gpio-small.tar.gz This one changes the API in a backward compatible way (see the README). The important part: the pin values and the time when the interrupt occurred are now obtained within the interrupt service routine. This gives much better precision. Also I observed that it is all too easy to read the wrong value from the pin, since it may change multiple times during the delay between the interrupt time and CHICKEN eventually handling it. Best /Jörg Am 05.01.2016 um 11:20 schrieb Caolan McMahon: >> If you like those changes, please pull them in. This would have the >> advantage to reduce clutter/pollution of the eggs listing. >> >> Pls. notify the list. If you pull those changes in Mario should _not_ >> include mine into the coop as it would become obsolete soon. If you >> don't I'd ask for inclusion into the coop anyways. > > Sounds good, I'll pull in your changes rather than us adding more gpio > eggs. Reducing the dependencies alone is worth doing since I expect > many people will just compile on the raspberry pi rather than set up a > cross-compiler. Please could you email me a git format-patch? ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Eggs metafile needs another property - doesn't it?
Argh, wait... Am 05.01.2016 um 21:09 schrieb Jörg F. Wittenberger: > Hi all, > > I need to specify a certain - not yet available - version of chicken > itself as the minimum requirement for an egg to work for real. as I sent the message I re-read http://wiki.call-cc.org/Metafile%20reference once more and stumbled upon what I've been looking for: (platform ID ...) using `chicken-4.11` should do the trick, shouldn't it? Sorry for the noise. > (((Backgground: Hacking away on this RPi gpio egg I created a version > which exacerbates an issue I fixed the other day - see ticket 1232. To > improve at the real-time behavior there is a real-time thread doing > nothing but wait for signal delivery. – Is there a better way to do > this??? – Now signals are more or less sure to arrive _not_ at the > chicken thread, which will mess up the memory management.))) > > As this is not the only egg not working for older chicken versions I > guess we should have a property like `min-chicken-version` to make sure > users do not get trapped. > > Any thoughts? > > Best Regards > > /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] another egg
Hi Coalan,
other users (especially egg authors) please read on, most of this
message is intended for you, not so much addressing Coalan.
Am 04.01.2016 um 15:54 schrieb Caolan McMahon:
> Hey Jörg,
>
> Thanks for the updates.
Great to learn that you are still around here and caring for the egg.
If you like those changes, please pull them in. This would have the
advantage to reduce clutter/pollution of the eggs listing.
Pls. notify the list. If you pull those changes in Mario should _not_
include mine into the coop as it would become obsolete soon. If you
don't I'd ask for inclusion into the coop anyways.
> I think I probably found things more
> complicated writing this module because of wiring-pi calling callbacks
> from other threads (hence pulling in concurrent-native-callbacks etc).
At least you found out that you need to use concurrent-native-callbacks!
(((What I did is just a very light weight, specialized
implementation of the same concept. Plus: drop the use of the
eggs you summarized under the "etc" lable.)))
After all use of `define-external` and superficial testing might have
left you with the impression that this would have been good enough.
NB: 1st point I'm stressing that here to raise QA awareness wrt. other
egg authors, since I've been bitting by that one elsewhere before.
However: I do not (yet) understand why you mean by "other threads" in
this context. Other pthreads or other srfi-18 threads from CHICKEN? If
the latter: I fail to see so far how this could come into play. (Am I
missing something?) If the former: that would be the same as with
signal handler callable from any other thread. See the related ticket
http://bugs.call-cc.org/ticket/1232 which is open at this time. The use
of concurrent-native-callbacks should – according to my understanding
chicken-hackers pls. correct me if I'm wrong at that – NOT actually
effect/fix this. (But may appear to do so under circumstances/by chance
as it changes to much of the code CHICKEN produces.)
> I'm currently using this library without hitting the 'case' issue you
> pointed out...
This begs the (academic) how that's possible that this did work for you.
To illustrate "case misuse" issue at hand:
The code which did not work for me (and which I called "obviously
wrong") looked like this:
(case
(('a) 1)
(('b) 2)
(else (error "s*t")))
while the – let's call it "correct" version would be:
(case
((a) 1)
((b) 2)
(else (error "s*t")))
Which is: you should NOT quote the symbols in `case` (here 'a and 'b) in
case if you want to compare to those symbol.
> not the first obviously broken code I've had 'work' in
> CHICKEN 4.10. Starting to think I'm losing it!
@chicken-hackers: How does it come this is working for Coalan? I'm
using "master" from three days ago, which is something like 4.10.1. But
I doubt there are any recent changes related.
@-users: After all: Scheme as a tradition of being a GIGO-language.
(Garbage-In-Garbage-Out) Thus "broken code" often has undefined
results. It MAY be working anyway.
/Jörg
> Caolan
>
> On 4 January 2016 at 13:27, Jörg F. Wittenberger
> <joerg.wittenber...@softeyes.net> wrote:
>>
>>
>> Hi all,
>>
>> yet another egg I put together, which may be interesting to you (and may
>> go the coop):
>>
>> http://askemos.org/chicken-eggs/raspberry-pi-gpio-small.release-info
>>
>> This is a (supposed to be) API compatible version of the
>> raspberry-pi-gpio egg.
>>
>> Maybe these modifications should simply be folded into the latter.
>> That's a matter of choice. (A choice left to Caolan McMahon, the author
>> of the latter.)
>>
>> Why did I feel the alternative may be good?
>>
>> * The `-small` suffix was chosen because of the reduced dependency list:
>> no dependencies except for CHICKEN core.
>>
>> * Throwing together those modifications took me about as much wall clock
>> time as chicken-install spent on installing the original one including
>> those dependencies.
>>
>> * Roughly half the code size.
>>
>> * Not jumping through various call should always be faster than doing
>> so. Thus I'd _expect_ less runtime overhead, which may be important
>> when controlling sensors.
>>
>> * Not needing those dependencies should make debugging simpler.
>>
>> (* Besides: I wonder how the original could ever have worked. The
>> example from the documentation runs into >>Error: uncaught exception:
>> "Unknown mode"<< for an obvious misuse of `case`.)
>>
>> Have fun
>>
>> /Jörg
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] another egg
Hi all, yet another egg I put together, which may be interesting to you (and may go the coop): http://askemos.org/chicken-eggs/raspberry-pi-gpio-small.release-info This is a (supposed to be) API compatible version of the raspberry-pi-gpio egg. Maybe these modifications should simply be folded into the latter. That's a matter of choice. (A choice left to Caolan McMahon, the author of the latter.) Why did I feel the alternative may be good? * The `-small` suffix was chosen because of the reduced dependency list: no dependencies except for CHICKEN core. * Throwing together those modifications took me about as much wall clock time as chicken-install spent on installing the original one including those dependencies. * Roughly half the code size. * Not jumping through various call should always be faster than doing so. Thus I'd _expect_ less runtime overhead, which may be important when controlling sensors. * Not needing those dependencies should make debugging simpler. (* Besides: I wonder how the original could ever have worked. The example from the documentation runs into >>Error: uncaught exception: "Unknown mode"<< for an obvious misuse of `case`.) Have fun /Jörg ___ Chicken-hackers mailing list chicken-hack...@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Any decent web development framework
There are many, each having it's own strength. It really depends on
what you are looking for.
I'm using ball.askemos.org . (Actually much of it I wrote.)
Now this was originally done in rscheme about 15yrs ago. It's not
monolithic, but consists of communicating actors/agents (which may be
owned/controlled by different individuals, no central admin there). In
addition to Scheme you may use XSLT with mixed/embedded with Scheme and
SQL. Each agent has it's very own sqlite database.
But actually it never was designed to be a Web dev framework. It was
meant to be a framework for "smart contracts". Thus those agent, their
database (including sqlite3) etc. are stored in a Merkle tree and may be
replicated with byzantine fault tolerance in a network. Each node
acting as registry and escrow, executing (Scheme) script and checking
the work of other nodes.
Much faster and older than Ethereum and ripple. But done too early.
Completely unknown.
Am 27.12.2015 um 16:56 schrieb 机械唯物主义 : linjunhalida:
> Hi scheme users,
>
> I'm a rails programmer, and knows scheme long time ago but don't have
> chance to write scheme code in production level. I want to use scheme
> for website development but it turns out there is no decent framework
> for web development in chicken.
>
> Is there any recommendations? awful is not very useful.
> Any library same as Rails or Sinatra?
>
> Sinatra writes like this:
>
> (get "/" (lambda (request) "hello")
> (get "/from/:id" (lambda (request) (sprintf "hello ~A" (request 'id
> (get "/page/:id" (lambda (request)
> (let ((data ($query (from pages) (where (= id (request 'id))
> (render "templates/page" ('data data
>
> Thanks.
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Dectecting disable-interrupts at compile time
Hi, I'd like to cond-expand code depending on whether or not the code is compiled with interrupts disabled. Is there a feature I can test? (Can't find any. Did I miss it?) Thanks /Jörg PS: Currently I use my own feature to cond-expand into a declaration to disable interrupts. But the problem at hand: there is a feature, which is unavailable when interrupts are disabled. And the latter could be the case because of command line arguments, no matter what my own feature tried to assert. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg: hopefully
Am 19.12.2015 um 23:31 schrieb Sudarshan S Chawathe: > Thanks for the update. I see the same behavior with tests/run.scm as > before: Compilation with csc is fine, but executing the resulting file > 'run' gives exactly the same error as before: > > Error: assertion failed: (= (obox-v b1) 455) > > (Detailed error message is same as in my earlier message.) Hm, that's strange. I blindly assumed this to somehow follow from the import gone wrong. Now I did no do much yesterday but re-run this over and over again to tune the implementation. Neither on 4.9.1 or master. Could you please _replace_ the let form in run.scm starting around line 217 with the one below and try. Should give me more details. The expected output: D #: also in other thread former ref is still unchanged... D even after commit. (Note: tests caching of references to fields.): 9 T2 x cc 2 6 T1 x cc 2 7 T2 y cc 2 7 T2 done cc 2 65 T1 y cc -2 6 T1 done cc -2 42 T1 x cc -3 7 T1 y cc -3 65 T1 done cc -3 455 D M1: not-owned D M2: not-abandoned Locking 2 op in 1530.0 ms (13.0718954248366 op/ms) Optimistic 2 op in 1324.0 ms (15.1057401812689 op/ms) Thanks for your help. /Jörg Here the more verbose test expression: (let ((mux1 (make-mutex 'T1)) (mux2 (make-mutex 'T2)) (call-count 0)) (define (step! msg mux1 mux2 val) (mutex-unlock! mux1) (if (and mux2 (> call-count 0) (< call-count 100)) (mutex-lock! mux2 #f #f)) (if msg (format (current-error-port) "~a cc ~a ~a\n" msg call-count val)) val) (mutex-lock! mux1 #f #f) (mutex-lock! mux2 #f #f) (thread-start! (lambda () (call-with-transaction (lambda (tnx) (if (>= call-count 0) (set! call-count (add1 call-count)) (set! call-count (sub1 call-count))) (if (< call-count 100) (let ((a (obox-v-ref b2 tnx)) (b (obox-v-ref b1 tnx))) ;; Normally one should never do this. We enforce thread ;; switches during transaction. (alter! a (let* ((x (step! "T2 x" mux1 mux2 (cell-ref a))) (y (step! "T2 y" mux1 mux2 (cell-ref b (+ 23 (* x y (step! "T2 done" mux1 #f (cell-ref a))) (step! "T2 call count exceeded" mux1 #f call-count (set! call-count (- call-count (call-with-transaction (lambda (tnx) (if (>= call-count 0) (set! call-count (add1 call-count)) (set! call-count (sub1 call-count))) (let ((a (obox-v-ref b1 tnx)) (b (obox-v-ref b2 tnx))) (alter! a (let* ((x (step! "T1 x" mux2 mux1 (cell-ref a))) (y (step! "T1 y" mux2 mux1 (cell-ref b (* x y))) (step! "T1 done" mux2 #f (cell-ref a) (assert (= call-count -3)) ;; -- not defined to be -3, but normally (dbg 'M1 (mutex-state mux1)) (dbg 'M2 (mutex-state mux2)) (assert (= (obox-v b1) 455)) (assert (= (obox-v b2) 65))) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg: hopefully
Am 20.12.2015 um 15:50 schrieb Sudarshan S Chawathe: > > Thanks for following up. I hope the cause isn't something silly in my > setup. > > I ran tested with a run.scm modified as you indicated, except that I'm > guessing you meant line 127, not 217. (I couldn't find any obvious Yes, 127 is correct. ;-) > match on line 217, so I replaced the one starting on line 127.) The > results are attached. It fails the assertion: > > (assert (= call-count -3)) This, and your'e getting a different execution sequence and all. Now this assert used to be commented out, since it's not by definition, but expected. I currently do not understand why T2 is not winning the race. Could you ignore that please for a moment (comment out). I'm interested in the mutex's state. Also please insert a thread-sleep! right after those debug prints, so we see what T2 is doing here. Like so (first and last line unchanged): (step! "T1 done" mux2 #f (cell-ref a) ;;(assert (= call-count -3)) ;; -- not defined to be -3, but normally (dbg 'M1 (mutex-state mux1)) (dbg 'M2 (mutex-state mux2)) (thread-sleep! 1) (assert (= (obox-v b1) 455)) > > Regards, > > -chaw > >> From: joerg.wittenber...@softeyes.net >> Date: Sun, 20 Dec 2015 15:07:17 +0100 >> Subject: Re: [Chicken-users] New egg: hopefully >> >> Am 19.12.2015 um 23:31 schrieb Sudarshan S Chawathe: >>> Thanks for the update. I see the same behavior with tests/run.scm as >>> before: Compilation with csc is fine, but executing the resulting file >>> 'run' gives exactly the same error as before: >>> = >> >>> Error: assertion failed: (=3D (obox-v b1) 455) >>> = >> >>> (Detailed error message is same as in my earlier message.) >> >> Hm, that's strange. I blindly assumed this to somehow follow from the >> import gone wrong. >> >> Now I did no do much yesterday but re-run this over and over again to >> tune the implementation. Neither on 4.9.1 or master. >> >> Could you please _replace_ the let form in run.scm starting around line >> 217 with the one below and try. Should give me more details. >> >> The expected output: >> >> D #: also in other thread former ref is still >> unchanged... >> D even after commit. (Note: tests caching of references to fields.): 9 >> T2 x cc 2 6 >> T1 x cc 2 7 >> T2 y cc 2 7 >> T2 done cc 2 65 >> T1 y cc -2 6 >> T1 done cc -2 42 >> T1 x cc -3 7 >> T1 y cc -3 65 >> T1 done cc -3 455 >> D M1: not-owned >> D M2: not-abandoned >> Locking 2 op in 1530.0 ms (13.0718954248366 op/ms) >> Optimistic 2 op in 1324.0 ms (15.1057401812689 op/ms) >> >> Thanks for your help. >> >> /J=F6rg >> >> Here the more verbose test expression: >> >> (let ((mux1 (make-mutex 'T1)) (mux2 (make-mutex 'T2)) >> (call-count 0)) >> (define (step! msg mux1 mux2 val) >> (mutex-unlock! mux1) >> (if (and mux2 (> call-count 0) (< call-count 100)) (mutex-lock! mux2 >> #f #f)) >> (if msg (format (current-error-port) "~a cc ~a ~a\n" msg call-count >> val)) >> val) >> (mutex-lock! mux1 #f #f) >> (mutex-lock! mux2 #f #f) >> (thread-start! >>(lambda () >> (call-with-transaction >> (lambda (tnx) >> (if (>=3D call-count 0) (set! call-count (add1 call-count)) >> (set! call-count (sub1 call-count))) >> (if (< call-count 100) >> (let ((a (obox-v-ref b2 tnx)) >>(b (obox-v-ref b1 tnx))) >>;; Normally one should never do this. We enforce thread >>;; switches during transaction. >>(alter! >> a >> (let* ((x (step! "T2 x" mux1 mux2 (cell-ref a))) >> (y (step! "T2 y" mux1 mux2 (cell-ref b >> (+ 23 (* x y >>(step! "T2 done" mux1 #f (cell-ref a))) >> (step! "T2 call count exceeded" mux1 #f call-count >> (set! call-count (- call-count >> (call-with-transaction >>(lambda (tnx) >> (if (>=3D call-count 0) (set! call-count (add1 call-count)) >>(set! call-count (sub1 call-count))) >> (let ((a (obox-v-ref b1 tnx)) >> (b (obox-v-ref b2 tnx))) >>(alter! >> a >> (let* ((x (step! "T1 x" mux2 mux1 (cell-ref a))) >>(y (step! "T1 y" mux2 mux1 (cell-ref b >>(* x y))) >>(step! "T1 done" mux2 #f (cell-ref a) >> (assert (=3D call-count -3)) ;; -- not defined to be -3, but normally >> (dbg 'M1 (mutex-state mux1)) >> (dbg 'M2 (mutex-state mux2)) >> (assert (=3D (obox-v b1) 455)) >> (assert (=3D (obox-v b2) 65))) > > > > ___ > Chicken-users mailing list > Chicken-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-users > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg: hopefully
Am 18.12.2015 um 23:37 schrieb Sudarshan S Chawathe:
> Thanks for the updated pointer to the source.
>
> I installed the egg in the usual way ('chicken-install' in the directory
> with the source files) but could not run the included test
> (test/run.scm) successfully, although csc compiles it fine. (Details
> below.) In interactive use, I get an error:
>
> cannot load extension: hopefully-intern
>
> Perhaps I'm missing something obvious, or perhaps the tests/run.scm is
> for internal use only?
It's actually supposed to be runable. Though it does open internal
modules for testing.
I just released a minor update (which should only impact performance).
Please try that one. I just did rm hopefully* from my repository, thus
it should no longer find the module under the outdated name... and still
run.scm compiled for me. But you never know.
I'm glad you're trying this out. But before you use it too much, please
see the new "Issues" section:
http://wiki.call-cc.org/eggref/4/hopefully
Comments very much appreciated.
CU
/Jörg
>
> Regards,
>
> -chaw
>
>
> $ csc run.scm
> $ ./run
> D Initial: set
> D Value in other thread is unchanged...: 9
> D #: also in other thread former ref is still unchanged...
> D even after commit. (Note: tests caching of references to fields.): 9
> D Value in other thread is unchanged...: 9
> D Second round expecting changed value: 252
> D #: also in other thread former ref is still unchanged...
> D even after commit. (Note: tests caching of references to fields.): 9
>
> Error: (run.scm:161) assertion failed: (= (obox-v b1) 455)
>
> Call history:
>
> run.scm:159: step!
> run.scm:123: mutex-unlock!
> hopefully.scm:224: transaction-commit!
> hopefully.scm:165: hopefully-intern-atomics#stmtnx-owner
> hopefully.scm:167: hopefully-intern-atomics#stmtnx-id
> hopefully.scm:168: hopefully-intern-atomics#stmtnx-refs
> hopefully.scm:199: loop
> hopefully.scm:196: loop
> hopefully.scm:186: loop
> hopefully.scm:177: hopefully-intern-atomics#transaction-close!
> hopefully-intern-atomics.scm:119: transaction-reset!
> hopefully-intern-atomics.scm:33: ##sys#block-set!
> run.scm:161: obox-v
> run.scm:22: hopefully-intern-atomics#current-transaction
> hopefully-intern-atomics.scm:68: %current-transaction
> run.scm:161: ##sys#error<--
> $
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg: hopefully
Am 18.12.2015 um 17:41 schrieb Sudarshan S Chawathe: > > I cannot seem to access this egg. 'chicken-install' doesn't know about > it (yet?) which didn't surprise me too much, but I also get HTTP 404 > errors when using the link to the source from the egg's doc page on > call-cc.org (and ditto for the link on the askemos.org page): > > http://askemos.org/chicken-eggs/hopefully.tar.gz Thanks for the report. This link was wrong: http://askemos.org/chicken-eggs/hopefully/hopefully.tar.gz > > Is there some other place I should check? > > Regards, > > -chaw > >> To: chicken-users <chicken-users@nongnu.org> >> From: Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> >> Date: Thu, 17 Dec 2015 22:38:54 +0100 >> Subject: [Chicken-users] New egg: hopefully >> >> Hi, >> >> I just released the "hopefully" egg: Composable transactional memory. >> >> API inspired by Clojure's ref's and STMX. >> >> Currently only some record types may be used with hopefully. Further >> versions should add other mutable types. >> >> I'd love to get feedback on the API. >> >> https://wiki.call-cc.org/eggref/4/hopefully >> >> Release-info and source is at >> http://askemos.org/chicken-eggs/index.html >> (this may be added the egg index). >> >> Best >> >> /Jörg >> >> BTW: STM is usually advertised because it frees the programmer from >> getting locking sequences right. However at least the "good", low level >> API appears to here be marginally (~5-10%) faster than the equivalent >> code using mutexs. > > ___ > Chicken-users mailing list > Chicken-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-users > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] This may be a bug in chickens hash tables - or my bad
Am 18.12.2015 um 18:35 schrieb John Cowan: > Ivan Shmakov scripsit: > >> Given that the basic idea of hashing is to produce a key out of >> the object’s /value/, the change of the value – and mutation >> does just that – changes the hash. > > Well, yes and no. SRFI 69 and other Scheme hash table frameworks > support at least two kinds of hashing: hash by value and hash by > identity. If you have a large tree structure made with pairs, and > you want to keep ancillary information about some but not all of > the pairs, an identity-based hash table will let you keep the information > associated with *a particular pair*. Otherwise, if you had a tree like > (a (b c) (b c)), then any information associated with the first (b c) > would be overwritten if you associated information with the second (b c). > This is quite independent of whether you ever mutate the tree or not. Not necessarily. Given the typical vector+alist implementation, this would still allow to associate values to each particular pair. The problem really arises only around the question what hash-by-identity actually means. I would understand the language as: "two objects comparing eq? will hash to the same value". This would imply that the hash value would have to be somehow (implementation specific) being derived from a unique property of the particular object. (Easy if we'd assume malloc als allocator: just tag the address bits as fixnum. Harder for moving garbage collectors.) So the question is kind of nitpicking: does the srfi-69 /mandate/ that at least the hash-by-identity will produce the same value for the same object over the livetime of the object even if the object is mutated? If so, then we should change the chicken manual to document a deviation from the standard. Until we have a good idea how to fix it, that is. Otherwise I'd still put a warning into the manual. For boneheads like me. I mean: the problem is trivial to work around, once you know what you're dealing with. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] This may be a bug in chickens hash tables - or my bad
Am 17.12.2015 um 11:08 schrieb Kristian Lein-Mathisen: > I may be completely misunderstanding something here, but don't you have to > use equal? and not eq? for record structures? AFAIK eq? should hold true when the two objects are the same. Equal? will compare all the slots. (The latter is not defined to be so by Scheme, but it's what chicken does (if I remember the manual correctly)). > > K. > > On Wed, Dec 16, 2015 at 10:09 PM, Jörg F. Wittenberger < > joerg.wittenber...@softeyes.net> wrote: > >> Ah, great to learn. >> >> a) You are right: Per SRFI-69 it is actually undefined. Per chicken >> manual it returns the new value associated with key. >> >> As I've seen the latter (e.g. in the iup egg) actually being used, we >> might at least want to keep the behavior in chicken. >> >> b) But does not matter much. I ran into this originally from >> hash-table-ref signaling a missing key. >> >> The attached, modified test case fails because it i) does not find the >> key object hence hash-table-fold'ing the tree to ii) find an association >> with the very key the lookup failed for before. >> >> My hypothesis (after lightly reading the srfi-69.scm source) that the >> eq?-hash procedure produces a different hash value for the lookup before >> and after the mutation. Hence the lookup fails while walking the tree >> succeeds. >> >> /Jörg >> >> Am 16.12.2015 um 21:55 schrieb Peter Bex: >>> On Wed, Dec 16, 2015 at 09:47:31PM +0100, Jörg F. Wittenberger wrote: >>>> Hi, >>>> >>>> I always assumed that (make-hash-table eq?) would create a hash table >>>> usable with arbitrary chicken objects as keys. >>>> >>>> That is especially structures like objects created via define-record >>>> should be valid as keys. That is: referencing the table using the very >>>> same object (comparing eq? to the key object of the insert operation) >>>> will succeed. >>>> >>>> However this fails for me. At least after the key object was mutated >>>> between insert and reference time. >>>> >>>> See attached test case. >>>> >>>> Am I trying something illegal here? >>>> >>>> Thanks >>>> >>>> /Jörg >>> >>>> (use srfi-69) >>>> >>>> (define objtbl (make-hash-table eq?)) >>>> >>>> (define (register! obj arg) >>>> (hash-table-update! objtbl obj identity (lambda () (list obj arg >>>> >>>> (assert (eq? (register! 1 1) (register! 1 2))) >>> >>> I believe the return value of hash-table-update! is undefined. >>> >>> Cheers, >>> Peter >>> >> >> >> ___ >> Chicken-users mailing list >> Chicken-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/chicken-users >> >> > ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New egg: hopefully
Hi, I just released the "hopefully" egg: Composable transactional memory. API inspired by Clojure's ref's and STMX. Currently only some record types may be used with hopefully. Further versions should add other mutable types. I'd love to get feedback on the API. https://wiki.call-cc.org/eggref/4/hopefully Release-info and source is at http://askemos.org/chicken-eggs/index.html (this may be added the egg index). Best /Jörg BTW: STM is usually advertised because it frees the programmer from getting locking sequences right. However at least the "good", low level API appears to here be marginally (~5-10%) faster than the equivalent code using mutexs. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] This may be a bug in chickens hash tables - or my bad
Hi, I always assumed that (make-hash-table eq?) would create a hash table usable with arbitrary chicken objects as keys. That is especially structures like objects created via define-record should be valid as keys. That is: referencing the table using the very same object (comparing eq? to the key object of the insert operation) will succeed. However this fails for me. At least after the key object was mutated between insert and reference time. See attached test case. Am I trying something illegal here? Thanks /Jörg (use srfi-69) (define objtbl (make-hash-table eq?)) (define (register! obj arg) (hash-table-update! objtbl obj identity (lambda () (list obj arg (assert (eq? (register! 1 1) (register! 1 2))) (define-record foo bar) (define o1 (make-foo (list 23))) (define r1 (register! o1 1)) (assert (eq? r1 (register! o1 2))) (assert (eq? r1 (register! o1 3))) (foo-bar-set! o1 (list 42)) (assert (eq? r1 (register! o1 4))) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] This may be a bug in chickens hash tables - or my bad
Ah, great to learn. a) You are right: Per SRFI-69 it is actually undefined. Per chicken manual it returns the new value associated with key. As I've seen the latter (e.g. in the iup egg) actually being used, we might at least want to keep the behavior in chicken. b) But does not matter much. I ran into this originally from hash-table-ref signaling a missing key. The attached, modified test case fails because it i) does not find the key object hence hash-table-fold'ing the tree to ii) find an association with the very key the lookup failed for before. My hypothesis (after lightly reading the srfi-69.scm source) that the eq?-hash procedure produces a different hash value for the lookup before and after the mutation. Hence the lookup fails while walking the tree succeeds. /Jörg Am 16.12.2015 um 21:55 schrieb Peter Bex: > On Wed, Dec 16, 2015 at 09:47:31PM +0100, Jörg F. Wittenberger wrote: >> Hi, >> >> I always assumed that (make-hash-table eq?) would create a hash table >> usable with arbitrary chicken objects as keys. >> >> That is especially structures like objects created via define-record >> should be valid as keys. That is: referencing the table using the very >> same object (comparing eq? to the key object of the insert operation) >> will succeed. >> >> However this fails for me. At least after the key object was mutated >> between insert and reference time. >> >> See attached test case. >> >> Am I trying something illegal here? >> >> Thanks >> >> /Jörg > >> (use srfi-69) >> >> (define objtbl (make-hash-table eq?)) >> >> (define (register! obj arg) >> (hash-table-update! objtbl obj identity (lambda () (list obj arg >> >> (assert (eq? (register! 1 1) (register! 1 2))) > > I believe the return value of hash-table-update! is undefined. > > Cheers, > Peter > (use srfi-69) (define objtbl (make-hash-table eq?)) (define (register! obj arg) (hash-table-update! objtbl obj identity (lambda () (list obj arg (assert (eq? (register! 1 1) (register! 1 2))) (define-record foo bar) (define o1 (make-foo (list 23))) (define r1 (register! o1 1)) (assert (eq? r1 (register! o1 2))) (assert (eq? r1 (register! o1 3))) (foo-bar-set! o1 (list 42)) #;(assert (eq? r1 (register! o1 4))) (unless (hash-table? (hash-table-ref/default objtbl o1 #f)) (assert (not (hash-table-fold objtbl (lambda (k v i) (or i (eq? k o1))) #f signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
