Re: [Chicken-announce] [ANN] CHICKEN 5.3.0 release candidate available
Hi, all seems to work, yet installing "sendfile", "http-session", "srfi-18" gave: ``` Warning: Deprecated identifier `current-milliseconds' ``` Otherwise: Operating system: Ubuntu Mate 20.04 Hardware platform: x86-64 C Compiler: gcc 10.3.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes Best Christian - On Aug 12, 2021, at 12:28 PM, Peter Bex pe...@more-magic.net wrote: > Hello everyone, > > We are happy to announce the first release candidate of the upcoming > CHICKEN 5.3.0. > > CHICKEN 5.3.0rc1 is now available at this location: > https://code.call-cc.org/dev-snapshots/2021/08/12/chicken-5.3.0rc1.tar.gz > > The SHA256 sum of that tarball is > 61d59cb4f3ca226995d7dca3510c7a646c2cf1e28ebc771bf6c5177e28d14c81 > > This is bugfix release which takes care of several important issues. > > Irregex has been updated to the latest upstream (0.9.10), which fixes > a few issues with bol handling and irregex-replace/all with positive > lookbehind replaces all matches rather than just the first. > > A few bugs in the module system's handling of reexport have been fixed, > as well as a few bugs in the optimization of using argvector directly > in rest arguments, and a nasty issue where mutated parameters would be > reset if the mutation happened in a signal handler. > > A nice improvement is that to build CHICKEN, on most platforms you no > longer need to provide the PLATFORM variable to Make; we auto-detect > the platform you're building on. Of course, for cross-compilation > you'll still have to set it. > > Finally, we tweaked the garbage collector to avoid thrashing when the > heap was almost full. This should drastically improve performance for > certain usage patterns that trigger this pathological behaviour. > > The complete list of changes since version 5.2.0 is available here: > https://code.call-cc.org/dev-snapshots/2021/08/12/NEWS > > Please give it a test and report your findings to the mailing list. > > Here's a suggested test procedure: > > $ make PREFIX= install check > $ /bin/chicken-install pastiche > > If you want to build CHICKEN with a compiler other than the default one, > just use C_COMPILER= (e.g., C_COMPILER=clang) on the make > invocation. > > Of course, feel free to explore other supported build options (see the > README file for more information) and actually use CHICKEN 5.3.0rc1 for > your software. > > If you can, please let us know the following information about the > environment you tested the RC tarball on: > > Operating system: (e.g., FreeBSD 12.0, Debian 9, Windows 10 mingw-msys under > mingw32) > Hardware platform: (e.g., x86, x86-64, PPC) > C Compiler: (e.g., GCC 6.4.0, clang 5.0.0) > Installation works?: yes or no > Tests work?: yes or no > Installation of eggs works?: yes or no > > Thanks in advance! > > The CHICKEN Team -- Dr. rer. nat. Christian Himpe Computational Methods in Systems and Control Theory Max Planck Institute for Dynamics of Complex Technical Systems Sandtorstr. 1 39106 Magdeburg Germany https://himpe.science
Reository Path, FAQ, and Index Questions
Hello, I would like to ask how I can programmatically determine the system location of eggs? I ask because if I installed an egg to a user directory and I want to use the system's eggs as well as the user egg, it seems I need to have the system's and the user egg repository in the CHICKEN_REPOSITORY_PATH environment variable. As the system's location may differ among operating systems, I would like to determine this path from the command line and add it by script. Also, is it possible that the "How can I install CHICKEN eggs to a non-default location?" section of the "Frequently Asked Question": http://wiki.call-cc.org/faq#how-can-i-install-chicken-eggs-to-a-non-default-location is out of date? "chicken-install -init" and "(repository-path ...)" seem not be available in CHICKEN Scheme 5.2, unless I am using it incorrectly. Lastly, I would like to ask if CHICKEN Scheme has a function/symbol index, as for example Chez Scheme has: https://www.scheme.com/csug8/csug_1.html and I just overlooked it? Thank You Christian
Re: Performance question concerning chicken flonum vs "foreign flonum"
felix.winkelm...@bevuta.com schrieb am 2021-11-04:
> > 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
Dear Felix,
thank you for ypur explanantions. I tested your modified source and indeed the
number of GCs is significantly reduced, but the timing difference remains:
original code:
7.656s CPU time, 0/225861 GCs (major/minor), maximum live heap: 30.78 MiB
8.849s CPU time, 0/256410 GCs (major/minor), maximum live heap: 30.78 MiB
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?
Thank you
Christian
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*+: #;2> (fp*+ 1.0 2.0 3.0) Error: unbound variable: g18021803 Call history: (fp*+ 1.0 2.0 3.0) (fp*+ 1.0 2.0 3.0)<-- But, fp*+ is found: #;2> (procedure? fp*+) #t I performed the following build steps: git clone git://code.call-cc.org/chicken-core cd, mv etc. patch -p1 < 0001-Add-support-for-fused-multiply-add.patch make PREFIX=XXX PLATFORM=linux OPTIMIZE_FOR_SPEED=1 CHICKEN=XXX/chicken52/bin/chicken make PREFIX=XXX PLATFORM=linux install Best Christian felix.winkelm...@bevuta.com schrieb am 2021-11-07: > 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 -- Dr. rer. nat. Christian Himpe University of Münster / Applied Mathematics Münster Orléans-Ring 10 / 48149 Münster / Germany https://himpe.science
Re: Performance question concerning chicken flonum vs "foreign flonum"
felix.winkelm...@bevuta.com schrieb am 2021-11-07: > > 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 Dear felix, the latest patch works. I extended my test code and here are the results: without -C -mfma: csc -O5 -d0 -C -O3 fma-test.scm && ./fma-test 7.998s CPU time, 0/225861 GCs (major/minor), maximum live heap: 30.78 MiB 10.104s CPU time, 0/256410 GCs (major/minor), maximum live heap: 30.78 MiB 10.69s CPU time, 0/311364 GCs (major/minor), maximum live heap: 30.78 MiB with -C -mfma: csc -O5 -d0 -C -O3 -C -mfma fma-test.scm && ./fma-test 7.697s CPU time, 0/238095 GCs (major/minor), maximum live heap: 30.78 MiB 9.135s CPU time, 0/262467 GCs (major/minor), maximum live heap: 30.78 MiB 11.008s CPU time, 0/317460 GCs (major/minor), maximum live heap: 30.78 MiB It seems the number of GCs is a lot higher than for fp*/fp+ or c99-fma with or without fma compiler flag. So currently, there seems to be no benefit integrating c99's fma as fp*+ besides a slightly better rounding error. At least for me, this comes unexpected. Thank you for providing the patch. If you want to test something in this regard in the future, I am happy to test further patches. Cheers Christian
Re: Performance question concerning chicken flonum vs "foreign flonum"
Christian Himpe schrieb am 2021-11-07: > felix.winkelm...@bevuta.com schrieb am 2021-11-07: > > > 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 > Dear felix, > the latest patch works. I extended my test code and here are the results: > without -C -mfma: > csc -O5 -d0 -C -O3 fma-test.scm && ./fma-test > 7.998s CPU time, 0/225861 GCs (major/minor), maximum live heap: 30.78 MiB > 10.104s CPU time, 0/256410 GCs (major/minor), maximum live heap: 30.78 MiB > 10.69s CPU time, 0/311364 GCs (major/minor), maximum live heap: 30.78 MiB > with -C -mfma: > csc -O5 -d0 -C -O3 -C -mfma fma-test.scm && ./fma-test > 7.697s CPU time, 0/238095 GCs (major/minor), maximum live heap: 30.78 MiB > 9.135s CPU time, 0/262467 GCs (major/minor), maximum live heap: 30.78 MiB > 11.008s CPU time, 0/317460 GCs (major/minor), maximum live heap: 30.78 MiB > It seems the number of GCs is a lot higher than for fp*/fp+ or c99-fma with > or without fma compiler flag. So currently, there seems to be no benefit > integrating c99's fma as fp*+ besides a slightly better rounding error. At > least for me, this comes unexpected. > Thank you for providing the patch. If you want to test something in this > regard in the future, I am happy to test further patches. > Cheers > Christian 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. Thank you very much Christian
Module Exports
Dear All, I was wondering about module definition, particularly about the export syntax. The documentation ( http://wiki.call-cc.org/man/5/Modules ) states that a module is defined by: (module NAME (EXPORT ...) BODY ...) Now, there also exists an `(export ...)` form for appending the exports from the module body. So if I define a module by: (module NAME (export EXPORT ...) BODY ...) what happens? Will the `export` form be exported, or expanded here? I assume the former, but in case of the latter, is this a legal module definition? Maybe this works differently altogether? I tried this (and it seems to work), as I would find it more readable if used right above `import`, `reexport`, etc. Thank you Christian
Egg release: matrico 0.2
Dear All, I released version 0.2 of the "matrico" egg: http://wiki.call-cc.org/eggref/5/matrico . Feedback is appreciated Christian
Re: CHICKEN version dependent expansion
Mario Domenech Goulart schrieb am 2022-06-28: > Hi, > On Tue, 28 Jun 2022 23:00:37 +0300 Lassi Kortela wrote: > >>> #;1> (cond-expand (chicken-5 'a) (chicken 'b) (else 'c)) > >>> a > >> This only seems to let me differentiate between major versions and > > not minor versions, am I correct? I would need to decide based on > > minor versions. > > > > #;2> (cond-expand (chicken-5.3 'a) (else 'b)) > > a > > > > To find these, I used the r7rs egg (since the r7rs standard mandates a > > `features` procedure). > > > > $ chicken-install r7rs > > $ csi -R r7rs > > #;1> (features) > > (r7rs srfi-13 srfi-14 ...) > There's also `features' from chicken.platform, in case you don't want to > depend on the r7rs egg only for that. Sorry, I totally overlooked this function, and solely relied on the online docu. Christian > All the best. > Mario > -- > http://parenteses.org/mario -- Dr. rer. nat. Christian Himpe University of Münster / Applied Mathematics Münster Orléans-Ring 10 / 48149 Münster / Germany https://himpe.science
Re: CHICKEN version dependent expansion
Christian Himpe schrieb am 2022-06-28: > Lassi Kortela schrieb am 2022-06-28: > > >I am trying to define a function depending on the version of CHICKEN. I > > >was thinking to use "cond-expand" for this purpose, but found no suitable > > >feature in the documentation > > #;1> (cond-expand (chicken-5 'a) (chicken 'b) (else 'c)) > > a > This only seems to let me differentiate between major versions and not minor > versions, am I correct? I would need to decide based on minor versions. But > thanks nonetheless, "chicken-5" seems not to be mentioned in the docu. > Christian OK, I just blindly tested with minor versions, i.e.: chicken-5.X, and it seems to work. Should I add this to the docu? Great! -- Dr. rer. nat. Christian Himpe University of Münster / Applied Mathematics Münster Orléans-Ring 10 / 48149 Münster / Germany https://himpe.science
Re: CHICKEN version dependent expansion
Lassi Kortela schrieb am 2022-06-28: > >>#;1> (cond-expand (chicken-5 'a) (chicken 'b) (else 'c)) > >>a > >This only seems to let me differentiate between major versions and not minor > >versions, am I correct? I would need to decide based on minor versions. > #;2> (cond-expand (chicken-5.3 'a) (else 'b)) > a > To find these, I used the r7rs egg (since the r7rs standard mandates a > `features` procedure). > $ chicken-install r7rs > $ csi -R r7rs > #;1> (features) > (r7rs srfi-13 srfi-14 ...) Thanks again! -- Dr. rer. nat. Christian Himpe University of Münster / Applied Mathematics Münster Orléans-Ring 10 / 48149 Münster / Germany https://himpe.science
Re: CHICKEN version dependent expansion
Lassi Kortela schrieb am 2022-06-28: > >I am trying to define a function depending on the version of CHICKEN. I was > >thinking to use "cond-expand" for this purpose, but found no suitable > >feature in the documentation > #;1> (cond-expand (chicken-5 'a) (chicken 'b) (else 'c)) > a This only seems to let me differentiate between major versions and not minor versions, am I correct? I would need to decide based on minor versions. But thanks nonetheless, "chicken-5" seems not to be mentioned in the docu. Christian
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. Best Christian Wolfgang Corcoran-Mathe schrieb am 2022-07-09: > On 2022-07-08 09:11 +0200, Christian Himpe wrote: > > I released version 0.2 of the "matrico" egg > I just installed matrico 0.2 and ran all tests successfully. > Thanks for your work. > I'm a little surprised that you use -O4. This uses the -unsafe > flag, which disables runtime checks. I see why you want maximum > optimization for this library, but I'd be happier with -O3. > (Maximum "safe" optimization.) > Regards, Wolf > -- > Wolfgang Corcoran-Mathe -- Dr. rer. nat. Christian Himpe University of Münster / Applied Mathematics Münster Orléans-Ring 10 / 48149 Münster / Germany https://himpe.science
CHICKEN version dependent expansion
Dear All,
I am trying to define a function depending on the version of CHICKEN. I was
thinking to use "cond-expand" for this purpose, but found no suitable feature
in the documentation (
http://wiki.call-cc.org/man/5/Extensions%20to%20the%20standard#cond-expand )
that could achieve this, only if a CHICKEN is currently expanding. R7RS
suggests such features (in Appendix B: ) and other Schemes such
as Guile (
https://www.gnu.org/software/guile/manual/html_node/SRFI_002d0.html#index-cond_002dexpand
) and Gauche (
https://practical-scheme.net/gauche/man/gauche-refe/Feature-conditional.html#index-cond_002dexpand
) provide such features. Did I miss something in the documentation, or is
there an alternative ("R5RS") way to do this?
Thank You
Christian
Re: New Egg: matrico
Hi, I would appreciate if somebody could verify that "matrico" can be fetched and installed. Here is the `.release-info`: https://raw.githubusercontent.com/gramian/matrico/main/matrico.release-info Thank you very much Christian Mario Domenech Goulart schrieb am 2022-04-29: > Hi Christian, > On Thu, 28 Apr 2022 22:21:26 +0200 (CEST) Christian Himpe > wrote: > > I would like to communicate the pre-release of the "matrico" egg, > > which provides real-valued flonum matrix functionality for numerical > > computation and linear algebra in pure CHICKEN Scheme: > > > > https://github.com/gramian/matrico > > > > This project is still in (early) development, and I welcome feedback > > in general, but particularly on what needs to be added or fixed to be > > included into the official egg index, egg repository and egg reference > > (I prepared some documentation under `doc/matrico.wiki`). Thank you! > Thanks! > For us to add your egg to the egg index our tools must be able to fetch > and install it. > You can test that process with test-new-egg: > http://wiki.call-cc.org/eggs%20tutorial#testing-your-extension > All the best. > Mario > -- > http://parenteses.org/mario
Re: New Egg: matrico
Dear Mario, Mario Domenech Goulart schrieb am 2022-04-30: > On Sat, 30 Apr 2022 15:10:21 +0200 (CEST) Christian Himpe > wrote: > > I would appreciate if somebody could verify that "matrico" can be > > fetched and installed. Here is the `.release-info`: > > > > https://raw.githubusercontent.com/gramian/matrico/main/matrico.release-info > > > > Thank you very much > Thank you. Your egg has been added to the coop. Thanks! > P.S.: According to the declaration in the .egg file the egg is > Linux-specific. Not sure if that's intentional or if the declaration is > some leftover from tests. I was particularly unsure about handling of #\newline on Windows. As I do not have a Windows system at hand, I was not able to test. For now, I removed the platform configuration and I will wait for a bug report. I also added my documentation in the wiki. Best Christian > All the best. > Mario > -- > http://parenteses.org/mario
New Egg: matrico
Dear All, I would like to communicate the pre-release of the "matrico" egg, which provides real-valued flonum matrix functionality for numerical computation and linear algebra in pure CHICKEN Scheme: https://github.com/gramian/matrico This project is still in (early) development, and I welcome feedback in general, but particularly on what needs to be added or fixed to be included into the official egg index, egg repository and egg reference (I prepared some documentation under `doc/matrico.wiki`). Thank you! Best Christian
Egg release: matrico 0.3
Dear All, I released version 0.3 of the "matrico" egg: http://wiki.call-cc.org/eggref/5/matrico . Feedback is, as always, very much appreciated Christian PS: @Wolf: As by your suggestion, the default optimization level for this egg is now `-O3`.
http-client egg and authentication
Dear All, I am exploring the use of the http-client egg ( http://wiki.call-cc.org/eggref/5/http-client ) for communicating with a database server. For this I need some basic authentication, which I did not get to work. I tried including: (determine-username/password (lambda (uri realm) (values "myuser" "mypass"))) (see http://wiki.call-cc.org/eggref/5/http-client#authentication-support ), which returns a 403 (Forbidden). However, authenticated communication works with the server from the shell with "curl" using the argument "--user myuser:mypass" ( https://curl.se/docs/manpage.html#-u ). I assume I am missing, overlooking or doing something wrong here. Does somebody have experience with this, or know some sample code? Thank You Christian
Re: http-client egg and authentication
Dear All, so I found this recent StackOverflow issue: https://stackoverflow.com/questions/72904388/how-do-i-use-http-basic-auth-with-http-client based on which I tried to use `make-uri` and pass the URI record (including credentials) to the http-client. This also gives a 403 reply from the server. I also tried manually encoding `"myuser:mypass"` as base64 without use. As a sidenote, using `uri-common`, I was not able to get a slash between port and path from `make-uri`; I had to use `(update-uri (uri-reference ...) ...)`. @Vasilij: Thanks for testing and explaining. Best Christian Christian Himpe schrieb am 2022-09-25: > Dear All, > I am exploring the use of the http-client egg ( > http://wiki.call-cc.org/eggref/5/http-client ) for communicating with a > database server. For this I need some basic authentication, which I did not > get to work. I tried including: > (determine-username/password (lambda (uri realm) (values "myuser" "mypass"))) > (see http://wiki.call-cc.org/eggref/5/http-client#authentication-support ), > which returns a 403 (Forbidden). However, authenticated communication works > with the server from the shell with "curl" using the argument "--user > myuser:mypass" ( https://curl.se/docs/manpage.html#-u ). > I assume I am missing, overlooking or doing something wrong here. Does > somebody have experience with this, or know some sample code? > Thank You > Christian
Re: New Egg: arcadedb
Hi Mario, Thank you for adding my egg. With regard to your dependency remark: I assume you refer to the README docs and not .egg file(?), which I will clarify. Please let me know if I made an error in the .egg file. Best Christian > On 15. Nov 2022, at 19:36, Mario Domenech Goulart > wrote: > > Hi Christian, > > On Tue, 15 Nov 2022 00:44:45 +0100 Christian Himpe > wrote: > >> I would like to announce the first release candidate of the “arcadedb” >> egg with a repository at GitHub: >> >> https://github.com/gramian/chicken-arcadedb >> >> This egg provides a driver / client for the multi-model NoSQL database >> ArcadeDB ( https://arcadedb.com ) in CHICKEN Scheme, and requires a >> running database instance. Feel free to give feedback or ask >> questions. >> >> PS: Testing the egg with: >> >> test-new-egg arcadedb >> https://raw.githubusercontent.com/gramian/chicken-arcadedb/main/arcadedb.release-info >> >> tests pass, except “Checking version” (—), “Testing” (—), and “Checking >> documentation” (fail). > > Thanks! Your egg has been added to the coop. > > A note regarding dependencies: they are usually mentioned as build time > dependencies. I have a feeling the dependencies you mention are run > time ones. Maybe you want to clarify that in the documentation. > > All the best. > Mario > -- > http://parenteses.org/mario >
New Egg: arcadedb
Dear All, I would like to announce the first release candidate of the “arcadedb” egg with a repository at GitHub: https://github.com/gramian/chicken-arcadedb This egg provides a driver / client for the multi-model NoSQL database ArcadeDB ( https://arcadedb.com ) in CHICKEN Scheme, and requires a running database instance. Feel free to give feedback or ask questions. Cheers Christian PS: Testing the egg with: test-new-egg arcadedb https://raw.githubusercontent.com/gramian/chicken-arcadedb/main/arcadedb.release-info tests pass, except “Checking version” (—), “Testing” (—), and “Checking documentation” (fail).
Re: Deprecated current-milliseconds
> On 7. Dec 2023, at 13:20, Peter Bex wrote: > > On Thu, Dec 07, 2023 at 12:48:34PM +0100, Vasilij Schneidermann wrote: >> Hello, >> >> the openssl egg does no longer produce the warning in version 2.2.5 by >> either importing the new or old identifier, depending on whichever is >> available. Feel free to use that approach in the other egg and consider that >> it may skew the grep results. > > So does the sendfile egg. > > Cheers, > Peter In the “matrico” egg (file “matrico.scm"), the string “current-milliseconds” just appears to provide “current-process-milliseconds” to CHICKEN version before 5.3, see: https://github.com/gramian/matrico/blob/main/matrico.scm#L66 . Best Christian
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. Thanks for your help and insights Christian
Re: Commented by default
> On 27. Apr 2024, at 20:02, felix.winkelm...@bevuta.com wrote: > >> 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 > Dear felix, This looks like a very good starting point. Thank you for pointing me in the right direction. Cheers Christian
Re: [Chicken-announce] [ANN] CHICKEN 5.4.0 release candidate available
Hi, here are my 5.4rc1 results: HW: MacBook Air M2 (arm64) OS: macos Montery 12.7.5 CC: clang 14.0.0 Installation works?: yes Tests work?: no (see attachment) Installation of "pastiche" egg works?: yes Installation of “arcadedb" egg works?: yes Installation of "matrico" egg works?: no (see attachment, it works with brew-installed chicken-5.3) Best Christian check.log Description: Binary data matrico.log Description: Binary data > On 31. May 2024, at 10:08, Peter Bex wrote: > > Hello everyone, > > We are happy to announce the first release candidate of the upcoming > CHICKEN 5.4.0. > > CHICKEN 5.4.0rc1 is now available at this location: > https://code.call-cc.org/dev-snapshots/2024/05/31/chicken-5.4.0rc1.tar.gz > > The SHA256 sum of that tarball is > 61d59cb4f3ca226995d7dca3510c7a646c2cf1e28ebc771bf6c5177e28d14c81 > > This is mostly a bugfix and maintenance release, preparing for the > upcoming CHICKEN 6 release (hopefully later this year). > > It contains some security hardening regarding option parsing and a > fix for CVE-2022-45145 handling of escape characters in egg metadata. > > Notable new features are new thread-safe APIs for POSIX signals and > finalizers, support for weak pairs and having line numbers available > on error traces in the interpreter. > > The complete list of changes since version 5.3.0 is available here: > https://code.call-cc.org/dev-snapshots/2024/05/31/NEWS > > Please give it a test and report your findings to the mailing list. > > Here's a suggested test procedure: > > $ make PREFIX= install check > $ /bin/chicken-install pastiche > > If you want to build CHICKEN with a compiler other than the default one, > just use C_COMPILER= (e.g., C_COMPILER=clang) on the make > invocation. > > Of course, feel free to explore other supported build options (see the > README file for more information) and actually use CHICKEN 5.3.0rc1 for > your software. > > If you can, please let us know the following information about the > environment you tested the RC tarball on: > > Operating system: (e.g., FreeBSD 14.0, Debian 12, Windows 11 mingw-msys under > mingw32) > Hardware platform: (e.g., x86, x86-64, PPC) > C Compiler: (e.g., GCC 11.3.0, clang 16.0.6) > Installation works?: yes or no > Tests work?: yes or no > Installation of eggs works?: yes or no > > Thanks in advance! > > The CHICKEN Team >
Re: [ANN] CHICKEN 5.4.0 release candidate 2 available
Hi, Thanks for the rc1 fixes! Here are my 5.4-rc2 results: HW: MacBook Air M2 (arm64) OS: macos Montery 12.7.5 CC: clang 14.0.0 & gcc 14.1.0 Installation works?: yes Tests work?: yes Installation and tests of "pastiche" egg works?: yes Installation and tests of "matrico" egg works?: yes Installation of "arcadedb" egg works?: yes I built with: make PREFIX=/tmp/chicken PLATFORM=macosx C_COMPILER=gcc install check Cheers Christian > On 25. Jun 2024, at 10:21, Peter Bex wrote: > > Hello all, > > The second release candidate for CHICKEN 5.4.0 is now available for > download: > > https://code.call-cc.org/dev-snapshots/2024/06/25/chicken-5.4.0rc2.tar.gz > > The sha256sum of that tarball is: > > 4733f7eaffbb9917605314fbc820ae693cb05a4d6829a229b0340ecd81479d72 > > The list of changes since 5.3.0 and 5.4.0rc1 is available here: > > https://code.call-cc.org/dev-snapshots/2024/06/25/NEWS > > This release candidate fixes a problem with chicken-install on > Windows when using the native shell, which would lead to empty .egg-info > files. The other fixes are all minor, mostly fixing build and test > suite issues. > > Please give it a test and report your findings to the mailing list. > > Here's a suggested test procedure: > > $ make PREFIX= install check > $ /bin/chicken-install pastiche > > If you want to build CHICKEN with a compiler other than the default one, > just use C_COMPILER= (e.g., C_COMPILER=clang) on the make > invocation. > > Of course, feel free to explore other supported build options (see the > README file for more information) and actually use CHICKEN 5.3.0rc2 for > your software. > > If you can, please let us know the following information about the > environment you tested the RC tarball on: > > Operating system: (e.g., FreeBSD 14.0, Debian 12, Windows 11 mingw-msys under > mingw32) > Hardware platform: (e.g., x86, x86-64, PPC) > C Compiler: (e.g., GCC 11.3.0, clang 16.0.6) > Installation works?: yes or no > Tests work?: yes or no > Installation of eggs works?: yes or no > > Thanks in advance! > > The CHICKEN Team >
