[Chicken-users] letrec expansion
Hi, I've noticed that letrec seems to have a problematic expansion. I'm not sure if this has been discussed before (I couldn't find any matches): csi> (macroexpand '(letrec ((x 1)) x)) (let ((g1312 (##core#undefined))) (begin (##core#set! g1312 (quote 1)) g1312)) This definition doesn't use temporaries -- as, for example, in the standard R5RS syntax-rules definition of letrec, http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.3 Without using temporaries, some call/cc + letrec combinations don't work: (letrec ((x (call/cc list)) (y (call/cc list))) (if (procedure? x) (x (pair? y))) (if (procedure? y) (y (pair? x))) (let ((xk (car x)) (yk (car y))) (and (call/cc xk) (call/cc yk) (call/cc xk csi produces #f, while SISC, Scheme48 and guile correctly output #t. Thanks go to Al Petrofsky for describing the problem. Dan Muresan http://alumnus.caltech.edu/~muresan/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Spiffy
Hi, I have had, at last, the pleasure to play with spiffy to creaet a simple web front-end. As I said, it has been a pleasure, mostly, but there are some warts: * generate-directory-listing: the computation of the parent directory is broken: (string-intersperse (butlast foo)) intersperses blanks, not slashes. Add a "/" final argument. * there's some horrendous HTML markup (things like "" -- that's right, an unquoted attribute -- and "http://alumnus.caltech.edu/~muresan/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Spiffy
Oh yeah, now I remember: handlers (defined with http:add-resource or the spiffy helper macro) don't receive POST attributes in the the second argument (the args in (lambda (req args)). The built-in http:content-parser 'application/x-www-form-urlencoded parses POSTs just fine. But read-request puts the parsed pairs in the request body (which is supposed to be a string, not an a-list in any case), not in the arguments arguments. It looks like somewhere along the road internal conventions have changed... -- Dan Muresan http://alumnus.caltech.edu/~muresan/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Spiffy
More remarks: * even with debug: #f, spiffy still logs 404's to stdout (or stderror -- not sure). This wouldn't be too bad, but for some other reason, it prevents the process from running in the background: whenever an output action is attempted, the shell tells me the job has been stopped. Possibly chicken tries to access stdin when writing? * sxml->html breaks naming conventions and makes it hard to use the macro define-http-resource. sxml->html is not a function, but a procedure with side effects (it displays the result). define-http-resource expects a value to be returned. Bonus: a hard-to-debug situation where sxml->html writes its output (plus some incomplete headers) and returns #, which define-http-resource dutifully appends to the stream (with the rest of the headers). -- Dan Muresan http://alumnus.caltech.edu/~muresan/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: spiffy patch attempt (was Re: [Chicken-users] Minor issue with spiffy's sxml->html)
On 12/31/06, John Cowan <[EMAIL PROTECTED]> wrote: A suggestion for all this introduction of newlines: instead of adding newlines after end-tags and worrying about which ones can and cannot have a problem with it, why not add a newline *within* the end-tag, thus: ""? That's a general solution and simplifies the problem greatly. While that's valid HTML, it will easily confuse some non-compliant HTML parsers (I tried that and had problems in at least one piece of proprietary software). Personally, I'd vote for no newlines at all. Humans can use 'tidy -indent' to reformat code. Dan Muresan http://alumnus.caltech.edu/~muresan/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] json egg bugs
Hi, two problems with the json egg: 1) Compiling json fails when packrat is not installed. packrat should be an egg dependency. 2) (require-extension json) fails unless srfi-1 is pre-loaded. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] json egg bugs
John Cowan wrote: Did you download the json egg and try to install it locally? The dependency information exists only on the web site, so local installs will not retrieve it and do not know what other eggs to install. (IMHO this is Evil and Wrong; each egg should contain the names of the eggs it depends on. Yes, I downloaded the egg locally with wget. OK, that solves the first point... Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] pthread interaction
Hi all, is it safe to call (from Chicken) a C function that spawns off a pthread before returning? Are there any restrictions on what that thread can do, e.g. w.r.t. malloc() ? Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] busy-wait in tcp-connect
Hi, I've noticed that calling tcp-connect when a single Chicken thread exists maxes out the CPU. Try (tcp-connect "1.2.3.4" 80). In tcp.scm, I see that a thread-block-for-i/o! was commented out: ;; line 543 (let loop () (let ((f (##net#select-write s))) (when (eq? f -1) (fail)) (unless (eq? f 1) ;(##sys#thread-block-for-i/o! ##sys#current-thread s #t) (yield) (loop) ) ) ) I assume that thread-block-for-i/o somehow failed to wake-up in certain circumstances, so uncommenting that statement would not be workable? See also http://www.mail-archive.com/chicken-users@nongnu.org/msg03122.html That message suggests that when connecting to a filtered port (or, in my case, a non-existent host) not only will the CPU max out, but the call will never time out. This is not good. Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] srfi-19 doesn't work with stable Chicken release
Hi all, the latest stable release (Chicken 2.6) doesn't work with the srfi-19 egg. Sorry if I missed any related messages (I don't think I did) but it sounds like a bad idea for an egg do depend on the unstable version of Chicken... Or maybe a new release is imminent? # chicken-setup srfi-19 The extension srfi-19 does not exist. Do you want to download it ? (yes/no/abort) [yes] downloading srfi-19.egg from (www.call-with-current-continuation.org eggs 80) gunzip -c ../srfi-19.egg | tar xf - Error: CHICKEN version 2.61 or higher is required -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-19 doesn't work with stable Chicken release
Chicken 2.6 has inconsistent meaning for timezone offset across
platforms. 2.61 fixed this.
Provided you are not using MacOS X or Windows you can get the current
version (2.6.9) which skips the requirement otherwise.
Well, I was in a rush, so I've wrapped strftime(). This might actually
be useful to others, so I'm posting it. I've used SWIG, but I'm sure
it's trivial using the Chicken FFI (which I don't know though):
#include
#include
#include
// See strftime(3) manpage for format string
char *system_time (const char *fmt) {
time_t t;
struct tm tm;
time (& t);
localtime_r (& t, & tm);
char buf [500];
size_t ret = strftime (buf, sizeof (buf), fmt, & tm);
if (ret == 0) return NULL;
else {
char *res = malloc (ret + 1);
memcpy (res, buf, ret + 1);
return res;
}
}
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] busy-wait in tcp-connect
While we're on the topic, I find Chicken's lightweight-threads and srfi-18 compatible streams incredibly useful. However, it's a pity that only unit tcp (and the (process) function) can create such streams. For example, it would be nice if one could create pipes with the same property; or, more generally, if any file descriptor could be wrapped in a srfi-18 compatible stream (or pair of streams). The code is already there, so this should be quite feasible. I *almost* understand how it works, but there seem to be some messy details... P.S. I have some other thoughts about binary streams and a possible stream API, but I'll make that a separate message. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] busy-wait in tcp-connect
While we're on the topic, I find Chicken's lightweight-threads and srfi-18 compatible streams incredibly useful. However, it's a pity that only unit tcp (and the (process) function) can create such streams. I assume you mean streams that block the current thread on I/O, yes? That shouldn't be a problem as long as you have an fd and can make it non-blocking. Yes, streams that block the current thread on I/O. Are you saying that I can already create such streams from an fd? How? Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] 32 bit integers?
Hi, I've just realized that "normal" Chicken integers are 31 bits wide: csi> (inexact->exact 1073741824) [ nasty error ] csi> (inexact->exact 1073741823) 1073741823 csi> (/ (log 1073741824) (log 2)) 30.0 Wider integers are promoted to flonums. This is somewhat undesirable when interfacing to C libraries. Is there a native-integer type (like in OCaml)? Since the SRFI-4 vectors have exact 8, 16 and 32-bit integer elements, it might make sense to have native integers too... Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] 32 bit integers?
Wider integers are promoted to flonums. Or to bignums with the numbers egg (full numeric tower). Right, that's why I specified "normal" numbers. Especially if you didn't expect it. (It is documented but a tutorial on foreign function interfacing would be nice.) Actually, I haven't found the 31-bit format documented anywhere (maybe I missed it). I thought that at least normal C int's would always fit in a fixnum. It was an unpleasant surprise to see an expression like (logior flags ...) fail, when "flags" was promoted to a flonum. If you use one of integer unsigned-integer integer32 unsigned-integer32 integer64 long unsigned-long as a foreign parameter/return type Chicken will automatically convert a flonum integer to/from the native type. Yes, but flonum's can't be used in some contexts: * bit ops * modulo-2^32 arithmetic (i.e. C-like 32-bit wraparound arithmetic) I don't see a way to hack these using flonums. Bignums would solve the problem but they're slow. Would the native integers be part of the numeric tower? If so this is a major piece of work. If disjoint from the number type then fairly straightforward to create but of limited utility. I'm not really sure what "disjoint" means here... They would be available without (require-extension numbers). There would be separate functions native+, native* etc. OCaml has native integers for this very reason. Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] 32 bit integers?
I don't see a way to hack these using flonums. Bignums would solve the problem but they're slow. You pays your money and you takes your choice. Yeah, thanks for the reminder :) One problem is that some "obvious" pitfalls are not documented prominently. That's confusing: it makes you think you're missing something (when in actuality you're hitting a genuine limitation that should have been acknowledged more explicitly). But enough "meta-talk". which use GMP, I found that the only reliable way to pass a bignum from one system to the other was as a string. That thought crossed my mind, but I was hoping never to have to do that:) -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] 32 bit integers?
The bitwise-* procedures & arithmetic-shift are supposed to work w/ fixnums & integer flonums. The magnitude of a flonum is converted to a C unsigned int (on 32 bit machines, u_int64_t otherwise), operated upon, then the result is returned as a fixnum or flonum, depending on the precision of the operation result. Hm, what's an "integer flonum"? A 32 bit signed-int converted to a float? Anyways, how is it supposed to work? csi> (require-extension (srfi 60)) csi> (bitwise-ior 4.0 1) Error: (vector-ref) bad argument type: 11.0 This is with chicken 2.6, before (req-ext numbers) The modulo-2^32 is a problem though. Yeah... You really have to keep it all in C; as soon as you go through Chicken, you lose precision. Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] 32 bit integers?
Ahh, you are using the SRFI-60 egg. I was referring to the procedures in the library unit. Correct. I always use SRFIs when an identifier is not R5RS. Either that, or I (cond-expand) the alternatives. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] stream API (was busy-wait in tcp-connect)
LOCATIONcalling procedure/context id NAMEname for the port (usually the process command pathname) FILENOopen file descriptor BUFFER-INFOeither a fixnum size or a string ON-CLOSEfileno was closed notification procedure MORE-PREDICATE boolean procedure indicating whether more input is available, usually not needed but the programmer may know something that the C 'read' procedure doesn't Interesting... Let me put forward the following proposal: 1. Binary streams, maybe wrapping fread / fwrite. 2. Two stream APIs (one for binary and one for char ports) The ideea would be that I'd be able to write, for example, my own application-level reliable transport protocol over UDP, and wrap it into Chicken Streams. The char output stream API could look like (##sys#make-output-stream write-char close) and the input one (##sys#make-input stream peek-char read-char close) This, of course, doesn't yet take into account threads and UTF8. What do you guys think? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: stream API (was busy-wait in tcp-connect)
See make-output/input-port, in the extras unit. Very nice, I missed it. So I guess if READ and PEEK yield instead of blocking, then that stream plays nicely with threads, just like tcp streams? Any thoughts on binary streams? Calling read-char repeatedly is probably not efficient; besides, read-char may not be the same as read-byte (if utf8 is loaded). -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: stream API (was busy-wait in tcp-connect)
Not sure what you mean. As opposed to text streams? Binary streams as in binary data, as opposed to text. Calling read-char repeatedly is probably not efficient; besides, read-char may not be the same as read-byte (if utf8 is loaded). Actually 'read-byte' uses the builtin 'read-char' when the utf8 egg is loaded. I was wrong about ##sys#custom-*-port not working w/ UTF8, at least in the broader sense. Excellent. 1. I can't find the documentation for read-byte. I didn't even realize that read-byte existed. What i meant was that read-char might read multiple bytes, when the programmer wanted to read a single byte of binary data. 2. You did not address the other point -- calling read-char repeatedly is probably not efficient. I think being able to read binary data efficiently is mandatory for a language that's supposed to be practical, no? Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] records in evicted objects
Evicted objects do not work with srfi-9 records for some reason: (define-record-type :pare (kons x y) pare? (x kar set-kar!) (y kdr)) (kar (object-evict (kons 1 2))) Error: bad argument type - not a structure of the required type Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] records in evicted objects
The zeroth "slot" of the record contains the symbol representing its type. When you evict the record, you also evict the symbol. The interned and uninterned symbols are not equal, hence the type-check failure when it is inspected. (equal? :pare (object-evict :pare)) => #f You could set the slot-value back to the non-evicted, interned symbol: Well, the Chicken manual warns against setting slots in evicted objects to non-evicted data, so I'm not gonna do it. I think the right thing to do would be to change the SRFI-9 implementation so that, for evicted objects, it skips the record type test. Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] JSON and unicode escapes
Hi, (json-read) doesn't support Unicode escapes: csi> (json-read ) csi> "\u201c" "u201c" I'd like to fix that. Parsing the escapes should be easy since Chicken's (read) actually seems to understand the escapes (even without the utf8 egg). I see from Trac that a number of people have worked on this egg, and that there's an official Tony G repository somewhere. Where is that repository? Does anyone know how to fix interpret-string-escape (i.e. can it return multiple chars, how to obtain the next token)? Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] unjoined thread memory consumption?
Hi, if a thread exits and is not joined, does it still occupy memory? I'd like to spawn many threads that exit quickly, and never worry about joining them. Are there any problems with this approach? Thanks, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] csc segfaults with certain recursive sources
$ cat x.scm (require 'y) (module x (fx) (define fx 10) ) $ cat y.scm (require 'x) (require-for-syntax 'x) (import x) (define fy 20) $ csc -R syntax-case -s x.scm $ csc -R syntax-case -s y.scm Error: (open-input-file) can not open file - Too many open files: "./x.so" Segmentation fault (core dumped) *** Shell command terminated with exit status 139: /opt/chicken/bin/chicken y.scm -output-file y.c -dynamic -feature chicken-compile-shared -quiet -require-extension syntax-case ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: [Chicken-bugs] #227: csc segfaults with certain recursive sources
I've submitted to Trac. Interesting... the ticket formatting got screwed up in Trac (it seems that single-newlines are treated as whitespace, while double newlines break paragraphs). Yet the automated e-mail that Trac sent has the correct newlines. Chicken Scheme wrote: #227: csc segfaults with certain recursive sources -+-- Reporter: Dan Muresan <[EMAIL PROTECTED]> |Type: defect Status: new |Priority: minor Milestone: | Component: compiler Version: 2.6 |Keywords: -+-- This is Chicken 2.6 on Linux built from tarball with automake. $ cat x.scm (require 'y) (module x (fx) (define fx 10) ) $ cat y.scm (require 'x) (require-for-syntax 'x) (import x) (define fy 20) $ csc -R syntax-case -s x.scm $ csc -R syntax-case -s y.scm Error: (open-input-file) can not open file - Too many open files: "./x.so" Segmentation fault (core dumped) *** Shell command terminated with exit status 139: /opt/chicken/bin/chicken y.scm -output-file y.c -dynamic -feature chicken-compile-shared -quiet -require-extension syntax-case If I try to compile x.scm first, $ cat x.scm Error: (open-input-file) can not open file - Too many open files: "./x.scm" (no segfault) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: [Chicken-bugs] #227: csc segfaults with certain recursive sources
Thanks for registering in Trac and submitting what you've already submitted. Working with the Trac process helps all of us immensely and improves Chicken. Firstly, thanks for replying publicly to a private message, Brandon. Secondly, I believe in using Trac; but your evangelism struck me as a tad overwhelming (and maybe a tad imposing). For your future reference, a lighter approach would probably work better with most reporters. Thirdly, I think that you should consider taking some conversations off-list when they're not necessarily of general interest. On that note, let's please not take this any further, I'm sure no one wants to read this. Please reply in private if you really feel the need to. -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] csc segfaults with certain recursive sources
Serves you quite right - a segfault is not sufficient for someone who does these perverted things. You should rightfully suffer for this... Um, I wasn't saying that this should work. The point was that a segfault usually uncovers a deeper problem, such as a buffer overflow that may or may not occur under other circumstances as well. But, if Felix is happy with a segfault, that's fine. Notice that reversing the compilation order does not produce a segfault. -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS Rant
Umm, I might see my 60th birthday before packaging is core Scheme. (I don't think there should be anything else, except "optional.") You forgot to mention your current age :) Well, 'require-extension' is an accepted SRFI. And Chicken does support 'require' (I use it in the bloom-filter egg, however it isn't PLT-Scheme compliant) & 'load' (I use it in the 'procedure-surface' egg). require-extension is very useful, even just as a cross-platform way of loading SRFIs. But you should read the SRFI-55 mail archive to see the incredible opposition it draws from some folks. Or try asking for require-extension on the PLT or Scheme 48 mailing lists. Anyway... Two glaring omissions related to (load): 1) (include ...) is not standardized 2) no one has thought of specifying what nested (load) or nested (include) should do. That is, what happens when you have x.scm dir/y.scm dir/z.scm where x.scm does (load "dir/y.scm"), and y.scm does (load "z.scm"). Does dir/y.scm load the correct dir/z.scm, or the non-existent z.scm? Same for (include), of course. R5RS does not standardize this, neither do most implementations specify what they do. In practice, most schemes use the absolute path convention, while SISC uses the relative path convention. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
BTW, has anyone gotten stalin to work lately? I ran my 512mb Athlon for the whole night and was not able to compile stalin 0.11 (gcc 4.1.2). Same here with a 768 MB box. The machine tries to compile stalin.c but mostly trashes the swap space (strangely, since it's just a -O2 compilation). I wonder how much memory is needed to avoid swapping. -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
This goes far beyond games on Windows. This is about people completely wasting their time on projects that, if they have no academic context, are completely worthless. I've gone bankrupt chasing nonsense. I have delusions of grandeur that I *might* save some young buck from his/her utter cluelessness in the face of industrial reality. Brandon, your penchant for getting involved in long, useless polemics is NOT a quality. Also, you may want to be more cautious when judging the difficulty level of various software platforms, especially when you haven't really tried using them. I think it's pretty well established that Stalin (and Gambit?) are faster than Chicken, but Chicken has a much better ecosystem (community, libraries etc). If you see people interested in Stalin, I'm pretty sure they know the deal they're getting. You're not adding value by trying to convince them otherwise; and they certainly won't appreciate your suggestion that you know better what's good for them. Let's stick to discussions that provide value to all participants. Keep in mind that when you feel like belaboring a random point to death, you can always reply in private. P.S. All this talk of Stalin has made me curious; is there a page documenting Stalin's limitations / standard adherence? If it's just the lack of syntax-rules support, that can be worked around with the help of Alexpander. Zdravstvuite, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] a file system using Chicken
Hi folks, I've released DuggFS, a file system based on Fuse and implemented in Chicken Scheme. http://www.omnigia.com/scheme/duggfs/ It lets you view Digg content as a filesystem: $ ls /tmp/duggfs config stories users $ cd /tmp/duggfs/stories/topics/programming/popular $ ls A_Computer_Science_Degree_Doesn_t_Hurt_Much Let_s_Build_a_Grid_Webdesign LifeHacker_How_to_build_a_Firefox_extension The_Google_Maps_Street_View_Team_Pic # ... $ cat A_Computer_Science_Degree_Doesn_t_Hurt_Much/diggs 1286 You may or may not find this useful (or amusing), but there's some good code in there in case you ever want to implement your own file system in Scheme. I find it pretty cool that using Chicken's cooperative threads and TCP unit, you can handle multiple file system requests in parallel, in case the file system sees, uh, heavy usage. Thanks go to Felix and the helpfull Chicken community. See the web page for more details, and feel free to ask questions. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
fuse_mod_wrap.c: In function '_wrap_fuse_main_real': fuse_mod_wrap.c:5204: warning: passing argument 3 of 'fuse_main_real' from incompatible pointer type fuse_mod_wrap.c:5204: error: too few arguments to function 'fuse_main_real' *** Shell command terminated with exit status 1: gcc fuse_mod_wrap.c -o fuse_mod_wrap.o -c -DHAVE_CHICKEN_CONFIG -Os -fomit-frame-pointer -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -DC_ENABLE_PTABLES -DC_NO_PIC_NO_DLL -fPIC -DPIC -DC_SHARED -I /usr/local/chicken-2.6/include -D_FILE_OFFSET_BITS=64 make: *** [fuse_mod_wrap.o] Error 1 > PS: I've installed the libfuse-dev package (it's a Xubuntu machine) Interesting. You probably need fuse-utils as well, but that isn't the main problem. The main problem seems to be that you have an older version of fuse, and I boneheadedly left SWIG output in the tarball (thinking it would save people the need to install SWIG to compile the filesystem). Do a "make swig_clean" and then run setup.sh again. OTOH, since I'm depending on Fuse API version 25, it's very possible that compilation will fail again (with a more informative error message this time). Hm, maybe I should downgrade the Fuse API dependency (though my own /usr/include/fuse/fuse.h says new apps should depend on v. 25). Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
I second Mario, that is really an amazing idea; filesystems implemented in high-level languages have been a long-time fascination of mine. Would it be possible for you to release the libfuse Chicken wrapper as a standalone egg? Thanks for the kind words, Mario and Ivan. It would be possible, though as Mario's case shows there are compatibility problems between various Linux distros (which could quickly become a support nightmare). Also, I think I'd have to downgrade to the lowest Fuse API version commonly in use, which is less than ideal. For the moment I think it's best to copy the sources if you want to write a new file system. If you don't touch the fusehi-related sources, you'll be able to simply replace them when there are updates. And if you do touch them, send a patch along so I can merge your changes in :) Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
Thanks Arto. Also, the existing FUSE bindings for Ruby and Python appear to have achieved stability on a number of platforms and may be worth looking at for tips and tricks. I'm not so sure about that. I distinctly remember it was a bitch to compile a Python-based filesystem (something along the lines of "the old bindings are no longer valid, the new ones rely on the unstable devel branch of fuse"). But I'd like to invite everyone who has a bit of time to look at the end of /usr/include/fuse/fuse.h and fuse_common.h (the "compatibility" macro mess). Fuse uses tricks like int func (int); #if API_VERSION == 22 #define func compat_func22 #endif (where of course compat_func22 has a different number of arguments). This really doesn't work with SWIG, as SWIG only considers the first declaration and doesn't do anything with the #define. Why the Fuse people felt it was a good ideea to use this hack, and to constantly change the signature of various functions, I don't know. I also don't know what a good solution would be, given the constantly shifting Fuse API and its un-swiggable nature. I'm open to input. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
Also, does chicken have native threads available? I'm under the impression that native threads are needed if you want multiple processes to be accessing files on a fuse fs simultaneously. Stklos does native threads but I wasn't able to get the stklos/fuse package to compile/install on my system and try it out. My filesystem consists of a C library and a Chicken server. The C fuse wrapper runs in multi-threaded mode, serializes requests to Chicken and waits for replies. The Chicken server spawns separate light-weight threads to service each request. So, in the end, we get both traditional multi-threading and lightweight threads under the same roof. I was actually quite excited about this part of the design. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
You mention on your webpage that "Scheme functions cannot serve as C callbacks" ... was the showstopper the multithreaded -> cooperative-threaded impedance difference, or was there another issue with calling back into Scheme from C? Not really. I said that Scheme functions cannot serve as C callbacks. I did not say that you cannot call a Scheme function from C. Fuse expects a structure fuse_operations filled with callbacks such as int (*readlink) (const char *, char *, size_t); You can't really write a Scheme function that, when compiled with Chicken, has this signature. Of course it's possible to write C stubs that call Chicken functions, but you'd lose the advantages of cooperative threading in that approach. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
Hi, I've updated duggfs to address the compilation errors reported by Felix and Mario. I have taken a different approach by no longer attempting to get through SWIG. This loses some functionality, but I believe it's the only workable solution. I kindly ask those who reported errors (as well as anyone else who wants to help out) to download the latest tarball from http://www.omnigia.com/scheme/duggfs/duggfs.tar.gz and give it a shot. On my own machine it now works both with fuse 2.5.x and fuse 2.6.x. You still need at least Fuse 2.5.x. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
errno.i: ./gen_errno.sh >errno.i || $(RM) -f errno.i Another dash/bash problem on Debian or Ubuntu. I used the "source" command to load a script in the current shell, and presumably this is not POSIX, so dash (the default /bin/sh since last year) refuses it. Does anyone know the POSIXly correct way? Anyway, fixed. and made gen_errno.sh executable and now it builds for me. I'm now having permission problems when running: ./start_duggfs.sh /tmp/duggfs By default, fuse doesn't let user A view content in a file system mounted by user B. Even when A is root. It's an interesting security problem: the fuse daemon (running as user B) would get to see data belonging to A, without A having agreed to permit that. There's an allow_other option: ./start_duggfs.sh /tmp/duggfs -o allow_other but it's only available if you enable user_allow_other in /etc/fuse.conf (a file which doesn't exist by default and the format of which is not documented as far as I know). To summarize, you should use the same account to mount duggfs and to explore its contents. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
Hi Matt, Glad to hear it finally worked. Remaining problem: all the files are owned by root with group root and some are not world readable. Unreadable directories are so by design. I've just put up a note on the duggfs homepage. [EMAIL PROTECTED]:/tmp/duggfs$ ls -l total 0 drwxrwxrwx 2 root root 0 1969-12-31 17:00 config drwxrwxrwx 2 root root 0 1969-12-31 17:00 stories d--x--x--x 2 root root 0 1969-12-31 17:00 users [EMAIL PROTECTED]:/tmp/duggfs$ cd users/ [EMAIL PROTECTED]:/tmp/duggfs/users$ ls ls: .: Permission denied [EMAIL PROTECTED]:/tmp/duggfs/users$ I'm not sure where to go from here. Well, go to the duggfs homepage and use the example commands listed there. Start your exploration from stories/topics/. Basically, users/ contains a potentially infinite number of entries and thus it is unreadable. On the other hand, if you know a user's name you can read his directory users/digg_name. You can also get to users by following symlinks from within story directories. interesting. If you feel inspired a "hello world" level example would be appreciated by those to whom your code is a bit beyond :-) You really just need to replace duggfs.scm with your own FS code. It shouldn't be too difficult. Begin with function "duggfs-start!" and the variable "*duggfs-op-handlers*". Feel free to ask questions as necessary. Cheers, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
Not really. It is in the Linux world, but outside that, there are lots of
Unices that don't come with Bash. In fact, one of the things that are most
annoying to Unix people who don't use Linux is the widespread hidden
assumption that /bin/sh points to bash. The fact that bash doesn't act
like a POSIX shell, even in POSIX compat mode doesn't help.
Please don't assume bash is on a system if you don't have to. Most
shellscripts can be easily rewritten to be POSIXly correct, with just
a little bit of work. If you really have to use some more advanced
features, please consider using /bin/ksh, which is also standardized
by POSIX. Again, many kshs deviate from the standard, so be careful
here too.
While I understand the spirit of POSIX advocacy, note that this thread
is about a Linux file system. Also, care to share the concrete solution
in this case? What's the POSIXly correct way to load a script in the
current shell ("." or "source" in bash, neither of which works in dash)?
Cheers,
Dan
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
On Sun, Jun 10, 2007 at 03:30:15PM +0300, Dan Muresan wrote:
While I understand the spirit of POSIX advocacy, note that this thread
is about a Linux file system. Also, care to share the concrete solution
in this case? What's the POSIXly correct way to load a script in the
current shell ("." or "source" in bash, neither of which works in dash)?
How about $(cat filename) or `cat filename`?
No. I'm surprised you've never run across the "source" or "." commands,
they're fairly common. They execute execute scripts in the current shell
(as opposed to spawning a new shell process). They're essential when you
want a script to modify the environment of the current shell (e.g. set
some shell variables, like the /etc/profile.d/* series). In my case
though I was just micro-optimizing.
Cheers,
Dan
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
I looked a little further, and dash(1) says it supports dot. Turns out you're right; however, it seems that "the dot" is somehow affected by PATH considerations, so . setup.sh does not work, yet . ./setup.sh does work. Which is pretty strange; I expected dot to look in the current directory by default, and to ignore the PATH. -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
On a Xubuntu machine (where I first tried duggfs) it's now building ok, but I get an error when running start_duggfs.sh: $ ./start_duggfs.sh /tmp/duggfs To unmount, type "fusermount -u /tmp/duggfs" $ Error: (string-ref) bad argument type: # This is probably not related to fuse. Unfortunately the stack trace is not much to go by. Maybe you specified an empty API key? Can you send me the contents of start_duggfs.sh? Also, you can run duggfs in csi. Do a "make clean" and then "make compile-mods", then run "csi -R chicken-prelude -R duggfs". Does the error still appear ? Finally, you can increase logging verbosity by changing *trace-pri* to 5 in trace.scm. -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
Mario discovered that his problems were (most likely) due to an unstable url egg. As of now, there are no other active complaints about duggfs not building. Hopefully this will stay true :) A few of you have mentioned their past interest in using Scheme for a filesystem. Out of curiosity, what ideas did you guys have in mind? Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] memcached
Ok, so that's one vote for separate 'memcached' and 'cache' eggs. I would vote against a generically-named cache egg... There are many types of caches (depending on storage medium, indexing, time complexities of caching/retrieval, expiration strategies etc) Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] memcached
That's why my generic cache interface is intended to be a front-end to different cache implementations, with a common interface, and some tools built on top of that interface (such as memoizing functions). Yes, I understand the philosophy, but before you can make a generic API, one should study several concrete examples and generalize from their needs. Currently, you have a single example (your own memcached). So I'm a little wary... -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] redirects on Chicken web site
Has anyone seen this c.l.scheme thread http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/4a1bf208997148ab/4366a294132176db Basically, http://www.call-with-current-continuation.org/chicken.html ranks high in Google results, but uses a Javascript redirect, which leaves some users with a blank page. Suggested resolution -- use a META redirect or a true 3xx redirect if possible. -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] user list on wiki
Hi all, two things I don't understand about the user list: 1) Some people get links with space-separated names, e.g. http://chicken.wiki.br/mario%20domenech%20goulart while some get links with dash-separated names: http://chicken.wiki.br/dan-muresan Yet the wiki markup seems to be the same. Worse, the dash-separated names become s for the corresponding user pages, which looks kind of weird. 2) When creating a new wiki page, it gets a warning box saying "This page has no tags. Please contribute to the wiki by editing it and adding some." Yet I see no obvious way to tag a page from the edit view. What am I missing here? -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] user list on wiki
Do you think that Svnwiki should replace dashes with spaces in the titles when they come from a file name? What about upper/lower case? I suppose the best thing is to force the user to use svnwiki:title if he cares, but I'm not entirely sure. As always, good defaults, overridable by user choice :) So, in this case, I would titlecase titles coming from file names. -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] stable version?
Hi all, what happened to the "stable version" download? The homepage now says to go to http://chicken.wiki.br/dev-snapshots/current; the "dev-snapshots" part doesn't provide the same assurance as a "stable version"... Is there a mailing list thread that I have missed? Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] (include) in (repl)
Hi, if I compile x.scm which contains simply (repl) with csc -v -R syntax-case -run-time-macros x.scm I get the following error during (repl) execution: $ ./x #;> (require 'syntax-case) ; loading /opt/chicken-2.7/lib/chicken/2/syntax-case.so ... ; loading /opt/chicken-2.7/lib/chicken/2/syntax-case-chicken-macros.scm ... Warning: the following toplevel variables are referenced but unbound: when (in one-file.481) #;> (include "none.scm") ; including none.scm ... Error: unbound variable: when Am I doing something wrong? This is the current "development snapshot" of Chicken, but it seems to happen in 2.6 as well for me (and I didn't have this problem in 2.5). Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] stable version?
If the Windows build is to be kept up to date, some Windows developer will have to do that work. Look what happened after all the hard work Brandon put into it. It was welcomed with open arms, but when it proved to be unmaintainable, Windows support was the first to go. This is another thread I missed... Windows support is now gone? You do realize that this makes it harder to push Chicken in any project that cares about portability (even if that project is mainly Unix)? -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] stable version?
I don't understand why cmake was dropped. Was it hard to maintain But more importantly, Chicken used to be build-able with MSVC before cmake, IIRC. What happened to that? -- Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] stable version?
MSVC support is gone. The Microsoft compilers are not particularly robust (in particular there have been problems with VC 7.0 Express, IIRC). Maintaining the build for the inadequate and hard to automate While I understand your annoyance with MSVC, it's nevertheless an important environment, and I maintain that supporting it lends more credence to Chicken in the industry. I understand that you do not wish to spend time on it. I still hope "we" (the community) will be able to restore this feature at some point. If it's just the build tools that create problems, that may not be such a big impediment. There are command line tools for the MSVC compiler, and requiring GNU make for Windows to be installed would not be too onerous. Best, Dan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
