Re: [Chicken-users] Nested hash-tables, and so on..
On Sun, Feb 09, 2014 at 03:29:09PM +0100, mfv wrote: Hi, I've been fooling around a bit with chicken, and now I am on towards a small project. I have a question regarding the performance of list and hash-tables. I plan to use nested hash tables as a data structure e.g. hash-table1 | key1 | hash-table2 | key2 | list/string/some data Are there objections to such a nested hash table structure e.g. should one keep it as flat as possible and use multiple hash-table is parallel in order to maximize performance? In non-scheme languages, I use this technique a lot. It's a poor man's struct, and when you don't exactly know what problem you're solving yet, that's precisely the data structure you need. If you're worried about multiple hash table lookups, you can create a composite key: pick a character/object that won't appear in key1..n, and use it as a separator, joining and splitting your key to convert it to/from it's composite. I've rarely used this technique, compared to the above above nested hash tables, so I suspect that nested hashing will be adequate to solving the problem you have in mind. I don't believe there is anything fundamentally wrong with your approach. -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] combining syntax-rules and er/ir-macro
I'm working on a macro, |enum|, that accepts a prefix and a set of values, that expand in to a basic symbolic enumeration: (enum my foo bar) = (define my '(foo bar)) (define my-foo 'foo) (define my-bar 'bar) The reason for the above is immaterial, I really need help with the error I'm seeing trying to implement it. I am using a combination of syntax-rules and er/ir macros, and I'm getting an error message I don't understand (warning, untested code): ++ file.scm (define-syntax $%map (syntax-rules () ((_ fn () (r ...)) (r ...)) ((_ fn (x y ...) (r ...)) ($%map fn (y ...) (r ... (fn x)) ; (map foo x y z) = ((foo x) (foo y) (foo z)) ; (define-syntax %map (syntax-rules () ((_ fn l ...) ($%map fn (l ...) () (define-syntax enum (ir-macro-transformer (lambda (form inject compare?) `(define-values (,(cadr form) ,@(map (lambda (x) (symbol-append ,(cadr form) '- x)) (cddr form))) (values ,@(%map quote (cdr form))) (enum my foo bar) (pretty-print `(,my ,my-foo ,my-bar)) -- $ csi -n file.scm Error: during expansion of (enum ...) - unbound variable: %map Why is %map not visible inside enum? -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] combining syntax-rules and er/ir-macro
Thank you Evan, that helps explain the error message I was seeing. When I make your proposed changes, I get the following: ++ my-file.scm (begin-for-syntax (define-syntax $%map (syntax-rules () ((_ fn () (r ...)) (r ...)) ((_ fn (x y ...) (r ...)) ($%map fn (y ...) (r ... (fn x)) (define-syntax %map (syntax-rules () ((_ fn l ...) ($%map fn (l ...) ()) (define-syntax enum (ir-macro-transformer (lambda (form inject compare?) `(define-values (,(cadr form) ,@(map (lambda (x) (symbol-append (cadr form) '- x)) (cddr form))) (values ,@((inject '%map) (inject 'quote) (cdr form))) (enum my foo bar) (pretty-print `(,my ,my-foo ,my-bar)) -- $ csi -n my-file.scm Error: during expansion of (enum ...) - call of non-procedure: %map128 I might assume the problem here is that %map isn't a procedure, it's syntax, and that the symbol is being properly injected, but then how do I can a macro from a macro? I'm not even certain I'm diagnosing the problem correctly. -a On Thu, Jan 30, 2014 at 03:16:57PM +1300, Evan Hanson wrote: Hi Alyn, On 2014-01-29 18:07, .alyn.post. wrote: Why is %map not visible inside enum? In order to make `%map` available to the enum transformer, it needs to be defined at expansion time, e.g. (this is one way, there may be others): (begin-for-syntax (define-syntax %map (syntax.rules () ...))) Also note that because `enum` is an ir transformer, the form provided to it will already have been renamed, so as it stands it will most likely define something like my-foo123 rather than my-foo -- you'll probably have to `inject` those parts of the form in order to have the correct identifiers bound as a result /possibly unwelcome observation. Cheers, Evan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Keep `csi` open after reading from pipe
On Wed, Jan 22, 2014 at 10:03:37PM -0500, Quint Guvernator wrote: .alyn.post. alyn.p...@lodockikumazvati.org: The example below emulates the default Chicken Scheme exception handler, but continues the interpreter: This is precisely what I was looking for. Thank you for your assistance. I won't hesitate to come back to this list for advice. Regards, Quint Happy hacking! -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Keep `csi` open after reading from pipe
I believe the typical way to do this is to include the file after you load csi: $ cat my-input-file.scm (define (doit) (display hello world) (newline)) $ csi #;1 (include my-input-file) ; including my-input-file.scm ... #;2 (doit) hello world #;3 If you don't want to type (include ...) every time you load csi, you can (load ...) it in your ~/.csirc file. In the event of a syntax error in that file, you can use |csi -n| to start csi without loading your ~/.csirc. Since this is a common scenario, you may want to continue in the event of an error in your input file. The example below emulates the default Chicken Scheme exception handler, but continues the interpreter: $ cat ~/.csirc (handle-exceptions exn (with-output-to-port (current-error-port) (lambda () (print-error-message exn) (print-call-chain))) (load my-input-file)) $ cat my-input-file.scm (define (doit) (display hello world (newline)) $ csi Error: (line 4) unterminated list, starting in line 1 Call history: ... #;1 (doit) On Mon, Jan 20, 2014 at 08:41:32PM -0500, Quint Guvernator wrote: Hello All, I am not subscribed to this list, so please CC me if you respond. I am trying to find a way to keep the chicken scheme interpreter open even after it finishes running my input file (via a unix pipe) so I can play with the functions I define in the interpreter. Is there a simple solution? Cheers, Quint ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] #invalid forwarded object using FFI callback
Good day pulijzer. I have not. My best guess currently is that my call to make-string returns a scheme object back to C. I then make another call to make-string, and the GC doesn't (so far as I understand it) have a reference to that first make-string. If any of these intermediate make-string calls triggers a GC, I'll be left with a reference that was garbage collected. (I'm further given to understand I get a categorically distinct GC (a minor GC?) that doesn't longjmp, because I'm calling in to Scheme from non-reentrant C code. Which may or may not matter...) If the GC takes care to mark every object passed to C as a root pointer this wouldn't happen. I'm neither sure this is what is causing my invalid forwarded object problem nor whether or not Chicken does object marking around the C FFI boundary. on IRC I was advised to break up my call to C in to smaller pieces so I wasn't holding any/as many scheme objects. I haven't revisited this code since receiving that advice as I find it vaguely unsuitable and plan to review the relevant parts of the FFI interface for a more informed fix--as this becomes a crisis rather than an intermittent problem. I'm embarrassed to report this code fires during a consistent point during initialization of my code, and I set a high-enough initial heap to not trigger a GC. That initial heap size is there for other reasons--but it helped make this problem go away for me too. -a On Thu, Dec 19, 2013 at 09:15:21PM +0100, pluijzer . wrote: Hello Alyn, Did you find a solution to this problem? I seem to suffer a similar problem. thanks, Pluijzer 2013/12/8 .alyn.post. [1]alyn.p...@lodockikumazvati.org Greetings, I'm encountering the following error message inside a callback using Chicken's FFI interface: Error: (cdr) bad argument type: #invalid forwarded object * * * * Call history: * * * * pwent.scm:100: loop * * * * pwent.scm:56: ##sys#gc * * * * pwent.scm:56: g42 * * * * pwent.scm:24: make-string * * * * pwent.scm:24: make-string * * * * pwent.scm:24: make-string * * * * pwent.scm:24: make-string * * * * pwent.scm:50: clist-append! * * * * pwent.scm:100: loop * * * * pwent.scm:56: ##sys#gc * * * * pwent.scm:56: g42 * * * * pwent.scm:24: make-string * * * * pwent.scm:24: make-string * * * * pwent.scm:24: make-string * * * * pwent.scm:24: make-string * * * * pwent.scm:50: clist-append! * * * * * * -- What seems to be happening is that I'm running out of (stack?) memory while inside/around a C thunk. *I cannot seem to avoid this message by modifying the nursery, either from csc -nursery or from -:s. I have only a topical grasp of Chicken's FFI, so I suspect I'm simply doing something ill-advised, though I would appreciate advice on how to approach my problem: I'm trying to read /etc/passwd using getpwent(3) and store each record returned in a scheme list. *(My particular /etc/passwd file contains 100 elements, the above error happens near the end of the call.) *I'm marshalling records using two callbacks: one to create the memory for string data, and one to append each record to the list. May I have feedback on the pattern I'm using here to marshall data? And a suggestion on how to avoid invalid forward objects while reading large but disjoint data from C? *I'm at a loss as to why exactly I'm getting the above message, and it well could be incorrect code on my part. *Do my multiple calls to _make_string from C, below, cause the GC to loose track of my string pointers? *Something else? ++ csc -o pwent pwent.scm ./pwent (use extras) ; a circular list (where we track the ; head and tail) with a dummy head. ; (define (make-clist) * (let ((head (list #f))) * * (cons head head))) ; O(1) list append. ; (define (clist-append! d v) * (let ((l (list v))) * * (set-cdr! (cdr d) l) * * (set-cdr! d l))) ; return proper list ; (define (clist-list d) * (cdr (car d))) ; allocate a scheme string available in C. ; (define-external * (_make_string (size_t n)) scheme-object * * (make-string n)) (declare (foreign-declare #EOF #include sys/types.h #include string.h #include pwd.h EOF )) (define (getpwent) * ; append! each pwent record to our record list. * ; * (define-external * * (_getpwent_cb (scheme-object clist) * * * * * * * * * (scheme-object user) * * * * * * * * * (scheme-object passwd) * * * * * * * * * (scheme-object uid) * * * * * * * * * (scheme-object gid) * * * * * * * * * (scheme-object home) * * * * * * * * * (scheme-object shell)) void
Re: [Chicken-users] which RxRS?
Are there more appropriate mailing lists you could have this discussion on? Would you like some help with Chicken Scheme? -a On Tue, Dec 10, 2013 at 07:08:19PM -0500, Giorgio Flaverli wrote: @John Cowan; An Olin Shivers-style rant (the Jack'n'Zac one that opens the SCSH manual) would be extremely tempting given your lack of ability to comprehend the immense harm that your position brought to the unique value proposition of Scheme. I've noticed there is little hope arguing with people like you. Everytime you introduce a new standard, especially one that is backwards-incompatible, you split the codebase. Some people will write R6RS code that is incompatible with R5RS and R7RS implementations. Some people will write R7RS-large code that is incompatible with R6RS (and R7RS-small). Now we have R6RS which is even FORWARD-incompatible, and the 2 R7RS's which are SIDEWAYS incompatible, and you can't see a problem with this. This is bad for people who target multiple implementations. Nobody wants to write 5 versions of code because Chicken, Guile, Racket etc each decided to target a different standard, or haven't upgraded to the latest madness from the ADHD-impaired standardizers *just yet*. It's also bad for people who target a single implementation, because your code that runs today might no longer run a few years later as the implementation moves on, or the R(x-1)RS support in the implementation starts receiving less support etc. 2007 was a particularly bad year to split a community and waste efforts, as Scheme still had a good chance to be adopted for modern stuff (web frameworks, map reduce maybe). Another problem: anything other than a small standard makes it hard to write Scheme interpreters for everything. This was the amazing thing about Scheme. Want to drive your embedded system? Go ahead and embed a tiny scheme interpreter. Want to drive JVM code? Use KAWA or Sisc. Want to drive an Ocaml program? Embed OCS. R7RS-small might be good, but when lots people write R7RS-large code, and some write R6RS, a lot of code will be useless to minimalistic implementations. Finally, it's sad that this whole disaster was fostered upon the community un-necessarily. There was absolutely nothing wrong with extending Scheme via the SRFI process, particularly on the library side. In fact it was an amazingly effective way to assemble a small, interested community and develop a facility in an organized and controlled manner (as opposed to having a large electorate of non-experts trample over everything and argue over bike-shed issues over tens of messages, like a bunch of 'tards). The fact that most SRFI's had reference implementations **in scheme** made it extremely easy to add such facilities to a minimalistic interpreter. In the meanwhile a big implementation could write a C implementation of the SRFI. Programs would simply use (require-extension (srfi NN)) and not have to care about such details. Some SRFI's require interpreter support, of course, and users can pressure implementors to add SRFI NN support if it's important to them. So I don't think my language was excessively harsh. You really have no idea what you're talking about advocating multiple incompatible standards and huge incomprehensible standards instead of the concise gems that R5RS and R4RS were. With people like you on the loose a language can be destroyed (and probably was destroyed, as it's hard to compete with Python nowadays for any language; back in 2007 there was still a a chance to focus on software, not on misguided standards). -Original Message- From: John Cowan co...@mercury.ccil.org To: Giorgio Flaverli flave...@aol.com Cc: chicken-users chicken-users@nongnu.org Sent: Tue, Dec 10, 2013 7:43 pm Subject: Re: [Chicken-users] which RxRS? Giorgio Flaverli scripsit: I've gradually lost touch with Scheme after the R6RS debacle. It was a sad day to witness the victory of the pushers of complexity, helped along by a large number of well-meaning morons who should never have been allowed in the electorate given that they never even came close to implementing a meta-circular. I wonder how much more successful Scheme could have been without this disaster and without the harmful actions of those individuals who caused it. This is excessively harsh and downright insulting language. R7RS-small is, I believe, a substantial improvement over R5RS, but it could not have been achieved so easily and completely without R6RS first paving the way. R6RS provided a model of what standards can aim for as well as what they should not aim for. For example, the R7RS-small committee adopted the R6RS exception-handling system unchanged, but rejected the R6RS condition system
[Chicken-users] #invalid forwarded object using FFI callback
Greetings,
I'm encountering the following error message inside a callback using
Chicken's FFI interface:
Error: (cdr) bad argument type: #invalid forwarded object
Call history:
pwent.scm:100: loop
pwent.scm:56: ##sys#gc
pwent.scm:56: g42
pwent.scm:24: make-string
pwent.scm:24: make-string
pwent.scm:24: make-string
pwent.scm:24: make-string
pwent.scm:50: clist-append!
pwent.scm:100: loop
pwent.scm:56: ##sys#gc
pwent.scm:56: g42
pwent.scm:24: make-string
pwent.scm:24: make-string
pwent.scm:24: make-string
pwent.scm:24: make-string
pwent.scm:50: clist-append! --
What seems to be happening is that I'm running out of (stack?) memory
while inside/around a C thunk. I cannot seem to avoid this message by
modifying the nursery, either from csc -nursery or from -:s.
I have only a topical grasp of Chicken's FFI, so I suspect I'm simply
doing something ill-advised, though I would appreciate advice on how
to approach my problem:
I'm trying to read /etc/passwd using getpwent(3) and store each
record returned in a scheme list. (My particular /etc/passwd file
contains 100 elements, the above error happens near the end of the
call.) I'm marshalling records using two callbacks: one to create the
memory for string data, and one to append each record to the list.
May I have feedback on the pattern I'm using here to marshall data?
And a suggestion on how to avoid invalid forward objects while
reading large but disjoint data from C? I'm at a loss as to why
exactly I'm getting the above message, and it well could be incorrect
code on my part. Do my multiple calls to _make_string from C,
below, cause the GC to loose track of my string pointers? Something
else?
++ csc -o pwent pwent.scm ./pwent
(use extras)
; a circular list (where we track the
; head and tail) with a dummy head.
;
(define (make-clist)
(let ((head (list #f)))
(cons head head)))
; O(1) list append.
;
(define (clist-append! d v)
(let ((l (list v)))
(set-cdr! (cdr d) l)
(set-cdr! d l)))
; return proper list
;
(define (clist-list d)
(cdr (car d)))
; allocate a scheme string available in C.
;
(define-external
(_make_string (size_t n)) scheme-object
(make-string n))
(declare (foreign-declare #EOF
#include sys/types.h
#include string.h
#include pwd.h
EOF
))
(define (getpwent)
; append! each pwent record to our record list.
;
(define-external
(_getpwent_cb (scheme-object clist)
(scheme-object user)
(scheme-object passwd)
(scheme-object uid)
(scheme-object gid)
(scheme-object home)
(scheme-object shell)) void
(let ((pwent `((user . ,user)
(passwd . ,passwd)
(uid. ,uid)
(gid. ,gid)
(home . ,home)
(shell . ,shell
(clist-append! clist pwent)))
; retrieve the next pwent record and marshall it
; in to scheme.
;
(define _getpwent
(foreign-safe-lambda* bool ((scheme-object clist)) #EOF
struct passwd *pw;
C_word shell, dir, passwd, name;
size_t n;
pw = getpwent();
if(!pw) {
endpwent();
C_return(0);
}
n = strlen(pw-pw_name);
name = _make_string(n);
C_memcpy(C_c_string(name), pw-pw_name, n);
n = strlen(pw-pw_passwd);
passwd = _make_string(n);
C_memcpy(C_c_string(passwd), pw-pw_passwd, n);
n = strlen(pw-pw_dir);
dir = _make_string(n);
C_memcpy(C_c_string(dir), pw-pw_dir, n);
n = strlen(pw-pw_shell);
shell = _make_string(n);
C_memcpy(C_c_string(shell), pw-pw_shell, n);
_getpwent_cb(clist,
name,
passwd,
C_fix(pw-pw_uid),
C_fix(pw-pw_gid),
dir,
shell);
C_return(1);
EOF
))
; loop ever every entry in pwent and append
; it to our list.
;
(let loop ((clist (make-clist)))
(if (_getpwent clist)
(loop clist)
(clist-list clist
(pretty-print (getpwent))
--
Thank you,
-a
$ csc -version
(c) 2008-2013, The Chicken Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
openbsd-unix-gnu-x86 [ manyargs dload ptables ]
compiled 2013-10-03 on aeryn.xorinia.dim (Darwin)
--
my personal website: http://c0redump.org/
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] #invalid forwarded object using FFI callback
I wish I could take that advice, but getpwent_r is not available on OpenBSD. I do take care to call it sequentially, and the call is not being made from, say, multiple Scheme threads. Invocation of each loop in the (let loop ...) would have to be reordered by the compiler (I don't believe that is permitted, but would result in out-of-order records at worst, no?) or the runtime would have to make a call to getpwent while I'm doing my loop, and I find no reference to getpwent in Chicken's source code. I'd like to use a pattern like this in multiple places: anywhere I construct a record from C and want to pass it to Scheme, not just reading the /etc/passwd file. I could rewrite this to read records from an arbitrary file and suspect I'd still be getting this error. Thank you, -a On Sun, Dec 08, 2013 at 12:21:24PM -0500, John Cowan wrote: .alyn.post. scripsit: I'm trying to read /etc/passwd using getpwent(3) and store each record returned in a scheme list. The very first thing I would try is switching to getpwent_r(), because the fact that getpwent() uses a static buffer internally may well be confusing Chicken. -- John Cowan co...@ccil.org http://www.ccil.org/~cowan Raffiniert ist der Herrgott, aber boshaft ist er nicht. --Albert Einstein ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] 'f_125' undeclared with (declare (block))
I'm getting an error message when I use |(declare (block))|.
Using the same code in my previous email about invalid forwarded
object (repeated here), I declare it as an egg like so (the only
change is wrapping it around a module):
++ csc -s -j pwent pwent.so pwent-egg.scm
(module pwent
(getpwent)
(import scheme)
(import chicken)
(import foreign)
(declare (block))
; a circular list (where we track the
; head and tail) with a dummy head.
;
(define (make-clist)
(let ((head (list #f)))
(cons head head)))
; O(1) list append.
;
(define (clist-append! d v)
(let ((l (list v)))
(set-cdr! (cdr d) l)
(set-cdr! d l)))
; return proper list
;
(define (clist-list d)
(cdr (car d)))
; allocate a scheme string available in C.
;
(define-external
(_make_string (size_t n)) scheme-object
(make-string n))
(declare (foreign-declare #EOF
#include sys/types.h
#include string.h
#include pwd.h
EOF
))
(define (getpwent)
; append! each pwent record to our record list.
;
(define-external
(_getpwent_cb (scheme-object clist)
(scheme-object user)
(scheme-object passwd)
(scheme-object uid)
(scheme-object gid)
(scheme-object home)
(scheme-object shell)) void
(let ((pwent `((user . ,user)
(passwd . ,passwd)
(uid. ,uid)
(gid. ,gid)
(home . ,home)
(shell . ,shell
(clist-append! clist pwent)))
; retrieve the next pwent record and marshall it
; in to scheme.
;
(define _getpwent
(foreign-safe-lambda* bool ((scheme-object clist)) #EOF
struct passwd *pw;
C_word shell, dir, passwd, name;
size_t n;
pw = getpwent();
if(!pw) {
endpwent();
C_return(0);
}
n = strlen(pw-pw_name);
name = _make_string(n);
C_memcpy(C_c_string(name), pw-pw_name, n);
n = strlen(pw-pw_passwd);
passwd = _make_string(n);
C_memcpy(C_c_string(passwd), pw-pw_passwd, n);
n = strlen(pw-pw_dir);
dir = _make_string(n);
C_memcpy(C_c_string(dir), pw-pw_dir, n);
n = strlen(pw-pw_shell);
shell = _make_string(n);
C_memcpy(C_c_string(shell), pw-pw_shell, n);
_getpwent_cb(clist,
name,
passwd,
C_fix(pw-pw_uid),
C_fix(pw-pw_gid),
dir,
shell);
C_return(1);
EOF
))
; loop ever every entry in pwent and append
; it to our list.
;
(let loop ((clist (make-clist)))
(if (_getpwent clist)
(loop clist)
(clist-list clist)
--
With that |(declare (block))|, I get the following error message:
pwent.c: In function '_getpwent_cb':
pwent.c:107: error: 'f_125' undeclared (first use in this function)
pwent.c:107: error: (Each undeclared identifier is reported only once
pwent.c:107: error: for each function it appears in.)
Error: shell command terminated with non-zero exit status 256: gcc pwent.c -o
pwent.o -c -fno-strict-aliasing -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -Os
-fomit-frame-pointer -fPIC -DPIC -DC_SHARED -I/usr/X11R6/include
-I/usr/local/include
Removing |(declare (block))| allows compilation as normal.
Usefully, the egg version of this code does not exhibit the
invalid forward object error and completes successfully:
$ csi -n
#;1 (use pwent)
; loading ./pwent.import.scm ...
; loading /usr/local/lib/chicken/6/chicken.import.scm ...
; loading /usr/local/lib/chicken/6/foreign.import.scm ...
; loading ./pwent.so ...
#;2 (getpwent)
(((user . root) ...))
While it's certainly a blessing that my above code works when
compiled as an egg (though why it does so is a mystery to me),
what's going on with |(declare (block))| here? I don't understand
the documentation on this declare option to know whether I'm doing
something wrong or whether this code cannot be compiled with that
declaration.
Thank you,
-a
$ csc -V
(c) 2008-2013, The Chicken Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
openbsd-unix-gnu-x86 [ manyargs dload ptables ]
compiled 2013-10-03 on aeryn.xorinia.dim (Darwin)
--
my personal website: http://c0redump.org/
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] foreign-lambda declaration for char**?
On Mon, Dec 09, 2013 at 08:41:59AM +1300, Evan Hanson wrote: Hi Alyn, On 09/12/13 06:29, .alyn.post. wrote: What is the magic phrase to tell foreign-lambda a parameter is a char**? `(c-pointer c-string)` or `(c-pointer nonnull-c-string)` should do it. Cheers, Evan Bless you Evan, that worked. It's even obvious. Regards, -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] UTF-8 support in Chicken core [Was: [Q] uri-common has problem with UTF-8 uri.]
I'll throw in my two bits here. I'm not personally decided whether utf-8 in core would be an improvement. I don't have enough background or knowledge of the internals to contribute to that decision. I can offer this, however: I have found that I have to use utf-8 support in every project I've written in Chicken. I do so, and have only had a problem when the utf-8 egg did not map a procedure from core properly. I'm getting by just fine with the current state of affairs, and I do have a certain nostalgic love of ASCII. If I *could* get away with only having ASCII, I would. This has not been true in practice. My experience with numbers is slightly different, where I do find I need to do word-level calculation where I depend on the underlying machine implementation of character- and pointer-sized integers. I use the fx versions of these functions when I do rely on this, but I mainly have found I must intentionally subvert the numeric tower to get a specific behavior. This has never been true when I've dealt with characters. FWIW, -Alan On Sun, Jan 27, 2013 at 10:43:41AM +0900, Ivan Raikov wrote: Hi Alex, *** Yes, I would have thought that more people would be interested in having UTF-8 support in core Chicken (or at least wide-char compatible srfi-14). I have changed the title of this thread to reflect the subject more accurately :-) * Personally, I think that adding UTF-8* in core is much better than the hacks I had to do in mbox, and is a no brainer considering the benchmark results you have below.* But I am sure that opinions vary on this subject... ** Can you post your bounds-check patches to srfi-14 on the mailing list, and/or create a ticket for it? Hopefully there will be more responses this time. *** Ivan On Sat, Jan 26, 2013 at 1:42 PM, Alex Shinn [1]alexsh...@gmail.com wrote: On Wed, Jan 23, 2013 at 5:09 PM, Alex Shinn [2]alexsh...@gmail.com wrote: On Wed, Jan 23, 2013 at 3:45 PM, Ivan Raikov [3]ivan.g.rai...@gmail.com wrote: Yes, I ran into this when I was adding UTF-8 support to mbox... If you were to add wide char support in srfi-14, is there a way to quantify the performance penalty? To add the bounds check so it doesn't error? *Practically nothing. To branch to a separate path for a wide-char table if the bounds check fails? *Same cost if the input is ASCII. For efficient handling in the case of Unicode input... how small/fast do you want it? I've never met such stony silence in response to an offer to do work... I ran the following simple char-set-contains? benchmark with a few variations: * (time * *(do ((i 0 (+ i 1))) * * * *((= i 1)) * * * *(do ((j 0 (+ j 1))) * * * * * *((= j 256)) * * * * *(char-set-contains? char-set:letter (integer-char j) This is what most people are concerned about for speed, as the boolean and construction operations are less common. The results: ;; reference implementation ;; 0.312s CPU time, 1/2059 GCs (major/minor) ;; fixed reference implementation (no error but no support for non-latin-1) ;; 0.257s CPU time, 1/1706 GCs (major/minor) ;; utf8-srfi-14 with full Unicode char-set:letter ;; 0.243s CPU time, 0/1526 GCs (major/minor) ;; utf8-srfi-14 with ASCII-only char-set:letter ;; 0.242s CPU time, 0/1526 GCs (major/minor) I was able to add the check and make the reference implementation faster because I fixed the common case - it was optimized for checking for 0 instead of 1. Even with the enormous and complex definition of a Unicode letter, utf8-srfi-14 is faster than srfi-14. As for what we want in Chicken, the answer depends on what you're optimizing for. *utf8-srfi-14 will always win for space, and generally for speed as well. If the biggest concern is code-size, then you might want to borrow the char-set definition from irregex and use that as a fallback for non-latin-1 chars in the srfi-14 reference impl. *This would have the same perf as srfi-14 for latin-1, yet still support full Unicode and not increase the size of the Chicken distribution. --* Alex References Visible links 1. mailto:alexsh...@gmail.com 2. mailto:alexsh...@gmail.com 3. mailto:ivan.g.rai...@gmail.com ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Q] uri-common has problem with UTF-8 uri.
On Mon, Jan 14, 2013 at 09:18:52AM +0100, Peter Bex wrote: On Mon, Jan 14, 2013 at 02:42:40PM +0900, Alex Shinn wrote: On Mon, Jan 14, 2013 at 1:36 PM, Sungjin Chun chu...@gmail.com wrote: As far as I know, revised RFC permits UTF-8 characters in the URL without encoding. Am I wrong here? Thus you can't use raw non-ASCII bytes in a URI - they must be encoded, and interpretation is up to the origin (and is overwhelmingly utf8 these days). Wow, thanks for doing the research! I was a bit lazy in not doing that in the first place. It's not the first time though that people think something's wrong in uri-generic whereas on closer reading of the RFC it turns out to be correct :) There is a very common misconception held by many programmers that you only need to encode an URI whenever the link doesn't work in a browser. However, this is a source of vulnerabilities and subtle bugs. A lot of browsers simply try to cope with broken HTML and even broken URI strings, apparently. It would of course be possible for any tool or webserver to accept URIs with non-ASCII bytes, but I don't know of any browsers which would _send_ such a request, because in general it would be rejected. We've decided to make uri-generic follow the RFC as closely as possible. To our knowledge, this library is the most RFC-compliant URI library available for *any* language. I worked on an FTP program years ago that operated in an ecosystem where lots of technically incorrect URLs were pasted around, and we got a bug report that they weren't working in our client. To 'fix' it, we had to remove support for correct URLs to handle this more common use case. I regret having to do that to this day, so thank you very much for RFC-compliant parsing. -Alan -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] MacOSX setup-helper install error
I'm running Mac OS X 10.8.2 and have just installed the latest XCode+XCode command-line tools. I've built chicken 4.8.0, and am trying to install the setup-helper egg. I get the following error. I'm not familiar with install_name_tool, though I gather it's a piece of XCode and/or some Mac OS X-specific piece of the toolchain. Are any of you familiar enough with this platform to shed some light on what is going on? -Alan installing setup-helper:1.5.3 ... changing current directory to /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csi -bnq -setup-mode -e (require-library setup-api) -e (import setup-api) -e (setup-error-handling) -e (extension-name-and-version '(\setup-helper\ \1.5.3\)) /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper/setup-helper.setup /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc -feature compiling-extension -setup-mode-s -O3 -d1 setup-helper-mod.scm -j setup-helper-mod install_name_tool: changing install names or rpaths can't be redone for: setup-helper-mod.so (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names) Error: shell command terminated with non-zero exit status 256: install_name_tool -change libchicken.dylib /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/lib/libchicken.dylib setup-helper-mod.so Error: shell command failed with nonzero exit status 256: /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc -feature compiling-extension -setup-mode-s -O3 -d1 setup-helper-mod.scm -j setup-helper-mod Error: shell command terminated with nonzero exit code 17920 -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MacOSX setup-helper install error
Thank you Jim, I went ahead with #3. Neither #1 nor #2 worked for me, but I wasn't as thorough as I might have been testing them. -Alan On Thu, Dec 27, 2012 at 01:13:20PM -0600, Jim Ursetto wrote: Normally indicates the install path is too long; if so it is surprising the build and install of Chicken itself even worked. Try one of these fixes: 1) Recompile and reinstall chicken after changing this line in Makefile.macosx: LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad -Wl,128 to LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad_max_install_names 2) Recompile chicken after increasing the value 128 in the same line instead, e.g.: LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad -Wl,4000 3) Install Chicken into a shorter path Hopefully one of these works. On Dec 27, 2012, at 12:15 PM, .alyn.post. wrote: I'm running Mac OS X 10.8.2 and have just installed the latest XCode+XCode command-line tools. I've built chicken 4.8.0, and am trying to install the setup-helper egg. I get the following error. I'm not familiar with install_name_tool, though I gather it's a piece of XCode and/or some Mac OS X-specific piece of the toolchain. Are any of you familiar enough with this platform to shed some light on what is going on? -Alan installing setup-helper:1.5.3 ... changing current directory to /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csi -bnq -setup-mode -e (require-library setup-api) -e (import setup-api) -e (setup-error-handling) -e (extension-name-and-version '(\setup-helper\ \1.5.3\)) /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper/setup-helper.setup /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc -feature compiling-extension -setup-mode-s -O3 -d1 setup-helper-mod.scm -j setup-helper-mod install_name_tool: changing install names or rpaths can't be redone for: setup-helper-mod.so (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names) Error: shell command terminated with non-zero exit status 256: install_name_tool -change libchicken.dylib /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/lib/libchicken.dylib setup-helper-mod.so Error: shell command failed with nonzero exit status 256: /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc -feature compiling-extension -setup-mode-s -O3 -d1 setup-helper-mod.scm -j setup-helper-mod Error: shell command terminated with nonzero exit code 17920 -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] JQuery in Chickadee
On Sun, Dec 09, 2012 at 11:24:54AM -0700, Matt Gushee wrote: Last night I got a shock when I tried to use Chickadee (as I often do these days). The Contents section was at the bottom of the page, expanded, instead of collapsed at the top; the TOC section wouldn't expand, and incremental search wasn't working. It was rather mystifing, since I knew I hadn't installed or uninstalled any eggs for at least a couple of weeks, nor altered my Chicken configuration in any way. Eventually I got around to examine the Chickadee config file, where i discovered that Chickadee uses JQuery, accessed by default over the internet. Then I remembered that I had cleared my browser cache a day or two before ... and since I was working offline, that must be the problem. And indeed, I happened to have a copy of the JQuery library on my system, so I copied it into the Chickadee tree and edited the configuration to point to the local copy. Problem solved! But I wonder if it wouldn't make more sense to simply bundle JQuery with Chickadee in the first place--after all, I would think that offline usage is one of the major reasons for having Chickadee in the first place, and people do need to clear their caches now and then for a variety of reasons. I can't see any non-trivial disadvantages to bundling the library, unless there is a licensing conflict. What says the community? I'm not currently using this feature, but I work offline a fair bit, so the idea gets a +1 from me. -Alan -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A mfeta-observation
On Sat, Nov 24, 2012 at 03:03:06PM -0700, Matt Gushee wrote: Is it just me, or is this community undergoing a major growth spurt? Seems like there are a lot of new people with cool projects coming onto this list lately. Next: Chicken Scheme takes over the world? Anyway, it's good to see. -- Matt Gushee Interesting. We did recently make it easier to get eggs published, with the creation of the distributed egg repository./speculation -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] How can I check a new build of chicken?
On Mon, Nov 19, 2012 at 09:19:33PM +0100, Felix wrote: From: John Long codeb...@inbox.lv Subject: Re: [Chicken-users] How can I check a new build of chicken? Date: Sun, 18 Nov 2012 14:36:43 + Warning: reference to possibly unbound identifier `values' ../libchicken.so.6.0: warning: strcpy() is almost always misused, please use strlcpy() ../libchicken.so.6.0: warning: strcat() is almost always misused, please use strlcat() ../libchicken.so.6.0: warning: sprintf() is often misused, please use snprintf() Boy, these warnings are annoying. cheers, felix I suspect the OpenBSD team would say Well, stop using these routines. Because if you're going to put such a message in your linker you're also going to be annoying in person. I'm not recompiling my linker enough to make it worth it, but the patch to remove this check is ~5 lines. It's a pitty there isn't an environmental variable or something to shut them up. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Why doesnot (+ 1/2 1/3) equal to 5/6 ?
On Wed, Nov 07, 2012 at 11:57:33PM -, z_axis wrote: (+ (+ 1/2 1/3) Warning: cannot represent exact fraction - coerced to flonum: 1/2 Warning: cannot represent exact fraction - coerced to flonum: 1/3 0.8331/2 1/3) In racket, it is 5/6. And as i know it is 5/6 for any lisp implementation. Sincerely! I suspect in Racket your above code is a syntax error. ;-) More seriously, try this: (use numbers) (+ (+ 1/2 1/3)) That gives you the answer you expect. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Why doesnot (+ 1/2 1/3) equal to 5/6 ?
On Thu, Nov 08, 2012 at 01:30:44AM -, z_axis wrote: Welcome to Racket v5.3. - (+ 1/2 1/3) 5/6 If you look carefully at your below message, you have unbalanced parenthesis, which I was joking about when I spoke of a syntax error. The error did not affect the clarity of what you were asking. Consider my comment a too-subtle like a joke only not as funny. missive. BTW, what do the following message mean ? (use numbers) ; loading /usr/local/lib/chicken/6/numbers.import.so ... Note: re-importing already imported identifier: + Note: re-importing already imported identifier: - Note: re-importing already imported identifier: * Note: re-importing already imported identifier: / .. Chicken Scheme has a small base system that contains a minimal feature set. Certain eggs (specifically numbers and utf8) will amend this basic feature set with more powerful versions of existing routine. These messages are describing that phenomenon: the routine '+' exists in the core Chicken Scheme system, but does not, as you have observed, implement the full numeric tower. The numbers egg replaces the core '+' routine with it's own, as it does everything the core '+' does and substantially more. -Alan Best Regards! 在 Thu, 08 Nov 2012 00:17:23 -，.alyn.post. alyn.p...@lodockikumazvati.org 写道: On Wed, Nov 07, 2012 at 11:57:33PM -, z_axis wrote: (+ (+ 1/2 1/3) Warning: cannot represent exact fraction - coerced to flonum: 1/2 Warning: cannot represent exact fraction - coerced to flonum: 1/3 0.8331/2 1/3) In racket, it is 5/6. And as i know it is 5/6 for any lisp implementation. Sincerely! I suspect in Racket your above code is a syntax error. ;-) More seriously, try this: (use numbers) (+ (+ 1/2 1/3)) That gives you the answer you expect. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] zmq, problems with using several sockets, closing sockets
On Tue, Nov 06, 2012 at 06:48:33AM -0700, matt welland wrote: I guess this could be considered a bug: The finalizer unconditionally closes the socket which seems to lead to this error when it was explicitly closed before. Skimming the API reference I don't see a way to check whether a socket is already closed. Do you know of any? Or do you have a better idea how to handle this situation? I also could not find a way to check that a socket was already closed. As a last resort perhaps add a flag to disable finalizers? Can you call getsockopt with the SO_TYPE flag and check for EBADF and ENOTSOCK? That is essentially why the finalizer is 'failing' anyway... -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] string-join not in utf8-srfi-13
Thank you sir, I have installed the new release of the utf8 egg and things are working here. -Alan On Sat, Nov 03, 2012 at 01:43:27PM +0900, Alex Shinn wrote: Added. On Fri, Nov 2, 2012 at 11:52 PM, .alyn.post. alyn.p...@lodockikumazvati.org wrote: I'm trying to use string-join in my egg git-hooks-mediawiki[1]. This egg imports utf8-srfi-13, and I am getting an error message about this routine: Warning: reference to possibly unbound identifier `string-join' in: Warning:parse-error Warning:suggesting: `(import srfi-13)' I believe that importing utf8-srfi-13 should suffice to get this routine, and that the utf8 egg should but doesn't import this routine. Is that correct? is string-join the only routine from srfi-13 not imported by utf8-srfi-13? I appreciate your guidance here, -Alan 1: https://github.com/alanpost/git-hooks-mediawiki -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] string-join not in utf8-srfi-13
I'm trying to use string-join in my egg git-hooks-mediawiki[1]. This egg imports utf8-srfi-13, and I am getting an error message about this routine: Warning: reference to possibly unbound identifier `string-join' in: Warning:parse-error Warning:suggesting: `(import srfi-13)' I believe that importing utf8-srfi-13 should suffice to get this routine, and that the utf8 egg should but doesn't import this routine. Is that correct? is string-join the only routine from srfi-13 not imported by utf8-srfi-13? I appreciate your guidance here, -Alan 1: https://github.com/alanpost/git-hooks-mediawiki -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] utf8 open tickets
I have two open tickets against the utf8 egg: https://bugs.call-cc.org/ticket/423 https://bugs.call-cc.org/ticket/480 Both of them are simple fixes, one of them is causing several packages not to compile against the experimental branch, which Christian has just begun nightly builds for: http://pestilenz.org/~ckeen/salmonella-report/ Alex, will you fix these tickets? would you like help with them? What do you need to get these tickets fixed? -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] sqlite3 egg still failing in experimental branch
Thomas, The sqlite3 is still failing to compile in the experimental branch: http://pestilenz.org/~ckeen/salmonella-report/2011-01-14/sqlite3.html Will you apply the patches I sent you to the sqlite3 egg? Since sqlite3 won't compile, I can't test my own packages against the experimental branch. I believe a few other packages won't compile as well. After Felix e-mailed me the reference for the fixnum arthimetic procedures, I was able to modify genturfa'i to use those procedures rather than declaring fixnum. Would you like a new patch that uses this same approach in sqlite3? Disabling the fixnum declare but replacing you maths operations with fixnum versions? What do you need to get the sqlite3 egg updated to compile against the experimental branch? -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] srfi-19, srfi-29 not compiling in experimental branch
Kon, Would you update srfi-19 and srfi-29 to compile against the experimental branch in chicken?: http://bugs.call-cc.org/ticket/481 http://bugs.call-cc.org/ticket/482 The patch is very simple, getenv has been deprecated in favor of get-environment-variable. These are the only two srfi-* eggs not compiling against experimental, I'd love to see all of the baseline/infrastructure eggs working against this branch. Thank you! -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
