Re: [Chicken-users] [4.7.0.3-st] Compiling on Solaris 10
Hello John, Thank you for your suggestions. Here is the next episode of my sparc adventures... On Thu, Nov 10, 2011 at 00:36, John Cowan co...@mercury.ccil.org wrote: Currently, sparc is not a supported CPU. The first thing is to add it to the list of known CPU architectures. Add the line sparc) echo sparc;; I added the line as: sun4u) echo sparc;; since this is what uname -m says. 1) Try copying apply-hack.sparc64.S to apply-hack.sparc.S and hope it works. If it does build, be sure to run the tests. This does not work. The assembler complains about setx, ldx... saying instructions from a set more recent than sparcv8 are unsupported. Fair enough. Looking at what the code does, it seems it expects the number of arguments, and a base address for a function, treats the first 6 arguments as passed through registers and loads the rest from the stack. Hmm... Now, looking a little at the output of objects with objdump and dbx, here is how things look like on this machine: the object format is elf32-sparc. I am unsure about the C ABI. the addresses are 32-bit the global and output registers seem to be 64 bits wide, the local and input registers 32 bits wide (weird, maybe wrong). There are some magic constants in the apply-hack.sparc64.S file which I do not understand. What is the 2047? And the 176? The code just before these looks as if it already reserved a window for the registers on the stack, so what is this? In the case of sparc, if it is possible to use the same general scheme (no pun intended), I would have to replace ldx, sllx and co with shorter instructions, saving the higher, then the lower part of the %g and %o registers I suppose... And of course, modify the various other constants (8, -2, 3) to accomodate for the different register width. Does this make any kind of sense? 2) If that fails, try disabling APPLY_HACK by adding the following patch to Makefile.solaris after the comment line # options: ifeq ($(ARCH),sparc) APPLY_HACK= endif As far as I know, nobody has tried to build Chicken without an apply-hack in a long time. This was a simple thing to do, but did not work. As the first part of installilng chicken, I must first bootstrap it, with: gmake PLATFORM=solaris CHICKEN=/bin/true PREFIX=$HOME boot-chicken and after compiling for a few moments, the build fails with: gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -c c-backend.c -o c-backend-static.o -I. -I./ gmake[2]: *** No rule to make target `apply-hack.sparc.S', needed by `apply-hack.sparc.o'. Stop. Note on the /bin/true part: README is lying ;-) There is no bootstrap compiler included in the stable releases (1st lie), and there is no pre-compiled bootstrap compiler to be downloaded from the Chicken site (2nd lie). But thankfully the .c files are already there, so the vicious circle of having chicken to bootstrap chicken does not happen. Advice, comments, directions are most welcome. -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [4.7.0.3-st] Compiling on Solaris 10
Hello Mario, On Thu, Nov 10, 2011 at 20:05, Mario Domenech Goulart mario.goul...@gmail.com wrote: Hi Nicolas, On Thu, 10 Nov 2011 20:10:10 +0900 Nicolas Pelletier nicolas.pelleti...@gmail.com wrote: Note on the /bin/true part: README is lying ;-) There is no bootstrap compiler included in the stable releases (1st lie), and there is no pre-compiled bootstrap compiler to be downloaded from the Chicken site (2nd lie). I don't get the 1st lie. What section mentions that? I am refering to the secion 6. Bootstrapping in README: make PLATFORM=platform CHICKEN=path-to-existing-chicken boot-chicken When I read this, I thought path-to-existing-chicken meant there was an existing chicken included, which is not the case. On re-reading, I am not sure this is what was meant... but telling the user to point to an existing chicken when they are trying to bootstrap is certainly confusing. The second lie has been fixed in the chicken-core git repository. That was fast! Thank you! -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [4.7.0.3-st] Compiling on Solaris 10
Hello Chickeners, today I tried to compile the latest stable Chicken, 4.7.0.3-st on Solaris 10 (sparc), only to find out the the build fails: I used gmake PLATFORM=SunOS PREFIX=$HOME and make signalled a circular dependency while looking for apply-hack.sparc.S. As it turns out, there is a apply-hack.sparc64.S... but nothing for the other. I am not familiar with the sparc architecture, so I am looking for advice on what to do. Also please tell me if you need more information. Thank you in advance for your answers. -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [4.6.0] thread-sleep! sleeps too much
Hello, I've run into a case where a thread that uses thread-sleep! for a fixed amount of time seems to never wake up. I can reproduce this from csi as well: CHICKEN (c)2008-2010 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.6.0 linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] compiled 2011-01-16 on gladstone.duckburg.org (Linux) #;1 (require-extension srfi-18) ; loading library srfi-18 ... #;2 (thread-sleep! 10) #;3 (thread-sleep! (seconds-time (+ 10 (time-seconds (current-time) ^C The last call to thread-sleep! does not return after 10 seconds, nor 20 seconds... Has someone already bumped into this? Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [4.6.0] thread-sleep! sleeps too much
On Mon, Mar 28, 2011 at 22:25, David N Murray dmur...@jsbsystems.com wrote: Tests OK in 4.6.5. (Sorry, don't have 4.6.0 installed anymore.) On Tue, Mar 29, 2011 at 03:19, Felix fe...@call-with-current-continuation.org wrote: Can you try a newer chicken version? I can't reproduce this right now. Thanks to both of you. As pointed out, this problem does not exist in 4.6.5. Maybe I should change habits and follow the dev-snapshots instead of the stable releases. Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] raw packet interface
Hello, On Thu, Mar 10, 2011 at 23:09, Christiano F. Haesbaert haesba...@haesbaert.org wrote: Using raw socket is quite portable, you'll probably need something like filtering with pcap, and then using the raw socket to send your stuff. For anything at or above the network layer, this seems to be a good solution, thank you. For the link layer, I'll just use BPF ;-) Best regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] raw packet interface
Hello Chickenistas, As part of testing a network appliance (router/firewall etc...), I'd like to be able to read and write arbitrary data to the network. So I'm wondering if somebody has already some tools to interface to low-level networking services, such as BPF, libpcap... I am trying to find error cases in the handling of incoming packets in the appliance; I do not need throughput performance nor very precise timings. I am running under FreeBSD 8.1. I'd be grateful for any advice. Thanks in advance, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken segfaults with large-ish inputs
Hello, On Sun, Feb 20, 2011 at 06:47, Sam Hardwick sam.hardw...@gmail.com wrote: (define (sum term a next b) (if ( a b) 0 (+ (term a) (sum term (next a) next b You can use the following trick to accumulate intermediate results and thus turn the call to sum into a tail recursive one: (define (sum term a next b) (letrec ((helper (lambda (acc t a n b) (if ( a b) acc (helper (+ acc (t a)) t (n a) n b) (helper 0 term a next b))) With chicken 4.6.0, I get the following: #;14 (integral cube 0 1 10) 0.25 #;15 (integral cube 0 1 100) 0.25 #;16 (integral cube 0 1 1000) 0.25 #;17 (integral cube 0 1 1) 0.25 #;18 (integral cube 0 1 10) 0.249 #;19 (integral cube 0 1 100) ; Used to crash from that point on 0.25 #;20 (integral cube 0 1 1000) 0.25 Hope this helps, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Disable garbage collection
On Fri, Aug 6, 2010 at 12:54 AM, John Cowan co...@ccil.org wrote: I suppose you could have a startup option which disables major GCs and allocates one big space, and then kills the program while it runs out. You can compile with -heap-size XXX, which will produce an executable using a fixed amount of heap and die if it runs out of space. Running out of heap triggers a panic in the chicken library, so you cannot catch it as an error condition and try to act on it (and there would be no guaranties anyway as to what you would still be able to do if you could anyway). But perhaps the question is aimed at disabling GC in a given dynamic scope, so as to be sure that pointers retained internally by C code still work. This would have to be preceded by a minor GC, of course. The foreign function interface allows you to define new GC roots to avoid having data shared with foreign code from being garbage collected. Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
Hi, On Fri, Jul 30, 2010 at 9:13 PM, Felix fe...@call-with-current-continuation.org wrote: I propose to use flonums for timeout values. This makes the representation of srfi-18 time values simpler and removes any possibility of overflow. I don't think the performance impact is all that heavy. Okay, thank you. One thing that still bothers me is the use of gettimeofday inside the scheduler. I'm not sure everything will work nicely if an NTP server (or root) sets the date to something in the past. And then comes the problem of having a _portable_ way to represent monotonic time... If you are adventurous, you can try out the flonum-milliseconds branch in the git repository, where I made all the necessary changes (quite a lot, in fact). Feedback would be great, since I don't have decent testing code for multithreading. Thank you, I'll try it. Something will break, that's for sure, but I see no way around it. Well, it's an experimental branch, after all ;-) -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-users] current-time on 32-bit hardware Date: Thu, 29 Jul 2010 11:01:26 +0200 On Thu, Jul 29, 2010 at 7:12 PM, Felix fe...@call-with-current-continuation.org wrote: Peter Bex peter@xs4all.nl wrote: I'd suggest you use numbers but I don't think thread-sleep! accepts bignums. Felix fe...@call-with-current-continuation.orgreplied: That won't change anything. You are right, and using only small values for timeouts does not help either. No, the reason for this is that the scheduler uses fixnums in timeout checks for performance reasons and because of this, the time objects store time spans as fixnums as well. This will probably have to be changed to use flonums. I am currently looking at ##sys#schedule. The time-out queue only needs to hold time offsets from now. I suppose the reason for having now (aka ##sys#fudge 16) sitting around here is to find out whether C_msleep slept too long and fire the events the scheduler might have missed. But since there are no guaranties from the OS that we will not actually sleep a bit too much, I'm thinking of representing the current point in time with a plain 0 and replacing (if (= now tmo1) ...) by (if (= how-much-i-slept tmo1) ...), with how-much-i-slept being the time I asked to sleep for. I expect thus to be able to still use fixnums to represent time-outs while avoiding the 13 days since startup issue. The maximum for time-outs would then be 2**29 ms, or 6 days 5 hours or so, which does not sound as a limitation to me. Does anybody have any objections to this? Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. I can not reproduce this. On what platform are you running this code? It is a 32-bit Linux on a Pentium R. If my understanding is correct, the following call is subject to overflow (e.g. inexact-exact is called on a number that would have its bit 30 set if represented as an integer) after the process has been running for running for 12 days 10 hours 15 minutes 41 seconds. So yes, it is not immediately reproducible ;-) (inexact-exact (truncate (+ (* (- s ss) 1000) C_ms))) As a workaround, I can use immediate integers instead of timeout objects in the calls to thread-sleep! and mutex-lock!, at the expense of a few milliseconds time slip. Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current-time on 32-bit hardware
On Thu, Jul 29, 2010 at 6:01 PM, Peter Bex peter@xs4all.nl wrote: On Thu, Jul 29, 2010 at 05:34:27PM +0900, Nicolas Pelletier wrote: Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. I can not reproduce this. On what platform are you running this code? It is a 32-bit Linux on a Pentium R. That's why Felix couldn't reproduce it; I'm willing to bet he tried it on 64 bits only. This number cannot be represented as a fixnum on a 32 bit platform, because it requires 31 bits of storage. There are only 30 bits available, because one bit is used as fixnum tag and one bit is taken as the sign bit. Yes. I know this from exchanging data between C and Scheme processes. Values like 0x8000A010 were not going smoothly through at first. I'd suggest you use numbers but I don't think thread-sleep! accepts bignums. For my current needs, I only need small fixnums, so using numbers is enough, and seems like the way to go for an immediate solution. As a workaround, I can use immediate integers instead of timeout objects in the calls to thread-sleep! and mutex-lock!, at the expense of a few milliseconds time slip. huh? I don't understand that bit. I wanted to say the difference in behaviour between the two clocks below, for example, is not an issue for my current program. ; a clock with a gradual drift: (let loop ((x 1)) (thread-sleep! 1) (write x) (loop (+ x 1))) ; a clock with no drift: (let ((start (time-seconds (current-time))) (let loop ((x 1)) (thread-sleep! (seconds-time (+ x start))) (write x) (loop (+ x 1 Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] current-time on 32-bit hardware
Hello, I've run into the following problem. I am taking a mutex with a time-out, as follows: (mutex-lock! children-mutex (seconds-time (+ 1 (time-seconds (current-time) And I got the following error: Warning (#thread: my-thread): : (inexact-exact) inexact number cannot be represented as an exact\ number: 1189553855. Looking at srfi-18.scm, the implementation of current-time is: (define (current-time) (let* ([s C_get_seconds] [ss C_startup_time_seconds] [ms C_ms] ) (##sys#make-structure 'time (inexact-exact (truncate (+ (* (- s ss) 1000) C_ms))) s C_ms) ) ) Due to the different representation of integers between C and chicken (32 bits in C, 30 in chicken if I'm not mistaken), the above inexact-exact fails. I am using 4.3.0, but the implementation of current-time in 4.5.0 is the same. On one hand, using 64-bit hardware instead is not an option. On the other hand, I just need mutex-lock! to not wait forever; waiting a little more than one second is okay. Could someone suggest a workaround and/or a fix, please? Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] import and srfi-1
Hello, On Fri, Jul 23, 2010 at 6:52 PM, Moritz Heidkamp mor...@twoticketsplease.de wrote: Hi, Nicolas Pelletier sxatrxtfxcrwamvjk...@gmail.com writes: nico...@dynamo:~/tmp$ csc -s -j test test.scm nico...@dynamo:~/tmp$ csc toto.scm nico...@dynamo:~/tmp$ ./toto just a little hint: the disadvantage of this is that you either have to delete the test.so or recompile test.scm for every change you make. You can however use csc -Jt test.scm which will only generate the test.c but also the test.import.scm which you can use for requiring test.scm. Quite convenient! Remember to run csc -Jt again whenever you change the exports of the test module however :-) Indeed, this is more convenient. Thank you for pointing this out! -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] import and srfi-1
Hello, you can do it the following way by generating the import module for test.scm: nico...@dynamo:~/tmp$ cat test.scm (module test (rev) (import scheme) (import srfi-1) (require-extension srfi-1) (define (rev ls) (fold cons '() ls)) ) nico...@dynamo:~/tmp$ cat toto.scm (require-extension test) (display (rev (list 1 2 3 4 5))) (newline) nico...@dynamo:~/tmp$ csc -s -j test test.scm nico...@dynamo:~/tmp$ csc toto.scm nico...@dynamo:~/tmp$ ./toto (5 4 3 2 1) Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] procedure memoization
Hello, On Sat, Feb 13, 2010 at 5:53 AM, Hugo Arregui hugo.arre...@gmail.com wrote: there's a standard implementation for procedures memoization? Srfi or egg? R5RS says that the result of forcing a promise is memoized. So you might want to do something along the lines of: (let ((x (delay (begin (print Hi!) 1 (print (force x)) (print (force x))) Hi! 1 1 HTH, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: ... and a happy new year as well!
Hello, On Fri, Jan 8, 2010 at 1:06 AM, Christian Kellermann ck...@pestilenz.org wrote: * Ivan Shmakov i...@main.uusia.org [100107 17:00]: PS. Currently, I'm about to begin my preparations for the course on computer networks I'd be carrying on for the second time. While no part of the course the course has a specific focus on the network programming, I'd be glad to hear any suggestions on how Scheme (and functional programming in general) could be mentioned. I'd suggest protocol analysis or traffic inspection. Chicken's support for low-level access and easy ffi lets you hook almost anywhere in the network stack. Then Scheme's power lets you use more advanced tools for analysis (e.g. using a true parser to analyze a protocol, for example with the packrat egg). On top of that, you can hook some reasoning capabilities (for example, with the kanren egg) to detect intrusions, attacks, questionnable traffic, or suggest an optimal network configuration, etc... Or you can go for server-side programming, for example cgi, connection pooling, access policy... or even (gasp!) cloud computing (for example, cluster or cloud controllers); the kind of thing that is traditionally done in C with complicated data structures, a lot of pointers, and no help from GC, closures, or symbolic programming. And takes a lot of effort and money to develop and debug :-) Another hot topic today is the semantic web (RDF, OWL and friends). This is an area where high-level languages with dynamic and reasoning capabilities (e.g. Scheme, Lisp, Prolog, for example) shine. Whether you want to see the network from behind HTTP or not is up to you, of course. That's it for a few ideas. -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-install from behind a proxy?
Hello, On Wed, Nov 25, 2009 at 8:34 PM, Mario Domenech Goulart mario.goul...@gmail.com wrote: Felix has just implemented this feature. See http://chicken.wiki.br/cgi-bin/gitweb/gitweb.cgi?p=chicken-core.git;a=commit;h=895a4d51277071deee6cfe0f0e2a04f0bc10813e Thank you. I tried the patch over a vanilla 4.2.0. I am now able to see the download going through the proxy, but the installation still fails with the following error: reading files ... ./kanren.scm Error: invalid file name - possibly corrupt transmission: |# ./kanren-runtime.scm 82966 ; The body of KANREN ; ; The appropriate prelu... Inspecting what is really received on the wire shows that the data begins with a newline followed by this line: #||# ./kanren.scm 83807 It looks like the (read) operation in setup-download.scm (line 250 for me) does not skip over the last |#. Any ideas what might be causing this? Regards, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken-install from behind a proxy?
Hello, I successfully installed Chicken 4.2.0 on my machine (Debian 5.0, 64 bits Intel). However, I cannot install any eggs; the problem seems to be that I am sitting behind a proxy: nico...@dynamo:~/dev$ chicken-install kanren retrieving ... connecting to host chicken.kitten-technologies.co.uk, port 80 ... TCP connect timeout connecting to host galinha.ucpel.tche.br, port 80 ... TCP connect timeout Error: extension or version not found FWIW, the error message says TCP connect timeout, but a network capture shows that this is really the name resolution which is failing (which is just a peculiarity of the network setup here). I had previously no problems using chicken-setup and chicken-3.2.7 (chicken-setup -proxy my_proxy.xxx:8080 kanren successfully installed the kanren egg). Could you please help me around this problem? In case this is one feature that is already on the todo list for chicken-install (and just hasn't been ported from chicken-setup yet), I'd appreciate any hints as to which files and functions to modify to make this work. Thanks in advance, -- Nicolas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
