Re: Improve "busy" numeric code's performance [was: Re: Big Integers]
> On Wed, May 22, 2024 at 02:42:38PM +0200, Peter Bex wrote: > > Attached are two patches, one which has this bigger improvement, and > > another which is a minor improvement which translates to shaving about > > a second of runtime off your program (at least on my machine). > > The minor patch was incorrect. I copied some code from C_s_a_i_remainder > into C_s_a_i_modulo inline, but that code had an early return for the > case where both numbers are flonums. This code needs to be adjusted to > handle the case when the arguments aren't of the same sign, just like we > do after returning from integer_divrem(). > > I'm sending both patches again for your convenience. The second patch > has a fix for the aforementioned issue. > Appled - thanks! felix
Re: Commented by default
> Dear All, > > is it somehow possible (ie via macros) to have a line in a scheme source code > file being a comment line by default and only when a certain symbol or group > of symbols is starting a line it is an uncommented / evaluated line? > Basically, the reverse of a normal source file where I need to introduce a > comment line. I would imagine a header line setting up this "comment"-mode, > and below this every line becomes a comment unless explicitly uncommented. You could use "set-read-syntax!" or "set-sharp-read-syntax!" to define a sequence that either treats the line as a comment or reads and returns it as an expression. Dropping means to skip subsequent lines prefixed with the chosen sequence or returning the first expression that follows. Since an expression may straddle multiple prefixed lines, you may have to dynamically bind a flag that ignores the sequence in nested reads. This may need a bit of fiddling, but that is probably the approach I would try. felix
Re: Advises and feedback
> Hello everyone! > > My name is Miguel, and I am interested in developing in Chicken Scheme. > > I just created a toy project to put in practice what I have been > learning in the Little Schemer and SICP books, you can find it here: > > https://github.com/MigAP/simple_db > > It is a simple database to store urls. I am not a developer, so I would > appreciate any feedback from you. In particular, it is the first time I > write unit tests, and I am not sure if this is the correct way of doing-it. > > I thank you in advance for any feedback. I am looking forward to start > building stuff using Chicken Scheme! > > I wish you all a good day. Hi! Your code looks good to me. I haven't examined it in detail, but the overall impression is fine. Also, the unit-tests seem to be similar to what I've seen in other code by more experienced Schemers. Note that you compile your program but load additional files via "load-relative". This technically works, but if you want all code to be compiled, I recommend to use "include" instead: that way, the parts are inserted into your main program and fully compiled, which is of course more efficient and also makes it easier to move the compiled program around or call it from a different location. > PS: Is there any small/medium project that I could study to learn the > "good practices" for Chicken Scheme? One of my goals is to use Chicken > Scheme for scientific computing and embedded applications. The egg sources are usually good examples for how to structure libraries. Some of these have example programs that you might want to study. Also, you can look at http://wiki.call-cc.org/Software which lists a couple of larger projects that use CHICKEN. cheers, felix
Re: integer64 foreign type ( manual/Foreign%20type%20specifiers.html )
> integer64type > unsigned-integer64type > A fixnum or integral flonum, mapping to int64_t or uint64_t. When > outside of fixnum range the value will overflow into a flonum. > > [...] (Numbers between 2^62 and 2^64-1 have gaps.) > > --- > > > First of all I don't understand why it's documented as integerNNtype > when in foreign prims/values one uses "integerNN", not "integerNNtype", > both as arguments and return values. > > But also I don't see any "flonum" (float or double I assume) in > translated C code. Instead I see things like "C_int64_to_num" which > seems to return bignums when out of fixnum range; no flonums, no gaps, > values print out as integers, (exact? ...) prints #t even for > (u)int64-max. Is the documentation out of date? Are you sure you are looking at the latest git HEAD? Both of your assumptions are correct, but api.call-cc.org and git master look correct to me. felix
Re: csi from git version: slow?
I just recall that we added line-number info to evaluated code, this may also have an impact. You can measure the load-time (just load a large source file) to check whether this is the case. Evaluation performance should not have changed much, I think. felix
Re: csi from git version: slow?
> Hello, I've tried the git version (2024-02-23, compiled with LLVM-17 > clang, on a Debian 12 / linux 6.6.x). While csc and the executables it > generates are a bit faster, running my program under csi is now twice as > slow compared to the latest release (5.3.0). > > > Now before I engage in other investigations, like compiling with GCC, > checking the nature of my program (sets a large number of globals by > running some DSL-type macros hundreds of times, would be the most > obvious distinguishing characteristic), I need to ask this first: is > this to be expected? Are there some "development version" / debug flags > / expensive interpreter features that differ compared to stable? I > customized only config.make by changing the C_COMPILER and PREFIX. The default build-flags do not disable any specific debugging settings, so you should get the normal, default efficiency, as with a normal release. We changed some syntax-related stuff that might slow down the expansion process. Can you determine whether the actual run-time in csi is slower than before, without taking into account the expansion of macros? You can also test whether the expansion phase is now slower in the compiler by using the "-A" option (analyze only) and/or "-debug b". cheers, felix
Re: Native threads and GC?
> We have a (32-bit, fwiw) C program that we are attempting to augment with a > CS function. The program runs in ~17 native threads, but our function only > runs in one of those threads. We call > > CHICKEN_initialize(0, 0, 0, C_toplevel); > CHICKEN_run(C_toplevel); > > after the thread is created, but then it goes off into libchicken and > segfaults. > The last usefully-named function it calls is allocate_vector_2(). > > Is there a useful way to debug what's going on? The threads exchange > messages, though > I don't believe any of them should be in the purview of CS's GC. Am I missing > something > obvious? Is the Chicken code started in the main thread? Also, on what platform is this running? Threads other than the main thread often have a smaller default stack (depending on the OS used), so the thread's stack may be exhausted as the C code generated from Scheme uses the stack as a first level heap and so needs a bit of space. You can also try to run the code with a single native thread for testing to at least have a base that works and continue by enabling threads from there. cheers, felix
Re: Generalized-Arrays egg v1.0.1
> Aha, so as long as something is wrapped we don't see the same kind of > inlining. Correct. > So what would this look like? I can see fx+ above, which uses > `chicken:fx+` (prefixed, 2-arity) and foldr to accomplish its multi-arg > case. Is adding `(inline-file)` to the srfi-143.egg enough for this? I > suspect partly that the foldr and `(fx+ . args)` form in general is > going to be hard to optimize out, but perhaps a case-lambda is faster? If we make the operations variadic, the compiler can always optimize (fx+ ...) into nested calls to dyadic lower-level primitives, but this applies only to optimizations that the compiler knows about. For user-defined inlinings, this is currently not possible. > Thanks for the really informed reply Felix, this was very helpful in > understanding what's happening with SRFI-143. I can hopefully start > crafting a patch for this now. No problem, you are very welcome. cheers, felix
Re: Generalized-Arrays egg v1.0.1
> 1. The egg itself is not compiled with -O3, whereas if I link to > (chicken fixnum) I believe that these procedures will be inlined by the > CHICKEN compiler when the arrays egg is compiled with -O3 or higher. That's correct. As -O3 implies "unsafe", the compiler can just ignore type checks and always inline numeric primitives. > > 2. There may be some rewriting rules that the compiler uses for > procedures in the (chicken ...) namespace that optimizes these directly > into their equivalent optimized C procedures. I'm not sure the compiler > has the same visibility if you re-export these from behind a module, and > especially not if you link dynamically (any hope of inlining those is > thus gone forever). As a general rule all renamings and rexports preserve the run-time semantics - as long as a procedure definition is not wrapped inside another procedure, the original procedure gets compiled and any optimizations and inlinings the compiler performs for "known" primitives will be applied. Syntax- and module-specific expansions perform renaming only and never introduce run-time code that wasn't explicitly given by the user. > > In fact on the latter point above, this raises an interesting question I > had for the mailing list: if I re-export a CHICKEN-specific procedure, > does the way the compiler handles translation units prevent certain > optimizations from applying? I've somewhat noticed that to be the case > but I haven't seen any writing about it nor have I understood the extent > to which that might affect certain SRFIs or eggs. See above - unless something is wrapped, you get the inlining. But as I see in the SRFI-143 spec, their operations take any number of arguments, where the ones from (chicken fixnum) have arity 2, so I assume the srfi code wraps the primitives into multi-argument procedures and thus preserves imports from the srfi-143 module to be inlined. > > > If you have time/energy, it would be useful to make Chicken's > > implementation do what it was originally intended. See the > > "Implementation" section in the SRFI, or feel free to ask me for > > explanations of details. One approach would be to extend those exports from (chicken fixnum) that match the multi-argument operations from srfi-143 and make the compiler aware of these, internally expanding the multi-arg cases into nested applications of inline calls to the 2-argument C runtime primitive ops. > It might also be a good idea to enforce SRFI-143's behaviour around > overflow / underflow as part of CHICKEN's default behaviour in CHICKEN > 6, but I don't really know how I would get started having that discussion. The SRFI-page doesn't seem to specify any behaviour. The runtime system is compiled with "-fwrapv" in the hope to preserve wrapping semantics for integer arithmetic, but I'm not sure how reliable that is. cheers, felix
Re: define-er-macro lambda no args bug?
> > ;; a simple un-hygienic macro that sets p to a lambda expression > ;; using define-er-macro - errors out on lambda no args > ;; > ;; a lambda one arg is fine ... > [...] Hi! Sorry for the later eply, but I'm not familiar with the code - have you tried to contact the author of the "procedural-macros" egg? felix
Re: cannot open file if name contains accented characters
> I tried your code but I got all kinds of compile errors. Sorry, but it's > gotten to be too much effort to just open a file. Indeed, that's understandable. Sorry for not being able to help, but we are definitely working on improving this situation for the next major release of CHICKEN. felix
Re: cannot open file if name contains accented characters
> Thanks for the responses. I tried what I could, but it still doesn't work. > I wrote some code to test if I can open and close a file. The C code works > but the Chicken code doesn't. > > (import (chicken foreign)) > > (foreign-declare "#include ") > (foreign-declare "#include ") > > (define chicken_wfopen > (foreign-lambda (c-pointer "FILE") "_wfopen" (c-pointer "wchar_t") > (c-pointer "wchar_t"))) > (define chicken_fclose > (foreign-lambda int "fclose" (c-pointer "FILE"))) > > (let ([file-handle (chicken_wfopen "c:\\temp\\íűőúöüóéá.txt" "r")]) > (print "File has been opened at: " (number->string file-handle)) > (print "Closing file.") > (chicken_fclose file-handle)) > > The Chicken code fails with the error message: Error: unbound variable: > It doesn't say the name of the variable, and it returns the error code 70. > Note that in C the string needs to be prefixed with an L to make it wide > character. In Chicken I don't know how to do that. > Does anybody have a clue which variable is unbound? Ugh. Sorry, I don't know what variable is meant here. I also gave wrong information: _wfopen returns a FILE* (as you correctly implement above). The returned pointer will not be a number, though. Anyway: the strings you pass are Scheme strings, passes as char * to the FFI code, this is wrong, as you want UTF-16 Windows strings (wchar_t *) here. The proper way would be (I think) to do ;; warning: totally untested (define wfopen (foreign-lambda* bool ((c-string str) (c-string mode) (scheme-object port)) "int sz1 = 4 * (strlen(str) + 1), sz2 = 4 * (strlen(mode) + 1); wchar_t *buf1 = malloc(sz1), buf2 = malloc(sz2); FILE *fp; MultiByteToWideChar(CP_UTF8, 0, str, -1, buf1, sz1); MultiByteToWideChar(CP_UTF8, 0, mode, -1, buf2, sz2); fp = _wfopen(buf1, buf2); free(buf1); free(buf2); if(fp == NULL) return(0); C_set_block_item(port, 0, (C_word)fp); return(1);")) (define (fopen-utf16 fname mode input?) (let ((p (##sys#make-port (if input? 1 2) ##sys#stream-port-class name 'stream))) (if (wfopen fname mode) p (error "error opening file" fname mode the ##sys#make-port thing above creates a proper port to be used in Scheme, the input? flag is unfortunately needed to distinguish between input and output ports. Sorry if all this is a bit confusing. felix
Re: cannot open file if name contains accented characters
> Hi everyone, > > I want to read input from a file that contains accented characters in its > name, and Chicken says that it can't open the file. The source code is > saved in a UTF-8 encoded text file. > [...] > I use Windows, and I run the script in the Command Prompt. Before running > it, I change the code page to UTF-8 with this command: > > chcp 65001 Hi! I'm not too familiar with the way Windows handles non-ASCII characters in operating system calls, but I assume that what gets passed to the C library runtime functions like fopen(3), etc. assumes a particular encoding. >From a quick glance at the Windows docs[1] it seems one needs to use "_fwopen" with a wchar_t string argument to pass extended characters. What you could do is to use the FFI to call "_fwopen" with a suitably converted argument string and the use "open-input-file*" to convert it into a Scheme port (Just ask if you need help with this). Sorry, if this is not overly helpful. We are currently in the process of improving the unicode support for the next major version of CHICKEN. felix
Happy Christmas!
I wish you all a merry christmas and a relaxed and fulfilling 2024. cheers, felix
Re: So, I noticed that the ioctl egg doesn't compile on OpenBSD
> It fails because TIOCSTI is undefined. OpenBSD removed it for security > reasons. > > How could that egg be modified to allow it to compile on OpenBSD? Hi! Thanks for reporting this - I have added a dummy definition (ioctl 0.4) for OpenBSD. felix
Re: Deprecated current-milliseconds
> Would it be possible to mark deprecations with alternatives/documentation > to point users in the new direction? Yes, next time, such a warning should mention any replacements. There is also a DEPRECATED file in the sources that lists recent deprecations. Thanks for the suggestion. felix
Re: [PATCH] Re: Eggs not installing on msys-mingw32
> How about > "empty egg-info file, possibly due to an aborted egg-install - please remove > the file and reinstall the corresponding egg"? > > Rationale: Matt's case. check-errors.egg-info was empty, but the > installation of base64 was failing. If Matt had removed > check-errors.egg-info and retried installing base64, the installation of > base64 would work, but check-errors would still be broken > (chicken-status and chicken-uninstall would ignore it, for example). Sure, whatever - feel free to change the message, if you think that makes it clearer. felix
[PATCH] Re: Eggs not installing on msys-mingw32
> That was it. Thanks. I do have to keep running: > > find /software/ -name \*.egg-info -empty -delete -print > > as check-errors.egg-info seems to be a pervasive problem. Maybe it would be > worth it to add a defence against this? > > Sorry - wrong patch, this is the right one. felix From 8a2a82a8171744546badacaa297bcf754bff3eba Mon Sep 17 00:00:00 2001 From: felix Date: Mon, 30 Oct 2023 14:00:41 +0100 Subject: [PATCH] handle case when egg-info file is empty --- egg-information.scm | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/egg-information.scm b/egg-information.scm index 6f5f7cb9..1e7f8aec 100644 --- a/egg-information.scm +++ b/egg-information.scm @@ -34,8 +34,11 @@ (if (file-exists? fname*) fname* fname))) (define (load-egg-info fname) - (let ((fname (locate-egg-file fname))) -(with-input-from-file fname read))) + (let* ((fname (locate-egg-file fname)) + (info (with-input-from-file fname read))) +(if (eof-object? info) +(error "empty egg-info file, possibly due to an aborted egg-install - please remove the file and retry" fname) +info))) ;;; lookup specific toplevel properties of egg-information -- 2.40.0
[PATCH] (was: Re: Eggs not installing on msys-mingw32)
> That was it. Thanks. I do have to keep running: > > find /software/ -name \*.egg-info -empty -delete -print > > as check-errors.egg-info seems to be a pervasive problem. Maybe it would be > worth it to add a defence against this? > Attached is a patch that catches at least this case. felix From 5a8cef35941109e5c5ee5d9596f855274185db30 Mon Sep 17 00:00:00 2001 From: felix Date: Mon, 30 Oct 2023 13:27:12 +0100 Subject: [PATCH] on *BSD, default C++ compiler to "c++" --- Makefile.bsd | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile.bsd b/Makefile.bsd index 690ce8d2..d66d1f06 100644 --- a/Makefile.bsd +++ b/Makefile.bsd @@ -31,6 +31,7 @@ SRCDIR ?= ./ ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) C_COMPILER ?= cc +CXX_COMPILER ?= c++ # options C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -- 2.40.0
Re: Question about how to check a symbol is bound
> On 28/06/2023 14:09, felix.winkelm...@bevuta.com wrote: > >> > >> (define-object-type bar > >> (field-1 name-of-library#foo) > >> (field-2 name-of-other-library#some-other-type)) > >> > >> ...even though calling symbol-value on those symbols at run time works > >> just fine. It seems that the symbols imported into the environment at > >> macro expansion time are handled differently in some way. > >> > > > > I guess during expansion identifiers are renamed to some internal gensym > > and thus not accessible by name (which is the whole point of a hygienic > > macro system). Could you not register the "foo" type in a expansion time > > hash table? > > Alas, the requirement is that things like "foo" are part of the lexical > environment - so can be imported from modules, renamed, be hidden inside > local scopes, all that stuff! > I guess some macro wizard will come up with a way to do this. But I still think that keeping an expansion/compile-time registry and accessing it using procedure macros (via "strip-syntax"ed identifiers to drop all renaming artifacts) is a possible solution. felix
Re: Question about how to check a symbol is bound
> > (define-object-type bar >(field-1 name-of-library#foo) >(field-2 name-of-other-library#some-other-type)) > > ...even though calling symbol-value on those symbols at run time works > just fine. It seems that the symbols imported into the environment at > macro expansion time are handled differently in some way. > I guess during expansion identifiers are renamed to some internal gensym and thus not accessible by name (which is the whole point of a hygienic macro system). Could you not register the "foo" type in a expansion time hash table? felix
Request change to hypergiant
> I want to get mouse clicks from the ui scene but I cannot access the ui > camera. In hypergiant/window.scm the ui camera is found in *ui-camera* but > this is not exported. When I added it to the exports I was able to see the > mouse clicks with this: > > (get-cursor-world-position *ui-camera*) > > Is there a better way to do this? If not, can hypergiant be updated with > this change? Sounds like a working solution. But you better contact the author/maintainer if you have change requests. felix
Re: hypergiant line-mesh - what are POINTS?
> It looks like I should be able to do line drawings with line-mesh. The spec > in the docs is: > > [procedure] (line-mesh POINTS [mode: MODE]) > > Create a non-indexed mesh of POINTS. MODE should be a valid argument to > mode->gl, defaulting to #:line-strip. > > But I can't figure out what POINTS are supposed to be. I've tried list > and vector of (make-point x y z) but I get: "line-mesh" invokes "make-mesh", check out this page, perhaps it gives you more information: https://api.call-cc.org/5/doc/gl-utils/make-mesh felix
Re: Static compile using csm question; how to add linked extension?
> I'm trying to compile the simple.scm example from hypergiant statically > using csm. Is this possible? > Hi, again! Can you try the attached alternative .egg file for hyperscene? Just invoke chicken-install -r hyperscene and replace the .egg file with the one in this mail. This should give you a static hyperscene build that csm (hopefully) finds. felix ;; hyperscene.egg -*- scheme -*- ((synopsis "Scene graph and spatial partitioning") (author "Alex Charlton") (maintainer "Adrien (Kooda) Ramos") (category graphics) (license "BSD") (dependencies miscmacros) (component-options (csc-options -C "-I./hyperscene/include/" -C "-I./hyperscene/hypermath/include/")) (components (c-object aabb-tree (source "./hyperscene/src/aabb-tree.c")) (c-object camera (source "./hyperscene/src/camera.c")) (c-object lighting (source "./hyperscene/src/lighting.c")) (c-object pools (source "./hyperscene/src/pools.c")) (c-object scene (source "./hyperscene/src/scene.c")) (c-object vector (source "./hyperscene/src/vector.c")) (c-object hypermath (source "./hyperscene/hypermath/src/hypermath.c")) (extension hyperscene (objects aabb-tree camera lighting pools scene vector hypermath
Re: Static compile using csm question; how to add linked extension?
> I'm trying to compile the simple.scm example from hypergiant statically > using csm. Is this possible? > > [...] (followup) That default to dynamic linkage was chosen to circumvent a csc limitation, I'm afraid. Hyperscene passes several .c files on the cmdline which doesn't work with "-c" (needed to generate an .o file). Let me think about this... felix
Re: Static compile using csm question; how to add linked extension?
> I'm trying to compile the simple.scm example from hypergiant statically
> using csm. Is this possible?
>
> all.options:
> -program simple -C -I/usr/include
>
> simple.options:
> -L -L/usr/lib/x86_64-linux-gnu -L -lepoxy -L -lGL -static -L -static -L -lm
> -L -ldl -link hyperscene
>
> I've tried -R hyperscene and -link hyperscene but neither works.
>
> What am I missing?
>
> '/home/mrwellan/data/buildall/ck5.3_23WW01/bin/csc' '-o' 'simple' '-I'
> '/home/mrwellan/data/opensrc/hypergiant-examples' '-C' '-I' '-C'
> '/home/mrwellan/data/opensrc/hypergiant-examples' '-static'
> '/home/mrwellan/data/opensrc/hypergiant-examples/simple.scm' '-C'
> '-I/usr/include' '-L' '-L/usr/lib/x86_64-linux-gnu' '-L' '-lepoxy' '-L'
> '-lGL' '-L' '-static' '-L' '-lm' '-L' '-ldl' '-link' 'hyperscene'
> csc: could not find linked extension: hyperscene
> command failed with non-zero exit status:
> '/home/mrwellan/data/buildall/ck5.3_23WW01/bin/csc' '-o' 'simple' '-I'
> '/home/mrwellan/data/opensrc/hypergiant-examples' '-C' '-I' '-C'
> '/home/mrwellan/data/opensrc/hypergiant-examples' '-static'
> '/home/mrwellan/data/opensrc/hypergiant-examples/simple.scm' '-C'
> '-I/usr/include' '-L' '-L/usr/lib/x86_64-linux-gnu' '-L' '-lepoxy' '-L'
> '-lGL' '-L' '-static' '-L' '-lm' '-L' '-ldl' '-link' 'hyperscene'
>
It seems hyperscene is only build statically ("(linkage dynamic)" in
the hyperscene egg file), so no .o file is found to be linked.
You can try to modify the hyperscene egg to build a static extension
variant, just drop that linkage property.
felix
Re: Different versions of syntax-rules
> Is there a desire to stick to r5rs features only in the chicken-core > expander, or is the intention to fold the R7RS / SRFI 46 features back > into the chicken-core expander at some point in the future? I haven't thought about it, and the extensions for R7RS are from Peter (I think). We could add them in a future version of the core system, I'd say. Peter, what do you think? felix
Re: CHICKEN meeting in June
> Hi, > > > I have updated the wiki page for the event at > > > > http://wiki.call-cc.org/event/village-chickens-2023 > > > > with some info regarding location and travel. Please > > contact me if you have any questions or need assistance. > > > > See you in June! > > I've just seen this. > > Is it too late to sign up? The wiki page says "January (latest)". > > Who else is currently intending to come? > > ...and are Significant Others welcome? > > Many of us are getting on a bit since our last Chicken meetup and it might > be nice to be able to do some family stuff as well. Hey, Andy! I'd be delighted if you could attend. SOs are certainly welcome, Peter, Kristian, Alex, Thomas, Juergen, Mario, Evhan, Vassiliy and others are planningto attend, so it should be a pleasant and familiar crowd. I asked for early "registration" because the venue has several rooms that I wanted to pre-book. These are all booked now. You can book a room in the vicinity (I put several links on the wiki page, I can't say much about the quality, though). Driving to the place of our meeting is not the problem, I (or someone else who gets here with the car) can pick you up, in case the bus connections should turn out to be inadequate. If you want to explore the area, there are several things to visit if you like nature and can live without metropolitan conveniences for a short while (but there are cities as well, Göttingen and Kassel are quite near), only transport is something that has to be solved - there is a public transport system, but naturally it only provides the very basic service. If you need further advice or assistance, please contact me. felix
CHICKEN meeting in June
Hi! I have updated the wiki page for the event at http://wiki.call-cc.org/event/village-chickens-2023 with some info regarding location and travel. Please contact me if you have any questions or need assistance. See you in June! felix
Re: Threading, mailboxes, and exceptions
> Also I'm from Python land, where exceptions are never resumable. The YouTube
> talks about Common Lisp rave about conditions, mostly in the context of
> interactive development ("Call a function that doesn't exist yet!" etc). Now
> here I see exceptions and conditions, and they are well enough documented
> that I can catch them, but I don't feel like I really understand them. Where
> does one learn about Scheme conditions and why they are what they are and not
> something different?
Hi! Pure Scheme has no exception system, so the only sources are
implementation specific features or SRFIs that address creating and
handling exceptions. This situation is typical for Scheme, which has
a very small and simple core language but leaves additional features
at the discretion of implementations. Common Lisp's condition system
is very powerful and sort-of standardized, but completely separate
from the Scheme world. This has both advantages and disadvantages, I
think. Resumable exceptions can be cool but can also make control-flow
completely inscrutable.
I would refrain from using exceptions for controlling the flow of
computations. Have you looked at http://api.call-cc.org/5/doc/gochan ?
This model of communication may be more robust and flexible than using
the bare threading facilities. I haven't used it myself, but I believe
the erlang-inspired message passing / actor concept has turned out to be
a pretty good model of writing concurrent code.
felix
Re: openssl eggs: current-milliseconds -> current-process-milliseconds
> >> If breaking 5.X | X < latest is a concern, this means > >> current-milliseconds must stay in 6.x and can only be removed in > >> 7.x? > > > > Hm I don't see how that follows. Removing current-milliseconds in 6.x > > doesn't break anything 5.x. > > Right, but just because that's already kinda broken in 5.X. > CHICKEN 6 will have other changes that break existing stuff because of subtle differences regarding string and port representation in foreign code and other things that we don't know about yet, that's just how things go. Issues like "current-milliseconds" vs "current-process-milliseconds" are, compared to that, trivial and easy to explain to users, I'd say. That's what major releases are there for, sometimes one just has to move on. I agree that the handling of the name change + deprecation was unwise (likely to be caused be me, initially). Now we will have to stick with it and learn something for the future. cheers, felix
Re: Not compiling statically
> Hi everyone. Sorry if this is an obvious question, but can I *not* compile an > extension statically? > > In other words, I’m trying to build chickadee, and I believe it's taking > around twice as long as expected because it is building every egg dependency > dynamically and then again statically. > > Is it possible to not do this? This seems to be controlled by > `default-extension-linkage` and by each individual extension with the > `linkage` property, but there doesn’t seem to be a way to control this at > runtime or build a whole set of dependencies dynamically only. I think this may require a csc option (to override the default setting). I can look into this, but currently it is not supported. felix
A very happy and relaxed christmas...
is what I wish to all of you! cheers, felix
Village CHICKENs 2023
Hi! I have added a wiki page for our next CHICKEN meeting: http://wiki.call-cc.org/event/village-chickens-2023 The page contains some more details. Please make sure to announce your participation until mid-January, so we can plan the event accordingly. cheers, felix
CHICKEN meeting in June
Hello! I'd like to organize a CHICKEN meeting at the start of June in the place where I live. Our regular live meetings were always a lot of fun, and I think it would be nice to pick this tradition up again. The plan is currently to have the event on the first weekend of June 2023. The location is a village in central Germany[1], called Ziegenhagen, roughly between Göttingen and Kassel. The place is easily reached by car (the A7 motorway is near) and there are 2 train-stations around 5m away (by car). I can pick up travellers from there, if you contact me aarly enough. There is nothing much going on here, so we can concentrate on hacking, talking and perhaps the odd presentation about something you are interested in (usually CHICKEN related, or perhaps just inspirating). Accomodation can be organized, there are a number of boarding houses in the village and in the direct neighbourhood and I will enquire about prices and availability beforehand once I have an idea about the number of attendees. Anyway, I would be delighted to see some of the CHICKEN hackers and everybody interested in joining us and learn more about the project. If you'd like to join, please drop me a note, giving your name or nick, so that I get a rough idea about the expected number of participants, which lets me plan accomodation and food. The main event will be from 2nd to 4th of June, perhaps stretched a few days in one or two directions. I'm just in the planning phase yet. cheers, felix [1] https://www.openstreetmap.org/query?lat=51.3650=9.7540
Re: Partial automation of egg dependencies
> > Actually, perhaps the best way would be to use a custom build > > using csm to build the components of the egg. A little bit of > > inventiveness might be required, but I think it should be possible. > > This would make the egg depend on csm. I don't mind this for programs, > but for eggs that are just libraries, isn't this a bit "opinionated" / > heavy given that all the build steps (apart from the import groveling) > can be done using the current chicken-install? > Here a quickly hacked together approach: try.egg: ((components (extension bar (custom-build "build")) (extension foo (custom-build "build" foo.scm: (module foo () (import scheme) (import bar) (bar)) bar.scm: (module bar (bar) (import scheme) (define (bar) (display 'bar))) build: #!/bin/sh sf= while [ -n "$1" ]; do case "$1" in -static) sf=-static;; esac shift done csm -compile-imports $sf It's a totally mad hack - but, man, do I love to improvise ... :-) felix
Re: Partial automation of egg dependencies
> > Actually, perhaps the best way would be to use a custom build > > using csm to build the components of the egg. A little bit of > > inventiveness might be required, but I think it should be possible. > > This would make the egg depend on csm. I don't mind this for programs, > but for eggs that are just libraries, isn't this a bit "opinionated" / > heavy given that all the build steps (apart from the import groveling) > can be done using the current chicken-install? Well, the import grovelling is what you need, right? It is an additional dependency, true, but so is every other egg you depend on, like, say, the r7rs egg. csm is not big, nor complex, and it basically just builds a dependency graph, with some attempts to be able to read all source files involved. > > Perhaps the csm groveler could be extracted into a library? Perhaps it > could even be shipped in chicken-core at some point, since after all > Chicken has to be able to trace all imports and includes in order for > the compiler and interpreter to work. The compiler and interpreter do this incrementally, they never build the total dependency graph. This is not needed in the core system, so we externalize it into an egg. > > > I added a "-compile-imports" to csm today to force import libs to > > be compiled, which may be a start. Perhaps we can cover this > > particular scenario without too much extra effort. > > This is above my paygrade :) I'll try to understand the patch. It just enables an option that I forgot to expose to the user :-) (It really does nothing else than compile the import lib after a module is compiled). I was trying out some stuff thinking about the problem that you are trying to solve and noticed that import libs are not compiled by default by csm. If you use a custom-build rule in an egg, it might be required to be able to do this. I will try to come up with a simple test case and figure out how to combine custom-build with csm. felix
Re: Partial automation of egg dependencies
Actually, perhaps the best way would be to use a custom build using csm to build the components of the egg. A little bit of inventiveness might be required, but I think it should be possible. I added a "-compile-imports" to csm today to force import libs to be compiled, which may be a start. Perhaps we can cover this particular scenario without too much extra effort. felix
Re: Partial automation of egg dependencies
> Would it be possible to add a feature something like this? > > (extension foo.bar >(source "bar.sld") >(auto-dependencies) ; <-- The new feature. >(csc-options "-R" "r7rs" "-X" "r7rs")) > > auto-dependencies would compute the deps by traversing the given source > file. It would look at csc-options and notice that r7rs is being used. > Then expect an R7RS-style define-library form in bar.sld, look at > (import ...) libraries matching those in the .egg and add those to > component-dependencies, as well as traverse all (include "...") and add > those to (source-dependencies ...). > > If csc-options doesn't say r7rs, it would do the same, but expect > Chicken module syntax instead. > > I wrote some code to grovel r7rs libraries, and there's probably similar > stuff in csm and Akku.scm too. So if the feature is ok we could stitch > together the implementation from these. That is quite a lot of stuff... You mention csm already, which does most of this, but for packaging eggs I think this is a bit too much automatic processing for my taste. I don't think such a feature belongs into the core system, but a preprocessor (perhaps by scavenging code from csm) or a mode for csm to emit egg files might be appropriate. felix
Re: Personal library
> Over time I have amassed a small collection of useful (to me) > procedures. I have a folder, containing several files each of which > defines a library (equivalent to a module in chicken, I think). I set > the environment variable CHEZSCHEMELIBDIRS to point at this folder and > then I can do things like (import (maths)) to import my "maths" > library. > > What would the equivalent setup for chicken be? I have had a scan > through the manual, but nothing is standing out to me. I am hoping it > is less complicated than writing my own personal eggs (but maybe not > and maybe this is not so complicated?) Eggs are just a method of packaging compiled modules. To have your personal set of loadable libraries, you don't need to go through all of that, just compile each source file for a module into a shared loadable binary (.so), like this: csc -s lib1.scm -J csc -s lib1.import.scm # assuming lib1.scm defines a module named "lib1" OLD=$(csi -p '(begin (import (chicken platform)) (car (repository-path)))') export CHICKEN_REPOSITORY_PATH=:$OLD Now, when you run "csi" or "csc" imports will search your libraries before trying to resolve built-in or installed extension modules. Should there be any problems, don't hesitate to ask for help. cheers felix
[SECURITY] Potential OS command execution during egg install
Hello! Vasilij found a security issue with the way egg-information files are created during installation of an extension package. Currently, escape characters in the .egg file may be used to perform arbitrary OS command injection due to the method the egg metadata is created and installed in the local egg repository during the install-stage of an egg. The issue is fixed in commit a08f8f548d772ef410c672ba33a27108d8d434f3 and has been assigned the CVE identifier CVE-2022-45145, see here for the patch: https://code.call-cc.org/cgi-bin/gitweb.cgi?p=3Dchicken-core.git;a=3Dcommitdi= ff;h=3Da08f8f548d772ef410c672ba33a27108d8d434f3;hp=3D9c6fb001c25de4390f46ffd7= c3c94237f4df92a9 All CHICKEN versions from 5.0.0 and later are vulnerable. Many thanks to Vasilij for reporting the issue and suggesting the necessary changes to mitigate the problem. Since all egg-downloads go through our centralized egg-locations file in SVN, it is highly recommended to verify *.egg files for possible shell escape characters before including their access information there. Future Salmonella runs should point out problematic eggs but it may be prudent to not rely on this, as Salmonella runs and additions to the egg-locations file are not synchronized. felix
Re: Updated egg locations
> > ...aaand I've erred once more. Sorry, the following is the correct link for > srfi-143: > > (srfi-143 > "https://git.sr.ht/~dieggsy/srfi-143/blob/master/srfi-143.release-info;) > Fixed. felix
Re: Updated egg locations
> Hi, > > I've just moved all my eggs to sourcehut. Here are the new locations. I've > run all of them through test-new-egg again just in case. > > (chalk "https://git.sr.ht/~dieggsy/chalk/blob/master/chalk.release-info;) > (chibi-generic > "https://git.sr.ht/~dieggsy/chibi-generic/blob/master/chibi-generic.release-info;) > (chicken-update > "https://git.sr.ht/~dieggsy/chicken-update/blob/master/chicken-update.release-info;) > (espeak > "https://git.sr.ht/~dieggsy/chicken-espeak/blob/master/espeak.release-info;) > (genann > "https://git.sr.ht/~dieggsy/chicken-genann/blob/master/genann.release-info;) > (icu "https://git.sr.ht/~dieggsy/icu/blob/master/icu.release-info;) > (math "https://git.sr.ht/~dieggsy/chicken-math/blob/master/math.release-info;) > (r6rs-bytevectors > "https://git.sr.ht/~dieggsy/r6rs-bytevectors/blob/master/r6rs-bytevectors.release-info;) > (r7rs-tools > "https://git.sr.ht/~dieggsy/r7rs-tools/blob/master/r7rs-tools.release-info;) > (srfi-105 > "https://git.sr.ht/~dieggsy/srfi-105/blob/master/srfi-105.release-info;) > (srfi-123 > "https://git.sr.ht/~dieggsy/srfi-123/blob/master/srfi-123.release-info;) > (srfi-144 > "https://git.sr.ht/~dieggsy/srfi-144/blob/master/srfi-144.release-info;) > (srfi-160 > "https://git.sr.ht/~dieggsy/srfi-160/blob/master/srfi-160.release-info;) > (srfi-179 > "https://git.sr.ht/~dieggsy/srfi-179/blob/master/srfi-179.release-info;) > (srfi-197 > "https://git.sr.ht/~dieggsy/srfi-197/blob/master/srfi-197.release-info;) > Has been updated. cheers, felix
Re: How does process-fork affect mailbox and threads
> 1) The SRFI-18 egg has not reached version 1. Which threading egg do you > recommend for my simple case? There is really just this one egg for threading. The version number you should ignore - the code is in production use for ages. felix
Re: Egg release: matrico 0.2
> Dear Wolf, > > thank you for testing. I am currently using -O4 as the performance gab > between -O3 and -O4 is rather large (likely because of those safety > measures). You are probably right that -O3 is more sensible; I will adapt > this for the next version and think about how to provide a "safe" and a > "fast" version concurrently. > One possibl approach would also to split the extension into two parts: an unsafe one holding the low-level routines and a safe one for higher level wrappers doing argument checks, etc. This may or may not apply to your case (and the overhead may eat up any performance advantages), but you might keep this in mind as an idea. felix
Re: Impact of procedure aliases on performance
> What I would like to know is whether the opposite is true: if I define > a custom name to refer to a pre-defined procedure, can I expect it to > get the same kind of special treatment from the compiler? For example, > if I put the following expressions in my code: > > (define ≤ <=) > (define ≥ >=) > (define × *) > > Will then calling ‘≤’, ‘≥’, or ‘×’ perform just as well as if ‘<=’, > ‘>=’, or ‘*’ were called instead? Or will any kind of special treatment > the compiler may give to some names not extend to custom names of > equivalent meaning? (And if the latter is true, are there any better > ways to rename pre-defined procedures?) If the compiler can be sure that your redefinitions refer to the original "standard" procedures, then they will be optimized similarly. To make sure this is the case compile your code inside a module (or in "block" mode), or, simpler, redefine your aliases as macros, that way you can be sure the final code contains references to the primitives. felix
Re: csm static build fails on yaml egg
> This is on ubuntu, chicken 5.3: > > Test code: > (module yamltest * > (import scheme > chicken.string > yaml) > (write (yaml-load "test.yaml"))) > > > csm -static -program yamltest > '/home/ubuntu/data/buildall/w23-0-ck5.3/bin/csc' '-o' 'yamltest' '-I' > '/home/ubuntu/data/opensrc/testsnips/yaml_static' '-C' '-I' '-C' > '/home/ubuntu/data/opensrc/testsnips/yaml_static' '-static' > '/home/ubuntu/data/opensrc/testsnips/yaml_static/yamltest.scm' > /home/ubuntu/data/buildall/w23-0-ck5.3/lib/chicken/11/yaml.o: In function > `f_3911': > yaml.static.c:(.text+0xae1c): undefined reference to `yaml_parser_delete' > yaml.static.c:(.text+0xae48): undefined reference to `yaml_parser_delete' Does this egg require an external library to be linked? It looks like it does. You need to add that. felix
Re: What is this message trying to tell me? csc: could not find linked extension: chicken.csi
> ck5 csm -program kvpub -static > '/home/mrwellan/data/buildall/ck5.3/bin/csc' '-c' '-static' '-J' > '/home/mrwellan/data/kvpub/mtargs.scm' '-I' '/home/mrwellan/data/kvpub' > '-C' '-I' '-C' '/home/mrwellan/data/kvpub' '-unit' 'mtargs' > '-emit-link-file' 'mtargs.link' '-o' 'mtargs.o' > '/home/mrwellan/data/buildall/ck5.3/bin/csc' '-o' 'kvpub' '-I' > '/home/mrwellan/data/kvpub' '-C' '-I' '-C' '/home/mrwellan/data/kvpub' > '-static' 'mtargs.o' '-uses' 'mtargs' '/home/mrwellan/data/kvpub/inval.scm' > csc: could not find linked extension: chicken.csi > command failed with non-zero exit status: > '/home/mrwellan/data/buildall/ck5.3/bin/csc' '-o' 'kvpub' '-I' > '/home/mrwellan/data/kvpub' '-C' '-I' '-C' '/home/mrwellan/data/kvpub' > '-static' 'mtargs.o' '-uses' 'mtargs' '/home/mrwellan/data/kvpub/inval.scm' You are trying to link statically a program that uses the (chicken csi) module, but there is no such object file for static linking available (chicken.csi lives in "csi" the interpreter and is not part of libchicken or the set of statically linkable extensions). You have to create a shared object and load it into csi to be able to use exports from the chicken.csi module. felix
Re: Performance question concerning chicken flonum vs "foreign flonum"
> Dear felix, > > after coming back to this function and the associated issues regularly, I > revised my opinion on integrating"fp+*" into (chicken flonum), given it uses > the C99-fma function. On the one hand, this operation is so fundamental in > numerical computations that it warrants a specialized function, on the other > hand the (somewhat) improved rounding could help a little. Finally, Gauche ( > https://practical-scheme.net/gauche/man/gauche-refe/R7RS-large.html#index-fl_002b_002a > ) and MIT Scheme ( > https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref.html#Flonum-Operations > ) provide this functionality. All in all, I would really appreciate if an > inclusion of a fma-based "fp+*" function into the (chicken flonum) module > could be considered in future versions of CHICKEN Scheme. Maybe your provided > patch reduces the effort for this. All right, I'll submit the existing patch to the mailing list. Thanks for your suggestion - it makes sense to follow the other implementations here. cheers, felix
Re: chicken 5.3.0 - improving POSIX test on Cygwin platform
> On Mon, Mar 21, 2022 at 5:19 AM wrote: > > > > Sorry for the overly late reply. I'm not too familiar with cygwin, what > > should the tests report here? The cond-expand for "windows" should trigger > > on cygwin, how is it handling the permission bits (as compared to "raw" > > Windows systems)? Does it "fake" the normal UNIX permission bits? > > > Cygwin maps Windows ACLs into Posix permissions bits, but not 1-1; > consequently, you can't assume that setting the permissions bits and then > reading them back will necessarily produce the same results. Therefore, > any test that depends on that property should be skipped altogether. > Very good, thanks for the information. felix
Re: chicken 5.3.0 - improving POSIX test on Cygwin platform
> Bonjour, > > Currently, Chicken Scheme 5.3.0 builds without problem on Windows 10 Home > (21H2 64-bit) with a recently updated Cygwin64. > > The check fails during the POSIX test when testing file system permissions. > This failure is expected, but the check process dies. The error is farther > below. > > There are already conditional statements in posix-tests.scm to handle other > Windows differences. Could some familiar with the checking system add a > conditional to handle this expected failure more gracefully. Hi! Sorry for the overly late reply. I'm not too familiar with cygwin, what should the tests report here? The cond-expand for "windows" should trigger on cygwin, how is it handling the permission bits (as compared to "raw" Windows systems)? Does it "fake" the normal UNIX permission bits? felix
Re: New Egg: posix-regex
> Chris Brannon wrote: > > I've been working on something along those lines myself, in fits and > > starts. I haven't gotten too far with it, but my basic idea is to make > > a library of data structures and functions suitable for creating > > ed-style interfaces where the basic metaphor is a buffer of lines. > > My basic idea is to write a POSIX ed(1) implementation which is > extensible through a library interface which allows defining custom > editor commands through provided macros and parser combinators. If you > are interested, you can find the source code at: > > https://github.com/nmeum/edward > > By now the editor is largely compatible with the POSIX ed(1) > specification. As such, I also have a "buffer of lines" abstraction with > POSIX ed undo support in `lib/buffer.scm`. > Brilliant! felix
Re: buffered inter-process communication
> Hi, > I am new to chicken and got stuck trying to do buffered inter-process > communication. > Could someone give me a hint why in the sample code below `copy_b` > freezes whereas `copy_c` works as expected? > Thanks! > As read-buffered only returns the data buffered by the last read operation, your code will not work. You should read block-wise by using "read-string" or read byte-wise (as does copy_c in your code). felix
Re: irregex match objects
> Under these assumptions I concluded that it should be possible to > detect what has been matched by checking whether the indices of the > assoc. list are valid in the current match object, stopping after the > first successful test. > > (import (chicken irregex)) > ;;; swapping fred and wilma > (irregex-replace/all '(: bow > (or (=> "f" (w/nocase "fred")) > (=> "w" (w/nocase "wilma"))) > eow) > "fred dino wilma barney" > (lambda (match-obj) >(assert match-obj) >(letrec ((iter (lambda (alist) > (unless (null? alist) > (let ((pair (car alist))) > (assert (pair? pair)) > (if > (irregex-match-valid-index? match-obj (cdr pair)) > (let ((name (car pair))) > (assert (string? name)) > (cond >((string=? name "f") > "Wilma") >((string=? name "w") > "Fred") >(else (error > "unknown named match" name > (iter (cdr alist > (iter (irregex-match-names match-obj) > > To my suprise the result is "Fred dino Fred barney" instead of "Wilma > dino Fred barney". What did I miss? I haven't looked very deep into this, but it seems the replacement lambda is called with the same match object for every substitution. You don't seem to distinguish between the different matches in any way - the result of the lambda will always be the same. felix
Re: Patch for "bind" egg: support for modern C++ nested namespace definition and scoped enums
> I hope this is the right place to send this to, but here we go. For our
> project, we wanted support for some modern C++-features in the "bind" egg:
>
> 1. nested namespace definitions: instead of namespace A { namespace B {
> ... } }, C++17 allows writing namespace A::B { ... }
> 2. typed and scoped enums: C++11 allows specifying the underlying type
> of an enum: enum C: int16_t { ... }. It also added scoped enums,
> that put all enumerators into a new scope: enum class D { E, F },
> which then need to be referenced as D::E and D::F.
>
> Since bind is a thin layer over some basic C and C++ constructs and
> mostly ignores namespaces, I've extended it to accept nested namespace
> definitions and scoped and typed enums. The underlying type for the
> latter are simply ignored by bind as well.
>
> These changes would really help reusing declarations between C++ code
> called by CHICKEN and bindings automatically generated with the bind
> module and chicken-bind CLI tools.
Excellent! Many thanks for your contribution, I'll apply these
changes and update the documentation.
>
> Disclaimer: Even though I have almost 20 years of professional coding
> experience, I'm still pretty new to both Scheme and Lisp in general.
> Feedback of any kind is welcome!
The code is about as idiomatic as can get, no need to be modest
about it! :-)
Thanks again.
felix
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.) > (That's a clever trick, Joerg.) As Joerg writes, block mode is specifically intended to ignore possibly external bindings. The idea is to have a single compilation unit only to give the optimizer maximum opportunities to inline calls and remove dead code. If you want to split up your code into several source files, use "include" to include the files into a single compilation unit, the files can include module definitions, if needed. So if compile-times are not an issue for you, I'd suggest "include", otherwise the trick suggested seems to me like the only alternative. felix
Merry christmas!
Everybody! I wish all of you a very happy christmas. felix
Re: require-extension and require-library
> In general, this lack of specificity and consistency when it comes to how > CHICKEN deals with files and modules in the smaller scale is something that’s > keeping me from being truly productive with the environment; I just can’t come > up with a flexible way to organize my projects that can adapt to my needs at > any given point. It’s hard to me to suggest an alternative, since I’m having > trouble seeing the full picture! But what I can say is that the manual could > do a better job at presenting this information, since I’m seeing some concepts > that are never directly addressed, just sprinked across multiple sections. Yes, you are quite right - the documentation is not particularly consistent on this point which is partially caused by legacy forms and concepts that are not really relevant anymore or only for very special situations (require-extension, units, etc.). Compiling single modules to .so's (+ import libs) should be the canonical way, and using "import" (and nothing else). Some of these concepts have their use, or reflect the internal structure of how compiled code is organized and linked but should be presented clearly in the documentation as such. We may get there at some stage, and suggestions would be very welcome. Have a try with csm, if you like. It is rather new and may need some tweaking, if you have any problems, please don't hesitate to contact me or this list. felix
Re: Guidance requested for debugging import problem.
> Hi Felix, > > I did not know about csm (or perhaps forgot it's existence?). Anyhow it > seems like a potentially much better solution than a > hand-maintained Makefile. I've tried it on a couple code bases and I'm > running into a few issues, some are just cruft in the code but two cases > I'm running into invalid sharp syntax errors: > === > csm -program logpro -ignore tests/run.scm > while reading file /home/mrwellan/data/logpro/logprocessor.scm: > > Error: invalid sharp-sign read syntax: #\/ > === > For logpro I wanted to expose the #/ ... / syntax to users. Since > regex-literals is not ported in chicken 5 I just injected the code into > logpro for now but it seems that csm doesn't understand the situation. > Hi! The problem here is that read-syntax extensions are not seen by csm, which tries to load and parse all source files. This was a blatant oversight on my part, I just committed a few changes to the csm trunk that adds a "-csm-extend FILENAME" option. You should be able to pass this directly to csm or via an options file - it works like csc's "-extend" and loads a file (source or compiled) into the processor so read-syntax extensions in the loaded file are installed. Could you give it a try? I have not tagged a new release yet, you can check it out via svn: svn co https://anonym...@code.call-cc.org/svn/chicken-eggs/release/5/csm I'd be very grateful for feedback. I think csm is quite useful, but it hasn't been tested enough yet and it needs serious usage to clarify whether the approach is worth it and robust enough. felix
Re: Guidance requested for debugging import problem.
> Wow, that seems to have fixed it. Thanks!! Also, I will not tire to point out that "csm" is always a viable alternative! :-) felix
Re: Guidance requested for debugging import problem.
> I went ahead and completed the minimal example build including the use of > .import.o files to enable using modules in evals. See attached tar. It > works fine which implies that, as you suggested, I have something wrong in > my build system. Thanks for the example code, this is really helpful understanding the problem. I have added -M to the compilation rules for the modules and removed the "uses" declaration of m1.import and the example still seems to work. -M includes the registration code in the binary, so that the module is visible at runtime. Perhaps this would help getting rid of the seprate *.import units. felix
Re: Guidance requested for debugging import problem.
> Thanks Felix for looking. Both run with -:d and attached. > > I only see the following loading calls in dashboard.log: > > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ > chicken.time.import.so ... > [debug] loading compiled library > /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so > (0x555a9a701260) > [debug] entering toplevel... > ; loading ./debugprint.import.scm ... > ; loading ./mtargs.import.scm ... > ; loading ./commonmod.import.scm ... > ; loading ./configfmod.import.scm ... I'm not sure I fully understand the problem here, but these look strange: [debug] entering apimod.import... [debug] entering debugprint.import... [debug] entering mtargs.import... [debug] entering commonmod.import... [debug] entering configfmod.import... [debug] entering bigmod.import... Are import-libraries compiled as modules? I think there might be a problem with your build system - these messages indicate the modules of the names given are compiled as library units / toplevel proceduresm which shouldn't be. Import libraries are auxiliary files that are loaded or included, but do not represent separate toplevel procedures. The latter are only created for library units and modules. Please check how the shown files (apimod, etc.) are compiled and with what options. felix
Re: Guidance requested for debugging import problem.
> On Fri, Nov 12, 2021 at 3:47 AM wrote: > > > > Update. I found that removing the *.import.scm files causes the problem > > to > > > also occur when running the executable in the directory where compiled. > > > However the non-gui executable still works fine. Why would a compiled > > > Chicken program be reading the import.scm files at run time? > > > > This can depend on compiler options: the import files contain code to > > register modules and imports, depending on compilation type > > (static/dynamic) > > and certain compiler options, this code is compiled into the executable > > or is loaded from a separate file. > > > > If you run the binaries with "-:d" and/or "-:d" do you get any information > > regarding the loaded files? > > > > I see the *.import.scm files being loaded in the output only in this one > place after chicken.time.import.so: > > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ > chicken.time.import.so ... > [debug] loading compiled library > /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so > (0x555a9a701260) > [debug] entering toplevel... > ; loading ./debugprint.import.scm ... > ; loading ./mtargs.import.scm ... > ; loading ./commonmod.import.scm ... > ; loading ./configfmod.import.scm ... > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/base64.import.so ... > Can you run both apps with the debug flags and show their output? felix
Re: Guidance requested for debugging import problem.
> Update. I found that removing the *.import.scm files causes the problem to > also occur when running the executable in the directory where compiled. > However the non-gui executable still works fine. Why would a compiled > Chicken program be reading the import.scm files at run time? This can depend on compiler options: the import files contain code to register modules and imports, depending on compilation type (static/dynamic) and certain compiler options, this code is compiled into the executable or is loaded from a separate file. If you run the binaries with "-:d" and/or "-:d" do you get any information regarding the loaded files? felix
Re: Performance question concerning chicken flonum vs "foreign flonum"
> Dear Felix,
>
> Thank you for the patch. I built the current git head with your patch.
> After importing chicken.flonum, I get the following error when calling fp*+:
>
I'm terribly sorry. I'm an ass, I didn't even test it in the interpreter. Please
find attached a revised patch.
felix
From 29b7abfd1a990e1fe4fc10f3d2532eadd079151f Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 7 Nov 2021 13:48:31 +0100
Subject: [PATCH] Add support for fused-multiply-add
(suggested by Christian Himpe on chicken-users)
---
NEWS | 4
c-platform.scm | 3 ++-
chicken.h | 2 ++
lfa2.scm | 2 ++
library.scm| 6 ++
manual/Module (chicken flonum) | 3 ++-
types.db | 3 +++
7 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index de01c00e..69fe5054 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,10 @@
- Default "cc" on BSD systems for building CHICKEN to avoid ABI problems
when linking with C++ code.
+- Core libraries
+ - Added "fp*+" (fused multiply-add) to "chicken.flonum" module
+(suggested by Christian Himpe).
+
5.3.0rc4
- Compiler
diff --git a/c-platform.scm b/c-platform.scm
index 00960c82..e59b1f1c 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -149,7 +149,7 @@
(define-constant +flonum-bindings+
(map (lambda (x) (symbol-append 'chicken.flonum# x))
- '(fp/? fp+ fp- fp* fp/ fp> fp< fp= fp>= fp<= fpmin fpmax fpneg fpgcd
+ '(fp/? fp+ fp- fp* fp/ fp> fp< fp= fp>= fp<= fpmin fpmax fpneg fpgcd
fp*+
fpfloor fpceiling fptruncate fpround fpsin fpcos fptan fpasin fpacos
fpatan fpatan2 fpexp fpexpt fplog fpsqrt fpabs fpinteger?)))
@@ -652,6 +652,7 @@
(rewrite 'chicken.flonum#fp/? 16 2 "C_a_i_flonum_quotient_checked" #f
words-per-flonum)
(rewrite 'chicken.flonum#fpneg 16 1 "C_a_i_flonum_negate" #f words-per-flonum)
(rewrite 'chicken.flonum#fpgcd 16 2 "C_a_i_flonum_gcd" #f words-per-flonum)
+(rewrite 'chicken.flonum#fp*+ 16 3 "C_a_i_flonum_multiply_add" #f
words-per-flonum)
(rewrite 'scheme#zero? 5 "C_eqp" 0 'fixnum)
(rewrite 'scheme#zero? 2 1 "C_u_i_zerop2" #f)
diff --git a/chicken.h b/chicken.h
index 7e51a38f..ba075471 100644
--- a/chicken.h
+++ b/chicken.h
@@ -1204,6 +1204,7 @@ typedef void (C_ccall *C_proc)(C_word, C_word *) C_noret;
#define C_a_i_flonum_plus(ptr, c, n1, n2) C_flonum(ptr, C_flonum_magnitude(n1)
+ C_flonum_magnitude(n2))
#define C_a_i_flonum_difference(ptr, c, n1, n2) C_flonum(ptr,
C_flonum_magnitude(n1) - C_flonum_magnitude(n2))
#define C_a_i_flonum_times(ptr, c, n1, n2) C_flonum(ptr,
C_flonum_magnitude(n1) * C_flonum_magnitude(n2))
+#define C_a_i_flonum_multiply_add(ptr, c, n1, n2, n3) C_flonum(ptr,
fma(C_flonum_magnitude(n1), C_flonum_magnitude(n2), C_flonum_magnitude(n3)))
#define C_a_i_flonum_quotient(ptr, c, n1, n2) C_flonum(ptr,
C_flonum_magnitude(n1) / C_flonum_magnitude(n2))
#define C_a_i_flonum_negate(ptr, c, n) C_flonum(ptr, -C_flonum_magnitude(n))
#define C_a_u_i_flonum_signum(ptr, n, x) (C_flonum_magnitude(x) == 0.0 ? (x) :
((C_flonum_magnitude(x) < 0.0) ? C_flonum(ptr, -1.0) : C_flonum(ptr, 1.0)))
@@ -1513,6 +1514,7 @@ typedef void (C_ccall *C_proc)(C_word, C_word *) C_noret;
#define C_ub_i_flonum_difference(x, y) ((x) - (y))
#define C_ub_i_flonum_times(x, y) ((x) * (y))
#define C_ub_i_flonum_quotient(x, y)((x) / (y))
+#define C_ub_i_flonum_multiply_add(x, y, z)fma((x), (y), (z))
#define C_ub_i_flonum_equalp(n1, n2)C_mk_bool((n1) == (n2))
#define C_ub_i_flonum_greaterp(n1, n2) C_mk_bool((n1) > (n2))
diff --git a/lfa2.scm b/lfa2.scm
index 45057578..e4bd308e 100644
--- a/lfa2.scm
+++ b/lfa2.scm
@@ -191,6 +191,7 @@
("C_a_i_flonum_sqrt" float)
("C_a_i_flonum_tan" float)
("C_a_i_flonum_times" float)
+("C_a_i_flonum_multiply_add" float)
("C_a_i_flonum_truncate" float)
("C_a_u_i_f64vector_ref" float)
("C_a_u_i_f32vector_ref" float)
@@ -201,6 +202,7 @@
'(("C_a_i_flonum_plus" "C_ub_i_flonum_plus" op)
("C_a_i_flonum_difference" "C_ub_i_flonum_difference" op)
("C_a_i_flonum_times" "C_ub_i_flonum_times" op)
+("C_a_i_flonum_multiply_add" "C_ub_i_flonum_multiply_add" op)
("C_a_i_flonum_quotient" "C_ub_i_flonum_quotient" op)
("C_flonum_equalp" "C_ub_i_flonum_equalp" pred)
("C_flonum_greaterp" "C_ub_i_flonum_greaterp" pred)
diff --git a/library.scm b/library.scm
index 6c6a6942..45182e84 100644
--- a/library.scm
+++ b/library.scm
@@ -1590,6 +1590,12 @@ EOF
(fp-check-flonums x y 'fp/)
(##core#inline_allocate ("C_a_i_flonum_quotient" 4) x y) )
+(define (fp*+ x y z)
+ (unless (and (flonum? x) (flonum? y) (flonum? z))
+(##sys#error-hook (foreign-value "C_BAD_ARGUMENT_TYPE_NO_FLONUM_ERROR" int)
+ 'fp*+ x y z) )
+ (##core#inline_allocate ("C_a_i_flonum_multiply_add" 4) x y z) )
+
(define (fpgcd x y)
(fp-check-flonums x y 'fpgcd)
(##core#inline_allocate
Re: Performance question concerning chicken flonum vs "foreign flonum"
Hi!
Here a patch against the current git HEAD, adding support for "fp*+". Please
give it a try, if you want.
This is experimental, if people consider this worthwhile, I can submit it for
adding to the core
system. Note that you still may need passing extra C-compiler options to enable
inlining of
the fma(3) call.
cheers,
felix
From 0f9c68a2b3954eb7c7d2a6075d6b4dfa3dcfb2a5 Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 7 Nov 2021 13:48:31 +0100
Subject: [PATCH] Add support for fused-multiply-add
(suggested by Christian Himpe on chicken-users)
---
NEWS | 4
c-platform.scm | 3 ++-
chicken.h | 2 ++
lfa2.scm | 2 ++
library.scm| 4
manual/Module (chicken flonum) | 3 ++-
types.db | 3 +++
7 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index de01c00e..69fe5054 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,10 @@
- Default "cc" on BSD systems for building CHICKEN to avoid ABI problems
when linking with C++ code.
+- Core libraries
+ - Added "fp*+" (fused multiply-add) to "chicken.flonum" module
+(suggested by Christian Himpe).
+
5.3.0rc4
- Compiler
diff --git a/c-platform.scm b/c-platform.scm
index 00960c82..e59b1f1c 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -149,7 +149,7 @@
(define-constant +flonum-bindings+
(map (lambda (x) (symbol-append 'chicken.flonum# x))
- '(fp/? fp+ fp- fp* fp/ fp> fp< fp= fp>= fp<= fpmin fpmax fpneg fpgcd
+ '(fp/? fp+ fp- fp* fp/ fp> fp< fp= fp>= fp<= fpmin fpmax fpneg fpgcd
fp*+
fpfloor fpceiling fptruncate fpround fpsin fpcos fptan fpasin fpacos
fpatan fpatan2 fpexp fpexpt fplog fpsqrt fpabs fpinteger?)))
@@ -652,6 +652,7 @@
(rewrite 'chicken.flonum#fp/? 16 2 "C_a_i_flonum_quotient_checked" #f
words-per-flonum)
(rewrite 'chicken.flonum#fpneg 16 1 "C_a_i_flonum_negate" #f words-per-flonum)
(rewrite 'chicken.flonum#fpgcd 16 2 "C_a_i_flonum_gcd" #f words-per-flonum)
+(rewrite 'chicken.flonum#fp*+ 16 3 "C_a_i_flonum_multiply_add" #f
words-per-flonum)
(rewrite 'scheme#zero? 5 "C_eqp" 0 'fixnum)
(rewrite 'scheme#zero? 2 1 "C_u_i_zerop2" #f)
diff --git a/chicken.h b/chicken.h
index 7e51a38f..ba075471 100644
--- a/chicken.h
+++ b/chicken.h
@@ -1204,6 +1204,7 @@ typedef void (C_ccall *C_proc)(C_word, C_word *) C_noret;
#define C_a_i_flonum_plus(ptr, c, n1, n2) C_flonum(ptr, C_flonum_magnitude(n1)
+ C_flonum_magnitude(n2))
#define C_a_i_flonum_difference(ptr, c, n1, n2) C_flonum(ptr,
C_flonum_magnitude(n1) - C_flonum_magnitude(n2))
#define C_a_i_flonum_times(ptr, c, n1, n2) C_flonum(ptr,
C_flonum_magnitude(n1) * C_flonum_magnitude(n2))
+#define C_a_i_flonum_multiply_add(ptr, c, n1, n2, n3) C_flonum(ptr,
fma(C_flonum_magnitude(n1), C_flonum_magnitude(n2), C_flonum_magnitude(n3)))
#define C_a_i_flonum_quotient(ptr, c, n1, n2) C_flonum(ptr,
C_flonum_magnitude(n1) / C_flonum_magnitude(n2))
#define C_a_i_flonum_negate(ptr, c, n) C_flonum(ptr, -C_flonum_magnitude(n))
#define C_a_u_i_flonum_signum(ptr, n, x) (C_flonum_magnitude(x) == 0.0 ? (x) :
((C_flonum_magnitude(x) < 0.0) ? C_flonum(ptr, -1.0) : C_flonum(ptr, 1.0)))
@@ -1513,6 +1514,7 @@ typedef void (C_ccall *C_proc)(C_word, C_word *) C_noret;
#define C_ub_i_flonum_difference(x, y) ((x) - (y))
#define C_ub_i_flonum_times(x, y) ((x) * (y))
#define C_ub_i_flonum_quotient(x, y)((x) / (y))
+#define C_ub_i_flonum_multiply_add(x, y, z)fma((x), (y), (z))
#define C_ub_i_flonum_equalp(n1, n2)C_mk_bool((n1) == (n2))
#define C_ub_i_flonum_greaterp(n1, n2) C_mk_bool((n1) > (n2))
diff --git a/lfa2.scm b/lfa2.scm
index 45057578..e4bd308e 100644
--- a/lfa2.scm
+++ b/lfa2.scm
@@ -191,6 +191,7 @@
("C_a_i_flonum_sqrt" float)
("C_a_i_flonum_tan" float)
("C_a_i_flonum_times" float)
+("C_a_i_flonum_multiply_add" float)
("C_a_i_flonum_truncate" float)
("C_a_u_i_f64vector_ref" float)
("C_a_u_i_f32vector_ref" float)
@@ -201,6 +202,7 @@
'(("C_a_i_flonum_plus" "C_ub_i_flonum_plus" op)
("C_a_i_flonum_difference" "C_ub_i_flonum_difference" op)
("C_a_i_flonum_times" "C_ub_i_flonum_times" op)
+("C_a_i_flonum_multiply_add" "C_ub_i_flonum_multiply_add" op)
("C_a_i_flonum_quotient" "C_ub_i_flonum_quotient" op)
("C_flonum_equalp" "C_ub_i_flonum_equalp" pred)
("C_flonum_greaterp" "C_ub_i_flonum_greaterp" pred)
diff --git a/library.scm b/library.scm
index 6c6a6942..2fb82557 100644
--- a/library.scm
+++ b/library.scm
@@ -1590,6 +1590,10 @@ EOF
(fp-check-flonums x y 'fp/)
(##core#inline_allocate ("C_a_i_flonum_quotient" 4) x y) )
+(define (fp*+ x y z)
+ (fp-check-flonums x y z 'fp*+)
+ (##core#inline_allocate ("C_a_i_flonum_multiply_add" 4) x y z) )
+
(define (fpgcd x y)
(fp-check-flonums x y 'fpgcd)
(##core#inline_allocate ("C_a_i_flonum_gcd" 4) x y))
diff --git a/manual/Module (chicken flonum) b/manual/Module
Re: Performance question concerning chicken flonum vs "foreign flonum"
> a patch would be great, if it is not too much work. Attached you find three > assembly language files: > > * fma-test_original.s (unchananged csc c to assembly) > * fma-test_modified.s (modified csc c from previous mail) > * fma-test_modified_mfma.s (modified csc c and -mfma gcc option) > > all files were created with the additional gcc arguments -O3 -S > -fverbose-asm. Are these files sufficient? Yes, thanks a lot. the third case shows that the intrinsic is indeed used. > > I hoped the fma libc function would insulate one from intrinsics; the > compiler option -mfma should activate (I think via defining a C macro) the > use of the corresponding CPU instruction (fma3 on current x86), which my CPU > supports, but using it does not seem to make a difference. Suprising, but I guess, the speedup is too minor, in the presence of all the noise regarding stack usage, etc. In straight-line, dumb, cache-friendly C code it may make a difference, I guess... I will provide an experimental patch for the new operation. Stay tuned. felix
Re: Performance question concerning chicken flonum vs "foreign flonum"
> modified code: > > 7.378s CPU time, 0/225861 GCs (major/minor), maximum live heap: 30.78 MiB > 8.498s CPU time, 0/238095 GCs (major/minor), maximum live heap: 30.78 MiB > > Both were compiled with -O3 optimization level in gcc. > > I am fine with these results given your layout of the internals in the > background. > > Would it be theoretically thinkable to include such fma functionality > directly into chicken.flonum, i.e. as fp+*, or are included modules typically > unaltered? The core modules like chicken.flonum can be optimized freely, as they are always delivered with the base system and the compiler is often tuned to treat these specially. I wonder why the speed difference still exists, could you send me the generated assembly code for the test program, as produced by your compiler? I'd like to see how far the C compiler goes at inlining the fma operation. If this can give a noticable speedup, I see no reason why not to add such an operation, but it would be nice to measure the effect before we do this. I can send you a patch for testing if you like. Note that one may have to use compiler intrinsics or special C compiler options to enable this, see for example: https://stackoverflow.com/questions/15933100/how-to-use-fused-multiply-add-fma-instructions-with-sse-avx felix
Re: Performance question concerning chicken flonum vs "foreign flonum"
> 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
>
>[...]
>
> It would be great to get some help or explanation with this issue.
Hi!
I have similar timings and the difference in the number of minor GC indicates
that the c99-fma variant allocates more stack space and thus causes more
minor GCs.
Looking at the generated C file ("csc -k"), we see that scm-fma unboxes the
intermediate
result and thus generates relatively decent code:
/* scm-fma in k183 in k180 in k177 in k174 */
static void C_ccall f_187(C_word c,C_word *av){
C_word tmp;
C_word t0=av[0];
C_word t1=av[1];
C_word t2=av[2];
C_word t3=av[3];
C_word t4=av[4];
C_word t5;
double f0;
C_word *a;
if(C_unlikely(!C_demand(C_calculate_demand(4,c,1{
C_save_and_reclaim((void *)f_187,c,av);}
a=C_alloc(4);
f0=C_ub_i_flonum_times(C_flonum_magnitude(t2),C_flonum_magnitude(t3));
t5=t1;{
C_word *av2=av;
av2[0]=t5;
av2[1]=C_flonum(,C_ub_i_flonum_plus(C_flonum_magnitude(t4),f0));
((C_proc)(void*)(*((C_word*)t5+1)))(2,av2);}}
The other version allocates a bytevector to hold the result:
/* c99-fma in k183 in k180 in k177 in k174 */
static void C_ccall f_197(C_word c,C_word *av){
C_word tmp;
C_word t0=av[0];
C_word t1=av[1];
C_word t2=av[2];
C_word t3=av[3];
C_word t4=av[4];
C_word t5;
C_word t6;
C_word *a;
if(C_unlikely(!C_demand(C_calculate_demand(6,c,1{
C_save_and_reclaim((void *)f_197,c,av);}
a=C_alloc(6);
t5=C_a_i_bytevector(,1,C_fix(4));
t6=t1;{
C_word *av2=av;
av2[0]=t6;
av2[1]=stub21(t5,t2,t3,t4);
((C_proc)(void*)(*((C_word*)t6+1)))(2,av2);}}
I thought that the allocation of 4 words for the bytevector (which is more than
needed on a 64 bit machine) makes the difference, but it turns out to be
negligible
Changing it to 2 and also adjusting the values for C_calculate_demand and
C_alloc doesn't seem to change a lot, but you may want to try that -
just modify the C code and compile it with the same options as the .scm file.
On my laptop fma is a library call, so currently my guess is simply that
the scm-fma code is tighter and avoids 3 additional function calls (one to the
stub,
one to C_a_i_bytevector and one to fma). The increased number of GCs may
also be caused by the bytevector above, which is used as a placeholder for
the flonum result, which wastes one word.
There is room for improvement for the compiler, though: the C_fix(4) is overly
conservative (4 words are correct on 32-bit, taking care of flonum alignment,
but
unnecessary on 64 bits). Also, the bytevector thing is a bit of a hack - we
could actually just pass "a" to stub21 directly. You may want to try this out:
/* c99-fma in k183 in k180 in k177 in k174 (modified) */
static void C_ccall f_197(C_word c,C_word *av){
C_word tmp;
C_word t0=av[0];
C_word t1=av[1];
C_word t2=av[2];
C_word t3=av[3];
C_word t4=av[4];
C_word t6;
C_word *a;
if(C_unlikely(!C_demand(C_calculate_demand(4,c,1{
C_save_and_reclaim((void *)f_197,c,av);}
a=C_alloc(4);
t6=t1;{
C_word *av2=av;
av2[0]=t6;
av2[1]=stub21((C_word)a,t2,t3,t4);
((C_proc)(void*)(*((C_word*)t6+1)))(2,av2);}}
This reduces minor GCs on my machine to roughly the same. If your
compiler inlines stub21 and fma, then you should see comparable performance.
Also, default optimization-levels for C are -Os (pass -v to csc to see what is
passed to the C compiler), so using -O2 instead should make a difference.
felix
Re: Installing Chicken 5.2.0 on Windows - chicken-install -update-db hanging
Mark, Many thanks for this thorough analysis. Could you do me a favour? Could you send me the installation instructions and the generated chicken-config.h files for each build option you used? Perhaps that way we can figure out where our various Windows build configurations are inconsistent. felix
Re: [ANN] CHICKEN 5.3.0 release candidate available
> On Sat, Aug 14, 2021 at 08:25:21PM +0200, Sven Hartrumpf wrote: > > Hi. > > > > The segmentation violation disappeared after cleaning my build script for > > chicken. > > (It contained an old "-mpreferred-stack-boundary=4" in > > C_COMPILER_OPTIMIZATION_OPTIONS, > > which I dropped now.) > > hm, I have to wonder: why does that break things? > More obscure C compiler options sometimes break working code, the possibility of interactions with optimzations and hardware contraints are endless. We also have alignment restrictions regarding stack-allocated floats, so perhaps there is something borked in that regard. I wouldn't worry too much about it, though. felix
Re: What are the long-term goals for R7RS in Chicken?
> The convention (observed at least by Chibi, Gambit, and Gauche) is that > each .sld file contains one define-library form. > > Gambit can compile something like hello.sld: > > (define-library (hello) >(import (scheme base)) >(begin (write-string "Hello world\n"))) > > into an object file hello.o1 via "gsc hello.sld". The gsi interpreter > can load either the original hello.sld or the compiled hello.o1. (I'm > not sure why it appends a running number to the ".o" suffix.) The same > arrangement would probably work for Chicken. I think you can do the in Chicken as well, or I may misunderstand the implications ehre. > The code to implement simple libraries is often written directly into > the .sld file itself. Complex libraries tend to have the implementation > parcelled out into one or more separate .scm files, which are (include > "...") from the .sld file. Non-portable files may be included via > cond-expand. Looks easy enough to do. > > (include "...") must always specify the file name extension of the file > being included, though in practice that tends to always be ".scm". The > file foo/bar.sld files is imported via (import (foo bar)) and the import > never specifies the file name extension; ".sld" is implied, though > something else could be used as well; R6RS tends to use ".sls". But I"d like to stress the fact that run-time and compile-time file locations may differ, also things like dynamic loading vs static linking come into play. In the end this is a build issue, not necessarily a question of run-time semantics. Actually, the physical locations of code are secondary, as long as libraries are found, resolved and evaluated properly. Once again, I can not help but point towards "csm"[1], as a natural and convenient (yet, apparently sadly ignored), tool-based solution to this problem. cheers, felix [1] http://api.call-cc.org/5/doc/csm
Re: What are the long-term goals for R7RS in Chicken?
> If there are few substantial differences, it would be a boon to writing > portable code if the same syntax is eventually used as for standard R7RS > libraries, and the same filename conventions are supported as other R7RS > implementations (the .sld filename extension for an R7RS library is > becoming a de facto standard). You already support (include "...") and > (cond-expand ...) in a similar manner as R7RS. Note that include-files and loaded libraries are two different things, also in CHICKEN, libraries are usually compiled, so the .sld convention is only partially useful. felix
Re: Trying to link in modules
> I've got a module mymod in mymod.scm:
>
>[...]
>
> However, I can't figure out how to do the same thing with mymod as
> non-shared objects. I tried
>
> csc -c -J mymod.scm
> csc -c mymod.import.scm
> csc -static -o trymod.static mymod.o mymod.import.o trymod.scm
>
> but I got
>
> Undefined symbols for architecture x86_64:
>
> "_C_mymod_toplevel", referenced from:
> _f_138 in trymod.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> Error: shell command terminated with non-zero exit status 256: 'clang'
> 'mymod.import.o' 'mymod.o' 'trymod.o' -o 'trymod.static' -m64
> -L/usr/local/Cellar/chicken/5.2.0/lib
> /usr/local/Cellar/chicken/5.2.0/lib/libchicken.a -lm
When loading a shared object, the CHICKEN runtime uses the libld API
to obtain the entry point ("C_toplevel") to invoke top-level initialization code
of the module (which also sets up global bindings, etc.). But in a statically
linked executable, all entry points of linked modules must be available under
a separate name, so that they can be distinguished from each other.
What we do is to give the module (the binary *.o module) a name, which is
called "unit", so mymod would have, for example, the unit name "mymod",
which produces the entry point "C_mymod_toplevel". So you can link any
number of separately compiled binary objects (containing modules) and
their names don't clash.
So, to make it work:
csc -c -J mymod.scm -unit mymod
# compiling the import library is not needed
csc -static -o trymod.static -uses mymod mymod.o trymod.scm
The main file (trymod) doesn't need to resolve the imports, so you can omit
linking the import library. "-unit" gives the module a unit name, "-uses" tells
the main module to invoke the toplevel of the linked module.
This mechanism is a source of great confusion, but this mainly comes from
the fact that static linking uses a facility for resolving module toplevel and
initialization code from the whole module and namespacing machinery.
---
BTW, the "csm" utility, provided by the egg of the same name, figures this out
automatically, just put trymod.scm and mymod.scm into an empty directory
and enter
csm -program trymod
or
csm -program trymod -static
Add -d and -v to see what the program is doing and how things are compiled.
felix
Re: How to handle egg with multiple modules
> > > > (modules species (species ui)) > > > > declares 2 modules, I"m not sure chicken-install can detect that the > > extension > > consists of 2 files, with one module for each. > > > > Does this mean that extensions are not supposed to be composed of more > than one module? It is uncommon, or multiple modules are handled by including them in one master file. > It seems like I was kind of trying to use the extension mechanism as a > build system... It can be used as such (and is), but that is not what eggs are intended to solve. Extensions have to follow certain constraints, but it is unnecessary to impose these constraints on building more complex applications. felix
Re: csm 0.1
> Exactly what I was looking for! Feedback is welcome. Should you experience any problems, don't hesitate to report them. felix
Re: New egg: mdh
> Building, testing, and installing all worked out of the box, but I got > these two warnings while compiling (in red even though they're warnings): > >[...] Hm, I have no idea, but I noticed a couple of suspicious warnings. In fact, the code doesn't even compile without "-w", which may indicate further problems. I"m not a C++ expert, but there are some rather peculiar coding choices in there. I'm not keen on digging too much into the codebase, though, so unless users report genuine bugs, we should wait and watch. Thanks for the report. felix
csm 0.1
Hi! A first version of "csm" is available, a build system for CHICKEN Scheme programs: http://wiki.call-cc.org/eggref/5/csm Assuming a small set of conventions, this tool can infer dependencies and necessary command-line options for a set of source files written in CHICKEN or R7RS Scheme. A flexible method for customizing the set of options for targets is provided, as is generation of GNU/BSD makefiles (thus allowing parallel builds) and the creation of statically linked executables. The tool has tested this with ensemble, bintracker and other non-trivial projects, but will of course still contain bugs and shortcomings. Please send bug reports or questions to this list or to me directly. felix
Re: How to handle egg with multiple modules
> I have tried removing one of the 2 modules declared in the .egg but I > have the same problem. When I remove the > (species ui) import from darwin.scm it compiles and runs the tests > but of course fails to resolve the symbol at runtime. > (modules species (species ui)) declares 2 modules, I"m not sure chicken-install can detect that the extension consists of 2 files, with one module for each. felix
Re: How to handle egg with multiple modules
> Error: (car) bad argument type: > |\xcf\xfa\xed\xfe\x07\x00\x00\x01\x03\x00\x00\x00\x02\x00\x00\x00\x11\x00\x00\x00\x90\x06\x00\x00\x85\x00| > I haven't analyzed this, but this looks like is the header of a binary object, so the runtime system is trying to load a binary, perhaps a import library (and fails and thus treats the binary data as source code). Is your CHICKEN setup working properly? felix
New egg: mdh
Hi! This is to announce the "mdh" egg, an interface to the C++ API of O'Kane's MUMPS database. The concepts behind it were presented by Luke at the CHICKEN Coding Jam and produced quite some interest. MDH is a very easy to use multidimensional key-value store. The code is included in the egg, the only external dependency is libpcre. Documentation can be found here: http://wiki.call-cc.org/eggref/5/mdh (or of course at api.call-cc.org). Note that this is a first release. It seems to work fine, but has not been heavily tested with regards to scalability and performance. There are a few parameters than can be tweaked once there exists more experience with using this database. Many thanks to Luke K. for inspiration and fruitful discussions regarding a suitable Scheme API. felix
Re: Chicken 5, chicken-install goes silent for long time on installing long list of eggs
> chicken install address-info ansi-escape-sequences apropos base64 crypt > csv-abnf > directory-utils filepath fmt format http-client > intarweb json linenoise matchable md5 message-digest moremacros > pathname-expand postgresql queues regex-case rfc3339 s11n sha1 > slice sparse-vectors spiffy > spiffy-directory-listing spiffy-request-vars sql-de-lite sqlite3 > srfi-19 srfi-69 stack sxml-modifications sxml-serializer > sxml-transforms sxpath system-information tcp6 test uri-common z3 > > ... long wait before there is any output ... > > A little visual feedback would give the user some confidence that things > are proceeding. > This should actually be fixed in recent versions CHICKEN. Evan has added a change addressing exactly this. felix
Results of the CHICKEN Coding Jam 2021
Hello! We are happy to report that the 2021 coding jam at the previous weekend was a very entertaining and interesting event. Participation was quite good, we had excellent talks and presentations and did a very fruitful evaluation of the 2021 state of CHICKEN survey. Thank you all for taking part! We plan to have short but more frequent meetings like this in the future, since it turns out that a lot of fascinating projects and ideas are being followed in the CHICKEN user community. Feedback from users is highly welcome as it makes it easier to focus on important work in the core system. The results of the event can be found here: http://wiki.call-cc.org/event/coding-jam-2021-results Links to talks and presentation videos are included. See you next time! felix
The CHICKEN Coding Jam 2021 has been opened
Hi, folks! The CHICKEN Coding Jam 2021 has officially started. Please join #ChickenCodingJam on irc.freenode.net to participate. Everybody is welcome! Visit http://wiki.call-cc.org/event/coding-jam-2021 for the schedule and up-to-date information about the event. felix
Re: Compiling to C w/ eggs
> I'm trying to compile a small project with some imports (some srfi,
> matchable, and ncurses) to a bunch of *.{c,h} files for easier
> distribution. Following http://wiki.call-cc.org/man/5/Deployment
> compiling the example to a test.c went smooth. However, I'm already
> stuck with
>
> ; test.scm
> (import (srfi-1))
> (print "Hello, World!")
>
> > chicken-csc -t test.scm
> > gcc -Os -fomit-frame-pointer -DHAVE_CHICKEN_CONFIG_H test.c \
> build-version.c eval.c expand.c internal.c library.c modules.c \
> runtime.c chicken-syntax.c -o main -lm
> > ./main
> Error: (require) cannot load extension: srfi-1
>
> Not very surprising. I tried some of the compiler options -uses srfi-1,
> -emit-all-import-libraries, -unit, …, but to no avail. I guess I could
> compile chicken-install/srfi-1/* to .c/.h files (after I figure out how
> exactly), and bundle them together. But with ~15 modules this seems
> quite tedious for something that should be able to be done automatically,
> at least for the modules without FFI. Is there an easier way?
You should use static linking for srfi-1 and add it to the list of C modules.
There may still be some more obstacles, but you should go step by step.
The .c files for eggs you use can be found in the cache directory that
chicken-install uses to build the extension(s). You should also pass -k
when invoking chicken-install to make sure intermediate files are not
deleted.
felix
CHICKEN Coding Jam 2021
Hi, folks! This is the now the official announcement of the first CHICKEN Coding Jam, taking place online from 9th to the 11th of April 2021. It will be an opportunity to meet and discuss CHICKEN, Scheme, software, programming, hold talks, do presentations or just get to know each other. We also like to use the time for planning our road ahead for the next CHICKEN release, consider the current state of our project and community and think about what needs to be improved and collect ideas. The recently announced user survey (thanks, Mario!) will hopefully have collected some data to help us in that regard. Everybody is welcome! There will be a dedicated IRC channel on freenode, and bevuta IT GmbH kindly provides Jitsi videoconferencing infrastructure. We plan to have a 3-4 hour slot each day available for video time, so if you intend to hold a talk, show a presentation or demonstrate a cool piece of software (preferrably having some relation to CHICKEN), or an interesting application or workflow, please tell us in advance (via this mailing list, or mail me directly). For up-to-date information, visit http://wiki.call-cc.org/event/coding-jam-2021 We hope to see you soon! cheers felix
Re: Chicken GUI options survey and questions.
> I've spent a few months evaluating the existing options for C4 and > making a few myself. From the existing options pstk was the only one > worth using as it has been around the longest and solves the common GUI > problems you'd run into. Consider whether a design like ma [1] would > work for you (written in Tcl, interfaces with Scheme via IPC) and make > sure to look at bintracker [2]. Small correction: ma does not talk with scheme exclusively, it actually just communicates with shell processes, via rather crude Tcl/Tk IPC. felix
Re: filter
Hi, Jürgen! > I suggest, to include a filter routine with two values, the sublist > which passes the test and the sublist which fails at least into (chicken > base) which is imported most of the time. I think depending on SRFI-1 isn't that mauch hassle. On the other hand we have fundamental operations like "foldl" in the core, simply because it can be inlined. Adding a basic "filter" would probably acceptable, inlined similarly, like "foldl"/"foldr". felix
Re: Adding deprecation notices to CHICKEN 4 egg docs?
> Hi all, > > I've noticed that the documentation for CHICKEN 3 eggs (and also for > CHICKEN 2 eggs, where we have them) contain a "OUTDATED EGG" warning > at the top, to warn people away from them. > > I'm thinking, maybe we should do something similar for CHICKEN 4 > documentation now. CHICKEN 5 is now just over 2 years old[1] so it's > about time, even though some eggs may not have been ported yet. > > Also I noticed we didn't do this for the manual itself. I think it's > a good idea to that now, too. > > Thoughts? Comments? > Probably a good idea, perhaps with a "standard" text pointing to the most recent version (i.e. 5)? felix
Re: Web page with quick links to all C4 and C5 egg versions
> Here's a listing of all eggs with > > - egg name > - description > - license > - latest egg version number for Chicken 5 > - latest egg version number for Chicken 4 > - link to egg documentation (wiki) and git repo for both versions > - color indicator saying whether each version is up to date or not > > https://misc.lassi.io/2020/chicken-eggs.html > > Generated by https://github.com/chicken-contrib/chicken-quick-links > This is great - we should definitely put this somewhere at call-cc.org. (I especially like the #t at the end. :-) felix
Happy Christmas!
I wish all of you a very happy christmas. Many thanks to all who have participated, contributed, followed or just used CHICKEN and supported this project in one way or another. May your parens always be balanced! felix
Re: Some questions about concurrency (mostly)
> 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. felix
Re: Some questions about concurrency (mostly)
> 1. Are there any problems with creating a condition (as in exception, >not srfi-18 condition variable) in one thread and raising it in one >or more other threads? No problem here, I'd say, data can be freely exchanged between threads, since they share a global address space. A condition object is just a data structure. > 2. In my application I'm running a thread that reads from a TCP port and >dispatches frames back to the main thread using a mailbox (from the >mailbox egg). I'm also running a separate thread that sends a >heartbeat frame back over the TCP connecion every 30s. This works >fine, but I've noticed that after a while (this seems to happen >consistently after the first heartbeat has been sent) I cannot press >Ctrl-C in the terminal to stop the application. However, as soon as >the dispatcher thread reads an incoming frame, the process is >interrupted. I assume this has something to do with blocking threads? >Is there something I can do about it? Is this in a compiled application or inside csi? If the former, do you install a handler for SIGINT? > 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. Whenever the continuation is re-invoked, the before/after thunks will be called on entering the dynamic context in which the 2nd thunk above will be executed, and the before/after thunks will always be called in pairs, so your approach looks fine to me. For example, load this into csi: (define k0 #f) (define k1 #f) (define (foo) (call/cc (lambda (k) (dynamic-wind (cut print 'before) (lambda () (set! k0 k) (call/cc (lambda (k2) (set! k1 k2) #f)) (k 99)) (cut print 'after) #;1> (foo) before after 99 #;2> (k0 100) 100 #;3> (k1 101) before after 99 dynamic-wind is powerful, but can be very confusing, expecially if you mix in threads and exceptions. Better try to keep the control-flow of your code simple. > > 4. The srfi-18 thread scheduler seems to behave slightly differently >when running compiled code and in csi. Is that correct? This depends on what you mean with "slightly". Interruption of running threads (because the time-slice is used up) will happen at different points in interpreted vs. compiled code - compiled code is more compact and has of course completely different timing behaviour. Can you elaborate on what you mean with "differently"? felix
Re: New egg for SRFI 193: Command line
> Is there a way to figure out if running in csi at runtime without using > cond-expand? > You can test "(feature? #:csi)" to figure out whether the current executable is "csi". felix
Re: How to (eval ...) in a R7RS library?
> Hi *, > > I asked a question on stackoverflow (link below), but didn't get any answer > so far. If anyone knows how to deal with it, don't hesitate to let me know > (whether per mail or per SO answer). > I fixed the two bugs you encountered - one was caused by a non-existent internal library function in chicken-core, the other by a "fix" I added a long time ago for something completely unrelated. Apparently scheme.eval#environment was borked since CHICKEN 4.8.0, and it was all my fault... Please give r7rs 1.0.3 a try, it should be available via chicken-install in a few hours. Thanks for reporting this. felix
Re: How to (eval ...) in a R7RS library?
> Thanks for the suggestion! With this fix, I get as a result of > > (import (test-eval)) > (my-eval) > > an error which is shown below. Any ideas? The reference to "delq" is an error in the r7rs egg, but the other error is somewhere deep in the module system. I'm currently investigating this - sorry for the mess, I'll try to figure this out as quickly as possible. felix
Re: [ANN] CHICKEN 5.2.0 release candidate available
OS: OpenBSD 6.5 Hw: x86_64 cc: gcc version 4.2.1 20070719 Build, check and install works, but pastiche depends on sql-de-lite which needs to be patched for 5.2.0. I tried with awful, which also a bunch of dependencies, which worked fine. felix
Re: Missing Eggs in Chicken 5
> crypt egg helped a ton. Thank you for that. I'm also running into a > missing "sparse-vectors" egg. Should be available any moment. felix
Re: Missing Eggs in Chicken 5
> Matt Welland and I are porting some existing code to chicken 5. We ran > into some eggs that we are using that we would like in chicken 5: > > csv-xml > crypt > > We also needed the autload, pathname-expand and dbi eggs. > The diff for pathname-expand egg is here: > http://kiatoa.com/cgi-bin/fossils/megatest/vdiff?from=e6be7bbc9f5d29fb=2f7180aa77bfca2f > The diff for autoload egg is here: > http://kiatoa.com/cgi-bin/fossils/megatest/vdiff?from=80e66f4369f704fa=37f61c54aee37740 > The diff for dbi is here: > http://kiatoa.com/cgi-bin/fossils/megatest/vdiff?from=2f7180aa77bfca2f=80e66f4369f704fa > If any of the authors are on the list, feel free to take those changes and > do as you see fit with them. I have applied your patches for pathname-expand, thanks for providing it. felix
Happy Christmas!
Folks, I wish all of you a very happy christmas and a fulfilling and pleasant new year! cheers felix
