Re: [Chicken-hackers] [Chicken-users] Happy Christmas!
* felix.winkelm...@bevuta.com [181227 00:48]: > > I wish all CHICKEN -users, -hackers,- janitors, -meisters, -lovers and -haters > a very happy christmas. Take care of yourself and keep your parentheses > in shape. The same to you all! -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] ♥ Patch ♥ Fix 1565
Hi! Jim has encountered an issue with file-lock procedures. The attached patch fixes this. While investigating I have noticed that we don't actually check the locking procedures in our tests. I shall think of a test for these (Bug for this is #1566). Comments? -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. From 01fb92f81104dd9904e7314930e58b5ce8f21ea1 Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Fri, 30 Nov 2018 22:55:24 +0100 Subject: [PATCH] Test for port direction when setting up flock struct This fixes #1565. We create a read lock only on input ports, output ports and bidirectional ports will get a write lock. --- posixunix.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/posixunix.scm b/posixunix.scm index a85f9dce..ad1f42c4 100644 --- a/posixunix.scm +++ b/posixunix.scm @@ -990,7 +990,7 @@ static int set_file_mtime(char *filename, C_word atime, C_word mtime) (if (eq? #t len) (set! len 0) (##sys#check-exact-integer len loc) ) - (##core#inline "C_flock_setup" (if (##sys#slot port 1) _f_rdlck _f_wrlck) start len) + (##core#inline "C_flock_setup" (if (= (##sys#slot port 1) 1) _f_rdlck _f_wrlck) start len) (##sys#make-structure 'lock port start len) ) ) (define (err msg lock loc) (posix-error #:file-error loc msg (##sys#slot lock 1) (##sys#slot lock 2) (##sys#slot lock 3)) ) -- 2.19.1 signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] conditionals in .egg files
* Evan Hanson [180929 01:37]: > On 2018-09-27 21:38, felix.winkelm...@bevuta.com wrote: > > Opinions? > > I'm for it, yeah. > > In 5.0 people can make do with custom-build, but having cond-expand > available would be nice for simple cases. I also think this is a valuable addition, especially when you know you need certain flags for certain platforms... -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Use arc4random_buf on FreeBSD/DragonFly
* felix.winkelm...@bevuta.com [180906 12:27]: > Should be self-explaining... I would delay this patch. I did look up FreeBSD's code base and it seems that they have importet OpenBSD's version 18 days ago, according to https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/arc4random.c The old version does not use a save random number generator and using the old method is better in that case. Same goes for DragonFly. Maybe a FreeBSD user can correct me on this? -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] (chicken random) should use arc4random_buf on FreeBSD too
* Tobias Kortkamp [180904 09:46]: > Hi, > > arc4random_buf(3) should be used for entropy gathering on FreeBSD > too same as OpenBSD. This is fine for me! -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Make (repository-path) return a list
* felix.winkelm...@bevuta.com [180810 00:42]: > remote: [git] (close-output-port out) > remote: [process-ref-change] (##sys#call-with-values > (##core#lambda () (tcp-connect "localhost" 22722)) (##core#lambda (vin121 > vo... > remote: [process-ref-change] (tcp-connect "localhost" 22722) > <-- > > Probably some broken git hook?) That's vandusen, maybe the bot is not running? -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Merge chicken-5 into master? Also: git help needed
* Peter Bex [171206 10:12]: > On Wed, Dec 06, 2017 at 09:54:23PM +1300, Evan Hanson wrote: > > On 2017-12-05 22:44, felix.winkelm...@bevuta.com wrote: > > > > This will also loose all history information from the chicken-5 > > > > branch prior to the source drop. > > > > > > > > I think the easiest way for us would be to rename the master branch > > > > to chicken-4.x then rename the chicken-5 branch to master. > > > > > > > > For bug reports etc the commit hashes would still be the same so > > > > we can support chicken-4 for a while without too much hassle. > > > > > > > > The only downside is that people would have to do this on their > > > > machines locally as well (or just throw away the master branch) > > > > otherwise pushing will always fail. But that is more of a communication > > > > issue. > > > > > > > > After trying to merge this for a bit I think we should just do the > > > > renaming and be done. > > > > > > I think Christian is right here. If things fail locally, one can still do > > > a fresh checkout as a last resort. Git will just fuck up things, if > > > we let it. > > > > I agree, we should absolutely just rename the branches. > > > > git branch -m master chicken-4 > > git branch -m chicken-5 master > > > > We're a small team so I think everyone involved should just run these > > commands and be done with it. Someone will need to do this on the > > repository on call-cc.org, too. > > > > I've been thinking about this some more, but what happens when we want > to make a release? We'd merge master into prerelease, which won't work > and then prerelease into release, which won't work either. Why would you want to keep the old prerelease branches? or the old release branches? Why not rename them too? -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Merge chicken-5 into master? Also: git help needed
* Peter Bex [171205 21:17]: > Hi all, > > Just a quick question: Now that we've started the 4.13.0 release > process, should we branch off a "chicken-4" branch from master > and merge "chicken-5" into master? > > If we decide to do so, how does that work, exactly? I just tried > and it can be done relatively easily with the following sequence: > > $ git checkout master > $ rm -rf * # This will ignore .git in my zsh config > $ git checkout chicken-5 . # Check out chicken-5 files into master > $ git add . # Add any new files, remove any deleted ones > > I'm just not sure whether that's the best way to do this kind of thing, > given that you'd probably lose any sort of merge tracking info at all, > and it will probably produce quite a big commit. This will also loose all history information from the chicken-5 branch prior to the source drop. I think the easiest way for us would be to rename the master branch to chicken-4.x then rename the chicken-5 branch to master. For bug reports etc the commit hashes would still be the same so we can support chicken-4 for a while without too much hassle. The only downside is that people would have to do this on their machines locally as well (or just throw away the master branch) otherwise pushing will always fail. But that is more of a communication issue. After trying to merge this for a bit I think we should just do the renaming and be done. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] What to do with CHICKEN 4.13/4.12.1 release/snapshot?
* John Cowan [171028 22:15]: > On Sat, Oct 28, 2017 at 2:27 PM, Peter Bex wrote: > > Also, what happens to the CHICKEN 4 line after 5.0 is out? > > > > 1) Pick a EOL date for Chicken 4. > > 2) Stop accepting patches except security patches. > > 3) Accept security patches until the EOL date. > > 4) Profit!!! I would do all of the above with a 4.13 release. There may be people relying on CHICKEN 4 for their code base so we should give them a cleaned up ship they can sink with :) Seriously though, mitigation to CHICKEN 5 will take some time and there have been bugfixes in master that should make it into a stable version. -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] [5] Avoid storing threads in trace-buffer
* J?rg F. Wittenberger [171104 20:07]: > > > Just wondering. If memory usage was the concern, why not simple compile > without tracing? > > This way we pay one more slot per thread. Plus some lookup. What do we earn? > > Maybe I'm missing something? You will miss helpful error messages? -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Prevent uninitialized memory access when make-ing a srfi-4 vector
* Kooda [170315 00:52]: > Signed off and pushed. > > I just changed the `int` type to `size_t` to avoid integer overflow. Good catch, thanks! -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Should we make a 4.12 release?
* felix.winkelm...@bevuta.com [170103 23:50]: > > I think it would. To truly test in a clean environment I would suggest to > use a fresh chicken installation for case 1 as well. Note that this can > be done by pure copying/hardlinking of files, assuming the user didn't > modify installed files. But I didn't know of case 1 and am not sure what > advantages it provides. Case 1 does detect undeclared dependencies before authors check in their eggs. This has helped me in the past as I am known for missing those. This could be done with a fresh chicken install of course provided that the egg author does have a source checkout available. I don't know if all our users do that. One could simulate this with linking into a fresh dir but in the case of a binary installation we would check how package maintainers package it to find all necessary files. Maybe this could be solved with all the "introspection" we currently have. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix seemingly random crashes in foreign callbacks (#1337)
* Peter Bex [161228 19:18]: > Hi all, > > The attached patch fixes #1337, which has exactly the same root cause as > the "Salmonella crashes a lot" issue we struggled with back in 2015: > http://lists.gnu.org/archive/html/chicken-hackers/2015-10/msg1.html Thanks for finding this. I do think the patch is fine and I have pushed it to both branches. Thanks, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] Fix buffer overflow found by #1308
Hi! The attached patch adds range checks avoiding a buffer overflow for the environment and argument buffers used in the posix execvp/execve wrappers on linux and windows. Does that look OK? Cheers, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. >From 643848bbad2cb8858030507ca1c26bb0817b3633 Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Sat, 23 Jul 2016 21:23:50 +0200 Subject: [PATCH] Fix buffer overflow in posix execvp/execve wrapper This fixes bug #1308 found by wasamasa. It turns out that we don't check the number of arguments or the number of env entries before trying to write them to the target string. That target string is only ARG_MAX or ENV_MAX bytes long. This patch adds a ##sys#check-range for both arguments. The unix implementation and the windows implementation are both affected and fixed with this patch. --- posixunix.scm | 6 +- posixwin.scm | 9 ++--- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/posixunix.scm b/posixunix.scm index a21d0b0..cc9c947 100644 --- a/posixunix.scm +++ b/posixunix.scm @@ -1599,10 +1599,13 @@ EOF [freeargs (foreign-lambda void "C_free_exec_args")] [setenv (foreign-lambda void "C_set_exec_env" int c-string int)] [freeenv (foreign-lambda void "C_free_exec_env")] -[pathname-strip-directory pathname-strip-directory] ) +[pathname-strip-directory pathname-strip-directory] +[arg-max (foreign-value "ARG_MAX" size_t)] +[env-max (foreign-value "ENV_MAX" size_t)] ) (lambda (filename #!optional (arglist '()) envlist) (##sys#check-string filename 'process-execute) (##sys#check-list arglist 'process-execute) + (##sys#check-range (##sys#length arglist) 0 arg-max 'process-execute) (let ([s (pathname-strip-directory filename)]) (setarg 0 s (##sys#size s)) ) (do ([al arglist (cdr al)] @@ -1611,6 +1614,7 @@ EOF (setarg i #f 0) (when envlist (##sys#check-list envlist 'process-execute) + (##sys#check-range (##sys#length envlist) 0 env-max 'process-execute) (do ([el envlist (cdr el)] [i 0 (fx+ i 1)] ) ((null? el) (setenv i #f 0)) diff --git a/posixwin.scm b/posixwin.scm index 2f46aaf..cc9a583 100644 --- a/posixwin.scm +++ b/posixwin.scm @@ -1191,11 +1191,14 @@ EOF ;; At least it's secure, we can worry about performance later, if at all (let ([setarg (foreign-lambda void "C_set_exec_arg" int c-string int)] [setenv (foreign-lambda void "C_set_exec_env" int c-string int)] + [arg-max (foreign-value "ARG_MAX" size_t)] + [env-max (foreign-value "ENV_MAX" size_t)] [build-exec-argvec - (lambda (loc lst argvec-setter idx) + (lambda (loc lst argvec-setter idx max) (if lst (begin (##sys#check-list lst loc) + (##sys-check-range (##sys#length lst) 0 max loc) (do ([l lst (cdr l)] [i idx (fx+ i 1)] ) ((null? l) (argvec-setter i #f 0)) @@ -1207,8 +1210,8 @@ EOF (##sys#check-string filename loc) (let ([s (pathname-strip-directory filename)]) (setarg 0 s (##sys#size s)) ) - (build-exec-argvec loc (and arglst ($quote-args-list arglst exactf)) setarg 1) - (build-exec-argvec loc envlst setenv 0) + (build-exec-argvec loc (and arglst ($quote-args-list arglst exactf)) setarg 1 arg-max) + (build-exec-argvec loc envlst setenv 0 env-max) (##core#inline "C_flushall") (##sys#make-c-string filename loc) ) ) ) -- 2.9.0 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] user-information update for OpenBSD
* Timo Myyrä [160719 12:30]: > I think that would be more sensible approach. user-information would return > info > from /etc/passwd and then another procedure to get the encrypted password. > > That would probably happen for 5.0? Yes, 5.0 is the ultimate excuse to break backwards compatibility. Cheers, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Using mandoc for chicken manual pages?
* Timo Myyrä [160719 11:49]: > Peter Bex writes: > > > On Tue, Jul 19, 2016 at 10:53:07AM +0300, Timo Myyrä wrote: > > > >> Hi, > >> > >> Chicken manuals are currently little sparse and use older man(7) format. > >> Would it make sense to update the manual pages and switch to using mdoc(7) > >> format in them? Mdoc(7) format is easier to work on and the manual pages > >> need > >> attention in any case. Currently they just recommend to run the command > >> with > >> `-h' flag to get the information. > >> > >> On chickens user side this wouldn't cause anything new, better manuals I > >> hope. I > >> think most platforms can view mdoc(7) pages just fine. > > > > I think this would be great. The main problem with manpages is > > maintenance, because most of this is duplicated in the online help and > > the "manual" dir. > > Hmm, mandoc can output HTML from mdoc. Could the HTML page be generated from > mdoc file? That would keep those in sync? But that step could be worked on > later. I think the key point here is that the manual is also editable in the wiki, hence needs a manual merge on every release (which is not that often, so that's doable). Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Using mandoc for chicken manual pages?
* Peter Bex [160719 10:08]: > On Tue, Jul 19, 2016 at 10:53:07AM +0300, Timo Myyrä wrote: > > Hi, > > > > Chicken manuals are currently little sparse and use older man(7) format. > > Would it make sense to update the manual pages and switch to using mdoc(7) > > format in them? Mdoc(7) format is easier to work on and the manual pages > > need > > attention in any case. Currently they just recommend to run the command with > > `-h' flag to get the information. > > > > On chickens user side this wouldn't cause anything new, better manuals I > > hope. I > > think most platforms can view mdoc(7) pages just fine. > > I think this would be great. The main problem with manpages is > maintenance, because most of this is duplicated in the online help and > the "manual" dir. > > > On build side it would make mandoc a build dependency. It would also > > require a > > check in build scripts so that platforms which are not able to view mdoc(7) > > files would be able to generate man(7) formatted manuals out of the mdoc(7) > > using mandoc command. > > I don't know if that's necessary; we could pregenerate these just like > we do for the .c and .html manual files. Only if you want to build CHICKEN > from git sources you'd need mandoc proper. Or am I misunderstanding what > you're saying? That's correct imho. We would add the mandoc requirement when building a release / snapshot / git version only. I could live with that. Thanks! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] user-information update for OpenBSD
* Timo Myyrä [160719 09:20]: > Hi, > > OpenBSD-current was changed so that shadow database isn't opened by default > anymore: > http://article.gmane.org/gmane.os.openbsd.cvs/155646 > > This affects calls to getpwnam and getpwuid functions which chicken uses for > the > user-information procedure. > > I see two ways to fix this: > > 1) add defined(__OpenBSD__) checks to posixunix.scm to call the shadow > versions of >these functions if the encrypted password is really needed. > > or > > 2) add note to user-information that the OpenBSD doesn't provide the encrypted >password and check if any eggs depend on having the password. Maybe it makes sense to split out the sensitive information from the user-information for all Operating systems and thinking of another set of procedures that will produce the credentials. These can then use OS specific functions to get at the information. What do you think? Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH 0/5][5] Generalize port directionality and add basic refinement types
* John Cowan [160709 19:03]: > > For situations when it's desirable to expose only one end of a > > pair, we could create a procedure like "extract-input-port" and > > "extract-output-port" from a bidirectional port. I'm not sure what > > good names would be for these. > > I'm not sure that these are in the spirit of Scheme's duck typing. > In general we rely on programmer restraint to prevent, e.g., mutation > of lists or strings when the rest of the program doesn't expect it. I can see applications where this would be desireable though. I think the existing make-input-port and make-output-port could be changed to also accept an existing port and return a unidirectional port if needed. Better than introducing yet another name imho. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] A stupid but serviceable fix for #1110
Peter Bex writes:
> So here's another fix, this is an attempt to slightly improve the error
> message you get when Henrietta returns an error. Henrietta is supposed
> to return an s-expression (error "blabla") when something doesn't work
> out well, but there's a mismatch between the code that tries to parse
> the first line henrietta outputs and the code that READs the s-expression
> it returns.
>
> Detecting (error ..) on the line is an ugly fix, I know and not 100%
> reliable, but it's slightly better than what we have now, and at least
> the code that's supposed to be triggered gets triggered now. And we can
> close another ticket :)
>
I have pushed this for now, there seems to be a change in chicken-5's
version of setup-download.scm that's not in master:
--8<---cut here---start->8---
((irregex-match '(* ("\x09\x0a\x0b\x0c\x0d\x20\xa0")) ln)
(skip)) ; Blank line.
--8<---cut here---end--->8---
This has been introduced by commit,
0cf4eba9060bdd4354afe50cb6c4ef38146694e2 "Remove srfi-14"
Question is, what does it do and why is it there and should it be
backported?
Kind regards,
Christian
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Make ##sys#stat work with port objects.
lemonboy writes: > Take 2, this time the NEWS file and the manual have been updated too. > Sorry for the noise. I have applied this to the master branch and will cherry pick it into chicken-5. Thanks for your contribution! Cheers, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix undefined behaviour of shifting left signed values
Peter Bex writes: > Hello all, > > I ran another test with the sanitizer, this time using the undefined > behaviour checks (-fsanitize=undefined). This found a few problems: > > - We are using left shifts on signed types. According to the C spec >this behaviour is undefined (which is completely retarded, IMHO). >The even more retarded fix is to simply cast to unsigned and back to >signed whereever this is done. The attached patch does this for >master and chicken-5. I have pushed this as newer compilers will get more aggressive than they already are and try bending the language laws towards their needs. I hope code will at least fail in a more predictable mode then. > - We are dividing floating-point numbers by zero, which is apparently >undefined. However, we do this to obtain NaN and Inf values. >As far as I can determine, there is no really portable way to do >this. See also for example this Stack Overflow thread: >http://stackoverflow.com/questions/1923837/how-to-use-nan-and-inf-in-c >It looks like INFINITY is defined in C99, and NAN *may* be. Let's keep that as it is, it looks like it is too much effort for the gain atm. Thank you, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Make LENGTH argument to read-u8vector, {read, write}-string more precise in types.db
Evan Hanson writes: > Also fix up the signature of read-u8vector in the manual. As this is a simple bugfix I have also cherry picked it into prerelease. -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Make LENGTH argument to read-u8vector, {read, write}-string more precise in types.db
Evan Hanson writes: > Also fix up the signature of read-u8vector in the manual. Pushed to master. For the chicken-5 branch this won't apply as the srfi-4 stuff has been moved around it seems, I have pushed a similar patch to the chicken-5 branch. Thanks Evan! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Including chicken.h fails for C++11
* Peter Bex [150617 20:24]: > I've tested on Linux, and the attached patches fix the problem and compile > fine with normal C as well. I also got rid of a few warnings by wrapping > some more static strings in C_text() calls (which does nothing in C mode, but > in C++ mode it will add an explicit cast from string to C_char *). All applied thank you all! > I vote for also applying this to prerelease, as it is a reasonably > simple change and it fixes a real problem with C++. I agree, I have cherry picked the commit on prerelease. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Proposal] Officially drop SWIG support?
Ivan Raikov writes: > I am not sure SWIG ever worked in Chicken 4, and furthermore I am not > sure SWIG itself is that well maintained. > At this point Chicken provides a number of good tools for FFI, so > there really is no point in trying to support SWIG. I agree with Ivan, let's drop it. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Add debug build hint, register debugbuild feature
Hi,
maybe the following is useful to you as well. The small patch registers
the debugbuild feature and also shows it in the banner used by csi. I am
not sure whether this will have funny effects when cross compiling but
I have not found issues so far in my daily usage (w/o cross
compilation).
What do you think?
If you don't like that let's just forget about it. There is no need to
paint the shed again over this.
Cheers,
Christian
>From 4eb13b3d7ae3d29f93cf05a99bff72bbc37a1533 Mon Sep 17 00:00:00 2001
From: Christian Kellermann
Date: Mon, 13 Apr 2015 12:13:55 +0200
Subject: [PATCH] Add debug build hint, register debugbuild feature
This will add ' ** DEBUGBUILD **' to the version line of the banner, as
in "Version 4.9.1 (rev 39b1a12) ** DEBUGBUILD **".
This patch also registers the 'debugbuild hint.
---
library.scm | 4
1 file changed, 4 insertions(+)
diff --git a/library.scm b/library.scm
index fb85c86..1a5d2fa 100644
--- a/library.scm
+++ b/library.scm
@@ -3713,6 +3713,7 @@ EOF
"Version " ##sys#build-version
(if ##sys#build-branch (string-append " (" ##sys#build-branch ")") "")
(if ##sys#build-id (string-append " (rev " ##sys#build-id ")") "")
+#+debugbuild " ** DEBUGBUILD ** "
"\n"
(get-config)
(if (zero? (##sys#size spec))
@@ -3761,6 +3762,9 @@ EOF
(when (##sys#fudge 39) (set! ##sys#features (cons #:cross-chicken ##sys#features)))
(when (##sys#fudge 3) (set! ##sys#features (cons #:64bit ##sys#features)))
+#+debugbuild
+(set! ##sys#features (cons #:debugbuild ##sys#features))
+
(set! ##sys#features
(let ((major (##sys#string-append "chicken-" (##sys#number->string (##sys#fudge 41)
(cons (##sys#->feature-id major)
--
1.9.2
--
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Any thoughts on performance woes?
* Felix Winkelmann [150407 09:44]: > This is a terribly written program. It uses 3-element lists as vectors > (including higher-order "vector" arithmetic using "map") and allocates > like hell. The compiler can not do much with this code, and it > produces CPS calls everywhere. After reading the posts in this thread I wondered how I would have done it. And to be honest, while my code may not be as bad as this *cough* one thing that always puzzles me is a way to tell *why* a given program is slow. I just had this crazy idea of new tooling that would help the curious programmer to find the line of code that triggers a lot of allocation, or find the line of code that causes a lot of GCs. How about collecting ideas like this and find a way to test these against real code at the next meetup? While this might not fend of trolls, this would help the more dedicated people improve their code for CHICKEN. Just some thoughts of cause, no real code to show (yet?)... All the best, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Any thoughts on performance woes?
* Felix Winkelmann [150407 10:41]: > But I'm sick and tired of people throwing badly written code into the > net and making gross assumptions about implementation performance. The > possible options, the search-space available is massive and a little > difference in programming style can make a vast difference in > performance. > > Somehow there seems to be a large number of trolls that use some > ridiculuous piece of code, run it with a handful of implementations > (of course using suboptimal optimization options, since they really > don't know what they're doing) and then generalize their results > without the slightest bit of sense. Nowadays anyone who knows how to use a stop watch (or the modern equivalent time(1)) on some code (sometimes the first they write in a new language) tends to publish the results as a generalized benchmark. People have argued like this for ages, it's the all preserving google cache that shows them all in your face at once if you ask for it. For my personal reading habit I will quickly decide not to read an article/post if it contains "benchmark" or "performance" on a topic I am truly interested in. Unless I still do of course :) > That is (among a few other reasons) why I don't do much Scheme or Lisp > programming anymore - thinking about the community, reading all this > bullshit makes me sick. comp.lang.lisp/scheme is in ruins for most things. But I would not say that the 6-7 (regular) abusive posters there define the "community". Driven by countless snobbish books and articles the (passive/)agressive tone towards others seems to be *part* of the culture. But I think this is somewhat changeing albeit slowly. This fine community and its open attitude is one example but I have found guile people and others equally attitude free (with exceptions on all sides of course, but most of the active projects strive for a friendly atmosphere). After all who wants to spend their free time around abusive assholes? So "don't despair" as a compiler once said, it's a nice day outside and there's always enough bad code left to be laughed at (or deleted) tomorrow. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Big Chicken?
Daniel Leslie writes: > I've been working on improving editor support for Chicken lately. With the > (laudable) efforts to remove units from core underway it struck me that > there may be opportunity for improvement in the other direction. > > While reducing Chicken core to its essential components is desirable I > would like to think that the Chicken distribution, which contains more than > core, would be somewhat of a 'batteries included' package. At least insofar > as what is common to package with language distributions these days. IE, a > powerful debugger, a utility to fetch documentation, and a powerful set of > tools to explore the language within the REPL. > > With that in mind, and acknowledging that perhaps it's a little > self-serving, I would like to propose that the following Eggs be shipped > within the standard Chicken distribution: > >- apropos >- chicken-doc >- trace > > Any thoughts? Or is this out of the question? There is already an egg called big-chicken, which is basically a meta package that grabs a whole lot of eggs and reexports them when you say (use bigchicken). Maybe this already does scratch the itch you have if we amend that. And I doubt anyone would object to that. Adding these things to core make it more difficult for us to get rid of them or replace them with better parts later on. We already are very conservative when it comes to deprecating things and adding more that's not based on a technical decision just increases our maintenance burden I think. So, while I think the proposal is legitimate the core is not the right place. After all doing a chicken-install bigchicken after installing chicken does give you the same benefit. If you want you can prepackage those eggs in a chicken installer for your users. I think the IUP windows installer does something like this already. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CHICKEN in production
"Jörg F. Wittenberger" writes: > It's about 70KLOC of code (roughly doing what Ethereum will do once > the latter works, just about 20 times a fast [if Ethereum switches to > 12seconds per block as they are planning, otherwise it's even faster]) > we are talking about. > > (Not to mention that I'd like to cut out parts of those 70K, but I'd > rather get it to run on any version of an unmodified chicken first.) How big are the actual changes to CHICKEN and which versions are they based on? My offer of aiding you in getting these up in proper patches for master still stands... Cheers, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CHICKEN in production
"Jörg F. Wittenberger" writes: > Since chicken 5 is already there (and I'm depending on the fixes to > the current version to run our code at all, which forces more work to > set up a "compile your modified chicken" build for the time being), I > rather try porting those fixes into chicken 5, skipping the double > effort. > > For this I'd need to be able to run chicken 5 with no NULL checks > against strings as those still triple as both blobs and UTF-8 strings > in our code base. And I can't possibly a) follow all those changes to > chicken 5 b) find a solution to possibly wrong uses of those new > strings in our code c) port those fixes into chicken 5. I am sorry I could not follow you there. So you are saying you have fixes for chicken core which you seem to be worthy of including in CHICKEN but want that to be part of CHICKEN-5. But that needs reworking your patches, which you currently don't have energy for. Am I reading this correctly? Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CHICKEN in production
Oleg Kolosov writes: > We also struggled with posix and process control functions a lot (long > story), trying to be functional here backfires badly, so we ended up > with straightforward and ugly code (looking like verbose C with > parentheses), replacing some functions from standard library (namely > process-run) and customized error handling. Is this something you find useful to have in general? Maybe we can discuss your diffs if your contract permits that? Congratulations to your success and product launch! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Eggification & static linking
Evan Hanson writes: > Hi hackers, > > As core units are eggified, the ability to build statically-linked > programs that use their features is going, too. I think it would be good > to include an object along with the other files installed for each of > the units that have been ripped out of core, so that users can at least > point a linker at them manually to preserve any static builds they had > on CHICKEN 4. This is simple for the newly-moved core units as they > don't have any dependencies. Objections? Sounds like a good idea to me! Thanks, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
Felix Winkelmann writes: > The "foreign-declare" syntax expands into "(declare (foreign-declare > ...))". Oh *duh* ;) Thanks, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
Felix Winkelmann writes: > It includes literal C code directly in the code generated by the compiler. > There are a couple of helper functions and macros in there. You can ignore it, > just leave the foreign-declaration as it is. I just wondered whether pulling it out of the declare makes any difference. A diff between the generated C files showed no difference. Mind you I have no intention to change that if it has some subtle implications, I just want to understand it. It looked like an oversight to me. > "disable-interrupts" is needed to avoid context-switches inside the > scheduler code. "unsafe" squeezes out a bit more speed. The "not > inline" declaration for ##sys#interrupt-hook is needed to avoid that > the compiler inlines calls to this procedure (this may not be > necessary here, but since it is a hook function, we don't want the > compiler to make now (or in future) any assumptions about optimizing > accesses to it. Consider this the equivalent of a "volatile" declaration > in C.) Thank you for the explanation! Kind regards, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
Felix Winkelmann writes: >> To hide all the other helper procedures and to be able to replace >> it with something else. As it is now ##sys#schedule is already >> available so I don't see any harm in this. Maybe we have different >> expectations about the modularisation of core? > > We do, it seems. > > Can you describe in more detail what you are trying to do? Sure! My idea has been that we will wrap all internal "functinal blocks" into modules, so that we have a uniform way of controlling access and immediately see where a particular procedure is used in core. This might be tedious or even busy work but I think we could benefit from that. I did not intend to make this available to the user of fixate the API in any way. We still will be free to change anything at will, but we had a couple of bugs where we forgot to include this identifier or the other in the declare statements. At least this way you will get the (annoying) unbound symbol error / warning when compiling, so I think that's a plus. By speaking of the scheduler.scm: There's a foreign-declare statement *within* the (declare) clause. Does that work and what does it do? Kind regards, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
* Felix Winkelmann [140912 12:19]:
> What is the intention behind a scheduler module? There is only one
> procedure ("##sys#schedule"), which should definitely not be exported.
To hide all the other helper procedures and to be able to replace
it with something else. As it is now ##sys#schedule is already
available so I don't see any harm in this. Maybe we have different
expectations about the modularisation of core?
--
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
* Felix Winkelmann [140912 12:11]: > From: Peter Bex > Subject: Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69 > Date: Fri, 12 Sep 2014 11:40:17 +0200 > > > On Fri, Sep 12, 2014 at 10:39:59AM +0200, Felix Winkelmann wrote: > >> Hello! > >> > >> > >> This patch removes support for srfi-18 and srfi-69. I had to remove > >> some tests as well, specifically those that use threads. > > > > This seems like a bad idea. These tests are there because we've had > > very hairy problems with the scheduler in the past. Is it possible to > > keep the tests, using lower-level primitives? > > I have moved the last remaining tests (signal-tests.scm) into the > srfi-18 test suite, so all tests remain. I guess the underlying issue is the question: "How do we test the scheduler now?" And I think the answer to that is simply new tests. I am in the process of preparing a scheduler module, so maybe that also will make things a bit easier. I am in favor of pushing this patch. Peter, what do you think? Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
* Felix Winkelmann [140912 10:40]: > Hello! > > > This patch removes support for srfi-18 and srfi-69. I had to remove > some tests as well, specifically those that use threads. > > I will also move the eggs into the release/5 branch, together with > most tests that have been removed from the core test suite. Does it make sense to keep the scheduler in core then? Or in other words, do we need to have an "internal/inofficial/##sys#secret#" thread api for it to make sense? I don't fully understand the implications of the srfi-18 removal. Please enlighten me on that! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] remove memory-mapped-files, object-eviction, queues and binary-search from core
* Felix Winkelmann [140911 18:52]: > Hello! > > > Attached is a patch for the chicken-5 branch that completes the recent > CR about removal/eggification of some core stuff. I have pushed it to chicken-5. Thank you! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH(5)] remove memory-mapped-files, object-eviction, queues and binary-search from core
* Felix Winkelmann [140911 18:52]: > Hello! > > > Attached is a patch for the chicken-5 branch that completes the recent > CR about removal/eggification of some core stuff. > > I have moved the eggs into the release/5 branch. > > Should the documentation go into .../wiki/eggref/5 ? That makes sense to me. Cheers! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Master has been merged into chicken-5 branch
* Mario Domenech Goulart [140911 16:20]: > 4.x) and merging them into chicken-5. The rationale for this is: > > * We have a long road to CHICKEN 5 > > * CHICKEN 5 will be smaller, with less code, so it's easier to target > CHICKEN 4 and remove code that don't apply to CHICKEN 5; than submit > patches to CHICKEN 5 and backport them to CHICKEN 4 -- patches that > target CHICKEN 5 may be incomplete for CHICKEN 4. > > Does that make sense? Sounds reasonable, I agree! > For the sake of clarity and organization, I propose that patch > submissions exclusive for chicken-5 explicitly indicate that (e.g., in > the subject header). Ack! Thanks for your feedback, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] Master has been merged into chicken-5 branch
Hi hackers, I have just merged the last master commits into chicken-5. The idea is that we will do a final 4.10 release and then continue to work on the chicken-5 branch which could be merged back into master then. So for newer patches you should base them on the chicken-5 branch. Bugfixes worth of including into 4.10 will be backported from there. What do you think? Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Evaluate length/##sys#length subforms when specializing for null
Hi Evan, I have pushed all these. Thanks, Christian * Evan Hanson [140909 11:50]: > --- > types.db |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/types.db b/types.db > index 2621686..2b6c85b 100644 > --- a/types.db > +++ b/types.db > @@ -156,11 +156,11 @@ > (##sys#list (#(procedure #:pure) ##sys#list (#!rest) list)) > > (length (#(procedure #:clean #:enforce) length (list) fixnum) ; may loop > - ((null) '0) > + ((null) (let ((#(tmp) #(1))) '0)) > ((list) (##core#inline "C_u_i_length" #(1 > > (##sys#length (#(procedure #:clean #:enforce) ##sys#length (list) fixnum) > - ((null) '0) > + ((null) (let ((#(tmp) #(1))) '0)) > ((list) (##core#inline "C_u_i_length" #(1 > > ;; these are special cased (see scrutinizer.scm) > -- > 1.7.10.4 > > > ___ > Chicken-hackers mailing list > Chicken-hackers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers * Evan Hanson [140909 11:51]: > Previously, if typevars were given in a polymorphic type specification > but none of them were actually used within its body, type simplification > would still produce a "forall" type, e.g. `(forall () list)` where > simply a `list` would do. This patch fixes these cases by only keeping > the "forall" when at least one typevar is used within a type's body. > --- > scrutinizer.scm |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scrutinizer.scm b/scrutinizer.scm > index c437933..77b14f5 100644 > --- a/scrutinizer.scm > +++ b/scrutinizer.scm > @@ -1389,7 +1389,7 @@ > (cdr e))) > (else t) > (let ((t2 (simplify t))) > - (when (pair? typeenv) > + (when (pair? used) > (set! t2 > `(forall ,(filter-map >(lambda (e) > -- > 1.7.10.4 > > > ___ > Chicken-hackers mailing list > Chicken-hackers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers * Evan Hanson [140909 11:52]: > As with list/##sys#list. > --- > types.db |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/types.db b/types.db > index 2621686..9575a1b 100644 > --- a/types.db > +++ b/types.db > @@ -571,8 +571,8 @@ > (vector-set! (#(procedure #:enforce) vector-set! (vector fixnum *) > undefined)) > > ;; special cased (see scrutinizer.scm) > -(vector (#(procedure #:clean #:clean) vector (#!rest) vector)) > -(##sys#vector (#(procedure #:clean #:clean) ##sys#vector (#!rest) vector)) > +(vector (#(procedure #:pure) vector (#!rest) vector)) > +(##sys#vector (#(procedure #:pure) ##sys#vector (#!rest) vector)) > > (vector-length (#(procedure #:clean #:enforce) vector-length (vector) fixnum) > ((vector) (##sys#size #(1 > -- > 1.7.10.4 > > > ___ > Chicken-hackers mailing list > Chicken-hackers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers * Evan Hanson [140909 11:53]: > --- > scrutinizer.scm | 75 > +-- > 1 file changed, 1 insertion(+), 74 deletions(-) > > diff --git a/scrutinizer.scm b/scrutinizer.scm > index c437933..2221aac 100644 > --- a/scrutinizer.scm > +++ b/scrutinizer.scm > @@ -30,7 +30,7 @@ > procedure-type? named? procedure-result-types procedure-argument-types > noreturn-type? rest-type procedure-name d-depth > noreturn-procedure-type? trail trail-restore walked-result > - typename multiples procedure-arguments procedure-results > + multiples procedure-arguments procedure-results > smash-component-types! generate-type-checks! over-all-instantiations > compatible-types? type<=? match-types resolve match-argument-types)) > > @@ -895,79 +895,6 @@ >(cute set-car! (cddr t) <> > > > -;;; Converting type into string > - > -(define (typename t) > - (define (argument-string args) > -(let* ((len (length (delete '#!optional args eq?))) > -(m (multiples len))) > - ;;XXX not quite right for rest/optional arguments > - (cond ((memq '#!rest args) > - (sprintf "~a or more arguments" len)) > - ((zero? len) "zero arguments") > - (else > - (sprintf > - "~a argument~a of type~a ~a" > -len m m > -(string-intersperse (map typename args) ", ")) > - (define (result-string results) > -(if (eq? '* results) > - "an unknown number of values" > - (let* ((len (length results)) > -(m (multiples len))) > - (if (zero? len) > - "zero values" > - (sprintf > - "~a value~a of type~a ~a" > - len m m > - (string-intersperse (map typename results) ", ")) > - (case t > -((*) "anything") > -((char) "character") > -(else > - (cond ((
Re: [Chicken-hackers] [PATCH] Fix #1136 and a question about type specialisation
Peter Bex writes: > The attached patch is an updated version which also changes the > implementation of C_copy_ptr_memory to use memmove(). I have pushed this version to master and stability/4.9.0. Thank you! Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Remove ##sys# prefix from lambda-info names of library procedures
John Cowan writes: > Felix Winkelmann scripsit: > >> They can't be deprecated, as these procedures are used internally. > > I know that that is so, but is there any reason why it must be so? > Could not internal use also be converted from ##sys#error to error, etc.? Well deprecation is intended to give users of said procedures a heads up and allows them to change their code in advance. Since this is all internal API, I don't see the merit of such a process. Maybe it's nitpicking but I call this conversion simple refactoring which by itself also comes with costs and effort. >> But user/egg code should still not use it, of course. > > A longer-term effort would be to migrate these names out of the > "chicken" module and into a "##sys" module, so that they are only > imported explicitly. This may be possible once the core has been confined inside a namespace which is a lenghty goal as another thread on this list has elaborated. Kind regards, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Remove ##sys# prefix from lambda-info names of library procedures
Felix Winkelmann writes: > From: Peter Bex > Subject: Re: [Chicken-hackers] [PATCH] Remove ##sys# prefix from lambda-info > names of library procedures > Date: Wed, 23 Jul 2014 10:24:59 +0200 > >> On Wed, Jul 23, 2014 at 01:20:16AM -0700, Evan Hanson wrote: >>> On 2014-07-23 10:06, Peter Bex wrote: >>> > This change doesn't make much sense to me unless we also deprecate >>> > the ##sys#-prefixed versions. ##sys#error sounds more "internal" or >>> > "primitive" than "error", so (to me) it makes more sense to have >>> > error be an alias of ##sys#error, instead of the other way around. >>> >>> I don't think we should deprecate the prefixed versions -- this is just >>> intended to make e.g. REPL results print more cleanly, and to make e.g. >>> introspection slightly nicer when querying `procedure-information`. The >>> result is the same from core's point of view, but the user gets a >>> cleaner experience. >> >> Thanks for providing a motivation for this change. That makes sense >> indeed. Any objections from other chicken hackers? > > No, this makes sense. I have pushed this patch. Thank you! ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] library unit restructuring
Felix Winkelmann writes: > Regarding the eggification of binary-search, memory-mapped-files and > queues - are we all agreeing about this? Does this require a > change-request? It may break existing code, so I guess we would need a CR. But I have a feeling that this is just a red tape formality now. I am in favour of your proposal. Kind regards, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] mmap
Felix Winkelmann writes: > From: Andy Bennett > Subject: mmap (was: Re: [Chicken-hackers] library unit restructuring) > Date: Wed, 09 Jul 2014 14:56:38 +0100 > >> Hi, >> >>> - memory-mapped-files >> >> Without wishing to hijack the entire thread, as an aside, is there any >> way of making memory mapped files play nicely with the CHICKEN scheduler >> and threading model? It's possible for memory mapped files to cause a >> page fault which will then wait for I/O and, as I understand it, that >> will block the entire runtime. > > Since nobody replied to this - I wouldn't know how this is done. I > guess there is some UNIX arcana that allows one to implement > non-blocking behaviour. As memory access will cause the blocking, we > can probably not check for this via poll/select. Do you have any > information about this? Is it possible to test whether a page is in > memory, and whether one can do the equivalent of a poll/select on > this? IIRC mmap's flags MAP_NONBLOCK and MAP_POPULATE are linux specific and don't exist in all our other platforms, notably the *BSDs. Since mmap calls return a pointer to memory, the usual select/poll syscalls cannot be applied to it. (Also note that MAP_POPULATE is ignored in recent kernels even). Andy, can you elaborate on the blocking scenario you are seeing? HTH, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables
... also in the stability branch now. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1133
Peter Bex writes: > Hi all, > > Here's a pretty simple patch for #1133. It segfaults with a regular > build, but a DEBUGBUILD says exactly what's wrong: Pushed, thanks. Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables
Thanks, I have pushed the patch. Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables
Felix Winkelmann writes: >> Those two are a constant source of frustration :( I think we can best >> ignore them for now, as they're causing trouble either way: even providing >> them by default in the platform Makefiles can be problematic (see Haiku). > > Please note that these two options are required. I had cases where > strict aliasing caused code to fail and -fwrapv disables some > questionable optimizations with regard to signed integer overflow. C > compilers get more and more aggressive, cutting corners wherever > possible by exploiting undefined (but not necessarily unreaasonable) > behaviour. Well in the particular case of haiku or OpenBSD before that, the compiler simply has been too *old* to provide these options. So even if the troublesome optimisations are enabled, that way of disabling them does not work. Kind regards, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Remove several deprecated things which should not cause too much trouble
Peter Bex writes: > On Tue, Jun 10, 2014 at 09:05:25AM +0200, Christian Kellermann wrote: > >> Peter Bex writes: >> >> Must not be paying attention. Only marked in the source? >> > >> > Yeah, that's possible; I don't know exactly when it was marked as >> > deprecated. Sorry for that, we'll try to announce it in the NEWS file >> > but this looks like a historical oversight. >> >> Also with the new deprecation patch >> f47e7cc5ff02acdf93f52bf76444366e8d99145d, it should now be possible to >> generate a warning for this when compiling. > > Not really; this is a C function. Though this reminds me, I think I > proposed generating deprecation warnings for C code (using __attribute__) > before, but I can't seem to find that thread anymore. I think Felix > shot down this proposal because he thought that would be too annoying > or something. Sounds good to me, in the end this *should* be annoying. Pain seems to drive most development these days :p ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Remove several deprecated things which should not cause too much trouble
Peter Bex writes: >> Must not be paying attention. Only marked in the source? > > Yeah, that's possible; I don't know exactly when it was marked as > deprecated. Sorry for that, we'll try to announce it in the NEWS file > but this looks like a historical oversight. Also with the new deprecation patch f47e7cc5ff02acdf93f52bf76444366e8d99145d, it should now be possible to generate a warning for this when compiling. Kind regards, Christian ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Remove several deprecated things which should not cause too much trouble
* Peter Bex [140607 22:27]: > Hi all, > > The attached patch removes the majority of things that were officially > deprecated or just marked OBSOLETE. This is just the low-hanging fruit. > > I've kept around a few compiler flags and the ##sys#check-port-mode and > ##sys#check-port* as well as C_pair(). There are a few eggs still using > the mentioned ##sys#check procedures and C_pair() and even core is still > using C_pair in a few places! > > We can remove those after the eggs have been fixed and core has been > changed and a new dev snapshot tagged. > > I've "undeprecated" C_mutate, because it is actually documented and > performs a useful function. I think it's better to deprecate C_mutate2 > instead: it would be silly to have C_mutate2 be the official API! > Eventually I'd like to get rid of a few more "2" functions and macros, > but this will take some time. I don't want to break too much in one go! > > Finally, we need to start thinking about actually getting rid of the > deprecated ~ and $VAR expansion in pathnames (ticket #1001). I have pushed this and will take care of the C_pair usage in core. Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Bound read-u8vector! to dest vector's size when no length is given
* Evan Hanson [140518 05:41]: > Hi hackers, > > I believe issue #1124[1] is due to a missing bounds check in > `read-u8vector!`. Looks like it, thanks I have pushed it. This awesome explanation of the bug should have been part of the commit :) Thanks! Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] negative file-position seek
Hi all, I have pushed this patch (modulo NEWS rearrangements) Thank you. -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix "check" targets
* Peter Bex [140505 12:20]: > Hi all, > > Here's a simple patch to fix a simple problem: Pushed, thanks. -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #983 trivially by restoring the vector-like? procedure
* Peter Bex [140502 16:43]: > Hi all, > > The attached patch is really trivial. It re-adds a procedure that was > removed but is still documented. I think it can be of some use, so > it may be a good idea to re-add it. This should fix #983. Indeed, pushed. Thanks, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] runtime.c: remove unused FILE_INFO_SIZE constant
Hi Mario, * Mario Domenech Goulart [140328 15:13]: > Hi, > > Please, review the attached patch. Looks trivially ok to me, make check works. I have pushed it. Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] runtime.c: remove unused FILE_INFO_SIZE constant
* Christian Kellermann [140328 15:39]: > Hi Mario, > > * Mario Domenech Goulart [140328 15:13]: > > Hi, > > > > Please, review the attached patch. > > Looks trivially ok to me, make check works. > > I have pushed it. > Mario has done so himself in the meantime, please ignore. Nonetheless this trivial patch works ;) -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Use local -rpath in tests [was: Re: [PATCH] Fix finalizer issue on non-GCable constants]
* Peter Bex [140320 22:05]: > On Wed, Mar 19, 2014 at 02:34:39PM +0100, Christian Kellermann wrote: > > This triggered a bug in make check due to me not installing chicken, > > so our install-less make check is not complete. > > We both did the wrong test: we ran with a *nonexistent* PREFIX. Because > the runtest.sh script invokes ../csc, which builds all the test programs > with flags configured for $PREFIX, it will bake in an rpath in the > binaries. Indeed, thanks for the fix. pushed. Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix finalizer issue on non-GCable constants
* Peter Bex [140317 21:38]: > Hi all, > > The attached patch fixes the problem from subject, as described here: > http://lists.nongnu.org/archive/html/chicken-users/2014-03/msg00088.html > > It also cleans up the code a little bit by re-using well-named C > functions instead of repeating the same inline and C preprocessor-heavy > checks which required comments to make sense of them. > > Felix has provided feedback on this patch, and it has been tested by > Pluijzer. I have redone the Acknowledgement patch manually as it didn't apply, but it looks good to me. This triggered a bug in make check due to me not installing chicken, so our install-less make check is not complete. A different patch should fix this. Thanks, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Patch] Fix #1106
* Peter Bex [140315 13:50]: > Thank you. I checked and there's still a small problem with this > patch: it will always install the entire dependency chain from > scratch, even if some eggs have already been installed. Yes, I have been aware of that. I guess this is an uncommon use case though, since I would expect that development happens as usual and then to bundle your application you run chicken-install -deploy. The only downside I see here is that we reuse the usual code path and recompile, instead of just copying the necessary files over from the local repository. So I guess we are on the same page here. I am not sure whether the current db entries in a chicken repository are sufficient to extract already installed files and copy them to the deployment target. I will have to investigate on this. Maybe someone else here knows more without digging too deep into it? Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Patch] Fix #1106
* Christian Kellermann [140312 15:47]: > Hi there, > > thanks to Andy I have become aware of an issue with chicken-install > -deploy which should be fixed in this patch. For details see below. > Please note that I have not tested this against a cross chicken > scenario but I don't see why this should break. I got one positive report from user caolarm on #chicken. Has anyone else tried this? Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1057: make check works without having to install CHICKEN
* Peter Bex [140313 22:10]: > Hi all, > > Here's the final patch for #1057; this allows running the test suite > without first installing CHICKEN (a very long-standing feature request > from package maintainers). This should also make it less annoying for > CHICKEN hackers to quickly test some modifications. I have pushed this, awesome. Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [Patch] Fix #1106
Hi there, thanks to Andy I have become aware of an issue with chicken-install -deploy which should be fixed in this patch. For details see below. Please note that I have not tested this against a cross chicken scenario but I don't see why this should break. HTH, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. >From 67ea739be4ba6cd2366695950a2dfcd1d6da0686 Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Wed, 12 Mar 2014 15:42:29 +0100 Subject: [PATCH] Fix bug #1106 chicken-install -deploy dependencies This commit will make chicken-install ignore the local egg db while traversing the dependency list when in deployment mode. This results in all dependencies installed in the deployment directory, instead of just the explicitly stated one in the egg's meta file. I have tested this with a spiffy example and chicken-install -deploy -p $(pwd)/t spiffy Which installs all dependencies of spiffy and intarweb. --- chicken-install.scm | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/chicken-install.scm b/chicken-install.scm index 8bfae97..3cf85a9 100644 --- a/chicken-install.scm +++ b/chicken-install.scm @@ -236,8 +236,9 @@ (define (check-dependency dep) (cond ((or (symbol? dep) (string? dep)) (values - (and (not (ext-version dep)) -(->string dep)) + (if *deploy* (->string dep) + (and (not (ext-version dep)) +(->string dep))) #f)) ((and (list? dep) (eq? 'or (car dep))) (let scan ((ordeps (cdr dep)) (bestm #f) (bestu #f)) @@ -260,7 +261,7 @@ ((and (list? dep) (= 2 (length dep)) (or (string? (car dep)) (symbol? (car dep (let ((v (ext-version (car dep -(cond ((not v) +(cond ((or *deploy* (not v)) (values (->string (car dep)) #f)) -- 1.8.5.2 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Disable deployment tests on Hurd
* Peter Bex [140224 22:00]: > Hi all, > > Here's a simple patch to disable the deploy tests on GNU Hurd. > Apparently, this OS really identifies its kernel as "GNU" :) It does and I have pushed the patch 10 hours ago (or so). Sorry for the late reply, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #877, hopefully
* Peter Bex [140213 21:28]: > Hi all, > > I think I finally figured out the problem of #877; because it's sending > alternate signals from threads, some signals were probably arriving > while the child process' handler was adding another signal to the queue. > This would in turn cause the position in the queue to get corrupted. > > At least, I think that's what was happening... Concurrency makes my > brain hurt. I ran a few tests and I can't trigger the signal-test error > anymore. But that was also the case with my previous patch, so it could > be dumb "luck". Let's push it and see if Salmonella starts complaining. > It would also be great if everyone tests it on their multi-CPU boxes. Makes sense to me, I have pushed it. Thank you! -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Replace unsafe string functions with their safer counterparts
* Peter Bex [140203 22:30]: > On Thu, Jan 23, 2014 at 12:28:01PM +0100, Christian Kellermann wrote: > > Hi all, > > > > I propose the following patch. It has been tested on OpenBSD and > > Linux. Should work without troubles on all other OSes as well. > > Please give it a try. > > Hi Christian, > > After some reconsideration, I think this is probably a good idea. > The big swath of OpenBSD license text for these rather small functions > in our chicken.h really disagreed with me (the license is barely smaller > than the code!), so I looked around a bit for public domain > implementations and found a few. I decided to use the one by > C.B. Falconer, as it seems to have seen the most review. Upon further reflection on this issue, I think I have just started a needless bikeshed on this. If you think the PD version is better I have no further objections to it. I have pushed the patch as you posted it. Thanks for taking the time to review and amend the changes. This makes me a happier OpenBSD user. I got taken away for the sake of arguing. Let's not repeat this again. Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Replace unsafe string functions with their safer counterparts
* Christian Kellermann [140204 10:05]: > Hi Peter, > > please find my comments inline. > > * Peter Bex [140203 22:30]: > > After some reconsideration, I think this is probably a good idea. > > The big swath of OpenBSD license text for these rather small functions > > in our chicken.h really disagreed with me (the license is barely smaller > > than the code!), so I looked around a bit for public domain > > implementations and found a few. I decided to use the one by > > C.B. Falconer, as it seems to have seen the most review. > > Thanks for considering the patch and taking the time to go through > it. > > If you are concerned with the big license in the code, I will move > it to LICENSE. I don't know why exchanging the code solves > this issue, while an even simpler change would do so as well. > > I even think the PD version of strlcat has an issue: It assumes > that the size argument for the dst string is actually larger than > the strlen(dst). I don't see why this should be a valid assumption > as this does again provide a potential pitfall when using it. > > The OpenBSD version does not trust the size parameter and adjusts > the length first, then copying the data. please ignore the last two paragraphs, I need more coffee first. Sorry for the noise. -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Replace unsafe string functions with their safer counterparts
Hi Peter, please find my comments inline. * Peter Bex [140203 22:30]: > After some reconsideration, I think this is probably a good idea. > The big swath of OpenBSD license text for these rather small functions > in our chicken.h really disagreed with me (the license is barely smaller > than the code!), so I looked around a bit for public domain > implementations and found a few. I decided to use the one by > C.B. Falconer, as it seems to have seen the most review. Thanks for considering the patch and taking the time to go through it. If you are concerned with the big license in the code, I will move it to LICENSE. I don't know why exchanging the code solves this issue, while an even simpler change would do so as well. I even think the PD version of strlcat has an issue: It assumes that the size argument for the dst string is actually larger than the strlen(dst). I don't see why this should be a valid assumption as this does again provide a potential pitfall when using it. The OpenBSD version does not trust the size parameter and adjusts the length first, then copying the data. > Finally, to make it work on MingW I had to fix quite a few more things > than I expected, so I present my altered copy containing these fixes for > re-review: > > - The C_setenv fallback implementation for when C_GNU_ENV is unset >(a bit of a bogus check, if you ask me) contained swapped length >and buffer arguments, causing a segfault upon the first (setenv ) >call I made. I fixed the swapped calls and moved it to >posix-common.scm because Windows uses the exact same fallback >implementation (and C_GNU_ENV is unset in MingW). The Scheme side >of these functions is also completely identical, so I moved it >as well - this seems like a huge change, but it should prevent future >divergence. Thank you for testing it on windows! The refactoring should be a different patch IMHO that should go in before. Mixing these things does not make it easier to test, and this is quite a change and deserves more than a side note in a commit with a different topic. > - The Windows implementation of the POSIX unit broke due to the change >in foundfile()'s "prototype" which is now expected by the Scheme >code in posix-common, but wasn't carried on to posixwin.scm. >I moved your version to posix-common.scm as the original macros >were identical across both platform-specific files. Same for >C_opendir, C_closedir and C_readdir. > - In fact, posixwin.scm still contained several calls to C_strcat() and >C_strcpy() (which you removed from chicken.h), so after fixing the >compilition, it failed to to link. I've updated it to use the safe >versions too. Again thanks! I did not test this on windows due to lack of access. I deliberately removed those references so accidental usage will fail hard and reliably for exactly this scenario. I also found the string functions "hidden" in the TCP unit this way. > - You signed off on your own patch :) I removed this line from the >commit message so you can sign off again, on my modifications. That >way, we'll know that the change which carries both our signoff lines >is the correct one. Yes I signed it off as I wrote it and tested it. Sorry, this habit leaks in from other communities. I will try to refrain from doing so in CHICKEN in the future. As I see it apart from the POSIX unit issue by default the brought in replacements are used, so I won't expect issues with that. So my proposal is: I will rework my patch and move the license into LICENSE, you will move the refactoring of posix into a separate patch and we will throw the code into the salmonella pit and ask for testers? Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Enable -deploy on NetBSD [was: Re: [PATCH] Enable -deploy on OpenBSD]
* Thomas Chust [140201 20:48]: > the longer that disjunction of conditions gets, the more I feel that > something like > > (if (and deployed (memq (software-version) '(freebsd openbsd netbsd))) > ...) > > would look nicer ;-) I have pushed Peter's patch with this small correction. Thank you both! Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pastiche db drop
* John Cowan [140203 15:14]: > Alaric Snell-Pym scripsit: > > > Bah! Why did the sql engine (sqlite?) not reject that as a syntax error? > > Sqlite does reject it: > > [cowan@vrici ~]$ sqlite3 > SQLite version 3.8.0.2 2013-09-03 17:11:13 > Enter ".help" for instructions > Enter SQL statements terminated with a ";" > sqlite> delete from pastes where hash > "6e4bc38a652603314074d80094b39197fee50ac2"; > Error: near ""6e4bc38a652603314074d80094b39197fee50ac2"": syntax error I don't know exactly what I typed, the connection has been seriously lagged. I won't type stuff like this directly on the production thingy again ;) Lesson learned. Thanks for the support! Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] pastiche db drop
* Christian Kellermann [140203 10:55]: > I had a copy of the db which has been taken around december 9th > 2013 and copied that over to the server. Thanks to Mario we now have a backup dated Feb 1st back in action. Thanks so much! -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] pastiche db drop
Hi there, I have just dropped pastiche's database accidentally by omitting an equal sign during spam deletion. That is: delete from pastes where hash "6e4bc38a652603314074d80094b39197fee50ac2"; I had a copy of the db which has been taken around december 9th 2013 and copied that over to the server. I will setup a cronjob to rotate snapshots of the db daily, holding 5 days of copies, so next time we won't lose as much data. I apologise for the troubles this causes. Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Enable -deploy on OpenBSD
Hi there, this is another patch for the OpenBSD people, that will fix deployment. The patch commit says it all (I hope). Enjoy, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu >From a95ae626f3741cca23698de84f400ce0a55fe85c Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Fri, 24 Jan 2014 15:31:42 +0100 Subject: [PATCH] Enable -deploy on OpenBSD The fix is the same as for FreeBSD. DF_1_ORIGIN has to be set and this gets done by passing the -z origin flag to the linker. With this patch the deployment test passes and OpenBSD has a full and working make check run now. --- NEWS| 2 ++ csc.scm | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index ed114c6..3743e57 100644 --- a/NEWS +++ b/NEWS @@ -50,6 +50,8 @@ and "-emit-type-file", respectively; "-n" has been deprecated. - chicken-install now also accepts full URI syntax for proxy environment variables (thanks to Michele La Monaca) + - csc "-deploy" works now on FreeBSD (thanks to Jules Altfas and +Vitaly Magerya) and OpenBSD. - Syntax - Added the aliases "&optional" and "&rest" as alternatives to "#!optional" diff --git a/csc.scm b/csc.scm index 935687f..6d1ce58 100644 --- a/csc.scm +++ b/csc.scm @@ -276,7 +276,8 @@ (list (conc "-Wl,-R\"" library-dir "\""))) (else (list (conc "-L\"" library-dir "\"" - (if (and deployed (eq? (software-version) 'freebsd)) + (if (and deployed (or (eq? (software-version) 'freebsd) + (eq? (software-version) 'openbsd))) (list "-Wl,-z,origin") '()) (cond ((get-environment-variable "CHICKEN_C_LIBRARY_PATH") => -- 1.8.4.5 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Replace unsafe string functions with their safer counterparts
Hi all,
I propose the following patch. It has been tested on OpenBSD and
Linux. Should work without troubles on all other OSes as well.
Please give it a try.
Thanks,
Christian
--
In the world, there is nothing more submissive and weak than
water. Yet for attacking that which is hard and strong, nothing can
surpass it. --- Lao Tzu
>From ffaeb3e4fb97906bc2dd92f632fa727b842f65b5 Mon Sep 17 00:00:00 2001
From: Christian Kellermann
Date: Fri, 10 Jan 2014 15:43:07 +0100
Subject: [PATCH] Replace unsafe string functions with their safer counterparts
This patch removes strcpy, strcat and sprintf usage out of core in
favor for strlcpy, strlcat and snprintf. For systems that don't
include strlcat and strlcpy in their string.h these two functions have
been imported from OpenBSD.
Systems that *do* ship these functions should declare HAVE_STRLCPY and
HAVE_STRLCAT in their chicken-config.h.
The chicken definitions for strcpy and strcat have been removed.
This has been done for the Makefile.bsd as these do ship with these
procedures.
Signed-off-by: Christian Kellermann
---
Makefile.bsd | 2 ++
chicken.h| 100 ---
library.scm | 2 +-
posix-common.scm | 2 +-
posixunix.scm| 9 ++---
runtime.c| 85 --
tcp.scm | 4 +--
7 files changed, 145 insertions(+), 59 deletions(-)
diff --git a/Makefile.bsd b/Makefile.bsd
index 0dbc247..4dd003f 100644
--- a/Makefile.bsd
+++ b/Makefile.bsd
@@ -86,6 +86,8 @@ chicken-config.h: chicken-defaults.h
echo "#define HAVE_STRERROR 1" >>$@
echo "#define HAVE_STRINGS_H 1" >>$@
echo "#define HAVE_STRING_H 1" >>$@
+ echo "#define HAVE_STRLCAT 1" >>$@
+ echo "#define HAVE_STRLCPY 1" >>$@
echo "#define HAVE_STRTOLL 1" >>$@
echo "#define HAVE_STRTOQ 1" >>$@
echo "#define HAVE_SYS_STAT_H 1" >>$@
diff --git a/chicken.h b/chicken.h
index 51adeba..296b9d6 100644
--- a/chicken.h
+++ b/chicken.h
@@ -1,3 +1,4 @@
+
/* chicken.h - General headerfile for compiler generated executables
;
; Copyright (c) 2008-2014, The Chicken Team
@@ -920,12 +921,12 @@ DECL_C_PROC_p0 (128, 1,0,0,0,0,0,0,0)
# define C_memcpy memcpy
# define C_memcmp memcmp
-# define C_strcpy strcpy
+# define C_strlcpy strlcpy
# define C_strncpy strncpy
# define C_strcmp strcmp
# define C_strncmp strncmp
# define C_strlen strlen
-# define C_strcat strcat
+# define C_strlcat strlcat
# define C_memset memset
# define C_memmove memmove
# define C_strncasecmp strncasecmp
@@ -942,7 +943,6 @@ DECL_C_PROC_p0 (128, 1,0,0,0,0,0,0,0)
# define C_fopenfopen
# define C_fclose fclose
# define C_strpbrk strpbrk
-# define C_sprintf sprintf
# define C_snprintf snprintf
# define C_printf printf
# define C_fprintf fprintf
@@ -1306,7 +1306,7 @@ extern double trunc(double);
#define C_rename_file(old, new) C_fix(rename(C_c_string(old),
C_c_string(new)))
#define C_delete_file(fname)C_fix(remove(C_c_string(fname)))
#define C_poke_double(b, i, n) (((double *)C_data_pointer(b))[
C_unfix(i) ] = C_c_double(n), C_SCHEME_UNDEFINED)
-#define C_poke_c_string(b, i, from) (C_strcpy((char *)C_block_item(b,
C_unfix(i)), C_data_pointer(from)), C_SCHEME_UNDEFINED)
+#define C_poke_c_string(b, i, from, s) (C_strlcpy((char *)C_block_item(b,
C_unfix(i)), C_data_pointer(from), s), C_SCHEME_UNDEFINED)
#define C_peek_fixnum(b, i) C_fix(C_block_item(b, C_unfix(i)))
#define C_peek_byte(ptr, i) C_fix(((unsigned char
*)C_u_i_car(ptr))[ C_unfix(i) ])
#define C_dupstr(s) C_strdup(C_data_pointer(s))
@@ -2911,9 +2911,9 @@ C_path_to_executable(C_char *fname)
pid = C_getpid();
# ifdef __linux__
- C_sprintf(linkname, "/proc/%i/exe", pid);
+ C_snprintf(linkname, sizeof(linkname), "/proc/%i/exe", pid);
# else
- C_sprintf(linkname, "/proc/%i/path/a.out", pid); /* SunOS / Solaris */
+ C_snprintf(linkname, sizeof(linkname), "/proc/%i/path/a.out", pid); /* SunOS
/ Solaris */
# endif
ret = C_readlink(linkname, buffer, C_MAX_PATH - 1);
@@ -2963,7 +2963,7 @@ C_path_to_executable(C_char *fname)
/* absolute path */
if(*fname == '/') {
fname[ i ] = '\0';
-C_strcpy(buffer, fname);
+C_strlcpy(buffer, fname, C_MAX_PATH);
return buffer;
}
else {
@@ -2971,8 +2971,8 @@ C_path_to_executable(C_char *fname)
Re: [Chicken-hackers] [PATCH] Fix for #877
* Peter Bex [140105 21:38]: > Hi all, > > I finally took a shovel and dug in deep into #877. > It's a very tricky one and I think it's been so elusive due > to the fact that the bug *probably* only crops up on machines > with multiple CPU (cores). Thanks, I have pushed it. I looked at it the time you posted this but somehow forgot to push it... Sorry, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] make check starts a.out which runs forever in the background
* Mario Domenech Goulart [140121 10:20]: > Hi Sven, > > On Tue, 21 Jan 2014 07:36:50 +0100 (CET) Sven Hartrumpf > wrote: > > > Hi all. > > > > The git version of chicken shows an annoying behavior > > for some time. > > If I run "make check", the output looks ok, but an a.out > > process runs forever in the background (100% cpu usage). > > It cannot be killed with SIGTERM, but only with SIGKILL. > > The a.out appears at the end of "make check". > > > > (32bit build on 64bit Linux.) > > Maybe it is the annoying http://bugs.call-cc.org/ticket/877 Which patch is Peter referring to in the comments? -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] make check starts a.out which runs forever in the background
* Sven Hartrumpf [140121 07:37]: > Hi all. > > The git version of chicken shows an annoying behavior > for some time. > If I run "make check", the output looks ok, but an a.out > process runs forever in the background (100% cpu usage). > It cannot be killed with SIGTERM, but only with SIGKILL. > The a.out appears at the end of "make check". > > (32bit build on 64bit Linux.) This might be a rouge test case from the thread-join! test introduced by e2700786c777b8ef353e92c66f8ccdeea7524cca. Can you disable that test and run make check again and see if it is gone then? Sorry for the inconvenience! Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Patch for FreeBSD link error
* Evan Hanson [140117 04:49]: > Thanks for reporting this (again!). I was able to duplicate it, and it > seems "-z" should indeed be passed as a linker flag; attached is a `git > am`-formatted patch that fixes the issue (it actually implements Vitaly > Magerya's suggested fix from the original thread[1]). I don't see a > reason this shouldn't have been added after that first discussion, but I > think it's probably just because a patch never bubbled up up anywhere, > so thank you. Thank you all! I have pushed the patch. Sorry for the delay, this has been on my (too deep) stack of things to look at... Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] fix: eval.scm: use soname only with when USES_SONAME present
* Kristian Lein-Mathisen [140103 15:38]: > (define dynamic-load-libraries >(let ((ext > - (if (and (memq (software-version) '(linux netbsd openbsd freebsd)) > - (not (zero? binary-version))) ; allow "configless" build /--- Can someone explain that configless build to me please? Thanks, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] [LONG] Fix (hopefully) for #1068
* Peter Bex [131229 20:12]: > Since I'm having some problems with my laptop I'm on a slow machine > right now, so I can't do extensive testing or benchmarking. It would > be great if someone looking at this patch could perform a quick > Salmonella run to see if no other eggs are broken, and run a few > benchmarks comparing it against current master or 4.8.0.5 (you could > use the one from https://github.com/mario-goulart/chicken-benchmarks). > Please remember that you should compare optimized builds. That means, > without DEBUGBUILD, because this has been changed to check more things > now. I have run the chicken-benchmarks on it and it is still in the same ballpark on my machine. ; ./run.scm Repeating each program 10 times Using /home/ckeen/chickens/master/bin/csc (1/43) 0...0s (2/43) binarytrees.0.98s (3/43) boyer...1.47s (4/43) browse..1.28s (5/43) conform.1.19s (6/43) cpstak..5.04s (7/43) ctak2.38s (8/43) dderiv..11.4s (9/43) deriv...10.81s (10/43) destructive.0.94s (11/43) div-iter0.34s (12/43) div-rec.1.31s (13/43) dynamic.1.83s (14/43) earley..0.37s (15/43) fft.0.36s (16/43) fib.1.75s (17/43) fibc15.49s (18/43) fprint..1.52s (19/43) fread...11.48s (20/43) graphs..9.26s (21/43) hanoi...5.84s (22/43) kanren..32.83s (23/43) lattice.133.53s (24/43) maze1.42s (25/43) mazefun.62.01s (26/43) nbody...47.39s (27/43) nboyer..323.02s (28/43) nestedloop..29.52s (29/43) nfa.42.13s (30/43) nqueens.0.7s (31/43) nucleic241.03s (32/43) psyntax.12.27s (33/43) puzzle..0.39s (34/43) sboyer..812.42s (35/43) scheme..0.16s (36/43) slatex..67.08s (37/43) sort1...42.38s (38/43) tak.3.96s (39/43) takl2.18s (40/43) takr5.86s (41/43) traverse2.52s (42/43) travinit0.54s (43/43) triangl.6.81s Total run time: 34m57s I have pushed this patch to master to have a full salmonella run with it. Thanks for all the bug hunting Peter! Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1080 (condition-case warnings)
* Peter Bex [131213 21:57]: > Hi all, > > As Christian rightfully noticed, we now generate spurious notices for > condition-case with normal "fallback" entries due to the change in > cond that detects clauses following an "else". > > Attached is the simplest fix I could come up with. I also made a > version which gives a friendlier notice (detection is done in > condition-case itself, so it can show the offending source clause) > but unfortunately it's a bit ugly and much longer (45 lines versus > the current 30 lines) so I decided to scrap it. After some trials by Peter to give better warnings in case the user writes two catch-all clauses, we decided on IRC that all the other approaches are way more complicated than this simple fix. After all it removes an warning the user has no influence over, but does not prevent the user to write awful code. Hence, this patch has been pushed. Thanks Peter, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #765 and a small can of worms related to error handling under Windows
* Peter Bex [131122 21:46]: > Hi all, > > See the attached patch, it kind of speaks for itself. Thanks to arthurmaciel for testing this on XP, I have verified it does not break anything on windows 7 / 8. Thanks for the patch, Peter! Pushed. -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Go back to sleep when thread-join! is called without timeout.
* Christian Kellermann [131211 10:40]: > Since I forgot the manifest again, I don't quite understand it's > use. From the makefiles I gathered that it is used on windows to > enable priviledge escalation which suppresses a warning box each > time a chicken compiled program is run. > > If that's true, I don't see why we include *every* file from our > code repository in there. > > Could someone enlighten me there? Memo to myself: It's used by the makedist.scm script to create a release tarball. Nothing to do with the windows manifest, which is a different beast. Thank you future C-Keen! Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Go back to sleep when thread-join! is called without timeout.
Hello Peter, * Peter Bex [131210 23:53]: > Thanks a lot for the patch, and the bugreport! I've pushed it, after > a few small modifications: > > - Added the new file tests/srfi-18-signal-test.scm to distribution/manifest > - Updated NEWS > - Converted []-style parens to () > - Reworked tests output a little so it's a bit cleaner (pending #1080) > - Removed the tricky shell gymnastics in favor of a simpler setitimer() >call. This should make it easier to make it work on Windows when >(if?) we figure out a way to send signals. > - Added a cond-expand check for mingw32 which stops the program on >Windows if we're on msys (which uses runtest.sh). > > Regarding that last point, I discovered too late that my other change > for the second-to-last point broke the build anyway. So I've had to > push a second commit to fix that. > > Strangely, your way of sending the signal from the shell (via a separate > shell fork which sleeps and calls kill(1)) seems to be supported by MSYS, > and a quick test on a trivial other program seems to indicate that it > _should_ work but somehow the program never sees the signal in MSYS. > It looks like it holds the execution of the backgrounded srfi-18 test > program until the sleep and wait have finished (which is exactly what we > *don't* want, of course). Sorry for your troubles and thanks for testing it on windows! Since I forgot the manifest again, I don't quite understand it's use. From the makefiles I gathered that it is used on windows to enable priviledge escalation which suppresses a warning box each time a chicken compiled program is run. If that's true, I don't see why we include *every* file from our code repository in there. Could someone enlighten me there? Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Go back to sleep when thread-join! is called without timeout.
Hi! Thanks to Michael Greenly I have the opportunity to fix a bug in thread-join!. Please see the commit message for details. Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu >From 5f4e77f4f8444878655a5046d92fd624ad262646 Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Tue, 10 Dec 2013 12:41:54 +0100 Subject: [PATCH] Go back to sleep when thread-join! is called without timeout. This patch fixes an issue discovered by Michael Greenly. When a signal handler is called a thread waiting for another with thread-join! got woken up and the code assumed this could have happened only because the other thread died or the timeout occured. Hence if the waited-for thread is not in state terminated or dead a timeout exception is thrown. With this patch the thread is put back to blocking state (for termination of the waited-for thread) if no timeout has been given. Note: This is reliably triggered only when the signal is delivered external from the CHICKEN process. The patch also refactors the code to explicitly match the expected thread states and errors out in the else clause. A test case for this situation has been added and is enabled on unix systems (a patch for the runtests.bat is missing). --- srfi-18.scm | 22 ++--- tests/runtests.sh | 6 + tests/srfi-18-signal-test.scm | 55 +++ 3 files changed, 75 insertions(+), 8 deletions(-) create mode 100644 tests/srfi-18-signal-test.scm diff --git a/srfi-18.scm b/srfi-18.scm index 3f8cf25..9aef911 100644 --- a/srfi-18.scm +++ b/srfi-18.scm @@ -183,15 +183,21 @@ (##sys#make-structure 'condition '(uncaught-exception) (list '(uncaught-exception . reason) (##sys#slot thread 7)) ) ) ) ] - [else -(return - (if tosupplied - toval - (##sys#signal - (##sys#make-structure 'condition '(join-timeout-exception) '())) ) ) ] ) ) ) - (##sys#thread-block-for-termination! ct thread) + [(blocked ready) + (if limit + (return + (if tosupplied + toval + (##sys#signal + (##sys#make-structure 'condition '(join-timeout-exception) '())) ) ) + (##sys#thread-block-for-termination! ct thread) ) ] +[else + (##sys#error 'thread-join! + "Internal scheduler error: unknown thread state: " + ct (##sys#slot thread 3)) ] ) ) ) + (##sys#thread-block-for-termination! ct thread) (##sys#schedule) ) ) ) ) ) ) - + (define (thread-terminate! thread) (##sys#check-structure thread 'thread 'thread-terminate!) (when (eq? thread ##sys#primordial-thread) diff --git a/tests/runtests.sh b/tests/runtests.sh index 16e4bc2..7cc9950 100755 --- a/tests/runtests.sh +++ b/tests/runtests.sh @@ -68,6 +68,7 @@ interpret="../csi -n -include-path .." rm -f *.exe *.so *.o *.import.* a.out ../foo.import.* + echo " compiler tests ..." $compile compiler-tests.scm ./a.out @@ -329,6 +330,11 @@ echo " srfi-18 tests ..." $interpret -s simple-thread-test.scm $interpret -s mutex-test.scm +echo " srfi-18 thread-join! tests ..." +$compile srfi-18-signal-test.scm +./a.out & echo "sleeping and sending SIGINT to a.out (pid $!)" && sleep 1 && kill -s 2 $! +wait $! + echo " data-structures tests ..." $interpret -s data-structures-tests.scm diff --git a/tests/srfi-18-signal-test.scm b/tests/srfi-18-signal-test.scm new file mode 100644 index 000..7761558 --- /dev/null +++ b/tests/srfi-18-signal-test.scm @@ -0,0 +1,55 @@ +(require-extension srfi-18) +(require-extension posix) + +(define done #f) + +; set done = true on control-c +(set-signal-handler! signal/int (lambda (signal) (set! done #t))) + +(define (work-loop count) + (if (> count 100) + (error "Loop limit exceeded")) + (if done + (newline) + (begin +(display ".") +(thread-sleep! 0.25) +(work-loop (add1 count) + +(define (new-thread) + (set! done #f) + (make-thread (lambda () (work-loop 0 + + +;; Needs external signal it seems +(display "Correct handling of thread-join! with external signals: ") +(let ((t (new-thread))) + (thread-start! t) + (thread-join! t)) + +(display "g
Re: [Chicken-hackers] [PATCH] Fix "char = signed char" assumption in C-based s8vector operations
* Peter Bex [131126 22:15]: > Hi all, > > This was recently reported and I managed to reproduce it on my iBook. > The tests now crap out on compiler-tests.scm with the following message: I have pushed this. I couldn't test it on ARM, but it won't make things worse by looking at the code, so OK for me. -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Ticket 942 - make install uses user's umask
Setting SUDO_GID in your environment might also be enough... -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Ticket 942 - make install uses user's umask
* DG Ward [131122 07:03]: > Hey guys, > > I've been working away on fixing the problem described here: > http://bugs.call-cc.org/ticket/942 > > The problem only manifests itself when you install via. sudo. > > The reason that the issue arose is that no owner was specified for > the files being installed. This meant that the owner defaulted to > the person who ran the command. > > That itself may not seem like it should screw up the permissions as > they were directly specified (e.g. -m755). The gotcha? Sudo doesn't > let issued programs set a umask that's more permissive than that of > the invoking user. > > Explicitly stating the owner as root lets us set the mode to > whatever we please :) Changing the userid to "root" is not a good solution: It works except for local installs, where this trick breaks the install: $ make PLATFORM=linux PREFIX=~/chickentest install [...] install -d -o root -g root "/home/ckeen/chickentest/lib" install: cannot change owner and permissions of '/home/ckellerm/ckeen/lib': Operation not permitted [...] I don't know if that really is a global problem at all. I have never noticed this on my systems. Which OS are you running? Would it be possible for you to set the -g option in your sudo config? Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] More support for The Hurd
* Mario Domenech Goulart [131027 13:38]: > Hi Christian, > > On Thu, 24 Oct 2013 10:26:26 +0200 Christian Kellermann > wrote: > > > The attached patch make CHICKEN usable on the Hurd. Without the > > patch csc won't include the location hint of libchicken for the > > linker. And while we are at it, give The Hurd its own Makefile, > > currently just cloning linux. > > > > Stuff that's still missing: MAX_PATH (and maybe other limits) are > > not defined and so make check fails for the reverser test. > > > > I consider this another bug which has to be addressed more thoroughly > > in another patch. > > Indeed. Meanwhile, can't we just have something like > > /* GNU Hurd doesn't have PATH_MAX */ > #if defined __GNU__ && !defined PATH_MAX > # define C_PATH_MAX 1024 > # else > # define C_PATH_MAX PATH_MAX > #endif > > in chicken.h? It wouldn't make things more or less broken than they > currently are, I think. I have done so and rebased the two patches against current master. The patch now sets the limit to 1024 which is arbitrary but as good as any other, say 128 (I am looking at your windows). make check almost works, the deployment test is failing. I need toread up on the supported linker hints The Hurd supports. OK? Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu >From 40263eeb47623b32b80e6933587e21e6498f655f Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Wed, 23 Oct 2013 14:42:16 +0200 Subject: [PATCH 1/2] Don't rely on __MACH__ being MAC OS X when choosing the apply-hack This change enables compilation on the GNU/Hurd system which also defines __MACH__. Signed-off-by: Christian Kellermann --- runtime.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/runtime.c b/runtime.c index 58f8e07..24f8485 100644 --- a/runtime.c +++ b/runtime.c @@ -122,7 +122,7 @@ static C_TLS int timezone; #endif #ifdef C_HACKED_APPLY -# if defined(__MACH__) || defined(__MINGW32__) || defined(__CYGWIN__) +# if defined(C_MACOSX) || defined(__MINGW32__) || defined(__CYGWIN__) extern void C_do_apply_hack(void *proc, C_word *args, int count) C_noret; # else extern void _C_do_apply_hack(void *proc, C_word *args, int count) C_noret; -- 1.7.10.4 >From 82bff6132a9b4e61fd70e0f76596601d715866ec Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Thu, 24 Oct 2013 10:21:54 +0200 Subject: [PATCH 2/2] Make The Hurd a first class target This patch adds a Makefile which is currently a clone of the linux one. The Hurd also uses ELF binaries so it gets added to the list for csc. Also define PATH_MAX for now (1024). --- Makefile.hurd | 110 + chicken.h |4 +++ csc.scm |2 +- 3 files changed, 115 insertions(+), 1 deletion(-) create mode 100644 Makefile.hurd diff --git a/Makefile.hurd b/Makefile.hurd new file mode 100644 index 000..74c8c00 --- /dev/null +++ b/Makefile.hurd @@ -0,0 +1,110 @@ +# Makefile.hurd - configuration for Hurd -*- Makefile -*- +# +# Copyright (c) 2008-2013, The Chicken Team +# Copyright (c) 2007, Felix L. Winkelmann +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following +# conditions are met: +# +# Redistributions of source code must retain the above copyright notice, this list of conditions and the following +# disclaimer. +# Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following +# disclaimer in the documentation and/or other materials provided with the distribution. +# Neither the name of the author nor the names of its contributors may be used to endorse or promote +# products derived from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS +# OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR +# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR +# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. + + +ifneq ($(CONFIG),) +include $(CONFIG) +endif + +SRCDIR ?= ./ + +# pla
[Chicken-hackers] More support for The Hurd
Hi! The attached patch make CHICKEN usable on the Hurd. Without the patch csc won't include the location hint of libchicken for the linker. And while we are at it, give The Hurd its own Makefile, currently just cloning linux. Stuff that's still missing: MAX_PATH (and maybe other limits) are not defined and so make check fails for the reverser test. I consider this another bug which has to be addressed more thoroughly in another patch. I have tested this on Debian/Hurd (x86 32 bit). What do you think? Please note that this patch depends on the previous one I have sent to this list. Kind regards, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu >From 2c7c7561ffb403e688da238bd171a80b222cd6c3 Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Thu, 24 Oct 2013 10:21:54 +0200 Subject: [PATCH] Make The Hurd a first class target This patch adds a Makefile which is currently a clone of the linux one. The Hurd also uses ELF binaries so it gets added to the list for csc. --- Makefile.hurd | 110 + chicken.h |2 ++ csc.scm |2 +- 3 files changed, 113 insertions(+), 1 deletion(-) create mode 100644 Makefile.hurd diff --git a/Makefile.hurd b/Makefile.hurd new file mode 100644 index 000..89a2ef5 --- /dev/null +++ b/Makefile.hurd @@ -0,0 +1,110 @@ +# Makefile.hurd - configuration for Hurd -*- Makefile -*- +# +# Copyright (c) 2008-2013, The Chicken Team +# Copyright (c) 2007, Felix L. Winkelmann +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following +# conditions are met: +# +# Redistributions of source code must retain the above copyright notice, this list of conditions and the following +# disclaimer. +# Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following +# disclaimer in the documentation and/or other materials provided with the distribution. +# Neither the name of the author nor the names of its contributors may be used to endorse or promote +# products derived from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS +# OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR +# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR +# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +# POSSIBILITY OF SUCH DAMAGE. + + +ifneq ($(CONFIG),) +include $(CONFIG) +endif + +SRCDIR ?= ./ + +# platform configuration + +ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) + +# options + +C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H +ifdef DEBUGBUILD +C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused +else +ifdef OPTIMIZE_FOR_SPEED +C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer +else +C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer +endif +endif +LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared +LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -L. -shared -Wl,-R"$(RUNTIME_LINKER_PATH)" +LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R"$(RUNTIME_LINKER_PATH)" +LIBCHICKEN_SO_LINKER_OPTIONS = -Wl,-soname,lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).so.$(BINARYVERSION) +LIBRARIES = -lm -ldl +NEEDS_RELINKING = yes +USES_SONAME = yes + +# special files + +CHICKEN_CONFIG_H = chicken-config.h + +# select default and internal settings + +include $(SRCDIR)/defaults.make + +chicken-config.h: chicken-defaults.h + echo "/* GENERATED */" >$@ + echo "#define HAVE_DIRENT_H 1" >>$@ + echo "#define HAVE_DLFCN_H 1" >>$@ + echo "#define HAVE_INTTYPES_H 1" >>$@ + echo "#define HAVE_LIMITS_H 1" >>$@ + echo "#define HAVE_LONG_LONG 1" >>$@ + echo "#define HAVE_MEMMOVE 1" >>$@ + echo "#define HAVE_MEMORY_H 1" >>$@ + echo "#define HAVE_POSIX_POLL 1" >>$@ + echo "#define HAVE_SIGACTION 1" >>$@ + echo "#define HAVE_SIGSETJMP 1" >>$@ + echo "#define HAVE_SIGPROCMASK 1" >>$@ + echo "#define HAVE_STDINT_H 1" >>$@ +
[Chicken-hackers] Make CHICKEN compile on GNU/Hurd
Hi, the attached patch will make CHICKEN compile on GNU/Hurd, due to a mix up of __ARCH__ defines. At least my understanding here is, that the intention has been to check for Mac OS X in the original version. Could someone test this on Mac OS X please? Please note that there are some more pieces missing, one of them is the usage of PATH_MAX which is not defined on GNU/Hurd (and shouldn't be relied on as defined on any POSIX system). Another issue seems to be a linker issue where binaries built with csc will not find the libchicken library. The reason for this has yet to be investigated. Thanks, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu >From 7d9996a4b02823ad867bd1edd360dfbc72b0bec5 Mon Sep 17 00:00:00 2001 From: Christian Kellermann Date: Wed, 23 Oct 2013 14:42:16 +0200 Subject: [PATCH] Don't rely on __MACH__ being MAC OS X when choosing the apply-hack This change enables compilation on the GNU/Hurd system which also defines __MACH__. Signed-off-by: Christian Kellermann --- runtime.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/runtime.c b/runtime.c index 58f8e07..24f8485 100644 --- a/runtime.c +++ b/runtime.c @@ -122,7 +122,7 @@ static C_TLS int timezone; #endif #ifdef C_HACKED_APPLY -# if defined(__MACH__) || defined(__MINGW32__) || defined(__CYGWIN__) +# if defined(C_MACOSX) || defined(__MINGW32__) || defined(__CYGWIN__) extern void C_do_apply_hack(void *proc, C_word *args, int count) C_noret; # else extern void _C_do_apply_hack(void *proc, C_word *args, int count) C_noret; -- 1.7.10.4 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] `##sys#find-files' bug fix: handle dot files recursively
* Mario Domenech Goulart [131021 13:16]: > Please, consider the updated attached patch instead, since it contains a > test case. I have pushed this yesterday, sorry for the late response. Thanks, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1051 by removing dead code
* Peter Bex [130926 21:53]: > Can someone please test this on Windows? I did so on a cygwin build with Windows 7. It worked as expected and I have pushed the patch. Thanks, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix file-creation-mode
* Peter Bex [131001 22:29]: > Hi all, > > Here's another strange little bug found by the assertion patch. > I don't understand why (file-creation-mode) correctly returns the > old value, because the parens are mismatched. > > This patch fixes that and ensures that #f is never passed to C_unfix, > which is why the paranoid CHICKEN caused the panic. I've also updated > the documentation so it mentions the fact that file-creation-mode's > argument is optional. Excellent findings! I have pushed this. As for the patch that found this, it is too hairy to me, so I want to wait for a salmonella run on the other one. Thanks! Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
