Re: Question about how to check a symbol is bound
On 28/06/2023 14:09, felix.winkelm...@bevuta.com wrote: 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). Oh, and as a side thing, I don't think this is exactly "unhygienic". Well, the thing I'm trying to do is hygienic, and I'm just being forced to explore unhygienic techniques to try and recreate that hygienic solution. After all, we can do: (define-for-syntax foo 123) (define-syntax ... ... foo ...) ...and get 123 out of foo at macro expansion time. What I want to be able to do is: (define-inner-thing X 123) (define-outer-thing Y (X)) ...and have define-outer-thing's macro expander be able to get 123 from X. It doesn't really need to know about X as a symbol, and all this symbol-value nastiness is just a way to try and convert from X passed to it as a symbol to the value of X, which I'd rather do in a hygienic manner - if I could! Of course, we can do something like this: (define-syntax define-inner-thing (ir-macro-transformer ... `(define-syntax ,NAME (syntax-rules (context1 context2) ((_ context1) ,generated-code-for-context1) ((_ context2) ,generated-code-for-context2 ...) (define-syntax define-outer-thing (syntax-rules () ((define-outer-thing NAME ((FIELD TYPE) ...)) ...(TYPE context1)... ...(TYPE context2)...))) ...and thereby have define-inner-thing use arbitrary low-level macros to generate arbitrary code snippets and wrap them in a macro binding, that define-outer-thing can then pull out by invoking the macro. But define-outer-thing can only splice the generated code into its expansion, and not do things like combined generated ssql snippets and ssql->sql them at macro expansion time, which would be nice: if I follow that path I'll need to expand to code that calls a pure function on constant arguments at runtime. felix -- Alaric Snell-Pym (M0KTN neé M7KIT) http://www.snell-pym.org.uk/alaric/ OpenPGP_signature Description: OpenPGP digital signature
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! felix Thanks, -- Alaric Snell-Pym (M0KTN neé M7KIT) http://www.snell-pym.org.uk/alaric/ OpenPGP_signature Description: OpenPGP digital signature
Re: Question about how to check a symbol is bound
On 23/06/2023 14:35, Kon Lovett wrote: (symbol-value foo #f) Error: unbound variable: foo #;2> (symbol-value 'foo #f) #f (symbol-value foo #f) is asking for the symbol-value of the derefed variable `foo’ Does anybody have any tips for using symbol-value at macroexpansion time? I am trying to port a library from chicken 4 to 5, that lets users write something along these lines (full details available on request, I'm trying to just extract and summarise the important parts here): (define-custom-type foo ...some metadata...) And then later: (define-object-type bar ...list of fields and types...) Eg: ;; A foo contains three strings (define-custom-type foo string string string) (define-object-type bar (field-1 foo) (field-2 some-other-type)) Now, the implementation of define-object-type needs to be able to examine the contents of the foo custom-type at macro expansion time (to give a bit more detail, this is a wrapper around a SQL database and it needs to know the structure of everything to pre-generate SQL queries, create table statements, and so on) I've had partial success with making define-custom-type expand into a define-for-syntax that wraps a processed form of its metadata into a value and binds it to the symbol "foo", then making define-object-type find the type name symbols and call symbol-value on them - but this doesn't work if the type name is imported from a library. Even if I make the user write: (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. Is there a way to do what I want? I'm also working on an alternate approach - where define-custom-type defines a macro that actually embeds the parts of the implementation of define-object-type that depend on the structure and make define-object-type invoke that macro as part of its expansion - but it's so inside out it makes my head hurt so I'm not 100% sure it'll be possible yet (at the very least, it might leave some string/list concatenation to run time, which is disappointing). And it's a sad violation of abstraction boundaries between define-custom-type and define-object-type. Hey ho. PS: Hi everyone! I'm still alive! -- Alaric Snell-Pym (M0KTN neé M7KIT) http://www.snell-pym.org.uk/alaric/ OpenPGP_signature Description: OpenPGP digital signature
I ported the combinators egg to chicken 5
Hi there Kon, As I was porting something that needed it, I did a quick port of the combinators egg to C5... I did it with cond-expand so the same codebase works for C4 and C5 rather than making a new fork. Please find it attached - if you like it it's all yours, and I'll gladly add it to the C5 egg list if you wish :-) Thanks for the eggs, Alaricdiff combinators/bi-combinators.scm combinators.c5/bi-combinators.scm 10,11c10 < scheme < chicken) --- > scheme) 12a12,16 > (cond-expand >(chicken-4 > (import chicken)) >(chicken-5 > (import (chicken base diff combinators/generic-section-combinators.scm combinators.c5/generic-section-combinators.scm 16,20c16 < (import < (except scheme map) < chicken < (only data-structures identity) < (only srfi-1 circular-list map)) --- > (import (except scheme map)) 22c18,29 < (require-library data-structures srfi-1) --- > (cond-expand >(chicken-4 > (require-library data-structures srfi-1) > (import > > chicken > (only data-structures identity) > (only srfi-1 circular-list map))) >(chicken-5 > (import (chicken base)) > (import > (only srfi-1 circular-list map diff combinators/logical-combinators.scm combinators.c5/logical-combinators.scm 10c10,17 < (import scheme chicken data-structures srfi-1) --- > (import scheme) > > (cond-expand >(chicken-4 > (import chicken data-structures srfi-1)) >(chicken-5 > (import (chicken base)) > (import srfi-1))) diff combinators/section-combinators.scm combinators.c5/section-combinators.scm 13,16c13,24 < scheme < chicken < (only srfi-1 drop drop-right circular-list) < (only data-structures identity)) --- > scheme) > > (cond-expand >(chicken-4 > (import chicken) > (import (only srfi-1 drop drop-right circular-list)) > (import (only data-structures identity)) > (require-library srfi-1)) >(chicken-5 > (import (chicken base)) > (import (only srfi-1 drop drop-right circular-list)) > (import (only (chicken base) identity 18d25 < (require-library srfi-1) diff combinators/sort-combinators.scm combinators.c5/sort-combinators.scm 12,16c12 < (import < scheme < chicken < (only srfi-1 span) < (only bi-combinators bi-each)) --- > (import scheme) 18c14,23 < (require-library srfi-1 bi-combinators) --- > (cond-expand >(chicken-4 > (import chicken) > (import (only srfi-1 span)) > (import (only bi-combinators bi-each)) > (require-library srfi-1 bi-combinators)) >(chicken-5 > (import (chicken base)) > (import (only srfi-1 span)) > (import (only bi-combinators bi-each diff combinators/stack-combinators.scm combinators.c5/stack-combinators.scm 18c18 < (import scheme chicken) --- > (import scheme) 19a20,24 > (cond-expand >(chicken-4 > (import chicken)) >(chicken-5 > (import (chicken base diff combinators/tri-combinators.scm combinators.c5/tri-combinators.scm 10,12c10,16 < scheme < chicken) < --- >scheme) > > (cond-expand >(chicken-4 > (import chicken)) >(chicken-5 > (import (chicken base diff combinators/uni-combinators.scm combinators.c5/uni-combinators.scm 9,11c9,15 < (import < scheme < chicken) --- > (import scheme) > > (cond-expand >(chicken-4 > (import chicken)) >(chicken-5 > (import (chicken base combinators.meta -*- Hen -*- ((category data) (author "[[kon lovett]]") (license "Public Domain") (synopsis "Combinators") (test-dependencies test) (version "1.2.1") (components (extension uni-combinators (csc-options -optimize-level 3)) (extension bi-combinators (csc-options -optimize-level 3)) (extension tri-combinators (csc-options -optimize-level 3)) (extension section-combinators (csc-options -optimize-level 3)) #;(extension generic-section-combinators (csc-options -optimize-level 3)) (extension logical-combinators (csc-options -optimize-level 3)) (extension sort-combinators (csc-options -optimize-level 3) (component-dependencies bi-combinators)) (extension stack-combinators (csc-options -optimize-level 3
Chicken 5 ports of pkbdf2 and md2
Hi there!
As it was needed by something else I had to port, I did a quick port of
pbkdf2 and md2 to chicken 5 - using cond-expand so the same codebase can
work for C5 and C4, it's not a fork.
Also, I have a copy of a patch to md2 by Andy Bennett for C89 support
that I based the C5 port on top of, and he'd be delighted if that got
merged in upstream as well.
I've attached them all as patches, if you'd like to commit it to the
repo I'd be happy to add them to the C5 egg list so it can be installed
with chicken-install :-)
Hope you like it & thanks for the eggs in the first place,
Alaric Snell-PymFrom dc512f953cf5cda5bb1de4af0960f4f93e391c57 Mon Sep 17 00:00:00 2001
From: Alaric Snell-Pym
Date: Tue, 24 Nov 2020 13:06:19 +
Subject: Support Chicken 5
diff --git a/pbkdf2.egg b/pbkdf2.egg
new file mode 100644
index 000..b0ff965
--- /dev/null
+++ b/pbkdf2.egg
@@ -0,0 +1,10 @@
+((license "BSD")
+ (category crypt)
+ (dependencies message-digest hmac sha2 sha1 md5 md2)
+ (test-dependencies test)
+ (version "1.2")
+ (author "Tobias Heilig")
+ (synopsis "Password-Based Key Derivation Function as defined in RFC2898")
+ (components
+ (extension pbkdf2)))
+
diff --git a/pbkdf2.scm b/pbkdf2.scm
index 687afab..c8bf42c 100644
--- a/pbkdf2.scm
+++ b/pbkdf2.scm
@@ -48,9 +48,27 @@
pbkdf2-hmac-sha512)
- (import chicken scheme)
+ (import scheme)
+
+ (cond-expand
+ (chicken-4
+(import chicken)
+(use srfi-1 srfi-4 srfi-13 message-digest hmac sha2 sha1 md5 md2))
+ (chicken-5
+(import (chicken base))
+(import (chicken bitwise))
+(import (chicken blob))
+(import srfi-1)
+(import srfi-4)
+(import srfi-13)
+(import message-digest)
+(import hmac)
+(import sha2)
+(import sha1)
+(import md5)
+(import md2)))
+
- (use srfi-1 srfi-4 srfi-13 message-digest hmac sha2 sha1 md5 md2)
(define (^ s1 s2)
diff --git a/tests/run.scm b/tests/run.scm
index 2235ef8..3345982 100644
--- a/tests/run.scm
+++ b/tests/run.scm
@@ -5,7 +5,13 @@
-(use test pbkdf2)
+(cond-expand
+ (chicken-4
+ (use test pbkdf2))
+ (chicken-5
+ (import (chicken blob))
+ (import test)
+ (import pbkdf2)))
From ffb6f4aa296e93cdb534cacaad467609defdf302 Mon Sep 17 00:00:00 2001
From: Alaric Snell-Pym
Date: Tue, 24 Nov 2020 13:04:17 +
Subject: Support Chicken 5
diff --git a/md2.egg b/md2.egg
new file mode 100644
index 000..7c7b90f
--- /dev/null
+++ b/md2.egg
@@ -0,0 +1,10 @@
+((license "BSD")
+ (category crypt)
+ (dependencies message-digest)
+ (test-dependencies test message-digest)
+ (author "Tobias Heilig")
+ (synopsis "Message Digest 2 algorithm as defined in RFC1319")
+ (version "1.2")
+ (components
+ (extension md2)))
+
diff --git a/md2.scm b/md2.scm
index dba2f3d..09e27a1 100644
--- a/md2.scm
+++ b/md2.scm
@@ -41,10 +41,18 @@
(md2-primitive)
- (import chicken scheme foreign)
-
- (use message-digest)
+ (import scheme)
+ (cond-expand
+ (chicken-4
+(import chicken)
+(import foreign)
+(use message-digest))
+ (chicken-5
+(import (chicken base))
+(import (chicken foreign))
+(import message-digest)))
+
#>#include "md2-base.c"<#
From 90c6a5b7cc94a6c84b917ada29ffd84e49268d0e Mon Sep 17 00:00:00 2001
From: Andy Bennett
Date: Wed, 24 Jul 2019 14:54:27 +0100
Subject: Support C89 for CHICKEN 4.9
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
With GCC 4.9.2 (Debian Jessie 8.11) installation fails:
-
In file included from md2.c:13:0:
md2-base.c: In function âMD2_Updateâ:
md2-base.c:149:5: error: âforâ loop initial declarations are only allowed in C99 or C11 mode
for (size_t i = 0; i < len; ++i) {
^
md2-base.c:149:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
-
However, GCC Version 5.1.0 changed the default from -std=gnu90 to
-std=gnu11.
Signed-off-by: Andy Bennett
diff --git a/md2-base.c b/md2-base.c
index 808c453..24e3617 100644
--- a/md2-base.c
+++ b/md2-base.c
@@ -145,8 +145,9 @@ MD2_Init (MD2_CTX *ctx)
void
MD2_Update (MD2_CTX *ctx, const BYTE *data, size_t len)
{
+size_t i = 0;
-for (size_t i = 0; i < len; ++i) {
+for (i = 0; i < len; ++i) {
ctx->data[ctx->len] = data[i];
ctx->len++;
Re: Establishing Git repos for miscellaneous Chicken tools
On 17/11/2020 18:41, Lassi Kortela wrote: > Given: > > - a GitHub organization would be preferred for ease of maintenance by > Dan and Vasilij who have written some of the Chicken Emacs support so far > > - you and I don't object to GH > > - nobody else has said anything > > - a decision seems hard to make > > should we just make a `chicken-tools` org on GitHub? That would let us > resolve the current stagnation in maintaining these packages, and if we > disable the wikis and issue trackers we can move the repos to another > host later on. Sounds good to me. I'm a staunch opponent of the centralisation of the Internet by monopolies, but using free github stuff in ways that just treat it as a node in a decentralised web of git repos bleeds them of money without letting them use that to get their greedy hooks into you, so DO IT DO IT DO IT AND THEN BRING THEM CRASHING DOWN FROM WITHIN MUHAHAHAH, I reckon :-) -- Alaric Snell-Pym (2E0LOJ neé M7KIT) http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature
Re: [Chicken-users] I've gots an egg: missing.egg
On Wed, 12 Aug 2015, Alexej Magura wrote: Hey, I've got a new egg that I'm working on: https://github.com/amagura/eggs/tree/master/staging/missing/trunk Excellent! May I offer some tips? 1+ and 1- duplicate add1 and sub1, which are already in the library: http://api.call-cc.org/doc/library/add1 What is !* supposed to do? Using eval like that is most likely not a good idea. Should you be using apply instead? Something like (not (apply fn ...))? Rather than using a settings alist (note that mutation of things imported from modules is not a great idea!), it would be more idiomatic to use parameters: http://api.call-cc.org/doc/chicken/parameters Eg, export a paremter called egg-actions-need-sudo that's initialised to #f, and use the value of that in +install etc. That avoids mutation, and lets you safely override things locally (particularly in the presence of threads). This is a broad mixture of things to put into one egg, especially one claiming such a fine name as missing :-) It might be good to split the install/uninstall/upgrade stuff into an eggs egg, submit do* and setq for inclusion in miscmacros, and decide if you really need to publish the logic stuff, which seem less widely useful to me? Thanks have fun, ABS ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Any thoughts on performance woes?
On 08/04/15 09:26, arc wrote: I did interact with (or at least see some interaction with) people like Marc Feely, Anton van Straaten, Felix (pretty sure?), Alaric, et. al. They all seemed like thoroughly nice people, and it's hard to believe the intervening years have turned them all nasty... Dunno about the others but I, for one, have taken to murdering cute puppies for fun and profit. -arc. ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Correct type declarations for (call-with-... thunk) procedures
Hello folks! I've been trying to get into the habit of putting type declarations on everything I write in Chicken, to get the benefits of the lovely scrutinizer: type checks, specialisations, etc! I've also found that it's nice as documentation - I went around switching various bits of Ugarit to use typed records, and kept finding that some fields of structures were actually (or boolean ...), because I'd forgotten some things were optional. But now that's clear in the record definitions. I can certainly recommend using typed records and (: ...)-ing all your global definitions! It's being a worthwhile experience. Anyway, I have a question, as I can't figure out how to type one of my procedures. It's a (call-with-... thunk) wrapper. Indeed, it's this: (define (call-with-context-support global-rules thunk) (let ((top-level-context (parse-top-level-context global-rules))) (parameterize ((*context* top-level-context)) (thunk So I typed it: (: call-with-context-support (list (- *) - *)) However, I ran into trouble when I used it like so: (define-values (dir-key dir-reused? files bytes) (call-with-context-support (vault-global-directory-rules vault) (lambda () (store-directory! vault fspath (store-directory! ...) returns four values, and as call-with-context-support tail-calls the thunk, that works in practice. But the type checker doesn't like it, and complains that an anonymous lambda called tmpsome number expects four arguments but is called with one! So: What type should I give call-with-context-support to make it clear that it returns whatever the thunk passed to it returns, multiple values and all? I could figure out how to do it with forall if I knew how many values to expect, but I want it to work for any number of arguments! Ta, ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg: 2d-primitives
On 03/10/14 01:11, Richard wrote: To all poultry, I have created an egg called '2d-primitives', which consists of a collection of primitives and linear algebra function related to 2D graphics/games. You can find the documentation here: http://wiki.call-cc.org/eggref/4/2d-primitives I hope some people can make use of it, Oooh, convex hulls and stuff, nifty! cheers, Richard ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Using epsilon in test egg
On 29/07/14 04:58, Alex Shinn wrote: On Mon, Jul 28, 2014 at 10:09 PM, John Cowan co...@mercury.ccil.org mailto:co...@mercury.ccil.org wrote: Alex Shinn scripsit: If people think it's useful I'd consider walking pairs and vectors. They are the most important cases, because the expected value is expressed as a literal value, and that can only be a list or vector. Actually, the expected value can be anything. Literals may be the more common case though. As an interesting case in point, I have written a bunch of tests for procedures that have side-effects (where all I'm testing is that they don't raise any conditions or whatever) of the form: (test Do foo (void) (do-foo! ...)) ...which works, because I make sure I return (void) rather than some arbitrary expression from my side-effecting procedures! I've also thrown together a few macros for a common case - I have a constructor that makes an (opaque) object, and I want to test that the construction doesn't raise conditions, while keeping the value for later use. I do it with: (define-syntax test-define (syntax-rules () ((_ var expr) (test-define (-string '(define var expr)) var expr)) ((_ name var expr) (begin (define var (void)) (test-no-errors name (set! var expr)) (define-syntax test-define-values (syntax-rules () ((_ (var ...) expr) (test-define-values (-string '(define-values (var ...) expr)) (var ...) expr)) ((_ name (var ...) expr) (begin (define var (void)) ... (test-no-errors name (set!-values (var ...) expr)) Then I can do the likes of: (test-define Create key-stream writer ksw (make-key-stream-writer* a 'test-ks)) (test-define-values Close key-stream writer (ks-hash ks-reused?) ((key-stream-writer-finish! ksw))) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Using epsilon in test egg
On 27/07/14 01:42, Matt Gushee wrote: I can certainly define a custom equality predicate that will do what I need, but this is bugging me. I guess I don't really understand how epsilon is supposed to work. The test egg documentation says that applies to 'inexact comparisons', but I can't find a definition of 'inexact comparison'. I have also read that '=' may be unreliable for inexact numbers, but I don't know what else to use. Perhaps 'fp=' from the Chicken library? Then I would have to ensure that all numbers are expressed as floats, whereas currently my code has a number of cases where 1 and 0 are expressed as integers. As I understand it, the test egg epsilon won't change the behaviour of = - it's used purely internally by the test egg when you say the likes of: (test 1.0 (+ 0.5 0.5)) It's probably best to define your own equality predicate, I think! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] new egg: nrepl
On 21/05/14 13:26, Kristian Lein-Mathisen wrote: Hi! I've created a very simple egg that exposes a simple REPL over TCP connections. I've called it nrepl. Naming conflicts with Clojure's deprecated nrepl hopefully won't be a problem. I'm thinking this may be handy enough for debugging that it might be part of the official egg index. Have a look here: https://github.com/Adellica/chicken-nrepl I like it. I've wanted one of these for ages, but never gotten around to writing my own. Feature request: parameterize what it uses for eval so people can supply special environments, sandbox, sanity-check the sexprs, log them, etc. with suitable wrapping procedures :-) TLS support, and an optional connection authentication parameterized procedure to handle a login process (given the tcp socket on current-input/output-port and able to return #t to continue or #f to close the connection and abort), would be the next feature request for use in less trusted environments! Thanks! K. Good work that man, ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problems with the dollar egg.
On 02/03/14 17:27, John Cowan wrote: Daniel Carrera scripsit: Does that apply to other languages like Python? Python does not work in the Chicken interpreter either. :-) (Though in principle one could write a Python egg using the Python/C API.) There's slightly more to it than this, however. The FFI only works in compiled code, it's true. But you can compile a module that uses the FFI, then use that module from the interpreter. You just can't use the FFI *directly* because it works by integrating with the compiler's generation of C code, which is then compiled by gcc. Whereas the interpreter interprets directly, rather than going via C, so the FFI doesn't have a C stage to integrate with. This is similar to the situation with Python - to wrap a C library in Python, you compile a stub module that you can then load from the Python interpreter and away you go. The difference is that the stub module is written in C, rather than Python; while Chicken FFI stubs are written in whatever mix of Chicken and C you find convenient. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problems with the dollar egg.
On 03/03/14 17:10, Daniel Carrera wrote: I guess I'll continue playing with both Chicken and Racket until I know enough to form a preference. Depending on what kind of code you want to write, you can do a lot in the language they have in common and then run the same code in whatever environment best suits your current activity... Might need some ugly mechanism to deal with module export/import interop, however! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unix Scripting in Chicken
On 12/10/13 05:49, Evan Hanson wrote: Hi Danny, SCSH was made for just this, and Peter has ported much of it to CHICKEN -- have a look at the scsh-process egg: http://wiki.call-cc.org/eggref/4/scsh-process Also, I've been working on a set of tools for making UNIX shell pipelines with Chicken, although I want to do more work on it before I release it - feel free to check out trunk at: https://www.kitten-technologies.co.uk/project/magic-pipes Evan ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] set! atomic?
In the above code, will the primordial thread ever print a list that isn't exactly (1 2 3) or (iota 1e8)? The assignment itself is fully atomic, as is the destructive modification of any single data-cell like pair-cells, vector-elements or record-structure slots. Even so, code that uses something like a hash-table should have ALL accesses protected by the same mutex. I don't know the precise details of Chicken's hash table implementation, but it's a well-known problem in similar situations in other environments when a writing thread is interrupted during a resizing of the hash table (even though any given data cell may be atomic, the resizing of the hash table will involve many of them with inconsistent intermediate states), then readers may see the hash table in very crazy states. I think I've read an article about just this happening with Java hash tables, from memory. Readers ended up with a seemingly infinite list of elements inside a single hash-table bucket due to the chain being updated while being read, perhaps? It would certainly be easy to see it missing some or all of its elements, however. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] SPRING THING 2013 has ended.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2013 01:02 PM, Moritz Heidkamp wrote: Hello! Christian Kellermann ck...@pestilenz.org writes: I am sad to say that the CHICKEN Spring Thing 2013 is over. I hope everyone had a safe journey back home and enjoyed the weekend with all the other CHICKEN enthusiasts. I for one did enjoy it. When and where should we do the next? :-) There was some talk of Christian running CHICKEN DE 2013, wasn't there? If not, I could still rustle up another CHICKEN UK :-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIbBAEBAgAGBQJRpiPLAAoJENVnbn/DjbpJWlMP+Jt7u0Y5/6igtpsw4GUIkQDe i7zCuiAgzD7C8tH7aso1V1sDKPvubsPET+gTcTu4aODFvojJP7ca6wFx6G8BrBCF eSyANunHtaRDCOdTZEZ2T56/BtRCaFZMyAVuqFDYjQg9Z8qovKQcn2htZ32y+GGe leCGLaSIP5g7EabhmG2JMetIjbf9MUGVQHrR7EWG/LXRHRVvc6QvL2L/G7d5p4uO 5h61uUD+03IjZP4nWLgEJc3uebGQG5e9GqwtRwfpQrAgKlj9lMVVcvhXGfaf8fkh MYpn1i1vH5Aho+voL8b/1uTO3LIv0ze7LmfdGzQtYyAQTB2Jt8BRnTjP+vgeJPIZ t3fCOLbh4vpSnr9deDEcNbywI23N8JD3Uh6q9CTxxkBx3Xe9NfvZ4kvnl2T7chqy bHr/dw6lfeq7US+zydRLMl7LmVNrQUjNg+ov9sBuqgKtV3dodxh5NU1W1WIA1xwA +CsFV8EAFohdfxXI8viNb3g8uTtg+TU3jXNAhJzoGpK04k/5YFCrEVSKYHcN36cQ enpH3TVldAfL3n00bN9BupQjnC582lHikkJNNwSZxoY5ZkMbbQyuQ87FRLfIs65E 9bb7+GVjyWy7MQHkqBFpNyY6Mcco0C8QPpSG3eEGXddmeejYhsWxGgkI+8Jv75bn aQxuiGkY1ZOCxDuiR08= =F0Gk -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] The odd case of the channel egg's tests failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/30/2013 11:22 PM, Felix wrote: This usually means an inconsistent heap: some random data is interpreted as a proper Scheme object and the header contains some huge size indicator. I wonder if it might be possible to come up with some sort of analysis for these problems. What I need now is someone encouraging me in such an effort, suggesting various improvements to that work-intensive and toilsome project and who offers reliable support and hacking time. To remain realistic, I would even be happy with someone commenting on just least one or two of these three requests... Alright! If you write something to write this log file, with all the relevant information, I will: 1) Send you ONE BITCOIN! 2) Write a tool to analyse the dump file (I may need to bug you with questions about the meanings of things in it) and find out interesting facts. cheers, felix ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEKNQEACgkQRgz/WHNxCGrKQACeIpV1PdOLIh3wy5PXaJwQ2Zn1 VR4AmwSiUyxDS6MuZcEmdtumx7tmSII/ =eWyb -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] The odd case of the channel egg's tests failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2013 12:34 PM, Moritz Heidkamp wrote: What I need now is someone encouraging me in such an effort, suggesting various improvements to that work-intensive and toilsome project and who offers reliable support and hacking time. To remain realistic, I would even be happy with someone commenting on just least one or two of these three requests... This seems like a worthy addition to the Chicken debugging toolset but also like a lot of work. I won't discourage you from persuing it, of course, but I'm afraid I won't be able to help with actual hacking due to my ignorance of the relevant internals and the lack of time to become acquainted with them right now. I figured we could encourage Felix to do the internals bit and spit out a log file that the rest of us can learn to make sense of, as a good division of labour! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEKaxUACgkQRgz/WHNxCGpecwCggj/DR+KYPpWakFNcHEJ6lkjL mUkAn0Inu1LNdVZzHNNexlWMcfwTvxM3 =c/id -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken and Cocos2Dx on Google Play!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/2012 02:31 PM, Kristian Lein-Mathisen wrote: Thanks a bunch for the encouraging feedback! I wonder where this project might end up. Jean keeps asking to play with it. We've figured out that, with some careful jumping, you can get the truck over to the left and up a hill and back onto the slope that leads down to the start point! When I get a chance, I want to hook up the REPL and add more stuff to the world for her :-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCXyiIACgkQRgz/WHNxCGoLGgCfe1McQAedoAjwRA9g0ZpACd/S WKcAmgIoO0yYrvuK0kfSdWMc700NK7vP =og+C -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Spiffy OpenSSL in compiled code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2012 12:43 PM, Andy Bennett wrote: The long term solution is to fix the autoload egg so that we can use that: Alaric has a similar requirement for Ugarit so it makes sense to put that functionality into an egg. I currently have the following in ugarit: (define (get-bindings-from-module egg module bindings) (let* ((vektor (gensym)) (rekuire-extension (gensym)) (expression `(module ,(gensym) () (import (rename (only scheme vector require-extension quote) ; quote shouldn't need to be here (vector ,vektor) (require-extension ,rekuire-extension))) (,rekuire-extension ,module) (,vektor ,@bindings (handle-exceptions exn (if ((condition-predicate 'syntax) exn) (signal (make-composite-condition (make-property-condition 'exn 'message` (sprintf This feature depends upon the optional module ~a being installed. Please install it with 'chicken-install -s ~a'. module egg)) (make-property-condition 'unsupported-feature 'egg egg 'module module 'bindings bindings))) (signal exn)) (eval expression ;; FIXME: Write a macro to generate these for us. (define (autoload-lzma!) (let ((real-bindings (get-bindings-from-module 'lzma 'lzma '(compress decompress (set! lzma:compress (vector-ref real-bindings 0)) (set! lzma:decompress (vector-ref real-bindings 1 (define lzma:compress (lambda args (autoload-lzma!) (apply lzma:compress args))) (define lzma:decompress (lambda args (autoload-lzma!) (apply lzma:decompress args))) I'd love to wrap it in macros that emulate the features of the autoload egg, but I remain faintly daunted by writing complex macros. Would anybody fancy taking on my get-bindings-from-module function above, extending it to call an arbitrary closure in the error case rather than just raising an error (as autoload provides facilities for using a fallback rather than raising an error, which would be required for this spiffy case), and wrapping it in an autoload macro? http://api.call-cc.org/doc/autoload Or at least giving me the impetus to figure it out myself :-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBtq20ACgkQRgz/WHNxCGrs3QCfaL0+xY7cciIDYr3fkQcCetBk Ds0AoJDgZnqnPb5AlvIkLG6onW7pJfL4 =skuq -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken UK 2012 is this month :-D
Hello Chickens! September, once seemingly so distant, is now upon us, which means that Chicken UK 2012 is starting to come together. I've assembled a draft programme: https://wiki.call-cc.org/event/chicken-uk-2012 However, I'm really just writing it so we have some ideas for something to do each day; in practice, I plan to be flexible and consider the weather and what moods we're all in each morning and go from there ;-) There's several slots free for talks, if anyone would like to tell us about anything they've been up to. If everyone's too shy, I will do some more myself. You have been warned... If anybody doesn't know where to come to, email me offlist and I'll give you the URL of our how to get here page - I just don't want it getting into search indexes! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] spock tests
On 09/09/12 15:56, john saylor wrote: also, if the language turns out to be java, you should be worried- deeply worried ... It was saying something like Ph'nglui mglw'nafh Riastradh R'lyeh wgah'nagl fhtagn ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] Chicken at T-DOSE 2012
On 08/08/12 19:13, Peter Bex wrote: Another great opportunity to meet some Chicken fans will be at the Chicken UK meeting, at Alaric's home in Gloucester, from September 28 until the 1st of October. See http://wiki.call-cc.org/event/chicken-uk-2012 for more information. I'm sure Alaric will appreciate it if you could let him know in advance if you'll be there. Yep! Just pop yourself on the wiki :-) I've just received a delivery of some European power socket strips, which I'm going to be wiring up to UK plugs for the benefit of the many EU-originating delegates. If anyone has any other foreign electrical needs, do say! I can probably arrange 48v DC at a pinch, and I can do 110v, but multiple phases might be difficult... Cheers, Peter ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] Chicken on Raspberry Pi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2012 10:59 PM, Martin DeMello wrote: Wow, I've been wondering what to do with my Raspberry Pi and Alaric's idea looks fantastic. Go, Lazyweb, go :-D Adafruit have produced a Linux image for the Pi that has hardware drivers for all the I/O: http://learn.adafruit.com/adafruit-raspberry-pi-educational-linux-distro/occidentalis-v0-dot-1 This would be a good basis for a Chicken egg to drive that seductive I/O port! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAfl3IACgkQRgz/WHNxCGo/iQCfdEON7uJFTYy9cbV6npUJLje9 HOIAn04aj8VbZTPnGXvab9Ut4FCB5pCV =y61d -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] ANN: simple-graphics, a basic turtle graphics library for educational purposes
Hello folks, As my six-year-old is interested in making computers do things, but showing her how to do sums in csi grew old after half an hour or so, I built on Christian's fine work in the doodle egg (which handles all the evil bits for me) and wrote a very simple turtle graphics library. The goal is simplicity and immediate gratification; all setup of graphical context is done on demand when the user starts drawing pictures. https://wiki.call-cc.org/eggref/4/simple-graphics It can be improved in many ways; mainly, I want to put a little turtle sprite that rotates to show the turtle direction, but I need C-Keen to finish his work on doodle sprites first! However, I'd also like to provide more upwards paths to more advanced work, like integration with the doodle event loop and so on. I'd also like to lay down better infrastructure for drawing charts from numerical data, perhaps with a draw-to alongside go-to, line thickness, etc. However, it'll do for now! Enjoy, ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken UK 2012 is looming!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's only a few months away now, so high time I started finalising the plans for this :-) Please take a moment to update your entry in the table if you think you might be coming. And especially if you think you aren't coming but you're in the table! https://wiki.call-cc.org/event/chicken-uk-2012 I need to start thinking about a programme, so also consider this email as a CALL FOR PRESENTATIONS. Let's have a good old show and tell of whatever Scheme projects we've been working on, no matter how early stage or broken it is! The worse your code is, the more everyone can help you make it better ;-). I've put a table on the wiki page for people to suggest things they'd like to do (if there's something you'd like SOMEBODY ELSE to do, suggest it but leave the speaker column blank and somebody might rise to the occasion). ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/hywsACgkQRgz/WHNxCGrfqgCglCm0YcpuX/HSD6w7FL8c5gaQ jGkAniYftvoCBZFgBc6HKSpc3tAO6Cbx =A5Xl -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Planned downtime for chicken.kitten-technologies.co.uk
On 03/17/12 14:48, Alaric Snell-Pym wrote: I will be bringing apache up on the new server and checking that everything's working any moment now - then I'll send my notification email, and do the transfer. Well I *wanted* to send a final notification, but then I realised I'd already broken too much existing stuff to send any emails, so I pressed on and chicken.kitten-technologies.co.uk was quickly up again :-D Sadly, email has taken a little longer to bring back, due to confusions with there being two versions of postfix installed in different places *sigh* ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have now migrated the above email, and the results from the Doodle, into the wiki: http://wiki.call-cc.org/event/chicken-uk-2012 Please update the table with your requirements and needs if you're coming! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9XRHIACgkQRgz/WHNxCGqy4QCff1cHdsfZ/Kl11jvq9ChnGaHh /AUAnRSvcx+soBOD1NPTPa2HAWWop6uN =qXir -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Creating my own extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2012 05:25 PM, Mario Domenech Goulart wrote: For starters, there is no exe named chicken-setup in Debian, although there is a chicken-install. The following wiki page suggests that there should be: http://wiki.call-cc.org/man/3/chicken-setup#install-program The /3/ part in the path indicates that is the manual for CHICKEN 3.x. chicken-setup is for CHICKEN 3.x only. The tool to install eggs for CHICKEN 4.x is chicken-install. Is it time we either: 1) Removed /3/ from the wiki? 2) Kept it online for archival purposes, but put it somewhere even more hidden-away and obviously not current? 3) Slapped a big warning banner on every /3/ page? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9WSToACgkQRgz/WHNxCGoVKACffmJiR1mmEHzth3vifVWvp7iR JIkAnjuZ7cdVLpLrBHPytfCGdWaXCuuE =TVYa -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2012 04:03 PM, Alaric Snell-Pym wrote: In the resulting flurry of last-minute sign-ups, the end of September is now looking more popular! I'll keep you all posted... OK, as promised (on IRC), I'm now finalising a date for CHICKEN UK 2012! Looking at the responses on the Doodle, I think the best weekend for everyone will be Friday the 28th September to Monday the 1st of October. People are welcome to say in our house, and there's hotels and stuff nearby for people who don't want to queue for the bathroom in the morning! We have four guest beds, and loads of space to stretch out sleeping bags. You're welcome to come even if you didn't fill in the Doodle - the Doodle existed to find a widespreadly agreeable date, not as a ticketing system! I've certainly got enough space for everyone who signed up to the Doodle, and we can fit a few more people, so just email me if you didn't join the Doodle and would like to come. I plan to organise technical and social events on those four days, but people are welcome to stay over before and after that, be it if you want to travel up at convenient times and be refreshed and settled before the activities begin, or just for the heck of it. As for the programme. I propose the following kinds of sessions; 1) Hacking sprints, where interested parties choose a project and hack on it, alone or in groups. I'll have places to sit at laptops, with Wifi, Ethernet, and UK and Euro power sockets. 2) Talks/presentations. Does anybody want to stand up and tell us about anything? I can try and borrow a projector, and we've already got a whiteboard! 3) Social events. For meals, we'll provide breakfast and lunch in the house for all who want it (we're vegetarians, so tell me if you're a vegan or beyond, or have allergies), for convenience, but I propose that we go out for meals to save me the cooking and washing-up effort, and as a pleasant outing. But if there's interest, we could also take an afternoon or two out for an outing. Feel free to research Cheltenham, Stroud and Gloucester on the Internet and see if there's anything that appeals to you. I have three suggestions: We could go for a walk around the beautiful grounds of Gloucester Cathedral and the Docks, or if we go to Cheltenham we can drop into The Cheeseworks to look at bizarre cheeses, or a walk in the countryside around the village I lived in until recently. Oh, and if it's nasty and rainy outside, we have heaps of board games, including the legendary Robo Rally (http://www.wizards.com/default.asp?x=ah/prod/roborally). What do you all think? And remember: This isn't some big formal conference. It's us inviting the Chicken community over to our new house for a nerdy housewarming :-) So if there's something you'd like to suggest or ask, just say! Don't be shy! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Ta0kACgkQRgz/WHNxCGoAywCffTdCEUfuD3jAL+a2qqIcdxS/ IhQAnRWmu4yVjYw8h9lu89YGXc+LAtdq =ojd7 -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] foreign: Why is passing structs as arguments and return-types not supported?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/29/2012 01:29 PM, Thomas Chust wrote: Last but not least, passing structures as pointers makes memory management for them explicit and that is a good thing in this case because there is simply no way the FFI could automatically figure out how the optimal memory management strategy for structures passed by value should look like. For example, whether such a structure can be allocated as an atomic block of memory or not is impossible to answer without knowing what the functions producing and consuming instances of the structure actually do. I slightly disagree here. A structure passed or returned by value is just shoved on the stack, maybe in registers if it's a small structure. There's no extra memory management required; merely some extra copying to copy from the Chicken-side foreign-type pointer into the appropriate bit of stack or registers, or back again for returned values. But, indeed, it's easy to do that in C as your distim demonstration shows; return values are only slightly harder as you'll need to allocate a struct and copy the result in, then return that pointer. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ONY8ACgkQRgz/WHNxCGpVFQCdFmrrkp6RhMkQQNIaRtElcQUw At8An3tuScsj6vKNCi/CQDVVTeRR1ZHE =foQX -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] foreign: Why is passing structs as arguments and return-types not supported?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/29/2012 03:18 PM, Kristian Lein-Mathisen wrote: Since struct-by-value is so central in both of these libraries, manually writing wrapper-code would take too long. I am unsure of where to go from here, but I suppose my options are: - Modify `foreign` to support struct-by-value - Modify `chicken-bind` to automatically write wrapper-code for struct-by-value - Write a script that re-parses the generated scheme-binding and inserts the wrappers Any thoughts on how to pursue this? I would think that the first option is slightly neater, as it would then apply to users of foreign other than via chicken-bind, but it might be easier to do in chicken-bind! The last option looks ugly. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9OU8wACgkQRgz/WHNxCGrkdQCcDmKaG/yaXUzrIejXupDQ34zX y+MAn2eyLzmMwE+Swah/xbIH1NfH0S4W =gqMq -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2012 03:45 PM, Alaric Snell-Pym wrote: Dear Chickeners, Having just moved into a much larger house than I previously lived in (one large enough to have an actual guest room, plus a playroom for the kids that we're equipping as a second guest room, and a big lounge!), I hereby offer to host a Chicken meetup sometime this summer! We can easily sleep quite a lot of people here (particularly if they bring sleeping bags). Ok! Having collected some dates on the Doodle page, it's now looking like September is the most popular option, with the only person it's difficult for being Matt Welland, but everywhen else is difficult for more people... Sorry, Matt :-( The first weekend of September is likely to be my eldest daughter's seventh birthday party weekend, so I'm proposing the second weekend of September, Friday the 7th to Monday the 10th. This is still provisional - I give you all until the end of Feb to argue me otherwise; after that I'll start ordering the extra leased lines and submitting requests for quotes to the local pizza factories and breweries :-D ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8oDYYACgkQRgz/WHNxCGoZnACfRr02/x3zfPZtDxmVGmRcjrhO mCcAniPA7O58NtgbWWTRGo1WUFLvnMOl =ByS0 -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2012 03:49 PM, Alaric Snell-Pym wrote: This is still provisional - I give you all until the end of Feb to argue me otherwise; after that I'll start ordering the extra leased lines and submitting requests for quotes to the local pizza factories and breweries :-D In the resulting flurry of last-minute sign-ups, the end of September is now looking more popular! I'll keep you all posted... ABS ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8oENsACgkQRgz/WHNxCGoH9wCbB9Tkwj1ecIaNYM+N0agCKh9X xncAniytLc9g6USb2LA6tYLV7Slnmfay =9p9Q -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CSI and CSC do not do the same for syntax definitions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/17/2012 09:35 AM, obscurolocon...@googlemail.com wrote: I have two files which are run correctly by the interpreter but the compiled version fails to run: $ csi -i -s x.scm x y $ csc x.scm ./x x Error: unbound variable: y Is this the intended behavior? Yes. The effect of load is, necessarily, at run time. When run in csi, the load can therefore happen immediately, and csi gets the syntax definition of y. When compiled, the load happens not at compile time but at run time, when it's too late to expand any syntax; the compiler has compiled in a reference to y as a (initially unbound) variable in the hope that loading y.scm will assign a value to y. However, syntax definitions are not value assignments, as they are compile-time beasts! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8VUYMACgkQRgz/WHNxCGosyACcCY5CpL+aUap/omyXLL9aR0yb yLYAn1xr6cgmt05/9zW5/vkYBfgx3dgX =gvpQ -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have looked up the dates of the Olympics (25th July - 12th August), and made a Doodle for all the weekends from June to September (minus a few that might be difficult for us): http://www.doodle.com/7r7agikv6m5yakg9 Don't forget to put your favourite dates online at the Doodle if you're interested in coming! I'd like to set a date soon so I can start planning the rest of my life around it ;-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8UPM4ACgkQRgz/WHNxCGpE5ACeKohStTawoglbRYUl9vSXZ+w/ qHcAn1Gr6YbtThb69MqkpdIVY501R9dJ =7Hw4 -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/04/2012 09:09 AM, Felix wrote: Fantastic! I will try everything to take part. I will put up with chicken-cakes, but only if they are vegan. I'm a vegetarian, and my wife and one child are intolerant to anything that comes out of a cow in any shape or form, so that will hardly be a problem ;-) cheers, felix ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8EITsACgkQRgz/WHNxCGrduQCeMivIwe5KVKCL1is2JBVAygje myQAoJJrOCFQXVRszd8sB9W8qz5xzFl2 =WeUz -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Ugarit install problems and notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [We went over these in private email, but I thought I'd best reply here too, for posterity] On 12/31/2011 07:24 PM, Matt Welland wrote: 1. To install lzma on Ubuntu 11.04 I had to change lzmalib.h to lzma.h in lzma.scm Aye, I want to rewrite the lzma egg to bind to the more widespread xz library rather than lzmalib. But first I need to fix autoload, as Ugarit's optional support for compression and encryption eggs, and SHA hashes, is turned off due to a lack of working autoloading :-( 2. This storage definition gives error msg Invalid arguments to backend-fs (storage backend-fs splitlog /ugarit/data /ugarit/metadata 9) Aye, you no longer need to specify the split size on the command line; drop the number at the end. Instead, specify it with ugarit-archive-admin, using the set-max-logfile-size! command (the default is 6). 3. This storage definition gives the below error (storage backend-fs splitlog /ugarit/data /ugarit/metadata) matt@zeus:~/ugarit$ sudo ugarit snapshot ugarit.conf -c home-matt /home/matt Error: bad argument count - received 1 but expected 0: #procedure (f_6577) Call history: ##sys#require ##sys#require ##sys#require ##sys#require ##sys#require make-parameter make-parameter ugarit.scm:208: srfi-37#option ugarit.scm:226: srfi-37#option ugarit.scm:233: srfi-37#option ugarit.scm:240: srfi-37#option ugarit.scm:249: command-line-arguments ugarit.scm:248: srfi-37#args-fold ugarit.scm:247: reverse ugarit.scm:260: with-input-from-file ugarit.scm:261: ugarit-core#open-archive -- And I'm looking into this :-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8DIs0ACgkQRgz/WHNxCGoCogCfTlrrGwuG2gUNY54bTkAtdK3S CYgAoIfdfRtqw0n5a/qfRoCNeuX09Etr =hrZf -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Chickeners, Having just moved into a much larger house than I previously lived in (one large enough to have an actual guest room, plus a playroom for the kids that we're equipping as a second guest room, and a big lounge!), I hereby offer to host a Chicken meetup sometime this summer! We can easily sleep quite a lot of people here (particularly if they bring sleeping bags). The location is Gloucester, which is about an hour and a half from London by train. As well as having a few days' hacking, we should find time to go and visit some of the lovely attractions of the area, such as the legendary cheese shop in Cheltenham, or peering at GCHQ, which is Europe's largest supercomputer centre (through a barbed-wire fence, while watched suspiciously by armed guards), or going for strolls in the Cotswold countryside. And I must warn everyone that my wife is planning to bake Chicken-themed cakes and biscuits. I am open to suggestions for dates. Should I avoid the Olympics, as travel will presumably be more expensive then? Or should I coincide with the Olympics, as people might want to come over to the UK for them anyway, and sneak in a few days in Gloucester amongst it all? Who would like to come, and when can they get time off? I'd recommend we make it a long weekend, so we can fit in a good mixture of hacking and adventuring! But people are welcome to stay for longer if there's interest :-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8DIrYACgkQRgz/WHNxCGozlACfXDADEc18ZpvUu92r16BBUptG 9PkAnj9tJUazhx1tSWmqMkED409COcbz =uL0c -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-hackers] Summer 2012 meetup in the UK?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2012 04:18 PM, Andy Bennett wrote: How about the August Bank Holiday? Although I'm not sure how many UK people there are and whether it coincides with bank holidays elsewhere? I have looked up the dates of the Olympics (25th July - 12th August), and made a Doodle for all the weekends from June to September (minus a few that might be difficult for us): http://www.doodle.com/7r7agikv6m5yakg9 I've included Fri/Sat/Sun/Mon for each weekend as a starting point, but we're flexible as to the exact days! Regards, @ndy ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8DLoQACgkQRgz/WHNxCGrKDACfer2lK87LzWijEocWm5I3jCGY 0TsAnRYpERrvKQ37jAFb2jKd+qTnJHDE =JHS+ -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OT but of interest I think
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/2011 05:22 PM, John Cowan wrote: Matt Welland scripsit: Father of Lisp John McCarthy has died: http://www.theregister.co.uk/2011/10/24/father_lisp_ai_john_mccarthy_dies R7RS will be dedicated to his memory. He was also instrumental in the development of the Space Fountain, an idea that may one day make space travel widely affordable: http://en.wikipedia.org/wiki/Space_fountain ...in frickin' Lisp-powered spacecraft, I hope ;-) MY OTHER CDR IS A TRANS-ORBITAL SHUTTLE etc. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6n7X0ACgkQRgz/WHNxCGpVZACfdv92byq/D/53D20wXIv9pWIh PYkAmwTHQMJMv8Dal4HdLBjo5j2OcLH6 =g6Nj -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] BerkeleyDB binding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2011 12:56 AM, Thomas Chust wrote: Hello, during the past days I've written a small binding for the BerkelyDB library. You can find the code here: http://www.chust.org/fossils/berkeley-db You get a persistent key value store backed by files with an interface loosely resembling that of a SRFI-69 hash table. There is transaction support. The binding takes care of platform independent serialization of Scheme values. Good stuff, Thomas! I've done a lot of work with BDB (from C) in the past. It's certainly a useful tool to have around! Ciao, Thomas ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6cAHEACgkQRgz/WHNxCGpmSACeKid8T71BrywaEq7SEgaexCdS xpgAnRRh0jzDz0CS+tp68OsCz0n4D6RV =/X5V -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [PATCH] Compatability between eggs and chicken releases: a report on progress, and a patch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/2011 12:02 AM, Alan Post wrote: On Tue, Oct 11, 2011 at 11:05:55PM +0100, Alaric Snell-Pym wrote: The user-agent strings it generates look like: chicken-install 4.7.0.3-st linux x86-64 Rather than the previous: chicken-install 4.5.0 I think we should include the operating system version as well as the operating system and hardware platform. Given the way linux is distributed, I'm used to including: os+os version = Debian 5.0 kernel+kernel version = Linux 2.6 to distinguish Debian 5 from Linux 2.6. If I get to dream a bit, I'd love to include the compiler and it's version as well. I'll take the opportunity to attach one of my favorite C programs: it outputs the name and version of the compiler it was compiled with. Alrighty! I might find myself hacking the build system to record more of this kind of thing, too... We can try running lsb_release during the build process and record its output if found, for a start. Then there's your compiler-identifier. Then there's uname - via libc, not the command line tool (what does that do on Windows?) -Alan ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6VP0UACgkQRgz/WHNxCGo7BQCgijdmTtFuaBBXE4wPYdTmFILq oRwAn0almx9W1nxNXWzjyV6HY+XeyHM9 =zqDD -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A proposal for egg category reassignment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2011 08:40 AM, Ivan Raikov wrote: Good point, I did not think to check where these eggs are hosted. So here is the revised list; I have marked the eggs not hosted on call-cc.org with an asterisk (*) and I advise their respective authors to correct the categories. And yes, changing the category would also necessitate tagging a new release for each egg. -Ivan Eggs in Uncategorized or invalid category: aes - Cryptography crypto-tools - Cryptography I've done these, just not tagged a new version yet, so it's still showing them as invalid! (I put them in crypto when it should have been crypt...) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6URK0ACgkQRgz/WHNxCGpPBgCdFzYDTEO1UuaPuFfD45PBebX8 4bYAnjMK8P1XyH+tqmPZhS4878j1/HeU =0NtW -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [PATCH] Compatability between eggs and chicken releases: a report on progress, and a patch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As some of you may recall, some time ago I grumbled about the rather hodgepodge state of eggs still running on older versions of chicken - despite the likes of 4.5.0 being widely deployed by package managers. My main fear is that prospective Chicken users will install chicken from their local package manager, try and install eggs, and be presented with errors, which won't do wonders for their faith in Chicken. At the time, I proposed that people who make changes to the chicken core and then document them should note Added in version ... to the documentation near to new features, as appropriate, to make it easier for developers to notice when they are using bleeding-edge features and to decide if it's essential for their code; and that I run a clone of salmonella on an old version of Chicken to assess the level of support of old eggs. After a bit of debate on IRC, we decided that I should go for 4.5.0 as it's still widely packaged. I'm still trying to get my 4.5.0/NetBSD-i386 chicken chroot to actuall complete a salmonella run, as it keeps segfaulting :-) However, Mario has pulled one off on Linux without any trouble, so it may be a NetBSD issue: http://www.parenteses.org/mario/misc/salmonella-report-4.5.0/ It shows a lot of broken eggs, several of which can be attributed to the sendfile egg, which is known to not work on 4.5.0; there's been discussion on IRC about how to make it more backwards-compatible, which I think is great news. I will continue to press on with getting my salmonella setup going. I am hoping that we will end up with a network of salmonellas producing reports for different chicken versions on different platforms (requiring some manual effort from salmonella farmers to install needed packages in their chroots, or to mark eggs for skipping on their platform, to remove spurious failures from the reports), and submitting their reports to a central location where they can be merged, allowing developers of an egg, or potential users of an egg, to quickly see what platforms it currently works on. However, there's an open question of how important particular platform/chicken versions are. Should a developer see that their egg won't work on 4.1.0/AIX-PowerPC, and that it'd be a lot of work to fix, they may well be justified in saying Well, if a 4.1.0/AIX user complains, I'll ask them to help me to fix it and leaving it at that. But they might be more concerned about failures on 4.7.0/Linux-x86_64. To help guide this decision, I have a proposed patch to chicken-install (well, setup-download.scm, to be precise) which makes it send the Chicken version and platform string to henrietta whenever it requests an egg, so we can mine the logs and find out how important different targets are. The existing code sends the Chicken version, but no more than that, in the user-agent string, which is a start; but it would be nice to know software-type (eg, linux) and machine-type (eg, x86-64) as well. It'll take a few years for this to become widespread enough to be statistically useful, of course, but the sooner we start, the better. The user-agent strings it generates look like: chicken-install 4.7.0.3-st linux x86-64 Rather than the previous: chicken-install 4.5.0 I hope nobody considers that an unacceptable violation of user's privacy... The user-agent already has the chicken version currently anyway, which is a start. As I forgot to set up log rotation, the henrietta on kitten-technologies has 1.7GiB of entries, and yields the following statistics: http://chicken.kitten-technologies.co.uk/visitors.html#User%20agents Disturbingly, my biggest customer is a spider :-( But it looks like the league table of chicken versions used to install eggs is: 4.6.0 - 2338 4.5.0 - 1961 4.7.0 - 1336 4.2.0 - 1033 4.3.0 - 687 4.4.0 - 657 4.0.0 - 627 4.6.3 - 525 4.6.5 - 517 4.6.0rc1 - 335 If anything, it looks like 4.2.0 is an important version to think about, too! The logfile goes back to about April 2009, though - I should probably work out the user agents by month to see what the trends are and to not be swayed by the state of affairs a year ago. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6UvcIACgkQRgz/WHNxCGp5sgCeKUbPcpp6WJkPBC25uVZrG4oB Tw8AniIQ46Bd7bHkPoF5OQx+JpR+oekc =cgn/ -END PGP SIGNATURE- From 43da8392fd967aafb9b63510699afe0aee74f008 Mon Sep 17 00:00:00 2001 From: Alaric Snell-Pym ala...@snell-pym.org.uk Date: Tue, 11 Oct 2011 22:50:28 +0100 Subject: [PATCH] Make chicken-install submit Chicken version, machine type (eg, x86-64) and software type (eg, linux) to henrietta when requesting an egg. This can be used, in the long run, to gather statistics on what chicken platforms are in widespread use, to better decide what old versions need supporting. However, it will take a while
Re: [Chicken-users] A fix for parallel build (gmake -j)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/06/2011 06:12 PM, Mario Domenech Goulart wrote: We have a chroot environment for Linux (http://wiki.call-cc.org/playground) which contains libraries required to build most of eggs. It is the same environment as used by http://tests.call-cc.org. Maybe something similar can be made for FreeBSD. I'm setting up a salmonella box under NetBSD; I've chosen to run it on an older versino of Chicken (4.5.0) to try and look for eggs that depend on bleeding-edge features so won't install on versions of chicken shipped by many packagers... ...So far I've mainly been finding bugs in 4.5.0 so it's not running reliably yet, but once I get the basics going, I'm going to be building up a list of pkgsrc packages required to get them going, which might be a good start for FreeBSD ports! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6OGxkACgkQRgz/WHNxCGrKxwCeOP+qWhJEp2H4+fyFSXHc1rcI E6MAn2Y3OXPh9lNhjcJcAe6Qi/+YIKzl =fXd1 -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] difference between ##sys#error and posix-error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 08:36 AM, Christian Kellermann wrote: Hi Alan! * Alan Post alanp...@sunflowerriver.org [110929 05:51]: Looking at posixunix.scm, I find that some error messages are produced with ##sys#error, and others with posix-error. What distinguishes these two routines? Why would I use one but not the other? (define posix-error (let ([strerror (foreign-lambda c-string strerror int)] [string-append string-append] ) (lambda (type loc msg . args) (let ([rn (##sys#update-errno)]) (apply ##sys#signal-hook type loc (string-append msg - (strerror rn)) args) ) ) ) ) Ooof, is that correct? IIRC, strerror isn't thread safe. We may not be using POSIX threads, but might Chicken not schedule a new thread between strerror and string-append, which might itself call strerror and thus produce an invalid error message? I'm not sure at what points the scheduler is actually able to preempt. The solution, if that is a potential problem, is strerror_r, where you pass in your own string buffer. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EU0cACgkQRgz/WHNxCGoKwwCgh/PKkHikbGLulucz0Y9YwsvP HUEAniTO3Vq8zcCfYbbgghTcMm24khx7 =ZjGh -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote: I don't not have benchmarks for a reason: they would cost me too much time to do right. Personally I don't believe too much in benchmarks anyway. I believe in fast execution and source code review. Ah, but how can you measure fast execution without a benchmark? How should the community ever be able to improve over the current state of affairs, if each suggestion is upfront required to come with a benchmark, which is than probably first taken apart to show how flawed it is? If the benchmark is flawed, it should be fixed. I am getting the impression you have encountered some terrible benchmarks! Given how small the difference to the code is: wouldn't it be reasonable to just give it a try? Yes. But trying out some code involves reviewing it, then testing it - both for correctness and, in this case, for a performance improvement; and (the evil case...) for not worsening performance elsewhere. Which needs a test suite and some benchmarks! Or let me take the threading problem I solved ages ago. I did NOT want to get into that business. All I wanted was to have my prog run on chicken as it did on rscheme. Benchmarks said chicken is faster at that time. What a lie a benchmark can be! It was crawling slow. Tracked that down to the timeout queue. Fixed the complexity issue. Problem solved. Hm. So how would I device a benchmark case for that one? If the supposed performance improvement can't be benchmarked, then it's pointless, as nobody will actually benefit from it. Any case where somebody can benefit from a performance improvement can be turned into a benchmark that consists of running the code that is sped up, and timing it. Benchmarks are like unit tests; they are snippets of code that perform some operation but, rather than testing correct responses, their emphasis is on testing resource usage. We could work on a system by iteratively hacking it then measuring performance by hand, but in doing so, we will only measure the kinds of performance we personally care about, and may well do things that reduce performance in other areas of the system. Decent benchmarks can be put into the test suite, so future performance tinkerers can see the consequences of their changes for previous uses. And just like unit tests, performance benchmarks should be chosen carefully for what they test. Unit tests are often easier to write, as they have clearly-defined (sometimes in specifications, sometimes in common sense) goals. Performance benchmarks are trickier. A system that aggressively caches everything read might perform very well on read latency and throughput, but terribly on memory consumption and latency of noticing changes to source data. So the best benchmarks are derived directly from applications, and include representative mixes of operations to test overall performance as well as low-level per-operation benchmarks! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EXlAACgkQRgz/WHNxCGq02ACcDTZBt8R4f3PU8Zu7vl63TjIP ShAAnjUl0K8Z3uCwpJMuVSb9bZ5uilcZ =mZsg -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] difference between ##sys#error and posix-error?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 12:41 PM, Jörg F. Wittenberger wrote: The core units are compiled without interrupt checking. There is no chicken thread switch coming in here. Oh, good. Stand down all units :-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EYSoACgkQRgz/WHNxCGoxYACfT5bKZ1awtTTKZjGmWUu4/uKa Y2MAn29H5RxV3UcSSf6EVKaTxf2us/bI =sNUx -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 01:44 PM, Jörg F. Wittenberger wrote: On Sep 29 2011, Alaric Snell-Pym wrote: On 09/29/2011 12:38 PM, Jörg F. Wittenberger wrote: I don't not have benchmarks for a reason: they would cost me too much time to do right. Personally I don't believe too much in benchmarks anyway. I believe in fast execution and source code review. Ah, but how can you measure fast execution without a benchmark? Well, at the end of the day I run some complex applications. For instance I use httperf. Then that, my good man, is your benchmark :-) Yes, it's complex to run a chicken-based app and then run httperf against that to get real-world performance figures. Ideally you'd be able to distill the essence of that a little into a simpler test that nonetheless had almost the same performance characteristics. And maybe make mistakes in the process - but that's the art of performance estimation. If the supposed performance improvement can't be benchmarked, then it's pointless, Hey, I wrote crawling slow! That's worse than just a benchmark. If the same program needs seconds instead of a fraction, then I don't bother. I tracked the problem down, fixed a single thing and found a huge speed up. As expected. Case was closed for me: goal reached. If you had some operation you could measure before and after to see that speed up, then that's a benchmark too! At that time there was no point in perfomance measurements. If you found a huge speed up, you were measuring performance, by definition :-) If something works better for me than the current state of affairs, then I notify the list. Code review is due upon integration anyway. And those who do have benchmarks already are welcome to post their results. Reviews are welcome to challenge the code. For sure. I, for one, think it's great that you're contributing performance patches. But they do need to be checked with actual benchmarks. It looks like you *have* been doing that, but claiming you haven't, due to a disagreement about the definition of benchmark ;-) Case in point: In the project I work on for a living, I have been working on a series of performance improvements lately. In profiling, I found that a critical system thread spent a large fraction of its time in a function that was trivially optimisable; it was doing an inter-process call back into the same process (don't ask why...), which was then queued amongst other incoming requests before being handled, and the handler then simply checked the existence of a certain file, and sent the results back... so I changed the function to check for the existence of the file itself, without the IPC back into the same process. Result? Performance roughly HALVED. This was a surprise, but not a great shock, as the performance of complex threaded software is famous for being unexpected. We didn't have time to properly investigate, but I believe the problem is that causing this operation to run faster causes the thread to spend more of its time doing other things (rather than blocking on the IPC), and is therefore holding certain locks for a greater percentage of the time, blocking out other, more useful, things that could be happening. But without a benchmark, I'd have thought that this change couldn't possibly have any other effect than to improve performance :-) So we are back at the capacity issue again: I have only so much live time. I'm not ready to spent it maintaining benchmarks in the hope that those will eventually convince someone to benefit from the work I did. You are free to convince yourself. That's fine; it's just that you were complaining you didn't want to do benchmarks, which I now think was purely a communications mistake. Your httperf results are benchmarks, too, if a little informal, but infinitely better than just making changes that through inspection should improve performance, which was my fear :-) /Jörg ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EbhMACgkQRgz/WHNxCGoElgCgjWYuWJyhf/IxKng+UF5hqxGf OMsAn1O1Ly/kRojxwSCj2isdeGORF0lI =qCaS -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 02:43 PM, Jörg F. Wittenberger wrote: (define (chicken-enable-interrupts!) (set! C_interrupts_enabled #t)) (define chicken-disable-interrupts! (foreign-lambda void C_disable_interrupts)) (let ((pid (begin (chicken-disable-interrupts!) ((foreign-lambda int fork)) )) (if (not (= pid 0)) (chicken-enable-interrupts!)) ... ) To be honest, doing *anything* between fork and exec is pretty questionable. There's the big issue that threads might not be expecting to be randomly duplicated by actions in some other thread, and proceed to do something twice because of it (not a great issue if it's just touching RAM, but a great issue if it involves I/O or mutual exclusion mechanisms). Then there's the fact that you can't use vfork if you do anything other than go straight into an exec, so you need to pay the cost of duplicating the entire address space with CoW mappings (which turned out to be a critical performance factor in a fork-heavy workload here at work, recently!). Having said that, there are good uses of fork() other than as a vfork() then exec() pair; you just need to be VERY CAREFUL, and get whole-program cooperation. Eg, don't initialise some third-party library in the parent, then use it in the child; only take your own state across the fork, and audit it for the consequences. (Good uses of fork() I have seen include redis' technique of forking to get an atomic copy of the process memory to snapshot to disk while the parent continues to process updates, and software forking off its own daemon processes as a form of threading or to ensure isolation from the parent for security reasons! But all of these cases involve careful consideration of the transmission of state from parent to child.) POSIX says that fork needs to produce only a single surviving POSIX thread in the child. Perhaps Chicken fork needs to do the same with Chicken threads. Chicken fork - no food jokes! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EiHIACgkQRgz/WHNxCGr0zwCfUWMseuGomWLBL/jgQGHUtEPE RXkAn1C0eXxK1zfXgwfoCR4OFKstU7X2 =d9Ca -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 04:25 PM, Jörg F. Wittenberger wrote: POSIX says that fork needs to produce only a single surviving POSIX thread in the child. Perhaps Chicken fork needs to do the same with Chicken threads. Alaric, that's exactly the effect and reason why I'm using this disable-interrupts/enable-interrupts around fork: to make sure there is only this one Chicken-threads running in the child. With interrupts disabled there is no scheduling in chicken. (At least not until you run into a thread-yield! anyway.) And therefore I'd really recommend to keep it in the runtime. I think a better mechanism would be a way to abort all threads but the current one, triggered after the fork in the child, with no interrupts until the thread murder is complete. If you just go off and exec after the fork it'd be better to uninterruptably vfork-then-exec, but we have procedures to do that already! Aborting all threads but the one that asked for the fork also gives one the opportunity to inform them of this fact, should any of them leave useful data structures in incosistent states with locks held. There's something to be said for requesting permission to fork from all threads before doing so, so they can make sure they finish any operations on shared state in the parent, but that'll be complex, and a potential performance bottleneck, so probably not worth it! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EkCcACgkQRgz/WHNxCGoBNwCfS5syjjCVWFiyjcP0S6z/BFoB s6MAnjE+v+0Tf32+9bQ+X6wd6UgEA+pA =fjVS -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 04:47 PM, Alan Post wrote: The way Chicken is currently implemented, any signal that arrives during this time is discarded, which also makes me unhappy with this situation. A lot of blood and tears were spilled over signal handling on Unix to get to reliable signal delivery. I don't think Chicken should implement unreliable signal delivery on top of a reliable mechanism. I quite agree. It seems that the thread-like nature of signal handling and the thread-like nature of threading have been intermixed in the scheduler, and this particular feature is at cross-purposes. So it seems... Signals should always end up being handled somewhere, unlessly explicitly set to be ignored; in that case, ignoring it IS handling it, but not otherwise. IIRC, signals are handled by setting a flag and poking the stack limit then returning. A GC is then invoked as soon as the interrupted thread tries to allocate memory, due to the poked stack limit, but the GC checks for the signal flag and goes off to do the signal if it has to. I presume that invoking the Chicken runtime inside the C-level signal handler is unsafe on account of Chicken wanting to call non-signal-safe C functions. I presume that allocating memory in a Chicken-level signal handler is risky as you might have actually been at or near the stack limit when the signal happened. I have not looked at the mechanism in code - just heard hearsay about it - - so please take this suggestion with a pinch of salt: 1) Have a (signal-safe) data structure containing pending signals. This might just be a bitmask, or if we want to be flash, a queue of generic pending software interrupts if there's uses for it other than signals. 2) C-level signal handlers poke an entry into the structure indicating the need to invoke a Chicken signal handler, and poke the stack limit [all of the above is basically what I think we already have] 3) The GC, invoked due to the stack limit being breached, checks for pending signals. If there are any, it resets the stack limit to what it was originally, then modifies the currently active continuation to a newly-allocated one that invokes a system procedure which executes all pending signals, then continues to the previous continuation; and returns. The normal stack limit needs to be set so that there will always, in the worst case, be enough space to allocate that extra continuation frame. If the system WAS at the edge of the stack when the signal(s) came in, it would then still be able to allocate the special continuation; execution of it would then almost instantly trigger a perfectly ordinary GC, and execution would continue as usual, executing the pending signal handler(s) then continuing with user code as before. That would give you low latency, unless the GC really needed to happen, in which case... well... it needs to happen before the handler can run. It would run signal handlers in the context of the currently executing thread when they happened, so to all intents and purposes it would be normal Chicken code, and the current thread would just temporarily dart off into signal handlers when required; I'm not sure what dynamic environment (in the parameters/current-output-port) they should be in; neither do I know how they are implemented in Chicken! Perhaps they should encapsulate a copy of the dynamic environment in place when the signal handler was registered, as the most hygienic option... -Alan ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6El54ACgkQRgz/WHNxCGpebACfdxF+Fqb3OiEVJHoAaww3U23f inkAnRCPDl2dZhWrrdBODaBC8+rCDdHY =VjKl -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 04:51 PM, John Cowan wrote: Alaric Snell-Pym scripsit: If the supposed performance improvement can't be benchmarked, then it's pointless, as nobody will actually benefit from it. Any case where somebody can benefit from a performance improvement can be turned into a benchmark that consists of running the code that is sped up, and timing it. Benchmarks are like unit tests; they are snippets of code that perform some operation but, rather than testing correct responses, their emphasis is on testing resource usage. Your clarification down-thread that a benchmark can be of any size makes this comparison rather otiose. Nobody is going to have a benchmark suite that includes tests like these: With patch #1234, application 'foo' runs in an acceptable 18 hours rather than an intolerable 25 hours. (Obviously the improvement has to be nonlinear.) Actually, where I work we do! The full test suite takes all weekend - on a cluster of fairly beefy hardware, running different bits in parallel. But there's a hierarchy of tests and benchmarks. The correctness tests we run on our laptops before committing code to the trunk take fifteen minutes, and we run benchmarks in the five-minute range for quickly checking the results of changes. The full suite runs only once a week... ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EmFQACgkQRgz/WHNxCGp2IwCfcofES+0R2BLmTBZ18wStt5Yf /zUAn3Z0NYBhWzWrDodOF6+gPi3441k5 =DVDu -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Updated README
Now that the bootstrap binaries at code.call-cc.org/bootstrap are deprecated, and having stubbed my toe once too many times on building git versions of chicken, I'd like to suggest the attached patch to the build advice in README. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ diff --git a/README b/README index ba863c7..15bd431 100644 --- a/README +++ b/README @@ -53,12 +53,14 @@ either setting makefile variables on the make command line or by editing the platform-specific makefile. +2.1. Building from a release tarball + To build CHICKEN, first extract the archive (tar xzf chicken-version.tar.gz on UNIX or use your favorite extraction program on Windows), then change to the chicken-version directory and invoke make like this: - make PLATFORM=platform PREFIX=destination +make PLATFORM=platform PREFIX=destination where PLATFORM specifies on what kind of system CHICKEN shall be built and PREFIX specifies where the executables @@ -72,26 +74,53 @@ Note that parallel builds (using the -j make(1) option) are *not* supported. +If you invoke make later with different configuration parameters, +it is advisable to run: + +make PLATFORM=platform confclean + +to remove old configuration files. + +2.2. Building from git + If you build CHICKEN directly from the development sources out of the git repository, you will need a chicken executable to generate the compiled C files from the Scheme library -sources. If you have a recent version of CHICKEN installed, -then pass CHICKEN=chicken-executable to the make -invocation to override this setting. CHICKEN defaults to +sources. + +If you are building in a checkout where you have built other +versions of chicken, you need to make sure that all traces of +the previous build are removed. make clean is insufficient, +and you should do the following: + + make PLATFORM=platform spotless + + If you have a recent version of CHICKEN installed, then pass +CHICKEN=chicken-executable to the make invocation to +override this setting. CHICKEN defaults to $PREFIX/bin/chicken. If you do not have a chicken binary installed, you will have - to obtain a bootstrapping compiler, which can either be - built from a release tarball (see below for instructions) or - by using a precompiled and statically linked compiler binary - from here: + to build from the closest release tarball to the git version + you are trying to build (significantly older or newer ones are + unlikely to work), and then use that chicken to build from + your git sources. You don't need to install the release + tarball chicken; simply unpack and build it in its own + directory with make PLATFORM=platform, then use it to + build your git chicken like so: + + LD_LIBRARY_PATH=release dir make PLATFORM=platform CHICKEN=release dir/chicken + +The LD_LIBRARY_PATH is needed on Linux to allow chicken to +find libchicken; it may or may not be needed on your platform, +but probably won't do any harm. - http://code.call-cc.org/bootstrap/ +2.3. Finishing the installation If CHICKEN is built successfully, you can install it on your system by entering - make PLATFORM=platform PREFIX=destination install +make PLATFORM=platform PREFIX=destination install PREFIX defaults to /usr/local. Note that the PREFIX is compiled into several CHICKEN tools and must be the same @@ -102,6 +131,8 @@ It designates the directory where the files are installed into. +2.4. Optional features + You can further enable various optional features by adding one or more of the following variables to the make invocation: @@ -186,6 +217,8 @@ LLVM version of gcc and with clang, the LLVM-based C compiler, just set C_COMPILER to llvm-gcc or clang. +2.5. Uninstalling Chicken + To remove CHICKEN from your file-system, enter (probably as root): @@ -194,12 +227,7 @@ (If you gave DESTDIR during installation, you have to pass the same setting to make when uninstalling) -In case you invoke make with different configuration parameters, -it is advisable to run - -make PLATFORM=platform confclean - -to remove old configuration files. +2.6. What gets installed These files will be installed under the prefix given during build and installation: signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg - Chicken version compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2011 04:32 AM, Felix wrote: Hello! Hello, Alaric. Hi! Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Probably an oversight of the egg maintainer. Have you contacted that person? Kon had a patch out within SECONDS, before I'd even found out it was his egg. Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. Yes, that would be nice. But chicken-install is not a package manager, it's a tool to install libraries. That's an interesting distinction to make. Given that it has the facility to install executables anyway, what's the difference in your mind? In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. That wouldn't work for flags that take arguments. In the other message, though, you suggested using declares, where unknown ones emit warnings rather than errors. Can't the command-line optimisation flags have the same semantics? What happens with declares that correspond to flags with arguments? Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. That itself would be a rather messy change. Aye, I prefer the subsequent suggestions of sticking to -On for portable command lines, or declarations in the source! We've had other problems with problems due to moving things around in the core chicken libraries, too. Oh yeah, we head. Sometimes things have to change. Still we try to maintain backwards compatibility, if possible. Long deprecation phases, change request, etc. Yes, I mean it, even if development sometimes may make the impression of being haphazardly done. I've sent you a mail about compatibility issues regarding ugarit (use of getenv). IIRC, you never replied. Indeed! I'm only just getting back into sorting Ugarit out, after a too-long hiatus :-( I need to get it compiling before I can start to change things :-) I think, overally, we all need to think more about backwards and forwards compatibility when we change the chicken core, so that eggs can work reliably on older versions without needing too many version conditionals! The problem you encountered was not caused by core system changes in this case. Well, an egg was using a flag that didn't work in older versions - so adding that flag was a change to the core, no? And who do you mean with we? And think about? Can't you simply say that this is annoying and you want it to stop? Did I not managed to express that? :-) So, do you have any suggestions? What can we do better? What are YOU willing to contribute? Could you specify more precisely what you'd like to have? How are the necessary incompatibilities to be introduced? How can we safely distinguish between bugfixes and incompatibilities (probably brought in with the intend of fixing bugs)? How can we keep up fast-paced development and maintenance, and fast response/bugfixing cycles for user reports and feature requests? Well, as I'm still catching up on things myself, I didn't want to get too far into specifics, but here's a few ideas: * Let's have a discussion about what the best semantics for an optimisation flag are. Should it fail if that optimisation isn't available in this version, or just emit a warning? What this boils down to is, when somebody requests such a flag, are they saying My code NEEDS this optimisation or My could WOULD LIKE this optimisation but will work without it? * Can we work out what versions are being installed by distros out there and draw a line in the sand of the oldest version it'd be nice if eggs still worked with (to be revised periodically) and have salmonella do another build of all the eggs against the appropriate git tag of chicken, to help detect accidental dependencies in eggs? * How about, when interfaces change in the manual, writing something along the lines of added in version X, so that people writing code using those interfaces who are concerned about compatability are given pause for thought, and can take appropriate actions (SRFI-0 etc) As for what *I* can do? I've got some hardware on order for a new home fileserver to replace my long-dead one, so I could probably set up a chroot to bring up a geriatric chicken in and test the eggs for salmonella. cheers, felix ABS - -- Alaric Snell-Pym http://www.snell
Re: [Chicken-users] Egg - Chicken version compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2011 04:32 AM, Felix wrote: Hello! Hello, Alaric. Hi! Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Probably an oversight of the egg maintainer. Have you contacted that person? Kon had a patch out within SECONDS, before I'd even found out it was his egg. Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. Yes, that would be nice. But chicken-install is not a package manager, it's a tool to install libraries. That's an interesting distinction to make. Given that it has the facility to install executables anyway, what's the difference in your mind? In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. That wouldn't work for flags that take arguments. In the other message, though, you suggested using declares, where unknown ones emit warnings rather than errors. Can't the command-line optimisation flags have the same semantics? What happens with declares that correspond to flags with arguments? Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. That itself would be a rather messy change. Aye, I prefer the subsequent suggestions of sticking to -On for portable command lines, or declarations in the source! We've had other problems with problems due to moving things around in the core chicken libraries, too. Oh yeah, we head. Sometimes things have to change. Still we try to maintain backwards compatibility, if possible. Long deprecation phases, change request, etc. Yes, I mean it, even if development sometimes may make the impression of being haphazardly done. I've sent you a mail about compatibility issues regarding ugarit (use of getenv). IIRC, you never replied. Indeed! I'm only just getting back into sorting Ugarit out, after a too-long hiatus :-( I need to get it compiling before I can start to change things :-) I think, overally, we all need to think more about backwards and forwards compatibility when we change the chicken core, so that eggs can work reliably on older versions without needing too many version conditionals! The problem you encountered was not caused by core system changes in this case. Well, an egg was using a flag that didn't work in older versions - so adding that flag was a change to the core, no? And who do you mean with we? And think about? Can't you simply say that this is annoying and you want it to stop? Did I not managed to express that? :-) So, do you have any suggestions? What can we do better? What are YOU willing to contribute? Could you specify more precisely what you'd like to have? How are the necessary incompatibilities to be introduced? How can we safely distinguish between bugfixes and incompatibilities (probably brought in with the intend of fixing bugs)? How can we keep up fast-paced development and maintenance, and fast response/bugfixing cycles for user reports and feature requests? Well, as I'm still catching up on things myself, I didn't want to get too far into specifics, but here's a few ideas: * Let's have a discussion about what the best semantics for an optimisation flag are. Should it fail if that optimisation isn't available in this version, or just emit a warning? What this boils down to is, when somebody requests such a flag, are they saying My code NEEDS this optimisation or My could WOULD LIKE this optimisation but will work without it? * Can we work out what versions are being installed by distros out there and draw a line in the sand of the oldest version it'd be nice if eggs still worked with (to be revised periodically) and have salmonella do another build of all the eggs against the appropriate git tag of chicken, to help detect accidental dependencies in eggs? * How about, when interfaces change in the manual, writing something along the lines of added in version X, so that people writing code using those interfaces who are concerned about compatability are given pause for thought, and can take appropriate actions (SRFI-0 etc) As for what *I* can do? I've got some hardware on order for a new home fileserver to replace my long-dead one, so I could probably set up a chroot to bring up a geriatric chicken in and test the eggs for salmonella. cheers, felix ABS - -- Alaric Snell-Pym http://www.snell
[Chicken-users] Egg - Chicken version compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! Having a spare lunch hour, I started to set myself up to do some Ugarit hacking on my new work laptop. I quickly ran sudo apt-get install chicken-bin and a fresh 4.5.0 appeared in my path, so I ran off and tried to run my new ugarit test suite... ...only for it to die on trying to install tiger-hash, due to: installing message-digest: ... changing current directory to /tmp/chicken-install-31.tmp/message-digest /usr/bin/csi -bnq -setup-mode -e (require-library setup-api) -e (import setup-api) -e (extension-name-and-version '(\message-digest\ \\)) /tmp/chicken-install-31.tmp/message-digest/message-digest.setup /usr/bin/csc -feature compiling-extension -setup-mode message-digest.scm -shared -optimize-leaf-routines -inline -unboxing - -output-file message-digest.so -emit-import-library message-digest - -scrutinize -optimize-level 3 -debug-level 1 - -no-procedure-checks-for-toplevel-bindings -no-bound-checks csc: invalid option `-no-procedure-checks-for-toplevel-bindings' shell command failed with nonzero exit status 16384: /usr/bin/csc -feature compiling-extension -setup-mode message-digest.scm -shared -optimize-leaf-routines -inline -unboxing - -output-file message-digest.so -emit-import-library message-digest - -scrutinize -optimize-level 3 -debug-level 1 - -no-procedure-checks-for-toplevel-bindings -no-bound-checks Error: shell command terminated with nonzero exit code 17920 Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. We've had other problems with problems due to moving things around in the core chicken libraries, too. I think, overally, we all need to think more about backwards and forwards compatibility when we change the chicken core, so that eggs can work reliably on older versions without needing too many version conditionals! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5OYDEACgkQRgz/WHNxCGrKvQCgjmZJPhN7BWmA+XKRC6aHewdY pWIAn0ewJghNLA7zePapPToLLHZ4Y03s =ed5i -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Save the Gazette!
On 02/28/11 14:36, Alaric Snell-Pym wrote: So far, I've written my omelette recipe into SVN; and tools are gathering in the gazette-tools egg and on the wiki page at http://wiki.call-cc.org/gazette - hopefully this weekend I'll get a chance to integrate and test what we have, and we may even get our first gazette out of it! I've just taken a look at Felix's work in the gazette-tools egg, and added in Andy Bennett's script to parse mailing list archives. I've generalised the users.lst mechanism a little to make it easy to map from real names to wiki links, and modified Andy's script to do that for email author names - and the results are awesome! I'll look into Andy's shellery to parse the git logs next - in the meantime, I encourage interested parties to have a play: chicken-install -s gazette-tools generate-eggs-history generate-list-history ...and laud Andy and Felix for their good work so far! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Save the Gazette!
On 02/28/11 14:10, Christian Kellermann wrote: The Gazette is reaching that point, and I want to save it. After all the wonderful responses to this thread and the awesome amount of work that it has triggered. I wondered who is working on a new issue now? This feels like people that have gathered around a collapsing person for help and then everyone goes back to work because someone said he has called an ambulance... The gazette is still there, waiting... Hee hee, don't worry; I've just been a bit busy with business travel and the new babe. So far, I've written my omelette recipe into SVN; and tools are gathering in the gazette-tools egg and on the wiki page at http://wiki.call-cc.org/gazette - hopefully this weekend I'll get a chance to integrate and test what we have, and we may even get our first gazette out of it! P.S.: This is not a I-want-to-annoy-you but a I-want-to-get-back-in-the-loop post... I'm glad to hear it ;-) Watch that wiki page and that egg in SVN, they're the rallying points; anything good that comes to me in email, gets pushed in those directions when I get a chance. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] awful as cgi or fcgi?
On 02/20/11 15:36, Mario Domenech Goulart wrote: In your second awful scenario the (rather wonderful afaict) awful must still be a long running process, correct? Yes, that's correct. The CGI could, if awful is not responding, fire it up though (with, if rquired, steps taken to prevent two simultaneous requests firing up two awfuls), if I can't start daemons at startup as I'm not root is an issue here... Best wishes. Mario ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cvjm
On 02/20/11 13:31, Felix wrote: Hello! I have imported an attempt at a static Java-Scheme compiler into the repository, which can be found in the release/4/cvjm/trunk directory. It compiles Java .class files into low-level Scheme code with full support for tail calls and continuations. *eyes pop out* wow! (since this is a static compiler, dynamic class definition is not supported and introspection will be limited). I bet even that can be fixed, though. introspection can just be a matter of hauling around run-time metadata, and dynamic class definition a matter of implementing a sort of indirection class at worst, depending on how you've implemented the compiler. What made you do this, out of interest? Purely the thought it'd be cool, or was there some particular project in mind? ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Save the Gazette!
On 02/17/11 14:33, Alex Shinn wrote: Or replace every use of sed and awk with perl, which is consistent across all platforms and scales better. However, as I think most of the people likely to run this code will have chicken installed and know Scheme, why not do it in Chicken? I believe somebody even wrote a decent regex implementation for it ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Save the Gazette!
When a community agrees it'd be cool to do something on a regular basis, to begin with, there's a lot of enthusiasm and volunteering, so things go well. However, a crucial point comes at which producing that thing starts to become a chore, no matter how popular the product is. At this point, if measures are not put into place to make it continue, it dies out. The Gazette is reaching that point, and I want to save it. I am happy to write editorial content such as recipes and mailing-list summaries, as long as I have time (and it doesn't take me long, I'm notoriously verbose in even the simplest of emails ;-), but I can't (personally) stomach the tedious part: going through the svn and git commit logs to find out what's happened, and then mapping git/svn identities to real names and people's pages on the wiki. So, I propose that you lot should automate it for me. I want: 1) The users page on the wiki to, in parens or brackets or something, after each person's name, list their various identities used in IRC / svn usernames / etc. so they can be easily tallied together 2) A script that, when run in a local svn checkout, or maybe by talking direct to SVN, lists all the eggs that have seen commits in a specified time period (with the option of right up to now as the end of the time period); and then lists the commit messages and revision numbers (for deeper investigation, if required) for each. For extra points, make sure that tagging a version of an egg is clearly indicated somehow (eg, TAGGED 1.5). This should all be a relatively simple matter of parsing the svn logs. 3) A script that, when run in a local git checkout, or maybe by talking direct to the core git repo, lists all the commits in a specified time period, grouped by branch. 4) All scripts should map usernames found in svn/git to displayed names via a function that defaults to identity. Somebody else please write a function to replace this, that looks in the wiki page and parses it to map svn/git identities to Wiki markup for the user's user page with their full name as the anchor text, that can be inserted into the above scripts to make wonderful magic happen. For bonus points, the output of scripts (2) and (3) could be actual markup for putting straight into the gazette, say as a bulleted list, just requiring editing to remove useless commits and to add editorial insight. Super special bonus point: 5) Write a script that, given a date range, parses the mailing list archive into wiki markup for a list of links to the posts in the archive, along with links to the user's pages as per (4), grouped by thread. I think that the above are relatively bite-sized chunks that people who want to see the Gazette continue should be able to manage between them; if the above are done then, if needed, I'd be willing to pioneer alone with running them each week (or every other week at worst) and writing some content around them! So, volunteers please :-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Save the Gazette!
On 02/16/11 13:22, Alan Post wrote: Ivan, I understood Alaric's message to be a request to take the commit log, c, regardless of the form they are in, and convert that directly into a form useable by the gazette: Summarized, formatted, and checked in to the repository. Sort of. I know there's RSS and so on available, but it currently needs much manual work to turn it into content. I'd like a script that pulls that RSS feed and spits out (to current-output-port is fine, I can tie them all together into a top-level script) something that I can really easily turn into gazette text. Eg, all the hyperlinks are already generated and marked up. Let me make up some examples: 2) A script that, when run in a local svn checkout, or maybe by talking direct to SVN, lists all the eggs that have seen commits in a specified time period (with the option of right up to now as the end of the time period); and then lists the commit messages and revision numbers (for deeper investigation, if required) for each. For extra points, make sure that tagging a version of an egg is clearly indicated somehow (eg, TAGGED 1.5). This should all be a relatively simple matter of parsing the svn logs. * [[egg:ugarit|ugarit]] * [r12345] Added more bugs [[users:alaric-snell-pym|Alaric Snell-Pym]] * [r56789] Tagged 0.9 [[users:alaric-snell-pym|Alaric Snell-Pym]] I'd then look up the revision numbers if I needed to check out the background of a meaningless commit message, but largely, I'd edit that down into a paragraph like: In the [[egg:ugarit|ugarit]] egg, [[users:alaric-snell-pym|Alaric Snell-Pym]] added more bugs in handling FIFOs then tagged version 0.9 (and be roughly confident all the links are correct :-) 3) A script that, when run in a local git checkout, or maybe by talking direct to the core git repo, lists all the commits in a specified time period, grouped by branch. Similarly, I'd be hoping for something like: * experimental * [deadbeef] Implemented call/pc [[users:felix|Felix Winkelmann]] * master * [cafebabe] Tagged v4.9 [[users:felix|Felix Winkelmann]] ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Save the Gazette!
On 02/16/11 14:20, Felix wrote: ... and I want a pony. :-) What colour? It is never the question of whether some well-crafted, time-saving tool is useful or not, that's obvious. It's always the question of who does it and when. So instead of discussing the technical details, I propose to discuss when we will get together and fix this once and for all, or try to find someone who coordinates such an effort. I'm sure a bunch of chickenistas will be willing to write some part of the whole thing (I certainly am). It would be good to identify (in a concise and not too specific manner) the different tools (or parts of a more general tool) that are needed. Post them here, and I will pick out something that I'd like to do. Others will join, hopefully. And you will take care of project management. Agreed? Agreed! I've outlined what I think would be good; of course, partial implementations (I did X but Y is too hard) are a step in the right direction, and somebody else might do Y later, too :-) Every little helps! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Save the Gazette!
On 02/16/11 15:04, Andy Bennett wrote: This bash command, executed inside a git repo, should do the trick: - for b in `git branch -a --no-color | sed -e 's/^*//' -e 's/^\s*\(\S*\).*/\1/'` ; do echo * On `echo $b | sed -e 's#^remotes/##'`:; git log --pretty=format:' * (%h): %s (%an, %ar)' --since=1 week ago $b; echo ; done; - It's a one-liner. That's a good start! Perfect! It doesn't seem to *do* anything for me (the first sed seems to turn the output of git branch into just as many blank lines) but, ah, we can work on such details ;-) You might get commits appearing in more than one place if the branches overlap. That's fine, the human can easily tidy up such niggles. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Gazette issue 12
_/_/_/ _/_/_/
_/_/_/_/ _/_/_/ _/ _/ _/_/_/_/_/
_/_/_/ _/ _/_/_/ _/_/_/_/ _/_/
_/_/_/ _/ _/_/ _/_/_/_/
_/_/_/ _/_/ _/_/_/_/ _/_/_/_/_/ _/_/
--[ Issue 12 ]- G A Z E T T E
brought to you by the Chicken Team
== 0. Introduction
Welcome to issue 12 of the Chicken Gazette, live from icebound rural
England!
== 1. The Hatching Farm
* Moritz Heidkamp added link shortcuts to hyde
* Peter Bex released a fix to charset encoding rules for fragment in
uri-common.
* Christian Kellermann merged in upstream changes to linenoise, and
provided
an input port usable in csi.
* Kon Lovett added posix-utils, which currently provides some
environment
access routines, but he hopes to add more miscellaneous POSIX
routines in
due course.
* Kon Lovett also moved the variable tools from moremacros into its
own
extension, variable-item.
* Kon Lovett, clearly on a roll by now, continued the programme of
improvements to srfi-29 with package per thread support.
* Felix Winkelmann released v0.8 of the bind egg, but neglected to
put
anything in the changelog so the consequences are a mystery to us
all!
* David Krentzlin released log5scm, a logging library based on CL's
log5
library
* Jim Ursetto updated sql-de-lite to SQLite v0.5.2 and fixed
`fold-rows*`
* David Krentzlin released his eagerly awaited nomads SQL database
migration
tool
* Moritz Heidkamp updated scss and then updated hyde to use it (along
with
another minor improvement)
== 2. Core development
Other than the usual fixing of minor bugs, it has been decided that the
ability
to statically build eggs is not worth maintaining; the first step, removing
documentation for this facility, has now been done.
But the big news is that version 4.6.3 has been tagged. Here's the
changelog:
- Peter Bex has cleaned up the makefiles heavily, making the
build more maintainable and easier to modify; thanks to all
who helped testing this new build
- renamed the makefile to `GNUmakefile' to catch using the
a make(3) other than GNU make
- `-fwrapv' is disabled on OpenBSD, since the default compiler
does not support this option (thanks to Christian Kellermann)
- on Solaris `gcc' is used by default, override `C_COMPILER'
to use the Sun compiler instead
- added the new foreign type `size_t' (suggested by Moritz
Heidkamp)
- added the missing `unsigned-integer64' foreign type (thanks
to Moritz for catching this)
- added support for proxy-authentification to `chicken-install'
(thanks to Iruata Souza)
- `define-record' now allows defining SRFI-17 setter procedures
for accessing slots
- removed the stub definition for `define-macro'
- added new foreign type `pointer-vector' which maps to `void **'
and provided a low-level API in the `lolevel' library unit
for manipulating pointer vectors
- declaring a function `notinline' will prevent direct-call
optimization for known procedure calls
- when compiling in C++ mode, the compiler will be called with
the `-Wno-write-strings' option
- the expansion of DSSSL lambda-lists uses now `let-optionals*'
internally instead of `let-optionals' and so allows back-references
to earlier formal variables; this also results in faster and
more compact code for argument-list destructuring (thanks to Alan
Post)
- Peter Bex has contributed various bugfixes and performance
enhancements to the `irregex' library unit
- fixed bug in `getter-with-setter' that modified the first argument
if it already had a setter procedure attached
- added a SRFI-17 setter to `list-ref'
- control-characters in symbol-names are now properly escaped if
the symbol is printed readably (thanks to Alaric Snell-Pym Blagrave
for pointing this out)
- added literal blob syntax (#{ ... })
- `delete-directory' now optionally deletes directories recursively
- fixed incorrect size of internal data vector used in `time'
(thanks to Kon Lovett)
- `list-tail' gives now a better error message when passed a non-list
argument
- deadlock in the scheduler now terminates the process instead of
attempting to throw an error
- added some sanity checks to the scheduler
- when installing from a local directory `chicken-install' now removes
existing `*.so' files in that location to avoid stale binaries when
the `make' syntax is used in setup scripts
The source code for the development snapshot may
be had from http://code.call-cc.org/dev-snapshots/.
Since 4.6.3 was tagged off, work has continued on the experimental and main
branches, in preparation for 4.6.4; further work on automatic
Re: [Chicken-users] using mmap files as strings?
On 10/27/10 13:02, Jörg F. Wittenberger wrote:
Another application would be shared substrings. Or the combination of
both. Example: feed a file content to a port, formatted as HTTP chunked
encoding. A shared substring pointing right into the mmaped file could
save all copying. The expense would be one object allocation holding
#{pointer, start, end}.
Just FYI, ages ago I wondered if it would be a good idea to make an
underlying blob abstraction that's a pointer, a size, and a custom
freeing function, so it can wrap malloc()ed memory, mmap()ed memory, and
whatever other special things might exist.
Then have blobs, strings, srfi-4 vectors, and friends all have the
option of being a reference to one of the above with an offset and
limit, so they can be views into arbitrary data from external sources.
ABS
--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] More on Packaging eggs
On 09/29/10 21:50, Jim Pryor wrote: * The following don't declare (hidden) or anything like that. But neither do they appear on http://wiki.call-cc.org/chicken-projects/egg-index-4.html: aes, crypto-tools, embedded-test, format-compiler-base, format-compiler, google-v8, linenoise, mailbox-threads, simple-units Hmmm, not sure what's up with aes and crypto-tools... ah, it's probably that I've never tagged a version for them under chicken 4. I shall fix that! * ugarit depends on crypto-tools, so without the latter I can't package the former either. Ugarit is also not yet tagged - I'm working on some stuff relating to its dependencies anyway. I'll tag it when that's ready! I welcome feedback or corrections about any of this. I think what you're doing is awesome! It's certainly kicking a lot of bugs out of the woodwork :-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Autoloading optional dependencies
On 09/13/10 07:52, Felix wrote: When the toplevel variable passed to `autoload' refers to a module binding, then you have to import it, otherwise it refers to an undecorated toplevel variable. I've just taken a look at how autoload works. Basically: (autoload foo bar) expands into something roughly like: (define bar (lambda args (require foo) (let ((tmp (global-ref foo#bar))) (set! bar tmp) (apply tmp args ...with some extra stuff in to handle conditions arising and all that. If there's anything fatally wrong with this approach, please say now, as it *seems* to be working OK for Ugarit ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Autoloading optional dependencies
On 09/13/10 10:03, Felix wrote: Oh, it already seems to take care of the module prefix. In that case, everything is fine, then. Sorry for the noise. Did you seriously think Alex might have done something WRONGLY? ;-) cheers, felix ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Autoloading optional dependencies
On 09/11/10 12:41, Peter Bex wrote: Well, go ahead and add it :) (chicken-install already ignores unknown meta declarations) I am! I'm just suggesting it in case anybody else does the same thing, so they don't come up with a *different* tag ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Autoloading optional dependencies
On 09/12/10 15:49, Felix wrote: But that wouldn't work inside modules, because you would have to have access to the import library, right? If there's macros involved, yes - but then autoloading macros makes no sense as they're loaded at compile time anyway. When you set up an autoload, no compile-time loading happens (no import library, etc) so the macros from the library aren't loaded - but at run time, if you call a procedure imported from the library, then the library is run-time-loaded. It's currently working in the ugarit-core library, anyway :-) cheers, felix ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Autoloading optional dependencies
Hi there folks I've noticed that the autoload egg goes partway towards solving Ugarit's depends on EVERY hash, compression, and encryption egg problem. For those not familiar with it, the principle is that I can write: (autoload z3 z3:encode-buffer z3:decode-buffer) ...and only if I actually use the z3:encode-buffer or z3:decode-buffer functions *at run time* will there be an attempt to load z3.so. This means I can remove all the hash, compression, and encryption eggs from the needs declaration in ugarit.meta, making it easy to install, but the user needs to install (eg) z3 if they want to actually enable deflate compression in their Ugarit configuration. But they needn't install things they don't actually use. Obviously, eggs which export syntax aren't eligible for such magic, but after all, how could a syntax egg be optional at run-time anyway? This isn't a *complete* solution since it still means Ugarit needs to know about all the hash, compress, and encryption eggs it might need, meaning that Ugarit needs updating every time somebody adds a new one - and any other apps in a similar situation to Ugarit will also need updating. So I'd still like a dynamic plugin registry one day ;-) Anyway, my point is this: I feel a bit dirty not declaring the optional eggs *at all* in ugarit.meta. Therefore, I propose the use of an optional declaration therein, like so: (optional lzma z3 tiger-hash sha2 aes) ...purely to document which other eggs it *can* take advantage of if they are available. Whether chicken-install does something with this information one day is open to debate - my hunch would be to wait and see if any other eggs adopt this design pattern, and if so, decide then what would be a good approach. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken Gazette - Issue 3
_/_/_/ _/_/_/ _/_/_/_/ _/_/_/ _/ _/ _/_/_/_/_/ _/_/_/ _/ _/_/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ _/_/_/ _/_/ _/_/_/_/ _/_/_/_/_/ _/_/ --[ Issue 3 ]-- G A Z E T T E brought to you by the Chicken Team == 0. Introduction Welcome to issue 3 of the Chicken Gazette! There is work afoot to improve the build system, so we would very much like testing and feedback on the Cygwin, Solaris and Haiku ports. If you have access to any of these operating systems, please check out the `make-refactoring` branch of chicken-core from git and tell us if it works well for you; append any feedback to ticket 167 in trac (http://bugs.call-cc.org/ticket/167). == 1. Infrastructure Salmonella is now running on Chicken 4.6.0rc1, and a drive to attract attention to broken eggs has brought our current failing egg count (http://tests.call-cc.org/2010/09/10/salmonella-report/) down to a mere FOUR, which may well be the lowest it's ever been (since we only /had/ four eggs, at least). For those who find git is not to their taste, there is now a regularly-updated bzr mirror of the chicken core at https://code.launchpad.net/~chicken, and the git repository can also be accessed via the git protocol (as well as the existing git-over-http) at git://code.call-cc.org/chicken-core. Now you have no excuse not to track the development releases! == 2. The Hatching Farm - New Eggs The Egg Repository There have been no new eggs this week, but many commits - most notably, Ivan Raikov has done a great job of moving egg documentation to the wiki from various legacy formats, so they'll all appear in chicken-doc and chickadee. == 3. The Core - Bleeding Edge Development The week started with Felix fixing a bug reported by Sven Hartrumpf, where `-optimize-level 2` was causing chicken to die with Error: (=) bad argument type - not a number: #f. Not to be outdone, Felix then went and fixed the Cygwin build system, so even those of us unfortunate enough to be shackled to Windows can enjoy tasty Chicken goodness without needing to ssh into a real computer. There's been non-stop fun out on the branches, too, with Peter Bex instigating a massive refactoring of the build system on the `make-refactoring` branch, and Felix doing optimizer and arithmetic work on the `experimental` and `overflow-detection` branches. == 4. Chicken Talk The Chicken Users list has been fairly busy this week, starting with the aforementioned optimizer bug report. An issue was raised with the tinyclos egg using the `-no-procedure-checks-for-toplevel-bindings` flag to csc, only introduced in version 4.5.2, while 4.5.0 is the latest stable release. It was pointed out that chicken-install will gladly install older versions of eggs with the following syntax: chicken-install tinyclos:version However, in future, it would probably be a good idea if egg authors held off of releasing versions of their eggs that use features from development builds of Chicken! Alaric Snell-Pym (your faithful Gazette editor this week) suggested adding links to browse the source code and to discuss each egg on the egg index (http://wiki.call-cc.org/chicken-projects/egg-index-4.html) page; there was a positive response to the idea of the source code links as long as it doesn't clutter things, but it was felt that users should be encouraged to raise egg suggestions and questions on the mailing list. A patch is in the pipeline to add the source browser links, so we can decide if it's a good idea in practice. == 5. Omelette Recipes - Tips and Tricks One of my favourite eggs is fmt (http://wiki.call-cc.org/eggref/4/fmt). There are two reasons for this. One is that I like what it does; neat text formatting is difficult, and is usually a distraction from the core problem your application is trying to solve; the fmt egg makes things like columns and justification easy. The second is that I like how it works. Common Lisp has the format function, which works much like C's printf function: a format string is provided containing static text with special control sequences where values should be inserted at run time. Naturally, format far exceeds printf in power; it being /Common Lisp/, they of course had to include such features as Roman numerals alongside more immediately useful features such as formatting lists neatly. However, format is not extensible; it has a fixed library of control sequences that tell it how to format things like lists, numbers, and strings; and various formatting operations such as left or right alignment, padding to fixed widths, and so on. People who wish to have different formatting modes for arbitrary objects (such as user-defined types), or specific formatting operations (such as flowing text into a circular frame), had to abandon format and write
Re: [Chicken-users] A proposal for the egg index
On 09/05/10 23:47, Peter Bex wrote: I'm a little worried that the egg index would become too complex or overwhelming for first-time users though. Yeah, it'd have to be done non-obtrusively. Small text, for a start! It shouldn't consume too much room in every row. 2) For each egg, a link to http://wiki.call-cc.org/eggref/4/EGG/discussion or some such, to encourage user feedback, feature requests, etc. That seems like a good idea, but we've had discussion pages for the entire duration of our svnwiki use, and to my knowledge nobody ever used them. Because of that I didn't build discussion pages into qwiki, since it would be just another unused feature I'd have to maintain. Does it need special wiki software support? I thought it'd just be another page with a name generated from the egg-page name, and one that people should feel more confident about adding questions, requests, and so on to than the egg page itself. Where's the tool that generates this page live, anyway? I'd guess somewhere under chicken-eggs/maintenance, but I can't find it. SPOOKY! :-) Cheers, Peter ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] A proposal for the egg index
Re http://wiki.call-cc.org/chicken-projects/egg-index-4.html Here's a few ideas I had. Do people think there's merit in them? 1) Alongside/under the version link for each egg, provide a browse source link to http://bugs.call-cc.org/browser/release/4/EGG/tags/VERSION or to http://bugs.call-cc.org/browser/release/4/EGG/trunk if there's no tags. Perhaps a link to /trunk as well labelled browse trunk source if there IS a tag. This will make it easy for people to dive in and see how an egg works under the hood. 2) For each egg, a link to http://wiki.call-cc.org/eggref/4/EGG/discussion or some such, to encourage user feedback, feature requests, etc. Where's the tool that generates this page live, anyway? If there's interest in either of the above, I'm happy to propose a patch. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Packaging eggs
On 08/31/10 15:12, Felix wrote: Argh. You're right. An install from a checkout will always set the version to unknown. On the other hand, just checking the directory name does not necessarily mean that the directory name is the version. So, being picky about it, one could argue that, unless the version comes from henrietta, it is not known and can not be guaranteed. Which is true. Aye. An egg that's being built from a development version that hasn't been tagged as a version yet can't really have a meaningful version number assigned. At best, it could be considered as having the version number of the most recent tag it's based on, but even then, it'd be a lie. SVN doesn't make it particularly easy to do this, but git has some tooling to name a version by getting the most recent tag-name matching a regexp (eg, v[0-9]+\.[0-9]+ or something) before the commit in question, and then if that most recent tag isn't point to the actual HEAD appending the hash of the HEAD, and then if the sources have local modifications appending -dirty. Or something like that. The closest equivalent might be to produce version strings like r15231[-dirty] if building from an SVN checkout! Where I work we have slightly different development/official build processes - the development process, which is run if you just run make, produces version strings based on the date, time, and username of the builder (so anyone who leaks one can be BLAMED), while the official builds are identified by a version number. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Packaging eggs
On 08/31/10 10:26, Felix wrote: What's the official method for retrieving what non-scheme dependencies the eggs have? I think I just had to determine this by trial and error (sometimes reading the egg's documentation) and keep a record of it myself in the automation scripts. Is there no officially sanctioned way to mechanically retrieve this information? No. This could be put into the .meta file, but we would have to specify a single universal format usable over all supported platforms. Yeah, not highly tractable. However, it might be useful to put an external-dependencies key in the meta file which has a list of... I dunno... human readable strings saying postgresql client libraries? URLs of the main project pages of the dependencies? I've been asked by NetBSD users interested in packaging Ugarit as a pkgsrc package if chicken-install could have an option to extract from a previously-fetched henrietta-chunks file. pkgsrc has the following sequence: fetch (from a supplied URL, with fallback along a list if the first one fails, eventually back to a netbsd.org central mirror-of-almost-all-packages) [pkgsrc then checks the checksums] extract (into a directory tree) patch (any NetBSD patches are applied) build install The fetch/extract phases can be overridden somewhat, but it'd be nicer to make use of the checksumming and mirroring infrastructure that's already provided. I'm not sure if chicken-install would let us separate build and install, but at a pinch, build could be a no-op and install could do all the work, I think. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] new egg server at call-cc.org
On 08/11/10 00:06, Felix wrote: The `chicken-install' program usually downloads from two different servers of which one is currently unavailable (galinha.ucpel.tche.br), so it may happen that the attempt to retrieve the extension times out, if the remaining egg server (chicken.kitten-technologies.co.uk) is under heavy load. As the main cause of heavy load on that server was the chicken update cron job, I've taken steps to do that with svnsync now (and even written a tutorial on how to do it yourself for a nice local mirror: http://wiki.call-cc.org/running-an-egg-mirror ) Hopefully this will make chicken.kitten-tech more reliable in future... but more interestingly, maybe it will also make it easier for more people to run public mirrors so we can have more fallbacks ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg request: banterpixra
On 07/12/10 14:10, Alaric Snell-Pym wrote: If it's of use to anybody else (I wrote it so I could draw syntax diagrams for the constructed language Lojban - see http://love.warhead.org.uk/~alaric/junk/lojban.svg for a more stressful workout of the layout engine), I'd like to put it in an egg, please! Duly committed, and a 0.1 release tagged. It even has documentation (in SVG...) FYI, the name is a Lojban word for language artist, and is pronounced something like ban-tair-pihhh-ra :-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Egg request: banterpixra
Hello all, I've written a quick few hundred lines of Chicken Scheme that converts BNF-esque grammars such as: (s-expression . (choice (seq ( (one-or-more s-expression) . s-expression )) (seq ( (zero-or-more s-expression) )) (seq \ string \) (seq #( (zero-or-more s-expression) )) (seq # symbol) (seq : symbol) (seq symbol :) symbol number (seq ' s-expression) (seq ` s-expression) (seq , s-expression) (seq ,@ s-expression))) (symbol . (choice (seq | (one-or-more character) |) (seq symbol-first-character (zero-or-more symbol-subsequent-character Into SVG syntax diagrams such as: http://love.warhead.org.uk/~alaric/junk/sexpr.svg It uses matchable and sxpath-lolevel (from the sxpath egg) - the latter for turning the sxml representation of SVG into yucky XML. If it's of use to anybody else (I wrote it so I could draw syntax diagrams for the constructed language Lojban - see http://love.warhead.org.uk/~alaric/junk/lojban.svg for a more stressful workout of the layout engine), I'd like to put it in an egg, please! ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Egg request: 4/aes
Hello! I'm porting my old chicken3 aes egg to chicken4. Well, rather, I'm applying c-keen's patches to do same, and fixing a few things here and there. Please can I have a 4/aes egg dir in svn? There doesn't seem to be one yet! Thanks, ABS ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken core moved to git
On 28 Oct 2009, at 11:46 am, Mario Domenech Goulart wrote: git clone http://chicken.wiki.br/git/chicken-core.git Great news! For its flaws, I've found git a great improvement over SVN. But how's elf taking it?!?!? :-) Thanks all, ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wikipedia
On 22 Oct 2009, at 4:54 am, John Cowan wrote: I spotted one error: in a let loop, the loop identifier is not just callable in a procedure-like way. It's bound to an actual first-class procedure which can be exported from the loop and called at any time. Y'know, if I'd thought about it, I'd have expected that to be the case - but I'd only ever thought of using the loop identifier within the static and dynamic scope of the loop, as my brain is still steeped in lingering traces of C. Mmmm, beautiful delicious Scheme; how I wish I was using you in my day job. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Does Chicken garbage collect unreferenced symbols?
On 23 Aug 2009, at 10:38 pm, John Cowan wrote: The idea is to speed up string lookups. Currently the a-list maps strings to values, which means I must use assoc to search it. If it mapped symbols to values instead, I could use the faster assq. I'd rather intern the strings once and have done, but I don't want to cause a memory leak. Furthermore, the string I'm looking for is sometimes derived from symbol-string, so I actually have a symbol to start with. This is probably true for the majority of lookups, though not the majority of entries. Ah, OK. When you spoke of random symbols, I had a fear you were generating symbols with (eg) sequential numbers as names or something similarly meaningless, just to get a 'comparison token'. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Does Chicken garbage collect unreferenced symbols?
On 22 Aug 2009, at 11:43 pm, John Cowan wrote: If symbols aren't gc'd now, I'd like to argue for them to be. In an application I'm writing, I want to generate lots of random symbols at runtime so they can be looked up more quickly in a-lists, but I don't necessarily want them hanging around forever. Is that necessarily the best solution to your problem, though? Anything with an identity (a cons cell, for example) will work as a 'token' for a-list lookups? ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] SRFI-12 exceptions: best practices
Hello! I just fixed a bug in Ugarit that happened because I misused SRFI-12 exceptions. I'd just copied the usage I'd seen in other code, and wrote: (if (not (directory? base)) (signal (make-property-condition 'exn 'message The archive does not exist 'arguments base When I really should have written: (if (not (directory? base)) (signal (make-property-condition 'exn 'location 'backend-fs 'message The archive does not exist 'arguments (list base ...with the end result being a confusing error message about the wrong type of arguments to apply (as it appears something somewhere applies a function to the contents of the arguments property of the condition). Hunting for actual documentation on the correct usage, I finally found a small note at http://chicken.wiki.br/man/4/Unit%20library#exceptions that read: Error-exceptions of the exn kind have additional arguments and location properties that contain the arguments passed to the exception- handler and the name of the procedure where the error occurred (if available). It occurs to me that the documentation could be expanded a little. SRFI-12 itself really focusses on the underlying mechanism of exceptions, rather than talking about how best to use them. Perhaps http://chicken.wiki.br/man/4/Unit%20library#exceptions could give some real-world advice. For example, in Ugarit, I'm generally reporting fatal errors in the configuration file, so I just make a property condition as above, but I know that libraries that have more useful detail about the exception make a composite condition that merges a 'exn with their own condition type to report all the extra data. Am I ok in not making a composite condition, because I have no extra data to provide? Should I composite it with a 'chicken-configuration-error kind, even if it has no properties, just so that the source of the exception in a complex system with lots of libraries is known? Etc? If people could codify best practice here on the list, I'll happily write it up and submit a documentation patch :-) Thanks, ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Ann.: CHICKEN 4.0.0 released
On 6 Apr 2009, at 1:10 am, Leonardo Valeri Manera wrote: Also: kitten-technologies? :3 Meow ;-) ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cons-wm
Cool! (Unfortunately, I'm a Windows user now...) I have a similar problem, involving Macs! However, when I had a NetBSD workstation, I liked the ion window manager - but I always wanted to do my own, that would better combine tiling windows and floating windows in the way I THOUGHT BEST DAMMIT so messing around with my own WM was always on the cards - and if I get around to that again one day, cons-wm will form a great foundation :-) ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] efficient bytevector-ieee-double-native-ref
On 17 Feb 2009, at 3:47 pm, Eduardo Cavazos wrote: Eduardo Cavazos wrote: (define (bytevector-ieee-double-native-ref blob i) (f64vector-ref (blob-f64vector/shared blob) i)) So the obvious problem here is the conversion is going to impact performance. If somebody who is familiar with Chicken internals can suggest a way to extract an 'f64' element from a blob directly, I think I'll be set. :-) Hello! There's a few ways. For a start, you can always make shared vectors, as you do above - since they share the storage, creating them should be pretty efficient. Or you can write a C function that does tevector-ieee-double-native- ref; see the section in the manual about accessing foreign functions - a blob is passed to the C world as a pointer, and you can do ((double*)ptr)[index] in C and lo, a double will emerge. (IIRC, an f64 is a double, right?). But, in the long run, I think Something Must Be Done. Personally, I feel that bytevector is a bad idea - vector-of-bytes is just one possible interpretation of a region of memory. I like the idea of a blob that has no inherent access primitives - but that has ways of making 'aliases' to regions of it that have types. I made a proposal about this a while ago - I also wanted to avoid having to copy memory blocks returned by foreign code into blobs for use in the Chicken world; my proposal was to rewrite chicken's blobs so that they may either be a heap-allocated region (for small blobs) or an arbitrary pointer and length with a custom finalizer function (which can handle calling free() on malloc-ed blocks). Having thus abstracted out the management of the memory block, the underlying blob system could then form a basis for other large-data types - such as SRFI-4 vectors or R6RS bytevectors (if you must). These types would all keep a reference to a blob used as the backing store, then a base index and a length, so they can refer to just a subregion of the blob. It might also be worth storing a custom stride that's used as the multiplier when referencing rather than just sizeof(element), so that it'd be possible to make: 1) A vector that represents a row *or* column out of a 2D array - or any higher dimension 2) A vector that goes *backwards* without having to reverse it explicitly, by having a negative stride 3) An infinite vector of the same element (by having a zero stride and a MAXINT length) Then it'd be possible to make sub*vector/shared functions that just make a new vector referring to the same underlying blob, but having different start/length. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimizing mutually recursive loops
On 16 Feb 2009, at 5:09 pm, Tobia Conforto wrote: Alaric Snell-Pym wrote: Some would say that the matrix multiply should just be written in C and FFIed. In fact, most would just (use blas) or such. But I understand it was just an example. Well, yeah ;-) Concurrent Clean, a Haskell-like purely functional language that, unlike Haskell, implements mutating operations using uniqueness typing. I'm wondering whether we could apply a similar idea to Chicken. Do you think there is any space for improvement, where we could somehow reduce GC by declaring stuff as unique? I know I'm just hand-waving at this point, I need to think more about it. Quite possibly. In fact, Henry Baker (who wrote the paper on the Cheney MTA algorithm Chicken uses) has papers on the topic of Linear Lisp - see the references at http://en.wikipedia.org/wiki/Uniqueness_typing#Discussions_of_uniqueness_typing_in_programming_languages Any complex imperative algorithm involves a certain number of nested control structures, and before long, you need to add a single extra arc to that. This is quite true and I've found Scheme's named let an excellent syntax for this kind of algorithm. You can just write the loops in the natural order of variable declaration, and then jump back and forth as you need: Oh, I'll just restart with the 2nd outer loop here: (loop-row x (+ y 1)). In fact, I've been writing named loops in other languages too, where the language lets me do it... which means, if it has a syntax for lambdas. But they never come out as nicely as in Scheme. Yeah! I've made delightful use of escape continuations in the command line interface for Ugarit. My core command line function presents a prompt and processes what the user inputs; if this is a cd then it recurses to work in the subdirectory, while cd .. returns; other commands just tail-call the CLI function again, but quit escapes the whole lot by just calling a continuation established by a top-level let/cc. This made for a very natural structure; similar code in C I've written always seems to involve a boolean flag that requires sometimes complex handling... But written as a state machine, such extra control flow arcs are easy to add. I've been meaning for some time to experiment with writing Scheme macros that implement a state machine language designed for ease of use, and experimenting with using them. Nice! Do you have any prototype we could play with, or ideas we could discuss? No prototype, but lots of ideas: 1) Each state should be parameterised. This is a trick to convert a system of state machine plus mutable memory to just state machine - basically, you describe potentially infinite families of states in a single rule by giving the rule parameters. Rather than having mutable variables, you just pass parameters to states, and to modify them they just pass new values on to the next state (or to themselves, if looping). This reduces the state machine to a set of mutually recursive pure functions, and the uniqueness just removes the need for GC and opens up implementation as a set of registers. 2) Yet it'd also be nice to automate some of this by establishing a group of states as a form of lexical scope, declaring some state variables for that scope, and having the states within that scope, when they call each other, automatically passing any variables they don't explicitly pass. An example might make that clear. Say your state machine, from time to time, has to do something a hundred times. So you might have a parameterised state that does something N times. Say this thing has several steps - the steps would have to pass N around between themselves so the last state can jump back to the original state, passing in N-1. But that might get tiresome - it'd be nice to write: (let (N) step1: ... ... ... (goto step2) step2: ... ... ... (goto step3) step3: ... ... ... (if (zero? N) (goto ...exit...) (goto step1 N: (- N 1))) Eg, N is being automatically passed along when step2 calls step3 (the initial entry to step1, being from outside the 'scope', must pass it in explicitly, of course); but step3 explicitly gives a value for N, which is then used. I don't know if this is a good idea or not - hidden state can be bad, and it requires keyword-style arguments to states, which may be more pain than it's worth. 2) How about reuse of portions of state machines? They should allow some kind of lexical scope, too. A complex set of states should be packagable into a black box with a set of defined entry states, and dangling pointers out to exit states that must be supplied when the package is used, in effect providing enough exit continuations with the correct signatures. It's not quite like a closure, since it might have several entry states. But perhaps that's not important and it should just be called a closure? Really, I need to work on some examples and work on a syntax that's flexible
Re: [Chicken-users] optimizing mutually recursive loops
goto for large-scale program structure, which was too large a scope for a human to keep track of what's what, leading to the fabled spaghetti code. But the baby was thrown out with the bath water. Any complex imperative algorithm involves a certain number of nested control structures, and before long, you need to add a single extra arc to that. Oh, in this case, we need to go and restart from this point up here. At which point, you need to rearrange the whole thing in order to fit the new structure. This is particularly obvious in exception handling; C programmers often have to resort to a cleanup: label at the end of a function that they can goto, which exceptions are to some extent syntactic sugar for. But written as a state machine, such extra control flow arcs are easy to add. So, these two threads have been bubbling around in my head, and I've been meaning for some time to experiment with writing Scheme macros that implement a state machine language designed for ease of use, and experimenting with using them. Obviously, I was just going to make them generate letrecs, since I was interested in designing a structure that I knew *could* be implemented efficiently if made a special form, rather than actually trying to get Chicken to be efficient, but that's by the by; if I came up with a syntax that was elegant, we could look at an efficient implementation later - perhaps even one that the chicken core knows about (or, more likely, that compiles to a low- level special form that just handles generating a set of goto-able labels and gotos between them). ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Cryptographic eggs
On 11 Feb 2009, at 3:27 pm, Andreas Rottmann wrote: Peter Bex peter@xs4all.nl writes: On Sun, Feb 08, 2009 at 08:00:55PM +, Alaric Snell-Pym wrote: VOTE! :-) I don't find S3 all that exciting, while SFTP is very nifty to have. So I vote for SFTP. +1 Cheers, Rotty SFTP it is, then ;-) ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: GPG support?
On 11 Feb 2009, at 11:23 pm, Andreas Rottmann wrote: Hi! I'm considering switching to ugarit (from a home-made C program driving afio/tar/gpg) for my backup needs (a few Linux boxes), and would really appreciate: - GPG support (e.g. generate a random AES key/IV, and store it, encrypted via GPG, in the archive). This would do away with the need to store the AES key in plaintext in a config file. True, but there'd need to be something *equivalent* to the AES key still in the config file, even if that is just details of where to find a GPG key that can decrypt an AES key stored in the archive... ...would you prefer an option to prompt for a key on the console when opening an archive? (I already have a plan for plaintext passphrases, I just need to figure out a nice way to make 256-bit ones - Tiger hashes will produce 128 or 192 bit keys from passphrases, but not 256-bit ones). - .ugarit-ignore file support (as already on the list of planned features); this is in fact the itch I scratched with my custom-made backup tool, as I couldn't find a backup solution that offered that feature. Yeah! I'm mulling that a bit after a conversation that came up with Peter Bex on IRC. My original idea was just to make it an ignore file, to not archive certain things. But Peter raised the idea of filters such as magically archiving an SVN repository as just a file that's the result of an svnadmin dump on the repository and before/after commands, such as checkpointing a database before dumping it. However, such tricks would depend on being able to trust the rule files, while just supporting 'ignore' wouldn't; even if you run the commands as the UID of the user owning the rules file, they could fail to terminate and thus halt the snapshot. So my current thinking is to have dangerous and safe operations in the rules files, and dangerous operations would only be performed if the rules file was owned by a user in a trusted list, which defaults to the UID that ran ugarit. Dangerous operations would, in general, involve running an arbitrary wrapper closure to handle the object that matched, with procedures provided in the namespace that create closures to provide filtering and before/after shell command execution, with some support (to be determined) for running the commands as specified users (just punt that job to sudo?). For now, though, I can proceed with basic ignore functionality, but I'll need to leave my options open for the more advanced stuff :-) Keep up the good work! ;-) Regards, Rotty ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Cryptographic eggs
On 7 Feb 2009, at 2:13 am, Alaric Snell-Pym wrote: But, first, I'm going to go and add encryption support to Ugarit, the goal of this egg-writing arc! DONE! In the process, I also made a new release of crypto-tools, that handled CBC with an embedded IV. As in, you provide an IV when encrypting, and it prepends an encrypted copy of this to the output, then the decrypt operation doesn't require an IV since it can decrypt it from the cyphertext. The idea being that when encrypting you obtain IVs from some random source, rather than needing the decryptor to know them in advance. This is a fairly secure way of encrypting lots of messages with the same key, while going some way to obstructing chosen- plaintext attacks and the like. Ugarit, when you request AES encryption, will now happily use the embedded-IV CBC mode, pseudorandomly generating IVs by repeated application of the tiger hash function to the previous IV and the compressed blocks being uploaded; sadly, the likes of /dev/random wouldn't generate nearly enough entropy fast enough. For my next trick, I shall implement either SFTP or Amazon S3 as a storage backend. I looked at duplicity, the backup system that made me get off my arse and write ugarit, and to my horror its SFTP backend consisted of shelling out to ssh or sftp for every operation - and ugarit will often send lots of small objects, so that wouldn't do. However, the actual SFTP protocol looks easy - you pretty much just open an ssh connection by popen-ing ssh, then talking a simple protocol over the pipe: http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-4 The protocol supports all sorts of advanced stuff like remote access to ACLs; what I propose is that I produce an sftp-client egg that implements as much of the protocol as Ugarit needs, and then I can add other features on demand if people want them (or perhaps one day learn tinyclos and add a sftp driver for the vfs egg). For S3, I'll need to implement the S3 protocol, which is mainly HTTP PUTs and GETs with special HTTP request headers for authenticating the requests. For some reason that daunts me (in my experience, it's often a pain getting the hashing *just right*), but I'm sure I'll get there. But - what shall I do first? Which would people find most useful? SFTP will let you run backups to anywhere you can SSH to, while S3 will let you only run backups to S3 - but S3 is a nice cheap place to put backups. Personally I need S3 most for my backup requirements, but I want to support both. VOTE! :-) ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Cryptographic eggs
On 9 Feb 2009, at 12:40 pm, Peter Bex wrote: On Sun, Feb 08, 2009 at 08:00:55PM +, Alaric Snell-Pym wrote: For S3, I'll need to implement the S3 protocol, which is mainly HTTP PUTs and GETs with special HTTP request headers for authenticating the requests. For some reason that daunts me (in my experience, it's often a pain getting the hashing *just right*), but I'm sure I'll get there. Which egg would you use to do these requests? Intarweb, http, or hand roll something? It would be really nice if we could deprecate the http egg for Chicken 4. Although I'm developing on 3 now, I'm keeping a mind open for moving quickly and painlessly to 4 as soon as it's released (and in pkgsrc...)! AIUI, intarweb is chicken4-only, right? Yes, deprecating http would be good, so I'll avoid using that. So I might be tempted to do what I'm doing with the posix-extras: the posix-extras egg wasn't released (is it yet? I need to check), so I embedded the bits I needed in ugarit for the time being, so they can easily be stripped out and replaced with a (use posix-extras). Gah, I just realised I forgot to add the crypto eggs to the dependencies in the .meta file, whoops... mental note: write and propose patch to chicken-setup that makes use complain if you use a unit not declared in the base or in an egg listed in the .meta! Anyway, yes, back on topic: what might be best, then, is if I embed some of the innards of intarweb into the s3 egg's code for now, such that when it goes to chicken 4 I can just replace that with (use intarweb) (import doohickies without a prefix) or whatever it is ;-) VOTE! :-) I don't find S3 all that exciting, while SFTP is very nifty to have. So I vote for SFTP. Vote noted - SFTP is in the lead... ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
