Re: [PATCH] Clean up some hacks and obsolete code

[Jim Ursetto]

> On May 21, 2020, at 5:44 AM, Peter Bex  wrote:
> 
> More interestingly, it seems that define-record-printer either doesn't
> even work, or we're using it wrong somehow:
> 
> No clue why this doesn't work.  I checked, in CHICKEN 4 this worked,
> so I think we broke this somewhere during our massive CHICKEN 5 changes.
> I'm not sure it's worth fixing this, considering define-record-printer is
> obsolete anyway.  Presumably nobody is using it, or this would've been
> reported already?
> 
> Cheers,
> Peter
> <0003-Use-set-record-printer-instead-of-define-record-prin.patch>

Hey Peter,

I might be misunderstanding, but quite a few Chicken 5 eggs still use 
define-record-printer, and it seems to work fine in Chicken 5.1.0 and 5.2.0.

I’d be amenable to replacing this with set-record-printer! in my eggs for 
Chicken 5 (I was unaware this was deprecated), but you’d have to hunt down a 
lot of references if you want to remove it.

For example, a quick check of sql-de-lite looks ok:

> ag define-record-printer
sql-de-lite.scm
182:(define-record-printer (sqlite-database db port)
216:(define-record-printer (sqlite-statement s p)

> ~/local/chicken/5.2.0/bin/csi
CHICKEN
(c) 2008-2020, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.2.0 (rev 317468e4)
macosx-unix-clang-x86-64 [ 64bit dload ptables ]

Type ,? for help.
; loading /Users/jim/.csirc ...
#;1> (import sql-de-lite)
; loading /Users/jim/local/chicken/5.2.0/lib/chicken/11/sql-de-lite.import.so 
...
; loading /Users/jim/local/chicken/5.2.0/lib/chicken/11/sql-de-lite.so ...
[…]

#;2> (open-database "a.db")
# on "a.db”>

Re: [Chicken-hackers] [PATCH] Re: Alternative egg installation directories

[Jim Ursetto]

> On Jun 18, 2017, at 3:35 PM, Mario Domenech Goulart  
> wrote:
> 
> On Sun, 28 May 2017 23:22:40 +0200 felix.winkelm...@bevuta.com wrote:
> 
>> Here a patch for this. CHICKEN_INSTALL_PREFIX overrides the bin,
>> include or share directories when generating the install scripts. Note
>> that the installed egg-info files refer to the new directory as well,
>> so this is not the same as DESTDIR.  chicken-status +
>> chicken-uninstall will list and uninstall files woth set prefix
>> transparently. Egg-loading is not influenced, so this is much simpler
>> and less eror-prone than the old CHICKEN_PREFIX.
> 
> Not all programs shipped by salmonella have been ported (only salmonella
> and salmonella-log-viewer [*]), but salmonella is able to test itself,
> at least.  I've tried it with awful-static-pages (added to
> chicken-5-eggs repo), whose tests call a binary installed by its own egg
> and it seems to work as well.

I might have found an issue here. There doesn’t seem to be a way to locate the 
installed files after you’ve installed them into your install prefix.

For example, take the utf8 egg. It installs a file “case-map-1.dat” into the 
share directory, and it uses (chicken-home) to locate the share directory. 
However, (chicken-home) is not affected by CHICKEN_INSTALL_PREFIX, so it cannot 
locate these files. You can reproduce this problem with `csi -R utf8-case-map`. 
(installation-repository) does not work either, because it doesn’t point to the 
share dir and it could differ from the install prefix.

Thus utf8-case-map is currently broken in a private repo. Admittedly, this 
module is probably not used much, and even less in a private prefix.

This also affects chicken-doc, as that defaults to (chicken-home) when looking 
for its own repository. In this case though, it can be worked around because 
the CHICKEN_DOC_REPOSITORY env var can be set to specify the repository 
location directly.

It doesn’t look like too many eggs are affected in practice. Quite a few eggs 
install things in the share directory, but they don’t reference it at runtime. 
Eggs that I know are affected are:

- manual-labor: references a css file it installs (using 
##sys#include-pathnames — basically chicken-home)
- chicken-doc: references its repository, which can be worked around as above
- spock: references its "library-path”, which can be worked around by calling 
it with ‘-library-path’
- utf8: utf8-case-map files as above. Cannot currently be worked around as the 
path is hardcoded. (There is technically a way but it is not good.)

Although this isn’t widespread, it seems odd to have a property that is 
write-only. Clearly, it is possible to check CHICKEN_INSTALL_PREFIX yourself 
and reimplement the logic from egg-compile.scm, but that doesn’t seem robust.

Thoughts?

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Proposed patch for destination egg property

[Jim Ursetto]

Hi folks,When porting chickadee to Chicken 5, I hit a roadblock when installing data files into a namespaced directory — /share/chicken/chickadee. In Chicken 4, we can execute code in .setup to obtain this directory — (make-pathname (chicken-home) "chickadee”) — and use copy-file. In Chicken 5, we can’t execute code in .egg files, and the (data) component copies files directly into the shared directory.The destination property can override the install directory, but is only defined for absolute paths, and you can’t compute the absolute shared path in an .egg. (Also, chicken-install fails if the destination property is present.)There is a workaround for Chicken 5, where I can place all my data files into a directory “chickadee” inside the egg “chickadee”, then specify chickadee as the directory in the data component. Ugly, but effective.I feel a better solution is demonstrated by the attached patch, which accepts relative paths for destination. If relative, the provided directory is relative to the default install location, so (destination “chickadee”) now namespaces data files under /share/chicken/chickadee. Absolute paths still work as expected.The issue will affect at minimum these other eggs once they are ported to Chicken 5. They all namespace themselves using their egg name and copy-file:	formular, mistie, html-form, nemo, sigma, sigma-diagram, slatexThe downside is that any egg using destination will fail on major release 5.0.0. So for some amount of time, until 5.1.0 or maybe much longer, you would need to use the named directory workaround I mentioned above.An alternative way of solving this would be to transparently namespace the install into a directory based on the egg name. This might be better for general hygiene, although it breaks with long tradition. On the other hand, this would result in an unwelcome surprise (no namespace) when using 5.0.0 — whereas the destination property safely throws an error.Jim

0001-Enable-destination-egg-property-and-accept-relative-.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] read/write invariance of #!

[Jim Ursetto]

> On Jan 13, 2019, at 2:16 PM, Evan Hanson  wrote:
> 
> 
> I don't think this change fixes the example you gave as a "certain
> strange combination" in ticket #1572, i.e. (#! (foo bar)). ISTM that
> happens because any whitespace after a "#!" token causes the reader to
> skip everything until the end of the line (and the same goes for a
> forward slash); see the first clause at library.scm:4242:

That’s ok. With the change, #! will be written out as |#!|, which will be read 
back in as a symbol. The problem was #! being written out unquoted.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] read/write invariance of #!

[Jim Ursetto]

> On Jan 11, 2019, at 9:47 PM, Jim Ursetto  wrote:
> 
>> On Jan 11, 2019, at 3:12 PM, Evan Hanson > <mailto:ev...@foldling.org>> wrote:
>> 
>> In case someone decides to apply this patch, there's an unnecessary (and ...)
>> around the conditional that can be removed.
> 
> Hi Evan,
> Sorry for the delay. I happened to be testing this out earlier today—it 
> appears to be fine, applied to HEAD from today. (With the and clause intact.)


Looks like I tested this with core from a few days ago, prior to #1077 being 
applied, which touched the same code. Therefore the patch needs to be updated 
slightly. Unfortunately it missed 5.0.1. :(

Jim___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] read/write invariance of #!

[Jim Ursetto]

> On Jan 11, 2019, at 3:12 PM, Evan Hanson  wrote:
> 
> On 2018-12-27 10:38, Jim Ursetto wrote:
>> Thanks Felix. This looks good but I haven’t had a chance to test it yet.
>> Will report back.
> 
> Any luck? This looks OK to me.
> 
> In case someone decides to apply this patch, there's an unnecessary (and ...)
> around the conditional that can be removed.

Hi Evan,
Sorry for the delay. I happened to be testing this out earlier today—it appears 
to be fine, applied to HEAD from today. (With the and clause intact.) I haven’t 
seen any issues with the chicken-doc index after application.

I would apply but I haven’t touched core in a long time, and I don’t want to 
bork the procedure, so a regular contributor should probably do it. But if 
someone is willing to walk me through it on IRC this weekend, I certainly don’t 
mind.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] read/write invariance of #!

[Jim Ursetto]

Thanks Felix. This looks good but I haven’t had a chance to test it yet. Will 
report back.
Jim

> On Dec 23, 2018, at 1:46 PM, felix.winkelm...@bevuta.com wrote:
> 
> Hi!
> 
> Attached is a patch that seems to work for me. I don't think #!eof
> should be handled specially, as it is a distinct object.
> 
> 
> felix<0001-preserve-read-write-invariance-for-symbols-prefixed-.patch>


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] read/write invariance of #!

[Jim Ursetto]

In Chicken 5, read/write invariance of symbols beginning with #! is violated. 

> (with-input-from-string
(with-output-to-string (lambda () (write (string->symbol "#!abc" read)
Error: invalid `#!' token: “abc"

> (with-input-from-string
(with-output-to-string (lambda () (write (string->symbol "#!" read)
Error: invalid `#!' token: “"

This causes a problem with chicken-doc, as there is a syntax entry called “#!” 
which is written out but cannot be read back in. In Chicken 4, this symbol is 
escaped when written out and reads back in fine. 

This occurs because in Chicken 5, sym-is-readable? was changed:

commit 05f341e07a179ea95d891e5c55b2fe3d0dbe1ffe
Author: Evan Hanson 
Date:   Wed Mar 14 17:53:00 2018 +1300

Print #!-style symbols verbatim, without pipes

These symbols are readable, so should be printed as-is by `##sys#print'
just like #:keywords or the #!eof token.

-((and (eq? c #\#)
-  (not (eq? #\% (##core#inline "C_subchar" 
str 1
- #f)
+((eq? c #\#) ;; #!rest, #!key etc
+ (eq? (##core#inline "C_subchar" str 1) #\!))


Unfortunately this assertion is incorrect: not all #! style symbols are 
readable, only valid #! style symbols such as #!rest. Other symbols are 
rejected by the reader. Furthermore, certain strange combinations, such as “(#! 
(foo bar))” result in an unterminated list, no matter how many close parens are 
added. The latter is the issue I am hitting.

The fix is probably to explicitly test for valid tokens, which appear to be 
only: “optional”, “rest” and “key”. Probably “eof” is ok as well—not 100% sure. 
The reader, of course, already tests for these exact tokens, so the writer 
should too.

Alas, chicken-doc won’t work with Chicken 5 until this is fixed — I worked 
around the file locking bug in 5.0.0, but the writer bug is fatal.

Jim___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [C5] About `random` and its future

[Jim Ursetto]

You could use random-bsd as a drop-in replacement if you want.

http://api.call-cc.org/doc/random-bsd

> On Sep 17, 2017, at 12:43 PM, lemonboy  wrote:
> 
> Hello hackers,
> this time there's no patch and no code involved. I recently had some code that
> used the `random`/`randomize` duo from the `extras` module to do some 
> operations
> on some data. The code came with a modest test suite that worked just fine on 
> my
> laptop but failed when run on other systems running different OSs because of 
> the
> different underlying PRNG implementation used by `random()`.
> 
> Many programming languages offer in their standard library a portable and
> standardized PRNG beside the system's one (or, better, the libc's one) to
> provide a uniform and coherent experience across all the supported systems and
> avoid problems such as the one described just above.
> 
> AFAICT the `extras` module contains a bunch of useful procedures to get one
> started writing so it'd be nice if we could choose and implement a single 
> PRNG,
> taking advantage of the (light) breakage introduced by C5.
> 
> Of course shopping for a PRNG is no easy task so I did some research to get 
> the
> ball rolling, here's a list of contenders:
> 
> * SplittableRandom (aka splitmix64)
>  url: 
> https://www.researchgate.net/publication/273188325_Fast_Splittable_Pseudorandom_Number_Generators
>  (there's a small errata in the paper as outlined here [1])
> 
>  Used by Java, it is pretty simple to implement and has a state consisting of 
> a
>  single u64. There are a few minor caveats with this PRNG like the "small"
>  period of 2^64, I don't think that's a big problem for our use-case.
>  The nice thing about this PRNG is the ability to "split" a single stream but 
>  we may not really need it since CHICKEN is effectively single-threaded (let's
>  have each fork()'ed process have its own stream instead ?)
> 
> * xorshift128+
>  url: http://www.jstatsoft.org/v08/i14/paper / http://xoroshiro.di.unimi.it
> 
>  Implemented by rust, v8, Nim and a few other. Simple in its implementation 
> and
>  very compact (2 u64s) and it has a "big enough" period, it must be carefully
>  seeded [2]. It's been replaced by xoroshiro128 which sports similar qualities
>  and better statistical properties and it's being used in Erlang's OTP library
>  in a slightly different variant made to produce 58bit numbers.
> 
> * ISAAC / ChaCha{12,20}
>  url: http://burtleburtle.net/bob/rand/isaacafa.html
>  (ISAAC's algorithm has been slightly modified in a following paper [4])
> 
>  Those are CSPRNG, yes. Beside the big state required and the relative 
> slowness
>  of those algorithms the only downside I see in using one of those
>  "heavy handed" algorithms is that being stream-based we'd have to implement
>  some buffer-juggling to squeeze a single fixnum out of it.
>  ChaCha20 is what OpenBSD uses for their `arc4random` [3] and rust's `rand`
>  crate implements both at the time of writing [5].
> 
> * PCG
>  url: http://www.pcg-random.org/
> 
>  This is the new kid on the block as you can probably see by the fancy 
> website,
>  this means it hasn't been thoroughly scrutinized and is not battle tested.
>  Nevertheless its the one that's been already adopted by the Crystal
>  programming language and it seems that the next Go iteration is gonna go that
>  way too [6].
>  This one is pretty fast, has a small state, comes in different "sizes" (32,
>  64, 128) while providing a reasonably good output as seen on the website
>  (how much you can trust the results coming from the implementor is still TBD 
> :)
>  and as shown by Daniel Lemire in his blog [7].
> 
> In the end it's all about choosing an algorithm that's good enough for 99% of
> the cases, trying to cover every use case is not going to cut it. I'm no 
> expert
> so feel free to correct whatever error you may find, my English isn't not
> perfect either so you can be pedantic about that if you want. And please do :)
> 
> Thank you for reading,
> LemonBoy
> 
> [1] http://www.pcg-random.org/posts/bugs-in-splitmix.html
> [2] http://www.pcg-random.org/posts/predictability-party-tricks.html
> [3] http://bxr.su/OpenBSD/lib/libc/crypt/arc4random.c
> [4] https://131002.net/data/papers/Aum06b.pdf
> [5] https://doc.rust-lang.org/rand/rand/index.html
> [6] https://github.com/golang/go/issues/21835
> [7] https://lemire.me/blog/
> 
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Add branch prediction for C_demand checks [was: Re: [PATCH] Statically determine if argvector can be reused]

[Jim Ursetto]

This seems to have changed somewhere between kernel 2.4.37 and 2.6.12, where it 
used to be:

#define likely(x)   __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)
 
but I can’t find the exact reason it was changed.

Speculating, I would guess it was changed for the 1 case, where the double 
negation forces a non-zero (true) boolean value to be 1 (as Dan mentioned), and 
you have a definite value to compare against. 

Then, it may have been changed for the 0 case for one of two reasons:

1. Just to keep things similar.
2. The !! also forces the return value to be int, so for example, !!NULL is 
integer 0. The docs for __builtin_expect mention this, as its arguments are 
long integers:

Since you are limited to integral expressions for exp, you should use 
constructions such as

  if (__builtin_expect (ptr != NULL, 1))
error ();
 
when testing pointer or floating-point values.

It may work, but you get a warning about implicit conversion under clang or 
under gcc with -Wint-conversion:

$ gcc -o a.out a.c
a.c:4:38: warning: incompatible pointer to integer conversion passing 'void *' 
to parameter of type 'long' [-Wint-conversion]
printf("%ld\n", __builtin_expect(NULL, 0));

so it is likely the !! is to ensure int type in the 0 case.

Jim

> On Dec 30, 2016, at 12:08 AM, Dan Leslie  wrote:
> 
> Just a guess, but considering that the !! forces the value to resolve to a
> valid bool, either 0 or 1, they ran into an issue where the input to their
> macros wasn't just the outcome of Boolean operators? IE, perhaps they were
> seeing:
> 
>if (likely(SOME_FUNKY_MACRO))
> 
> And that SOME_FUNKY_MACRO could be any long value greater than or equal to
> zero; or it could expand to a Boolean operation.
> 
> -Dan
> 
> -Original Message-
> From: Chicken-hackers
> [mailto:chicken-hackers-bounces+dan=ironoxide...@nongnu.org] On Behalf Of
> Peter Bex
> Sent: December 27, 2016 9:15 AM
> To: chicken-hackers 
> Subject: [Chicken-hackers] Add branch prediction for C_demand checks [was:
> Re: [PATCH] Statically determine if argvector can be reused]
> 
> On Thu, Dec 15, 2016 at 11:55:01PM +0100, Peter Bex wrote:
>> Hi all,
>> 
>> I've been playing around a little bit with "perf" and Valgrind's 
>> cachegrind tool, and I noticed that the number of branch prediction 
>> misses can be reduced if the argvector reusing check can be hardcoded 
>> for cases where we know the size of the calling function's argvector.
>> 
>> Here's a simple patch to make this happen (works on both the master 
>> and chicken-5 branches).
> 
> And here's another one, that adds C_likely() and C_unlikely() macros, a la
> the Linux kernel's likely() and unlikely().  These are simple wrappers for
> __builtin_expect() which tell the compiler which branches in a conditional
> expression are likely to be taken.
> 
> These are now used in generated code, when we do a C_demand() check to
> allocate memory.  This is noticably faster in some benchmarks, and can bring
> down compilation time a bit as well.  Attached also are benchmark results
> for unpatched CHICKEN 5, the previous patch which adds static argvector
> checks and results for both this patch and the static argvector.
> 
> Question: Should this be:
> 
> # define C_unlikely(x) __builtin_expect((x), 0)
> 
> or, like Linux:
> 
> # define C_unlikely(x) __builtin_expect(!!(x), 0)
> 
> The latter seems to me like it would add more instructions due to the double
> negation, and the exact value of the expression in an if() is never
> important anyway, as long as it's zero or nonzero.  Right?
> 
> Cheers,
> Peter
> 
> 
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] On OS X, ensure DYLD_LIBRARY_PATH is passed to children (#1277)

[Jim Ursetto]

Here is a patch which uses the env idea.  
It is a much less invasive change and might slot into 4.11.
Tested only on OS X 10.11.

From 412434ba807f417000620286a23141076ec6dc09 Mon Sep 17 00:00:00 2001
From: Jim Ursetto <zbignie...@gmail.com>
Date: Fri, 15 Apr 2016 22:44:48 -0500
Subject: [PATCH] On OS X, ensure DYLD_LIBRARY_PATH is passed to children
 (#1277)

On OS X 10.11, according to Apple's System Integrity Protection Guide, "Any
dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are
purged when launching protected processes," including /bin/sh.  This causes a
failure running `make check` (bug #1277) because launching children via
system(3) wipes out the library path override used to test uninstalled
binaries.  Turning off SIP will resolve the issue but disables other useful
protections.

This patch simulates the pre-SIP behavior by prepending /usr/bin/env
DYLD_LIBRARY_PATH=...  to all shell calls made by csc, chicken-install and
setup-api, using the value of the variable in the caller's environment.

To get all tests in `make check` to work, it is only necessary to augment calls
from csc to chicken, from chicken-install to csi, and from setup-api to csc.
Converting these from system(3) to exec(2) works as well, but was deemed too
invasive.  This patch affects more calls than necessary in the interest of
simplicity, but calls to protected binaries will have the DYLD_LIBRARY_PATH
stripped out by SIP again anyway.
---
 chicken-install.scm | 20 
 csc.scm | 12 
 setup-api.scm   | 19 ---
 3 files changed, 32 insertions(+), 19 deletions(-)

diff --git a/chicken-install.scm b/chicken-install.scm
index 610097d..9f22296 100644
--- a/chicken-install.scm
+++ b/chicken-install.scm
@@ -637,7 +637,6 @@
(let ((cmd (make-install-command
(car e+d+v) (caddr e+d+v) (> i 1)))
  (name (car e+d+v)))
- (print "  " cmd)
  (keep-going 
   (name "installing")
   ($system cmd))
@@ -749,12 +748,18 @@
  (gather-egg-information dir)))  
 
   (define ($system str)
-(let ((r (system
-  (if *windows-shell*
-  (string-append "\"" str "\"")
-  str
-  (unless (zero? r)
-(error "shell command terminated with nonzero exit code" r str
+(let ((str (cond (*windows-shell*
+(string-append "\"" str "\""))
+   ((and (eq? (software-version) 'macosx)
+ (get-environment-variable "DYLD_LIBRARY_PATH"))
+=> (lambda (path)
+ (string-append "/usr/bin/env DYLD_LIBRARY_PATH="
+(qs path) " " str)))
+   (else str
+  (print "  " str)
+  (let ((r (system str)))
+   (unless (zero? r)
+ (error "shell command terminated with nonzero exit code" r str)
 
   (define (installed-extensions)
 (delete-duplicates
@@ -789,7 +794,6 @@
 
   (define (command fstr . args)
 (let ((cmd (apply sprintf fstr args)))
-  (print "  " cmd)
   ($system cmd)))
 
   (define (usage code)
diff --git a/csc.scm b/csc.scm
index 07cb67b..60a3235 100644
--- a/csc.scm
+++ b/csc.scm
@@ -1051,10 +1051,14 @@ EOF
 (define last-exit-code #f)
 
 (define ($system str)
-  (when verbose (print str))
-  (let ((str (if windows-shell
-(string-append "\"" str "\"")
-str)))
+  (let ((str (cond (windows-shell
+   (string-append "\"" str "\""))
+  ((and osx (get-environment-variable "DYLD_LIBRARY_PATH"))
+   => (lambda (path)
+(string-append "/usr/bin/env DYLD_LIBRARY_PATH="
+   (qs path) " " str)))
+  (else str
+(when verbose (print str))
 (let ((raw-exit-code (if dry-run 0 (system str
   (unless (zero? raw-exit-code)
(printf "\nError: shell command terminated with non-zero exit status 
~S: ~A~%" raw-exit-code str))
diff --git a/setup-api.scm b/setup-api.scm
index f4168a6..c969735 100644
--- a/setup-api.scm
+++ b/setup-api.scm
@@ -636,13 +636,18 @@
   (remove-file* (make-pathname repo egg setup-file-extension)))
 
 (define ($system str)
-  (let ((r (system
-   (if *windows-shell*
-   (string-append "\"" str "\"") ; (sic) thanks to Matthew Flatt
-   str
-(unless (zero? r)
-  (error
- 

Re: [Chicken-hackers] [PATCH] #1277 make check failure on OS X 10.11

[Jim Ursetto]

 
> On Apr 15, 2016, at 18:46, felix.winkelm...@bevuta.com wrote:
> 
> Another dirty solution would be to add a hack to those tools that invoke 
> uninstalled
> programs via system(3) to invoke "env DYLD_LIBRARY_PATH=... "
> instead.
> 

In limited testing the env approach seems to work.  But, I can’t see how to
do this only during the testing phase.  There’s no way for chicken-install or
setup-api, for example, to know that it’s being invoked as an uninstalled 
program,
and needs to pass DYLD_LIBRARY_PATH to its children.  I suppose that, if a tool
detects that the DYLD_LIBRARY_PATH variable is set at all, and the platform is
OS X, it could prepend the env call.  I would prefer to do only do it during
`make check`, but it may be an okay compromise.  I’ll look into it...

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] #1277 make check failure on OS X 10.11

[Jim Ursetto]

Already found a bug in the Windows code of course.  This patch replaces the
setup-api 0003 patch from the last message.

I will try to get a Windows VM running so I can test this myself.



On Thu, Apr 14, 2016 at 3:22 PM, Jim Ursetto <zbignie...@gmail.com> wrote:

> This is an initial patchset for #1277 on which I invite comments.
>
> The problem was correctly diagnosed in that OS X 10.11 blacklists
> certain environment variables such as DYLD_LIBRARY_PATH from being
> passed to trusted binaries, and /bin/sh is trusted.  This prevents
> `make check` from working.
>
> The cleanest solution was to change certain 'system' calls (to
> chicken, csc and csi) to direct calls via 'process-run'.  This avoids
> the blacklisting problem and as a bonus, lets us avoid quoting shell
> metacharacters.
>
> Since this needs thorough testing, it probably has to wait until after
> 4.11.  I did test building and rebuilding of the compiler as well as
> installing chickadee and dependencies, on OS X.
>
> Issues:
>
> 1. I don't know if it works on Windows.  It needs to be tested.  If it
> doesn't work we could fall back to the shell method, at the cost of
> extra code.
>
> 2. Only the minimum required calls were changed to direct: csc call
> out to chicken; chicken-install call out to csi; setup-api (compile)
> calls.  There are several other opportunities for direct calls, but
> they are not needed to pass the tests on OS X, so can be deferred until
> after this is approved and verified to work.
>
> 3. Some code duplication for execing of processes.
>
> 4. It loses a bit of quoting in verbose mode; we don't try to simulate
> a quoted shell command.
>
> Compatibility issue:
>
> The 'reverser' test executes a (compile) step via
> (standard-extension), so the (compile) macro was converted to direct
> call.  However, this affects a minority of eggs which execute
> backticks or assume a string with spaces denotes multiple arguments
> (usually, C or LD flags).  I think this is preferable and we should
> disallow shell metacharacters in (compile).  (run (csc ...)) still
> retains the old behavior, but a few eggs would have to be updated to
> use this form, so this is backwards incompatible.  If not acceptable, we
> could implement (compile*) separately and change standard-extension to
> use it, which would allow the test to pass without disrupting any
> eggs.
>
>
>
From a6dc1a05acb20bdc8ca1c24fac4f522182478b76 Mon Sep 17 00:00:00 2001
From: Jim Ursetto <zbignie...@gmail.com>
Date: Thu, 14 Apr 2016 12:31:33 -0500
Subject: [PATCH] Add (run*) to setup-api; change (compile) from shell to
 direct call (#1277)

A new macro (run*) is exported, which is like (run) but does not rely on
the shell.  (compile) is changed to be (run* (csc ...)).

This permits blacklisted environment variables such as DYLD_LIBRARY_PATH
to be passed to csc on OS X 10.11, addressing a problem with the
deployment tests in `make check` in bug #1277.

Due to the changed semantics of (compile), certain eggs which rely on
backticks or pass flags as single strings to (compile) will need to be
updated; for example, to use (run (csc ...)).
---
 setup-api.scm | 107 +++---
 1 file changed, 80 insertions(+), 27 deletions(-)

diff --git a/setup-api.scm b/setup-api.scm
index f4168a6..7db0c80 100644
--- a/setup-api.scm
+++ b/setup-api.scm
@@ -37,6 +37,7 @@
 (module setup-api
 
 ((run execute)
+ (run* execute*)
  compile
  standard-extension
  host-extension
@@ -212,12 +213,21 @@
   (set! *registered-programs* 
 (alist-cons (->string name) path *registered-programs*)))
 
+;; Not used here, but exported; may be relied on externally
 (define (find-program name)
+  (find-program* name #t))
+
+;; (run) does not quote or normalize unregistered program names, so names 
containing spaces are
+;; interpolated unchanged into the shell command line; this behavior is 
explicitly relied upon
+;; in *copy-command* for example.  This complicates the logic.
+(define (find-program* name shell?)
   (let* ((name (->string name))
 (a (assoc name *registered-programs*)))
-(if a
-   (shellpath (cdr a))
-   name)))
+(if shell?
+   (if a
+   (shellpath (cdr a))
+   name) ; deliberately not quoted
+   (normalize-pathname (if a (cdr a) name)
 
 (let ()
   (define (reg name rname) 
@@ -234,31 +244,41 @@
   (and-let* ((tp (runtime-prefix)))
 (make-pathname tp fname)))
 
-(define (fixpath prg)
+(define (_fixpath prg shell?)
+  ;; Requires shell? argument because unregistered programs should not be 
quoted,
+  ;; so we cannot simply quote in the caller.
   (cond ((string=? prg "csc")
-(string-intersperse 
- (cons*
-  (find-program "csc")
-  "-feature&q

[Chicken-hackers] [PATCH] Fix typo in library path used in deployment tests

[Jim Ursetto]

This doesn't seem to affect the results of the test, but it does quell an
invalid path error in the linker.

Without it a message such as

ld: warning: directory not found for option
'-L/Users/jim/scheme/chicken-core/tests..'

will be received during the rev-app deployment test.


0001-Fix-typo-in-library-path-used-in-deployment-tests.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] mutex-lock! sometimes not srfi-18 compliant

[Jim Ursetto]

Use git commit --amend to fix if you haven't committed the second one yet.

Use git rebase -i to squash existing commits together.

> On Nov 23, 2015, at 13:45, Jörg F. Wittenberger 
>  wrote:
> 
> Sorry,
> 
> this patch needs a patch.
> 
> Looks like I shot myself into the foot (using git) again the very same
> way.  (Looks like "git add" caches the changes, thus must be given not
> once per file but once I'm done changing things.)
> 
> Now I'm a bit lost.  How would I format a proper patch for git with both
> these changes rolled into one?
> 
> Anyway, attached "part two" of the change.  This adds more tests and
> fixed mutex-unlock! the way it should have been done before.
> 
> Best
> 
> /Jörg
> 
>> Am 23.11.2015 um 17:29 schrieb Jörg F. Wittenberger:
>> Hi all,
>> 
>>> Am 07.11.2015 um 21:55 schrieb "Jörg F. Wittenberger":
>>> Hi,
>>> 
>>> try the test case:
>> 
>> looks like I messed up with this one.  (I sent out half the patch.)
> 
> <0002-mutexlock-p2.patch>
> ___
> Chicken-hackers mailing list
> Chicken-hackers@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Cannot install regex with Chicken 4.9.1

[Jim Ursetto]

 Just a thought, weird stuff like this sometimes occurs when one version of 
chicken is installed in a nonstandard location and the other is installed in 
the standard system location, and the local one picks up the wrong libraries. 
Try removing the system package?


 On Jan 24, 2015, at 12:18, Dan Leslie d...@ironoxide.ca wrote:
 
 
 I built with:
 
 make PLATFORM=linux PREFIX=$HOME/local
 
 And then added ~/local/bin to the head of PATH.
 
 Likewise, I had to obliterate my .csirc because use was not defined by
 default, causing it to fail.
 
 uname -a
 Linux shodan 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC
 2014 x86_64 x86_64 x86_64 GNU/Linux
 
 Linux Mint, chicken-bin is also installed.
 
 -Dan
 
 Mario Domenech Goulart mario.goul...@gmail.com writes:
 
 Hi Dan,
 
 On Fri, 23 Jan 2015 22:00:01 -0800 Dan Leslie d...@ironoxide.ca wrote:
 
 Checking out tag 4.9.0 and retrying worked fine. So perhaps something
 broke since then?
 
 That's pretty weird.  Our salmonella machines don't report any error.
 
 Examples:
 http://salmonella-freebsd-x86-64.call-cc.org/master/clang/freebsd/x86-64/2015/01/24/salmonella-report/install/regex.html
 http://salmonella-linux-x86-64.call-cc.org/master-debugbuild/gcc/linux/x86-64/2015/01/24/salmonella-report/install/regex.html
 
 What platform is this?  How did you build  install CHICKEN?
 
 Best wishes.
 Mario
 
 Dan Leslie d...@ironoxide.ca writes:
 
 I just pulled Chicken from git and attempted to install the opengl egg,
 whereafter it failed when attempting to install the regex
 dependency. The output is:
 
 chicken-install regex
 retrieving ...
 connecting to host chicken.kitten-technologies.co.uk, port 80 ...
 requesting /henrietta.cgi?name=regexmode=default ...
 reading response ...
 HTTP/1.1 200 OK
 Date: Sat, 24 Jan 2015 05:32:15 GMT
 Server: Apache/2.2.29 (Unix) DAV/2 SVN/1.8.10 PHP/5.4.32 mod_fastcgi/2.4.6
 Connection: close
 Transfer-Encoding: chunked
 Content-Type: text/plain
 reading chunks ..
 reading files ...
  ./regex.meta
  ./regex.scm
  ./regex.setup
  ./regex.wiki
 regex located at /tmp/temped2f.16048/regex
 checking platform for `regex' ...
 checking dependencies for `regex' ...
 install order:
 (regex)
 installing regex:1.0 ...
 changing current directory to /tmp/temped2f.16048/regex
  '/home/dleslie/local/bin/csi' -bnq -setup-mode -e (require-library 
 setup-api) -e (import setup-api) -e (setup-error-handling) -e 
 (extension-name-and-version '(\regex\ \1.0\)) 'regex.setup'
 
 Error: unbound variable: unless
 
 
 Error: shell command terminated with nonzero exit code
 17920
 '/home/dleslie/local/bin/csi' -bnq -setup-mode -e \(require-library 
 setup-api)\...
 
 -- 
 -Dan Leslie
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix #1079 by ripping out pathname expansion and putting it into an egg [Was: Re: [PATCH] add pathname-expand]

[Jim Ursetto]

Thanks Peter!
Does this egg work with older Chicken versions? I.e. can I safely replace 
##sys#expand-home-path in sql-de-lite with pathname-expand across the board?
Jim

 On Jun 22, 2014, at 6:43, Peter Bex peter@xs4all.nl wrote:
 
 On Wed, Nov 13, 2013 at 01:05:55PM +, Mario Domenech Goulart wrote:
 Hi Felix and all,
 
 Getting rid of [pathname expansion] is the simplest approach.
 There are other ones, though.  Here are some of them:
 
 * move pathname-expand to an egg.  From users standpoint, I think it
  won't make a big difference between having pathname-expand in the core
  or in an egg.  It's something new anyway.  Having it as an egg can
  actually be a win in the end: it would be available to older chickens
  (although it wouldn't do anything, since pathname expansion is
  implicit).  But at least applications wouldn't break on an Unbound
  variable: pathname-expand error.  If pathname-expand is in the core,
  programs that use it will have a hard dependency on CHICKEN 4.9.0.
 
 I have now implemented Felix's pathname-expand patch as an egg (see
 http://wiki.call-cc.org/eggref/4/pathname-expand).  I've made a few small
 modifications:
 
 - The strings ~ and ~~ are also expanded, as are strings with a
   prefix of ~/ and ~~/ (but NOT ~~foo, and ~foo has the
   existing meaning of expanding too user foo's homedir)
 - The homedir is determined whenever it's required.  This allows
   privilege dropping and user switching to work correctly,
   in that the actual user id determines which homedir you get.
 - In case no user is found, we still raise an error, but I've added
   a specific exception subtype so that it can be caught more easily.
 - In case the repository path is undefined (can this be?), we raise
   an exception instead of using the current directory.
 
 I think we don't need to detect when it's running in an older CHICKEN,
 because in most situations when directories are expanded multiple times,
 they will be identical to the strings you get after only one expansion.
 By not stubbing out the procedures with no-ops, we nail down the
 behaviour more exactly, even in older CHICKENs.
 
 It's an egg, so if you disagree on the specifics, feel free to fix it
 and tag a new release.
 
 Attached is an updated version of Florian's patch to remove all implicit
 expansion from CHICKEN core.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Remove-sys-expand-home-path-as-shell-expansion-has-n.patch
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix #1079 by ripping out pathname expansion and putting it into an egg [Was: Re: [PATCH] add pathname-expand]

[Jim Ursetto]

Sounds good, I only use the tilde expansion, and that responsibility could 
probably even be removed and given to the caller. In my opinion the $FOO 
expansion can be jettisoned completely.
Jim

 On Jul 7, 2014, at 11:58, Peter Bex peter@xs4all.nl wrote:
 
 On Mon, Jul 07, 2014 at 11:43:20AM -0500, Jim Ursetto wrote:
 Thanks Peter!
 Does this egg work with older Chicken versions? I.e. can I safely replace 
 ##sys#expand-home-path in sql-de-lite with pathname-expand across the board?
 Jim
 
 That should work just fine.
 
 Because the algorithm is slightly different, results may vary a bit,
 but for 99% of the cases, they will be identical.  Of course, if you're
 relying on $FOO environment variable substitution, you'd have to roll
 your own replacement, because the egg (currently) does not do that at
 all.  If enough people demand this, it could be added to the egg as an
 optional feature.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] pathname expansion removed from sql-de-lite open-database

[Jim Ursetto]

Removed ##sys#expand-path from sql-de-lite's open-database in 0.6.3, in favor 
of requiring the user to call pathname-expand on the argument if desired.  I 
don't think this will break anybody's code, but let me know.
Jim

On Jul 7, 2014, at 11:58 AM, Peter Bex peter@xs4all.nl wrote:

 On Mon, Jul 07, 2014 at 11:43:20AM -0500, Jim Ursetto wrote:
 Thanks Peter!
 Does this egg work with older Chicken versions? I.e. can I safely replace 
 ##sys#expand-home-path in sql-de-lite with pathname-expand across the board?
 Jim
 
 That should work just fine.
 
 Because the algorithm is slightly different, results may vary a bit,
 but for 99% of the cases, they will be identical.  Of course, if you're
 relying on $FOO environment variable substitution, you'd have to roll
 your own replacement, because the egg (currently) does not do that at
 all.  If enough people demand this, it could be added to the egg as an
 optional feature.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Bug in socket egg read-line, fix diff attached

[Jim Ursetto]

Thanks for the patch.  Another user reported this same issue, but I haven't 
gotten a chance to look at it yet.  Actually, it appears ##sys#scan-buffer-line 
may have changed its signature recently to return multiple values.  I still 
need to verify that and if so, make sure the code works with both versions.

Jim

On Jul 6, 2014, at 6:55 PM, Jonathan Chan j...@fastmail.fm wrote:

 Hello,
 
 First of all, thanks again for the useful eggs and Scheme implementation. I 
 was trying to write a script using the intarweb egg and ran into a problem 
 where read-line on a socket would return a number instead of a string. I 
 looked into it and believe I have found a fix, which is attached.
 
 The problem had two parts: first, socket's implementation of read-line 
 returned the result of a call to ##sys#scan-buffer-line, which returns 
 multiple values, whereas read-line seems to be supposed to return only the 
 string that was read. Second, the bufindex variable representing the position 
 within the socket was updated within the eos-handler lambda, although it is 
 possible for the eos-handler procedure to never be called within 
 ##sys#scan-buffer-line. To fix the bug all that is needed is to unpack the 
 values returned from ##sys#scan-buffer-line and use those to set the buffer 
 index then return.
 
 Thanks,
 -- 
  Jonathan Chan
  j...@fastmail.fm
 fix_socket_read_line.diff___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] fix Mac OS X build

[Jim Ursetto]

Patches apply and build on OS X 10.9.  Applied.  I forgot to sign off 
beforehand.

Jim

On Jan 28, 2014, at 5:31 AM, Felix Winkelmann felix.winkelm...@bevuta.com 
wrote:

 Hello!
 
 
 The attached patches try to fix a few problems with building CHICKEN
 on Mac OS X.
 
 First, the build-tools are not automatically in the PATH, and are
 located somewhere deep in the Xcode.cpp application directory. I've
 added some variables that point to the default locations and which the
 user can override when invoking make(1).
 
 Second, I added a variable to chicken-config.h that gives the full
 path to the postinstall program, which is used on some platforms to
 fix up the runtime linker path for locating libchicken. On Mac this is
 install_name_tool. csc needs to call this on freshly linked
 executables, so it needs to be in chicken-config.h.
 
 And third, the stupid max-install-name thing, which causes the
 invocation of the postinstall program to fail sometimes, depending on
 the installation path length. csc needs to do some special magic
 here to and pass -headerpad_max_install_names to gcc(1) when
 linking. Jim noted that this might not be supported on older Macs, but
 I vote for using this anyway. It is supported by at least 2
 generations of Xcode, AFAIK, and is the official option provided by
 gcc itself on Darwin. We should support the current generation of the
 official toolchain, I'd say, and in the end the options can be adapted
 manually, in case someone desperately needs to get things running on
 an ancient Mac.
 
 
 felix
 From ac788e1fb3ae60c3d0cadfe3864a4251b98c6ef7 Mon Sep 17 00:00:00 2001
 From: felix fe...@call-with-current-continuation.org
 Date: Tue, 28 Jan 2014 10:16:09 +0100
 Subject: [PATCH 1/2] Use additional variables in MacOSX makefile to specify
 location of C compiler and build tools. Setting
 -isysroot doesn't seem to be necessary in this case,
 the default being to compile for Mac OS, apparently.
 
 ---
 Makefile.macosx |  6 +-
 README  | 11 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)
 
 diff --git a/Makefile.macosx b/Makefile.macosx
 index 39f395a..fea3ef9 100644
 --- a/Makefile.macosx
 +++ b/Makefile.macosx
 @@ -33,11 +33,14 @@ SRCDIR = ./
 
 # platform configuration
 
 +XCODE_DEVELOPER ?= /Applications/Xcode.app/Contents/Developer
 +XCODE_TOOL_PATH ?= 
 $(XCODE_DEVELOPER)/Toolchains/XcodeDefault.xctoolchain/usr/bin
 +C_COMPILER ?= $(XCODE_DEVELOPER)/usr/bin/gcc
 ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh)
 
 # commands
 
 -POSTINSTALL_PROGRAM = install_name_tool
 +POSTINSTALL_PROGRAM = $(XCODE_TOOL_PATH)/install_name_tool
 
 # options
 
 @@ -51,6 +54,7 @@ else
 C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer
 endif
 endif
 +LIBRARIAN ?= $(XCODE_TOOL_PATH)/ar
 LINKER_LINK_SHARED_LIBRARY_OPTIONS = -dynamiclib -compatibility_version 1 
 -current_version 1.0 -install_name $@
 POSTINSTALL_PROGRAM_FLAGS = -change 
 lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX)$(SO) 
 $(LIBDIR)/lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX)$(SO)
 LIBRARIAN_OPTIONS = scru
 diff --git a/README b/README
 index bb3a106..059718a 100644
 --- a/README
 +++ b/README
 @@ -442,7 +442,16 @@
 
   Mac OS X:
 
 -   - On 10.6 and 10.7, Chicken may incorrectly select a 32-bit build
 +  - The build currently assumes the Xcode application path is
 +/Applications/Xcode.app/, with the C compiler and build
 +tools being located in the Contents/Developer/usr/bin
 +and
 +Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 +subdirectories, respectively. To override these locations,
 +set XCODE_DEVELOPER and XCODE_TOOL_PATH on the make(3)
 +command line.
 +
 +   - On 10.6 and 10.7, CHICKEN may incorrectly select a 32-bit build
   environment when it should be building 64-bit, resulting in a
   build error.  This occurs when you have a 32-bit kernel and a
   64-bit gcc (that is, on Core 2 Duo systems running 10.6 Desktop).
 -- 
 1.7.12.4 (Apple Git-37)
 
 From 1fb9dadeb5f0fdf0994de25c3dfc63244e2c50e7 Mon Sep 17 00:00:00 2001
 From: felix fe...@call-with-current-continuation.org
 Date: Tue, 28 Jan 2014 10:17:18 +0100
 Subject: [PATCH 2/2] Store name of the post-install program in
 chicken-config, so that csc can pick up the path to
 install_program_name on Mac OS. Also pass
 -headerpad_max_install_names to the linker when
 building dynamically loadable .so's.
 
 ---
 Makefile.cygwin | 3 +++
 Makefile.mingw  | 3 +++
 csc.scm | 5 +++--
 defaults.make   | 3 +++
 4 files changed, 12 insertions(+), 2 deletions(-)
 
 diff --git a/Makefile.cygwin b/Makefile.cygwin
 index 8594882..6989ab8 100644
 --- a/Makefile.cygwin
 +++ b/Makefile.cygwin
 @@ -136,6 +136,9 @@ chicken-defaults.h:
   echo #ifndef C_INSTALL_CXX $@
   echo # define C_INSTALL_CXX \$(CXX_COMPILER)\ $@
   echo #endif $@
 + echo #ifndef C_INSTALL_POSTINSTALL_PROGRAM $@
 + 

Re: [Chicken-hackers] [PATCH] Remove -no-cpp-precomp flag for OS X

[Jim Ursetto]

Builds for me, applied.

FYI, this patch was encoded in iso-8859-1, and had to be converted to UTF-8 to 
match the Acknowledgements file.

Jim

On Jan 30, 2014, at 2:35 PM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 This was reported off-list: on OS X, we pass the -no-cpp-precomp option
 to the C compiler to enforce GCC's own preprocessor instead of Apple's
 own preprocessor (which was probably massively broken or incompatible).
 This was added to CHICKEN somewhere in 2003.
 
 This option has been deprecated by Apple (but is accepted and silently
 ignored since XCode 1.1), and reportedly this causes breakage using
 (non-Apple) Macports GCC on OS X 10.6.8 (64-bit, SnowLeopard).
 This is gcc (MacPorts gcc47 4.7.3_3) 4.7.3
 
 Here's a reference from the Mozilla project discussing this same problem:
 https://bugzilla.mozilla.org/show_bug.cgi?id=409224
 
 Considering this option stopped doing anything at all so long ago, I think
 we're safe to remove this as well.  The attached patch does that.
 If people decide to use an old OS X release (which isn't supported by
 Apple anymore), they could still override C_COMPILER_OPTIONS.
 I'd appreciate if any OS X users could report whether everything keeps
 working.
 
 Thanks to Jason E. Aten for reporting this bug.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Remove-obsolete-no-cpp-precomp-flag-for-OS-X-build-t.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] fix Mac OS X build

[Jim Ursetto]

On Jan 29, 2014, at 2:33 AM, Felix Winkelmann felix.winkelm...@bevuta.com 
wrote:

 From: .alyn.post. alyn.p...@lodockikumazvati.org
 I agree with Jim here.  I don't use Xcode, but need gcc/clang for brew,
 chicken, c.  I benefit from this project:
 http://kennethreitz.org/xcode-gcc-and-homebrew/, which provides gcc
 and associated darwin libraries on the command-line.  My gcc is in
 /usr/bin, which got that way installing brew, for which I assume I
 did something similar to/identical to the instructions upthread.
 
 So I have a proper compiler in /usr/bin, and I'd like chicken to
 continue to use it.
 
 You are free to do so, by overriding the appropriate build-variables. Yet, why
 shouldn't the default build play it safe?

Well, no one else appears to be having any issues right now, so I would argue 
using /usr/bin/gcc is playing it safe.  I would also argue that hardcoding 
paths into the XCode directories is a fringe use case.  So, please explain 
exactly what problem you are having, along with your OS version and XCode 
version.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] fix Mac OS X build

[Jim Ursetto]

Do you mean, why isn't it in the README for Chicken?  I think it is a recent 
change, prior to XCode 5 AFAIK the shims were always installed in /usr/bin 
automatically.  I thought that was still the case but it may have changed in OS 
X 10.9.  Yes, install_name_tool etc. are part of this.  See the FILES section 
at the bottom of xcode-select(1).

Try it out and if it works, we can add it to the README.  I can't try it 
because I already have all the shims in /usr/bin.  I am using 10.9 and XCode 
5.0.2 but just upgraded to those recently.  I may have had to run xcode-select 
to get homebrew to run, I can't remember.

Jim

On Jan 28, 2014, at 1:03 PM, Felix Winkelmann felix.winkelm...@bevuta.com 
wrote:

 From: Jim Ursetto zbignie...@gmail.com
 Subject: Re: [Chicken-hackers] [PATCH] fix Mac OS X build
 Date: Tue, 28 Jan 2014 12:02:42 -0600
 
 For the path -- actually, the build tools should be in /usr/bin, and if they 
 are not, you just have to run `xcode-select --switch 
 /Applications/XCode.app`.  This should install the shims into /usr/bin -- at 
 least that's my understanding.  You can also use `xcrun` to run command-line 
 tools associated with the currently selected XCode, but generally, they 
 should be available already as shims in /usr/bin.  If this is correct, I 
 would rather use Apple's official method of switching between command-line 
 tools than hardcode it into Chicken's makefiles.
 
 Then why isn't this in the README? Does the shims include install_name_tool 
 and ar and everything, or just gcc?
 
 
 felix


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] fix Mac OS X build

[Jim Ursetto]

On Jan 28, 2014, at 1:53 PM, Felix Winkelmann felix.winkelm...@bevuta.com 
wrote:

 From: Jim Ursetto zbignie...@gmail.com
 Subject: Re: [Chicken-hackers] [PATCH] fix Mac OS X build
 Date: Tue, 28 Jan 2014 13:10:53 -0600
 
 Do you mean, why isn't it in the README for Chicken? 
 
 Yes, that's what I meant.
 
 I think it is a recent change, prior to XCode 5 AFAIK the shims were always 
 installed in /usr/bin automatically.  
 
 Not in Xcode4, as I'm quite sure, since I had quite some trouble figuring out 
 the
 correct locations.

That is possible.  I never had to do anything special with XCode 4 as far as I 
remember; the binaries were always in /usr/bin.

 If the user uses xcode-select to switch to another toolchain, then an already 
 installed
 chicken/csc/chicken-install will not find the correct tools. So I see no 
 other way
 than hardcoding the paths. 

I don't see why not.  chicken should be using /usr/bin as its binary directory, 
and so when xcode-select changes the install location, it will still work.   (I 
think the shims just look up the actual XCode location and then exec() it -- 
they're not symlinks nor are they physically updated in place, AFAIK.)  Am I 
missing something?

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] fix Mac OS X build

[Jim Ursetto]

Do you know if there is ever a case where the tools are not installed in 
/usr/bin at all, but are available under /Applications/XCode.app?As far as 
I can remember, whenever I have installed the command-line tools (using the 
dialogue box, or the installer inside XCode) binaries are immediately available 
under /usr/bin.  However, it sounds like Felix is having an issue where 
/usr/bin is not populated, but the tools are available in their expected place 
in /Applications/XCode.app.  I do not recall experiencing this.

Jim

On Jan 28, 2014, at 2:21 PM, richo ri...@psych0tik.net wrote:

 On 28/01/14 13:58 -0600, Jim Ursetto wrote:
 On Jan 28, 2014, at 1:53 PM, Felix Winkelmann felix.winkelm...@bevuta.com 
 wrote:
 
 From: Jim Ursetto zbignie...@gmail.com
 Subject: Re: [Chicken-hackers] [PATCH] fix Mac OS X build
 Date: Tue, 28 Jan 2014 13:10:53 -0600
 
 Do you mean, why isn't it in the README for Chicken?
 
 Yes, that's what I meant.
 
 I think it is a recent change, prior to XCode 5 AFAIK the shims were always 
 installed in /usr/bin automatically.
 
 Not in Xcode4, as I'm quite sure, since I had quite some trouble figuring 
 out the
 correct locations.
 
 That is possible.  I never had to do anything special with XCode 4 as far as 
 I remember; the binaries were always in /usr/bin.
 
 
 As of Mavericks, /usr/bin/{clang,gcc,git,...} is a shim that invokes xcrun 
 (which
 is responsible for looking up the tools you've selected with xcode-select),
 but also for bringing up a Would you like to install dev tools if you don't
 already have them.
 
 The upshot is that getting the dev tools installed is pretty painless, the
 downside is that any check along the lines of which ${tool} will give you
 false positives, and better, trying to invoke the tools in an automated
 fashion will burst into flames because it'll bring up a dialogue if there's a
 windowserver attached and then block forever.
 
 richo
 
 -- 
 richo || Today's excuse:
 
 Terrorists crashed an airplane into the server room, have to remove
 /bin/laden. (rm -rf /bin/laden)
 http://blog.psych0tik.net
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] fix Mac OS X build

[Jim Ursetto]

On Jan 28, 2014, at 3:56 PM, Felix Winkelmann felix.winkelm...@bevuta.com 
wrote:

 
 I don't see why not.  chicken should be using /usr/bin as its binary 
 directory, and so when xcode-select changes the install location, it will 
 still work.   (I think the shims just look up the actual XCode location and 
 then exec() it -- they're not symlinks nor are they physically updated in 
 place, AFAIK.)  Am I missing something?
 
 If I compile the base chicken system using toolchain/xcode-version A
 with the c-compiler in some default location, xcode-select to another
 toolchain/xcode-version and then install an egg using the base chicken
 system, that calls whatever c-compiler is currently in /usr/bin, then
 we surely might get into trouble regarding binary-compatibility or
 c-compiler version differences, ABIs, or whatnot, right?

I guess so, but I don't see how it's any different than upgrading XCode in 
place, or even upgrading the gcc binary on any old system.  I don't think you 
should habitually be running xcode-select to switch toolchains, anyway.  I 
still don't see the problem with just using /usr/bin/gcc like every other UNIX 
program on the Mac, unless you've actually had a problem with this, which is 
possible as you've done a lot of work on iOS lately.

Jim
___
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

[Jim Ursetto]

I do have an XP install somewhere -- how do I verify the fix? (Other than 
making sure it compiles cleanly.)

 On Nov 23, 2013, at 11:06, Peter Bex peter@xs4all.nl wrote:
 
 On Fri, Nov 22, 2013 at 09:05:54PM -0600, Jim Ursetto wrote:
 Can you confirm it works under XP as well?
 If so I'll apply it to stability.
 
 I'd be grateful if someone could verify this for me.  The XP images
 from modern.ie don't seem to work on Qemu, and I've spent more than
 enough time in Windows to last a lifetime.  And I'll have to dig in
 more to fix the remaining other issues
 
 *feels dirty and hangs head in shame*
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net

___
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

[Jim Ursetto]

Can you confirm it works under XP as well?
If so I'll apply it to stability.
Jim

On Nov 22, 2013, at 2:43 PM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 See the attached patch, it kind of speaks for itself.
 
 I don't know why, but looks like Win7 doesn't allow cloning
 a handle from the current process and then setting its access
 to INHERIT.  I guess this is a security measure, but it should
 be just fine if we clone it and keep the current permissions
 because if *we* aren't allowed to inherit it, there's nothing we
 can do about it anyway to make it inheritable for the child.
 
 The error handling in Windows was completely broken; the errmap
 loop updated map, but looked at errmap.  I've made it a little more
 idiomatic, so it's obviously correct.  So far the errno isn't
 really used anywhere.  It looks like this exists only because errno
 is foolishly exposed to the user via the posix-error and errno
 procedures, and for that to sort-of work (it doesn't), this strange
 conversion is being done.  Reworking that will be like opening a
 whole other can of worms, so I kept it closed for the time being,
 at least until 4.9.0 is released.
 
 I think this patch should go into the stability branch.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Fix-process-under-Windows-and-fix-general-error-hand.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix nonblocking socket behaviour on Windows

[Jim Ursetto]

On Nov 20, 2013, at 4:20 PM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 Due to Shanmuhanathan's report I looked into Spiffy on Windows, and found
 out that multithreaded socket handling is completely broken there.
 Sockets are marked as nonblocking in tcp.scm, but that's done through
 fcntl() which is #defined as a no-op on Windows (because Windows has no
 fcntl() at all), so this could never have worked in the first place.
 
 I found some notes in the Windows documentation about some select()-like
 procedure automatically marking any sockets you pass to it as nonblocking,
 so perhaps this may have obscured this problem in the past if somehow
 a thread yielded before reading from such a socket.
 
 Attached is a patch which enables the marking of sockets as nonblocking
 for Windows.  This should definitely go into the stability branch!

Agreed, again as long as it works on XP, or at least doesn't break XP.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Use noreturn attribute in clang versions which support it

[Jim Ursetto]

On Oct 21, 2013, at 15:27, Peter Bex peter@xs4all.nl wrote:
 
 Hi all,
 
 Here's another small patch which will properly enable C_noret for clang.
 Currently it expands to nothing and causes a slew of warnings mostly
 because it doesn't understand that barf() won't return when it detects
 an error, and that will leave many variables uninitialised.  Luckily,
 clang has nice feature checking macros (builtins) which allow you to
 detect which features are available.  Damn, clang is nice!
 
 Anyway, I've added a __has_attribute definition for other compilers
 so they won't die on #if defined(__clang__)  !__has_attribute(noreturn)
 Not adding this would further complicated the logic, I think.
 
 Fixing this got rid of all the warnings, except one, which exposed
 a small bug which is also a minor inefficiency: C_2_divide will call
 C_fix() on an integer value, which in case of flonums will not be
 initialised.  In cases of flonums, it will be initialised, but it will
 get C_fix()ed and immediately C_unfix()ed afterwards.  This is
 unnecessary and wrong, so I've moved the C_fix() call to occur after
 the check.
 
 Perhaps this patch can also go into stability.  It's not important,
 but probably a good idea so users compiling with clang won't get
 spurious warnings.

Makes sense, let me check my notes as to why I took noreturn out -- I had to do 
this to get clang to work. Hopefully the feature test fixes the issue. noreturn 
isn't just for aesthetics you see -- it leaves out the assembly language return 
code stanza that is normally generated, saving quite a bit of code size in CPS 
style code.

 Sorry if this mail is a little rambling, I'm slightly ill right now.

It's that season.
Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [Chicken-janitors] #1045: [panic] out of memory - heap full while resizing - execution terminated (awful-picman)

[Jim Ursetto]

Yes, an access to freed memory leading (possibly) to segfault.  Let me know if 
you see a difference.

 On Oct 18, 2013, at 8:37, Alaric Snell-Pym ala...@snell-pym.org.uk wrote:
 
 On 17/10/13 23:28, Chicken Trac wrote:
 
 
 As discovered by Felix, it turned out to be an issue with sql-de-lite,
 which has been fixed by Jim in sql-de-lite 0.6.2
 
 sql-de-lite had a bug? Man! That may have also been a contributing
 factor to my ugarit backend woes (which mainly happened in a process
 which talks to sql-de-lite pretty heavily; I had problems with one that
 doesn't, but they were different problems).
 
 I look forward to having a moment to rebuild everything against the
 trunk chicken and re-running my unit test suite!
 
 ABS
 
 -- 
 Alaric Snell-Pym
 http://www.snell-pym.org.uk/alaric/
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix list-queue data corruption issue

[Jim Ursetto]

 On Oct 2, 2013, at 19:41, Mario Domenech Goulart mario.goul...@gmail.com 
 wrote:
 
 On Wed, 2 Oct 2013 23:42:47 +0200 Peter Bex peter@xs4all.nl wrote:
 
 Our beloved paranoid CHICKEN has found the root cause of another
 long-standing and hard to debug problem: the bug in the channel egg:
 http://tests.call-cc.org/master/linux/x86/2013/10/02/salmonella-report/test/channel.htmlz
 
 When run with paranoid CHICKEN, it tells us nicely where it's going
 wrong: the list-queue procedure uses the low-level structure constructor
 ##sys#make-structure with 3 arguments: the structure type, the list and
 the list tail.  Unfortunately, make-queue calls ##sys#make-structure
 with 4 arguments: the structure type, the list, the list tail and the
 queue's length.  All accessors assume the queue structure consists of
 these 4 slots, and it will segfault or cause other random corruption
 when attempting to access the length slot.
 
 The patch fixes this problem and adds a handful of basic tests for
 the queue implementation.
 
 I advise we add this patch to the stability branch as well.
 
 Thanks a lot, Peter.  I pushed your patch to master (I nuked some
 whitespaces).
 
 Jim: can you handle it for stability?

Yeah I'll put this in as well as the other pending bugfix hopefully tonight. 
Sorry, I've been totally swamped lately.

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] use -headerpad_max_install_names on Mac OS X when linking shared libs

[Jim Ursetto]

I normally do this in CSC_OPTIONS because it's in the makefile for the compiler 
but it isn't transmitted to chicken-install.

I think it is ok to hardcode it in csc.scm (I use -headerpad 128). Only thing 
I'm not sure about offhand is whether the max_install_names variant is 
available on all OS X versions.  I seem to recall it is fairly recent.

On Aug 29, 2013, at 5:45, Felix Winkelmann felix.winkelm...@bevuta.com wrote:

 Since we use install_name_tool(1) to modify the runpath of shared libraries 
 compiled
 with csc (all *.so's), this may fail, if the space inside the binary is 
 insufficient
 to hold the new updated paths. The patch adds -headerpad_max_install_names 
 to the
 linker command (both for gcc(1) and by using -Wl,... for the linker, I 
 found this
 on the 'net, so I'm not sure if this is really required).
 
 
 felix
 From 2f8748e0989279d2521d3f6e14981c1403322068 Mon Sep 17 00:00:00 2001 From: 
 felix Date: Tue, 27 Aug 2013 16:15:12 +0200 Subject: [PATCH] on darwin, pass 
 -headerpad_max_install_names or install_name_tool may fail, depending on path 
 length. and all that just to save a few kb, thank you, Apple! --- csc.scm | 2 
 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/csc.scm 
 b/csc.scm index a54c14c..ce35559 100644 --- a/csc.scm +++ b/csc.scm @@ -519,7 
 +519,7 @@ EOF (set! compile-options (append pic-options '(-DC_SHARED) 
 compile-options)) (set! link-options (cons (cond - (osx (if lib -dynamiclib 
 -bundle)) + (osx (if lib -dynamiclib -bundle 
 -Wl,-headerpad_max_install_names -headerpad_max_install_names)) (else 
 -shared)) link-options)) (set! shared #t) ) -- 1.7.9.5
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix tmpdir handling in chicken-install (#1048)

[Jim Ursetto]

Looks good, pushed.

On Aug 26, 2013, at 9:16 AM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 As Ivan reported in #1048, chicken-install's handling of TMPDIR is
 currently rather broken.  I noticed it has a nasty hack of dealing
 with current-directory as if it were a parameter (which it isn't),
 and it carries the e+d+v a bit too far.
 
 See attached a patch which cleans up both these things and fixes the bug.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Fix-TMPDIR-handling-in-chicken-install-1048.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Simplify and correct C_SIXTY_FOUR check (fix #979)

[Jim Ursetto]

On Aug 17, 2013, at 2:36 PM, Peter Bex peter@xs4all.nl wrote:

 I've tested this change on NetBSD/amd64 with GCC and LLVM/Clang,
 and on Linux/i386 with GCC.  I'd appreciate it if people on other
 platforms/compilers (especially Windows and OS X) could test this.

Works fine on 64-bit Mac OS X 10.8.3 with gcc and clang.

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [ANN]: Port Chicken to AIX

[Jim Ursetto]

On Aug 13, 2013, at 7:13 AM, Mario Domenech Goulart mario.goul...@gmail.com 
wrote:
 
 On Mon, 12 Aug 2013 22:42:22 -0600 Erik Falor ewfa...@gmail.com wrote:

 Yes - the AIX sys/socket.h header file doesn't like being passed an
 unsigned int in the third argument.  I took a cue from the call to
 getpeername() a few lines above the one I changed.  Though as I look
 at it now I missed some parens around the 'len' term...
 
 Ok.  I'm just afraid it can cause breakage on other systems.  For
 example:
 http://stackoverflow.com/questions/3531474/socklen-t-undeclared-when-compiling-c-code

True, but

1) socklen_t is already used several other times in the file.
2) the problem in the article occurs on MingW, and the suggested
   solution is a typedef, which is already done in tcp.scm.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] dynamic trace buffer resizing

[Jim Ursetto]

Proposed patch to allow user to resize trace buffer at runtime, not just 
through command line option.  Thoughts?



0001-Make-trace-buffer-resizable-at-runtime-via-sys-resiz.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] dynamic trace buffer resizing

[Jim Ursetto]

On Aug 12, 2013, at 2:11 PM, Peter Bex peter@xs4all.nl wrote:

 Looks useful.  Could it perhaps be more useful to make the argument
 to C_resize_trace_buffer a regular size_t instead of a Scheme fixnum?
 That might make it slightly more usable from an embedded situation.

Sure -- but C_trace_buffer_size is an int.  That's why I used int ;)  I could 
certainly fix that at the source, shall I?

 Also, why is a maximum size necessary, and why is it so small?

It's not.  But there's a minimum size, so I figured naturally there should be a 
maximum size, if only to eliminate accidentally or maliciously resizing the 
trace buffer to an arbitrary extent.  There are also max caps on some other 
resources.  Since it's a ring buffer, I suppose there are no *performance* 
problems with a trace buffer of large size, just potentially memory usage.  The 
default is also arbitrary.  I could either eliminate the limit or raise the 
default, your call.

Actually, I just realized the arg isn't checked to be a fixnum.  I'll change 
that when I incorporate any suggestions.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add detection for hitting rest argument count limit on direct procedure application (for #910, sort-of)

[Jim Ursetto]

Although this patch looks good and tests out fine, during the tests, chicken 
bloats to 1GB and gcc to 500MB, and they take forever to build apply-test -- 
probably because the .c file is 40MB!  I'm not sure it's wise to apply as-is; 
it may kill some machines.  Suggestions?

Jim

On Jul 24, 2013, at 2:07 PM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 As we figured out in ticket #910, there are two problems when directly
 invoking procedures with a large number of rest arguments (not via APPLY):
 
 - there's a bug in GCC 4.5's code generation which causes random errors
   like segfaults and illegal instructions to occur.
 - even with a correct C compiler, when going beyond the temporary stack's
   limit, this isn't checked and segfaults will occur.
 
 Here's a patch to add detection for the latter situation, and an improved
 version of the apply-test, which will detect the former situation as well.
 This can help users to determine whether their CHICKEN is built correctly
 and can produce working executables with procedure applications of large
 argument counts, and tells them to upgrade GCC if it segfaults.
 
 Unfortunately, the test takes rather long to build (it has to be
 compiled now), but I think it's worth it regardless as it will help
 prevent spurious bug reports by detecting both error situations.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Add-checks-for-hitting-the-rest-arg-count-limit-on-d.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Apply the same naming scheme for .so libs in libs target

[Jim Ursetto]

Hi,

This patch turned out to break the OS X build.  It removes the need to set 
SONAME_VERSION when calling the install-bin target, and therefore implicitly 
sets SONAME_VERSION to .$BINARYVERSION.  Unfortunately, some platforms such as 
OS X didn't use an SONAME_VERSION at all.  It worked before because the 
SONAME_VERSION setting code was never reached on OS X, being conditional upon 
NEEDS_RELINKING, whatever that does.  Now, however, the version number is 
always set.

The upshot is it installs libchicken.dylib.7 (which is probably an 
illegal/nonstandard name), but does *not* make a symlink from libchicken.dylib 
to it, as USES_SONAME is not set.  It is possible to work around this problem 
with a manual symlink.

My thought was to make the install of the versioned library conditional upon 
USES_SONAME as well, so OS X would go back to plain libchicken.dylib.  However, 
for whatever reason, Solaris sets NEEDS_RELINKING *without* USES_SONAME, which 
would probably break with this solution.

Therefore I'm not sure yet how to fix this correctly.  I think the logic is 
rickety and patching it just changed the failure case around.

The ticket for this issue is http://bugs.call-cc.org/ticket/1022

Jim

On Feb 11, 2013, at 10:20 AM, Mario Domenech Goulart mario.goul...@gmail.com 
wrote:

 Hi,
 
 On Sun, 10 Feb 2013 19:29:18 +0100 (CET) Felix 
 fe...@call-with-current-continuation.org wrote:
 
 I'm not sure about the right fix for this issue.  Can't we just get rid
 of SONAME_VERSION and use BYNARYVERSION instead?
 
 Sounds right to me.
 
 Attached is a patch that does that.  I've tested it for the mips
 cross-compilation case using libs install-dev as target and a regular
 installation (no cross-compilation) on linux/x86.  Both seem to work as
 expected.
 
 
 Meanwhile, how about changing the manual (Cross development chapter) to
 instruct users to use the install target instead of libs
 install-dev.  It'll probably install unnecessary things, but won't
 break anything, as far as I can see.  With the current instructions, the
 target installation ends up with a libchicken that is a dangling link.
 
 Good point. Would you want to do this? Otherwise, create a ticket and
 assign it to me, please.
 
 I've updated the wiki docs to suggest install instead of libs
 install-dev (and the expected generated tree).
 
 Notice that this wiki change doesn't need to be merged into git's manual
 if we fix the build system (I know it'll be hard to remember, but I just
 thought it should be mentioned anyway).  It's just a workaround to match
 the current chicken's build system behavior.
 
 Best wishes.
 Mario
 -- 
 http://parenteses.org/mario
 0001-Drop-SONAME_VERSION-use-.-BINARYVERSION-instead.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [Chicken-users] [PATCH] Make library tests compare numbers within epsilon

[Jim Ursetto]

I am curious why this happens though.  The only thing I could think of was the 
number is being constant folded in one case or being computed in one case via a 
hardware intrinsic instead of libm in the other, but the generated C code looks 
identical in both cases.  Perhaps some previous register state makes the values 
be off slightly, but to a degree gcc deems acceptable with -O2?  

It's also possible there is a genuine error.  Any ideas?  I'd be curious to see 
the generated asm.

On May 29, 2013, at 3:28 PM, Sven Hartrumpf hartru...@gmx.net wrote:

 Hi Peter.
 
 Wed, 29 May 2013 19:06:26 +0200, Peter.Bex wrote:
 This patch should fix it, but it does in a roundabout way: converting
 the number to a string causes it to lose precision because of the default
 value of (flonum-print-precision).  It's more explicit to check whether
 the two values lie within an epsilon of eachother, like the test egg does.
 
 I hoped that there will be a better patch. Thanks, Peter.
 
 Could you try whether make check on a -O3-compiled CHICKEN succeeds
 with the attached patch?
 
 It does!
 (Also for -O2.)
 
 Ciao
 Sven
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [Chicken-users] [PATCH] Make library tests compare numbers within epsilon

[Jim Ursetto]

On May 29, 2013, at 3:53 PM, Peter Bex peter@xs4all.nl wrote:

 The fpsin expands to a C inline call to sin(), whereas the sin() call
 expands to a call to C_a_i_flonum_sin, which is not inlineable so it has
 to issue a proper function call.  This then goes through libm, which is
 potentially different from the sin() implementation in gcc.

That was my guess, but when I built library-tests with Chicken 4.8.0.1, both 
fpsin and sin expanded to C_a_i_flonum_sin.  This must have been user error on 
my part.  Since you observed an inline sin(), that's definitely the issue, and 
your patch looks correct.

BTW machine epsilon for double is closer to 1e-16 than 1e-10 but it should be 
ok for our purposes (as wise men said, when in doubt, consult a numerical 
analyst).

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix for #1014 and minor cleanup of posix{win, unix} implementations

[Jim Ursetto]

On May 25, 2013, at 4:46 AM, Peter Bex peter@xs4all.nl wrote:

 There are also some memsets still left in the code after your patch,
 so some get initialized using C_tm_init, and some using memset.

Only strptime gets initialized with C_tm_init, and the rest with memset.  
strptime produces a time vector (C_tm_get), while the others deconstruct one 
(C_tm_set).  So these initializations are for two different purposes, i.e.:

The memset zeroes out the struct before we copy *all* fields in from a Scheme 
vector (in case there are hidden fields).  The C_tm_init zeroes out the struct 
and sets a few sane default values.  It is only strptime that needs this extra 
initialization, as it's the only call for which we may have only partial 
information.  This is basically equivalent to creating a Scheme vector with 
sane default values and copying it in using C_tm_set(), like the others do, 
just implemented in C without needing a fresh default time vector.

Just want to make sure you are aware of this.  I assumed the existing code uses 
a static buffer for efficiency to minimize garbage.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix for #1014 and minor cleanup of posix{win, unix} implementations

[Jim Ursetto]

OK, I didn't see this because it wasn't attached to the ticket.  I posted an 
alternate patch on #1014 which just addresses the old data problem in 
string-time.  As far as I can tell, the various uses of C_tm can not interfere 
with each other and all one needs to do is initialize C_tm to a sane default 
just prior to calling strptime.  Does that look correct?

On May 24, 2013, at 3:26 PM, Peter Bex peter@xs4all.nl wrote:

 Hi all,
 
 Attached is a bit of a nasty patch which slightly cleans up the even
 nastier C macro hackery in posixunix/posixwin/posix-common.
 
 This fixes #1014, which was created by David Krentzlin today.
 
 I'd appreciate if someone could test whether this does not break
 anything on Windows.  The posixwin.scm change is pretty small,
 but you never know :)
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Some-shuffling-about-and-fixing-of-the-POSIX-time-ha.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] windows paths with spaces

[Jim Ursetto]

I'm reluctant to apply this patch for two reasons.

1) (compile-file) still does manual quoting on mingw32 (see the crapshell 
variable) and I'm not convinced this is correct with the quoting change in (qs).
2) The API docs for (qs) explicitly state that it escapes metacharacters with 
backslash on UNIX, so someone could be using it to do exactly that.

If someone can convince me these are both non-issues I'll definitely apply it.

Jim

On May 15, 2013, at 4:25 AM, Răzvan Rotaru razvan.rot...@gmail.com wrote:

 Hi,
 
 I did a test with the latest chicken from the development repository and it's 
 working fine. Thanks. 
 
 Can this fix be applied to the stability branch as well?
 
 Răzvan
 
 
 
 On 9 May 2013 18:09, Peter Bex peter@xs4all.nl wrote:
 On Tue, Apr 23, 2013 at 05:57:29PM +0300, Răzvan Rotaru wrote:
  I see that the fix is not yet included in the main branch. What's the right
  aproach here? Shall I record a bug for it? Can I make pull requests
  directly to the core repository?
 
 Sorry for the (very) late reply.
 
 Can you try out whether the fix for CVE-2013-2024 fixes it?
 That's changeset 58684f69572453acc6fed7326fa9df39be98760e.
 
 Cheers,
 Peter
 --
 http://www.more-magic.net
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Fix solaris9 build for missing trunc, round, isinf math functions

[Jim Ursetto]

On Apr 20, 2013, at 4:45 PM, Felix wrote:

 From: Christian Kellermann ck...@pestilenz.org

 No, published patches are better not changed as they would require
 either a merge by everyone that already has the old patch, or you
 would force everyone to throw away that patch and take the other.
 
 I think git commit --amend --signoff should work.

Only if you haven't pushed already (which turned out to be the case here).

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] -block doesn't work for me

[Jim Ursetto]

I thought -block precludes the use of identifiers
from outside the compilation unit.

On Apr 10, 2013, at 4:04 PM, Jörg F. Wittenberger wrote:

 Sorry, I'd had sent this to chicken-users - but I'm kinda sure those
 who could answer don't read that list ;-)
 
 find attache two trivial module files foo.scm and bar.scm
 to be compiled with csc -c foo.scm bar.scm .
 Both declare (block) optimization.
 
 Plus several foobarX.scm for X in 1-6 versions, which show various
 attempts to make use of those exported foo and bar.  To be compiled
 with csc foo.o bar.o foobarX.scm -o foobar.
 
 None of them let's me ever make use of those definitions compiled
 with block optimization.
 
 Am I doing something wrong?
 
 Thanks a lot
 
 /Jörg
 
 
 
 
 ..
 
 foo.scmbar.scmfoobar.scmfoobar2.scmfoobar3.scmfoobar4.scmfoobar5.scmfoobar6.scm___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Restore row and column counting for ports (fixes #978)

[Jim Ursetto]

On Mar 28, 2013, at 3:48 AM, Moritz Heidkamp wrote:

 Jim Ursetto zbignie...@gmail.com writes:
 Unfortunately, I think it is essentially impossible at this time to
 have the compiler do this automatically via type analysis.  I believe
 it is possible to get the compiler to treat string ports, for example,
 as a separate type and specialize on that.  However, once you do this,
 you cannot use the existing procedures (such as close-input-port)
 which specialize on plain input-ports and output-ports, as there's no
 way to say that a particular type (string-input-port) is derived from
 another type (input-port) and is valid in lieu of the base type.
 
 Doesn't (define-type string-input-port input-port) work here?

My understanding is that defines a type alias and so you won't
be able to generate code targeted only at string-input-port
in that case.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Restore row and column counting for ports (fixes #978)

[Jim Ursetto]

On Feb 16, 2013, at 2:14 PM, Jim Ursetto wrote:

 On Feb 16, 2013, at 8:54, Peter Bex peter@xs4all.nl wrote:
 
 Just removing the port position bookkeeping altogether is better, I
 think.  I haven't done any benchmarks but Chicken's notoriously awful
 I/O performance might partially be due to the port position bookkeeping.
 
 I seriously doubt that; it's more likely all the indirection (and Scheme 
 code) that happens for each character when you call read-char.  read-string 
 and read-line are not subject to this as they read chunks at a time in C.  
 (And now that read-line reads into a static buffer it is very fast, not quite 
 at Perl speed.)

I had a look into this a few weeks ago and found that the impact of port 
position bookkeeping is indeed virtually nil, being dwarfed by the cost of 
procedure entry, checking for stack space and interrupts, etc.  So we are okay 
here.

 In my opinion a better solution would be to have the compiler figure out when 
 it is dealing with a file port etc. and inline the code to read-char (e.g. 
 getc) based on the port type.  It seems like this should be doable in the 
 flow analysis pass, but I don't know for sure. 

I also looked at this possibility.

First I measured the maximum possible speedup for string ports by manually 
inlining much of the read-char code, rather than have it call the read-char 
procedure through the port slot.  This led to a speedup of about 3x, which is 
not bad.

Additionally, in one situation I measured the speedup at 20x.  This happens 
when the read-char loop is tight enough such that there is no stack allocation 
or calls to closures (inlined procedures don't count).  In this case the 
compiler can generate a goto loop; and avoid interrupt and stack checks.  
Although this situation would not typically arise in normal Scheme code (like a 
character-by-character parser) it could happen in specialized code such as a 
base64 reader.

The only downside is possible code bloat due to inlining of every read-char.

The benchmarks are here:

http://paste.call-cc.org/paste?id=c491419d28381fd01a7ff5c18f763ab087a5e659

Unfortunately, I think it is essentially impossible at this time to have the 
compiler do this automatically via type analysis.  I believe it is possible to 
get the compiler to treat string ports, for example, as a separate type and 
specialize on that.  However, once you do this, you cannot use the existing 
procedures (such as close-input-port) which specialize on plain input-ports and 
output-ports, as there's no way to say that a particular type 
(string-input-port) is derived from another type (input-port) and is valid in 
lieu of the base type.

Also, as far as I know you can't extend existing definitions to add new 
specializations.  So, you would have to rewrite every port-related type 
definition to accept plain ports, string-ports, and every other specialized 
type of port.

So this looks like a no-go at the moment.  But if I am missing something and it 
is doable, then it is probably worth experimenting with.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.

[Jim Ursetto]

The following eggs in SVN use ##sys#expand-home-path, since this functionality 
is useful but was never exported as an official API:

openssl
osxattr
posix-extras
sql-de-lite
sqlite3
vfs

To be fair, three of those are mine.
Jim

On Mar 19, 2013, at 8:48 PM, Mario Domenech Goulart wrote:

 Hi John,
 
 On Tue, 19 Mar 2013 22:01:45 -0400 John Cowan co...@mercury.ccil.org wrote:
 
 Mario Domenech Goulart scripsit:
 
 b. Drop ##sys#expand-home-path.  Do not implicitly expand ~ and
   environment variables in pathnames.  Provide a procedure to expand ~
   in pathnames.  That's what this patch implements.
 
 I suggest:
 
  b2. Keep ##sys#expand-home-path, but make it the identity function.
  Provide a procedure to expand ~ in pathnames.
 
 That way, the security problem is removed, but we do not have to find
 and fix every reference to ##sys#expand-home-path.
 
 IMO, in this case we should just remove ##sys#expand-home-path, since it
 is an internal procedure.  Users should not rely on stability of the
 internal API.  By keeping ##sys#expand-home-path as an identity
 procedure, we'd be just polluting the core and adding a useless
 procedure call to every procedure of the filesystem API.
 
 Best wishes.
 Mario
 -- 
 http://parenteses.org/mario
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] non-termination with (declare (inline ...))

[Jim Ursetto]

On Mar 18, 2013, at 11:22 AM, Felix wrote:

 From: Jim Ursetto zbignie...@gmail.com
 Subject: Re: [Chicken-hackers] [PATCH] non-termination with (declare (inline 
 ...))
 Date: Mon, 18 Mar 2013 10:57:49 -0500
 
 Is that just for declare or does it also apply to define-inline?
 
 No, define-inline uses a completely different mechanism. It is
 effectively a different sort of macro.

OK, that's great news.  Thanks.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Avoid context switch during TCP errno reporting

[Jim Ursetto]

Here's a full patch to avoid context switches screwing up the error message
reported to the user, and also consolidates much of the error handling.

I think this patch is sufficient because the only actual issue, as I understand
it, is that under high load you will occasionally get an incorrect error message
(typically, operation in progress) instead of the real error message;
an exception will still fire regardless.  Disabling interrupts instead is 
probably
overkill, unless you know that won't cause hangs.

Also the patch doesn't do any harm and cleans up the code a bit, so you
can still apply a different fix on top of it.

Jim

From d856649a414b31e50e1b4971ce1c47f693161390 Mon Sep 17 00:00:00 2001
From: Jim Ursetto zbignie...@gmail.com
Date: Mon, 18 Mar 2013 13:40:05 -0500
Subject: [PATCH] Avoid context switch during TCP errno reporting

There is currently the potential for a scheduler context
switch between when the global (errno) is updated and the
when the textual error message is obtained.  This can
also happen if a non-inlined procedure is called prior
to updating (errno).

We fix the first by using the return value of
(##sys#update-errno), which is the updated value,
as the message errno.  The second is fixed by avoiding
a separate call to (fail).

We also consolidate error handling into a macro, which
catches a couple instances where (errno) was not updated.
---
 tcp.scm |  136 +++---
 1 files changed, 42 insertions(+), 94 deletions(-)

diff --git a/tcp.scm b/tcp.scm
index 5a9e2e1..44f52fc 100644
--- a/tcp.scm
+++ b/tcp.scm
@@ -219,6 +219,18 @@ EOF
(##sys#setslot ct 1 (lambda () (return (##core#undefined
(##sys#schedule) ) ) ) )
 
+(define-syntax network-error
+  (syntax-rules ()
+((_ loc msg . args)
+ (network-error/errno loc (##sys#update-errno) msg args
+
+(define-syntax network-error/errno
+  (syntax-rules ()
+((_ loc errno msg . args)
+ (##sys#signal-hook #:network-error loc
+(string-append (string-append msg  - )
+   (general-strerror errno))
+
 (define ##net#parse-host
   (let ((substring substring))
 (lambda (host proto)
@@ -233,11 +245,7 @@ EOF
 (let* ((s (substring host 0 i))
(p (##net#getservbyname s proto)) )
   (when (eq? 0 p)
-(##sys#update-errno)
-(##sys#signal-hook
- #:network-error 'tcp-connect
- (##sys#string-append cannot compute port from 
service -  strerror)
- s) )
+(network-error 'tcp-connect cannot compute port from 
service s) )
   p) )
(loop (fx+ i 1)) ) ) ) ) ) ) ) )
 
@@ -262,23 +270,17 @@ EOF
 int yes = 1; 
   C_return(setsockopt(socket, SOL_SOCKET, SO_REUSEADDR, 
(const char *)yes, sizeof(int)));) 
   s) )
-  (##sys#update-errno)
-  (##sys#signal-hook 
-   #:network-error 'tcp-listen
-   (##sys#string-append error while setting up socket -  strerror) s) )
+  (network-error 'tcp-listen error while setting up socket s) )
 (let ((addr (make-string _sockaddr_in_size)))
   (if host
  (unless (##net#gethostaddr addr host port)
(##sys#signal-hook 
 #:network-error 'tcp-listen 
-getting listener host IP failed -  host port) )
+getting listener host IP failed host port) )
  (##net#fresh-addr addr port) )
   (let ((b (##net#bind s addr _sockaddr_in_size)))
(when (eq? -1 b)
- (##sys#update-errno)
- (##sys#signal-hook
-  #:network-error 'tcp-listen
-  (##sys#string-append cannot bind to socket -  strerror) s port) )
+ (network-error 'tcp-listen cannot bind to socket s port) )
(values s addr) ) ) ) )
 
 (define-constant default-backlog 100)
@@ -289,10 +291,7 @@ EOF
   (##sys#check-exact w)
   (let ((l (##net#listen s w)))
(when (eq? -1 l)
- (##sys#update-errno)
- (##sys#signal-hook 
-  #:network-error 'tcp-listen
-  (##sys#string-append cannot listen on socket -  strerror) s port) )
+ (network-error 'tcp-listen cannot listen on socket s port) )
(##sys#make-structure 'tcp-listener s) ) ) ) )
 
 (define (tcp-listener? x) 
@@ -303,10 +302,7 @@ EOF
   (##sys#check-structure tcpl 'tcp-listener)
   (let ((s (##sys#slot tcpl 1)))
 (when (fx= -1 (##net#close s))
-  (##sys#update-errno)
-  (##sys#signal-hook 
-   #:network-error 'tcp-close
-   (##sys#string-append cannot close TCP socket -  strerror) tcpl) ) ) )
+  (network-error 'tcp-close cannot close TCP socket tcpl) ) ) )
 
 (define-constant +input-buffer-size+ 1024)
 (define-constant +output-chunk-size+ 8192)
@@ -331,9 +327,7 @@ EOF

Re: [Chicken-hackers] [PATCH] Avoid context switch during TCP errno reporting

[Jim Ursetto]

On Mar 18, 2013, at 4:17 PM, Felix wrote:

 From: Jim Ursetto zbignie...@gmail.com
 
 Here's a full patch to avoid context switches screwing up the error message
 reported to the user, and also consolidates much of the error handling.

 Applied. Thanks.

Argh!  I made an error in the patch.  I've attached the update
(but I went ahead and pushed it myself).

Jim
From beeba75c5c05b41116c179efaa7d69e5d5481ec4 Mon Sep 17 00:00:00 2001
From: Jim Ursetto zbignie...@gmail.com
Date: Mon, 18 Mar 2013 19:55:45 -0500
Subject: [PATCH] Fix mishandling of network-error arguments in 79cf5e9a0ac7

---
 tcp.scm |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tcp.scm b/tcp.scm
index 44f52fc..16071e2 100644
--- a/tcp.scm
+++ b/tcp.scm
@@ -222,14 +222,15 @@ EOF
 (define-syntax network-error
   (syntax-rules ()
 ((_ loc msg . args)
- (network-error/errno loc (##sys#update-errno) msg args
+ (network-error/errno loc (##sys#update-errno) msg . args
 
 (define-syntax network-error/errno
   (syntax-rules ()
 ((_ loc errno msg . args)
  (##sys#signal-hook #:network-error loc
-(string-append (string-append msg  - )
-   (general-strerror errno))
+   (string-append (string-append msg  - )
+  (general-strerror errno))
+   . args
 
 (define ##net#parse-host
   (let ((substring substring))
-- 
1.7.6.1

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 1/2] tcp: disable interrupts

[Jim Ursetto]

On Mar 17, 2013, at 1:58 AM, Florian Zumbiehl wrote:

  If you cannot be sufficiently sure
 that your approach is correct to be willing to build a full fix on it
 without testing first, I would consider that a sign that the approach is
 too fragile to rely on, at least without a good reason.

I was hoping you would just confirm you are experiencing the same problem
before I spend more time on it.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Ensure sleep seconds is a fixnum on Windows; also, don't halve sleep time

[Jim Ursetto]

If this patch was acceptable, could someone please apply it?  Thanks.

Jim

On Feb 19, 2013, at 9:45 AM, Jim Ursetto wrote:

 No, it returns 0 to indicate that zero seconds of sleep time remain (it was 
 not interrupted), just like posix sleep.  See the UNIX code, the Windows code 
 prior to the regression, sleep(3), and the chicken docs.
 Jim
 
 On Feb 19, 2013, at 4:34, Peter Bex peter@xs4all.nl wrote:
 
 On Tue, Feb 19, 2013 at 02:03:44AM -0600, Jim Ursetto wrote:
 sleep accepts any type arg but should accept only fixnums; also fix a 
 regression in be44f5328.
 
 Shouldn't it return undefined rather than 0?  This seems like a bug in
 the original implementation.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] fix setup-proxy to accept http URIs

[Jim Ursetto]

Pushed.

On Mar 16, 2013, at 12:43 PM, Peter Bex wrote:

 On Sat, Mar 16, 2013 at 12:29:35PM +0100, Michele La Monaca wrote:
 Oddly and inconveniently enough, (setup-proxy uri) does not not accept
 well-formed URIs:
 
 http_proxy=http://IP:PORT
 
 (it accepts only the short form http_proxy=IP:PORT)
 
 That's annoying indeed.  There isn't a proper standard for this, but
 I think most modern programs allow full URIs (which is why I chose to
 allow just full URIs for http-client).
 
 Find a simplified and signed off version of your patch attached.
 
 Thanks!
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 0001-Fix-setup-proxy-to-accept-http-URIs.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] alist-update: don't segfault on non-list

[Jim Ursetto]

I don't believe that will work; the list check must be done
inside the loop.  Otherwise this will crash:

(alist-update 'foo 'bar '((a . b) . 3))

This should also be true for alist-update! as well
(i.e. replace (and (pair? lst) ...) with ##sys#check)
or the one I showed below won't error out:

(alist-update! 'foo 'bar '((a . b) 3 (c . d)) (cut equal?  ))
 
On Mar 16, 2013, at 3:16 PM, Christian Kellermann wrote:

 * Jim Ursetto zbignie...@gmail.com [130314 08:13]:
 Nice catch.  Actually, it might be better rewritten with (##sys#check-list 
 lst 'alist-update), although that is not that important.
 
 Related, alist-update! behaves weird but doesn't crash on non-alists:
 
 (alist-update! 'foo 'bar 3)
 ;= ((foo . bar) . 3)
 
 And it's inconsistent when you give it a comparator:
 
 ;; this uses assoc
 (alist-update! 'foo 'bar '((a . b) 3 (c . d)) equal?)
 Error: (assoc) bad argument type: 3
 
 ;; this uses an assoc-like loop which does not check for lists 
 (alist-update! 'foo 'bar '((a . b) 3 (c . d)) (cut equal?  ))
 ;= ((foo . bar) (a . b) 3 (c . d))
 
 
 I propose the following patch, which checks the argument for both
 procedures with the usual ##sys#check...
 
 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
 0001-alist-update-don-t-segfault-on-non-list.patch


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.

[Jim Ursetto]

On Mar 15, 2013, at 1:04 AM, Florian Zumbiehl wrote:

 Remove ##sys#expand-home-path as shell expansion has no place in a filesystem
 API.

Definitely not happening. ;)

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.

[Jim Ursetto]

On Mar 15, 2013, at 2:21 AM, Felix wrote:

 From: Florian Zumbiehl fl...@florz.de
 Subject: Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.
 Date: Fri, 15 Mar 2013 07:58:02 +0100
 
 Remove ##sys#expand-home-path as shell expansion has no place in a filesystem
 API.
 
 Can't we just leave it in there? At least for load, which is used 
 interactively a lot? 

Although this is more secure in the weird case that you
have filenames starting with ~ or containing $, I think it would
potentially break existing code, especially scripts
(I have used the ~/ shortcut myself in scripts when opening files).
I assume users would have to call 'expand-path' manually then
when they want it, which isn't currently exported and would therefore
need a version test or shim egg to continue working with older
Chickens.

This would definitely need a change request and I can see the
security rationale, but due to the potential breakage I can't
say I'd vote for it without more convincing.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.

[Jim Ursetto]

On Mar 15, 2013, at 2:21 AM, Felix wrote:

 From: Florian Zumbiehl fl...@florz.de
 Subject: Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.
 Date: Fri, 15 Mar 2013 07:58:02 +0100
 
 Remove ##sys#expand-home-path as shell expansion has no place in a filesystem
 API.
 
 Can't we just leave it in there? At least for load, which is used 
 interactively a lot? 

You could have ,l expand the path itself, if you went this way.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.

[Jim Ursetto]

On Mar 15, 2013, at 3:35 PM, Peter Bex wrote:
 
 Finally, a flag would also need to go everywhere a path is accessed
 (including file-open, directory, directory?, call-with-input-file, etc...)
 unless you make it a parameter (which would be slower, if I'm not
 mistaken).

Oops, I see you already mentioned the parameter possibility.

Sure, it would be slower in theory, but looking at the code
for e.g. open-input-file I doubt you would even notice.  And
looking at something like with-input-from-file, which calls
apply, fluid-let, call-with-values, values, and apply again,
you will certainly not notice the difference in that case.

I think it would unusual to specify this flag on a per-call
basis; more typically it would be once at toplevel, so you're
not really incurring a per-call penalty to set the parameter,
just a small penalty to read the parameter in the procedure.
In a case where you normally don't want expansion but
occasionally do, you can call expand-path directly, so I
would argue for an expand-path procedure + expand-pathnames
parameter.

That said, even if you go the parameter way, you probably
need a backwards-compatibility module anyway.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 2/4] csi: fix untrusted code execution by (load)ing ./.csirc

[Jim Ursetto]

On Mar 15, 2013, at 5:47 AM, Peter Bex wrote:

 I nominate this patch for inclusion into the stability branch.

I hesitate to add it only because someone may be relying on
this behavior, and not know they have to update ~/.csirc.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] alist-update: don't segfault on non-list

[Jim Ursetto]

Nice catch.  Actually, it might be better rewritten with (##sys#check-list lst 
'alist-update), although that is not that important.

Related, alist-update! behaves weird but doesn't crash on non-alists:

(alist-update! 'foo 'bar 3)
;= ((foo . bar) . 3)

And it's inconsistent when you give it a comparator:

;; this uses assoc
(alist-update! 'foo 'bar '((a . b) 3 (c . d)) equal?)
Error: (assoc) bad argument type: 3

;; this uses an assoc-like loop which does not check for lists 
(alist-update! 'foo 'bar '((a . b) 3 (c . d)) (cut equal?  ))
;= ((foo . bar) (a . b) 3 (c . d))

Jim

On Mar 13, 2013, at 11:43 PM, Florian Zumbiehl wrote:

 Check the alist passed to alist-update is actually a pair before
 using ##sys#slot on it.
 ---
 data-structures.scm |   23 +--
 1 files changed, 13 insertions(+), 10 deletions(-)
 
 diff --git a/data-structures.scm b/data-structures.scm
 index 419e1ad..1c504f6 100644
 --- a/data-structures.scm
 +++ b/data-structures.scm
 @@ -229,16 +229,19 @@
 
 (define (alist-update k v lst #!optional (cmp eqv?))
   (let loop ((lst lst))
 -(if (null? lst)
 -(list (cons k v))
 -(let ((a (##sys#slot lst 0)))
 -  (cond ((not (pair? a))
 - (error 'alist-update bad argument type a))
 -((cmp (##sys#slot a 0) k)
 - (cons (cons k v) (##sys#slot lst 1)))
 -(else
 - (cons (cons (##sys#slot a 0) (##sys#slot a 1))
 -   (loop (##sys#slot lst 1)
 +(cond ((null? lst)
 +   (list (cons k v)))
 +  ((not (pair? lst))
 +   (error 'alist-update bad argument type lst))
 +  (else
 +   (let ((a (##sys#slot lst 0)))
 + (cond ((not (pair? a))
 +(error 'alist-update bad argument type a))
 +   ((cmp (##sys#slot a 0) k)
 +(cons (cons k v) (##sys#slot lst 1)))
 +   (else
 +(cons (cons (##sys#slot a 0) (##sys#slot a 1))
 +  (loop (##sys#slot lst 1))
 
 (define (alist-ref x lst #!optional (cmp eqv?) (default #f))
   (let* ([aq (cond [(eq? eq? cmp) assq]
 -- 
 1.7.2.5
 
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] test for r/w invariance

[Jim Ursetto]

I'd like to cherry-pick the following patch from stability into core.  This 
would add a test for commit 863a28e3c26f2b665dcaf75d892fcb09f62c09a1 (escape 
single backslash in symbols when printing).  Thoughts?

commit a09308b04128cecf5b93564599cbedd5e564cafd
Author: Jim Ursetto zbignie...@gmail.com
Date:   Wed Feb 27 17:25:15 2013 -0600

Test r/w invariance for symbols containing escaped backslash
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix for poll() special values in revent

[Jim Ursetto]

On Feb 26, 2013, at 12:02 PM, Peter Bex wrote:

 Hi all,
 
 Here's a patch to deal with special situations in poll().  Mario found a
 problem on Linux: [...]
 In any case, we don't check poll() revents for any other values than
 POLLIN/POLLOUT, which is clearly wrong; if a pipe is closed, there's
 nothing to read, but it will be POLLHUP'ed.  Apparently on non-Linux
 this generally won't be signalled like this (except maybe in some
 situations), which is why this wasn't noticed before.

Problem will likely occur on Solaris as well, according to

https://blogs.oracle.com/vlad/entry/poll_and_pollhup_in_solaris

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Ensure sleep seconds is a fixnum on Windows; also, don't halve sleep time

[Jim Ursetto]

sleep accepts any type arg but should accept only fixnums; also fix a 
regression in be44f5328.



0001-Ensure-sleep-seconds-is-a-fixnum-on-Windows-also-don.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Ensure sleep seconds is a fixnum on Windows; also, don't halve sleep time

[Jim Ursetto]

No, it returns 0 to indicate that zero seconds of sleep time remain (it was not 
interrupted), just like posix sleep.  See the UNIX code, the Windows code prior 
to the regression, sleep(3), and the chicken docs.
Jim

On Feb 19, 2013, at 4:34, Peter Bex peter@xs4all.nl wrote:

 On Tue, Feb 19, 2013 at 02:03:44AM -0600, Jim Ursetto wrote:
 sleep accepts any type arg but should accept only fixnums; also fix a 
 regression in be44f5328.
 
 Shouldn't it return undefined rather than 0?  This seems like a bug in
 the original implementation.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Restore row and column counting for ports (fixes #978)

[Jim Ursetto]

On Feb 16, 2013, at 8:54, Peter Bex peter@xs4all.nl wrote:

 Just removing the port position bookkeeping altogether is better, I
 think.  I haven't done any benchmarks but Chicken's notoriously awful
 I/O performance might partially be due to the port position bookkeeping.

I seriously doubt that; it's more likely all the indirection (and Scheme code) 
that happens for each character when you call read-char.  read-string and 
read-line are not subject to this as they read chunks at a time in C.  (And now 
that read-line reads into a static buffer it is very fast, not quite at Perl 
speed.)

It is worth a shot to bench it though just to prove it.

Note that custom ports don't expose all functionality (like read-line) and so 
they will be abysmally slow unless you implement one using the non-public API, 
and even then, the underlying code like read-string should still be written in 
C instead of repeatedly calling read-char, or performance will be completely 
unacceptable.  And maintaining this nearly duplicate code would be very 
annoying.

In my opinion a better solution would be to have the compiler figure out when 
it is dealing with a file port etc. and inline the code to read-char (e.g. 
getc) based on the port type.  It seems like this should be doable in the flow 
analysis pass, but I don't know for sure. 

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] do not apply PROGRAM_PREFIX/PROGRAM_SUFFIX to target include directory in a cross-chicken build

[Jim Ursetto]

I can't test the functionality but as long as it doesn't break existing builds 
I will apply it to stability.  OK?

On Feb 9, 2013, at 5:50, Mario Domenech Goulart mario.goul...@gmail.com wrote:

 Hi,
 
 On Thu, 7 Feb 2013 13:11:28 +0100 Christian Kellermann ck...@pestilenz.org 
 wrote:
 
 * felix winkelmann fe...@call-with-current-continuation.org [130206 22:46]:
 
 The attached patch removes the use of PROGRAM_PREFIX and
 PROGRAM_SUFFIX in the include-directory name for the target dev
 installation in a cross-chicken build. 
 
 Thanks, I have pushed this.
 
 Thanks, guys.
 
 This patch has been added to the meta-chicken layer for OpenEmbedded
 too (against 4.8.0.1).
 
 I think it should also go to stability.
 
 Should it be mentioned in NEWS?  Maybe something like
 
 - Build system
  - Bug fix: do not apply PROGRAM_PREFIX and PROGRAM_SUFFIX to include
directory for cross-built target installation.
 
 
 Best wishes.
 Mario
 -- 
 http://parenteses.org/mario
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] A cache system for the build environment

[Jim Ursetto]

On Feb 4, 2013, at 1:43 PM, Michele La Monaca wrote:

 The goal of this patch is to cache build-related variables to avoid to
 repeat them in every single make invocation after the first one.
 [...] For example:
 
 make PREFIX=/tmp/chicken ARCH=x86-64
 vi file_to_be_fixed
 make
 make install
 make check
 make clean
 make PREFIX=/usr/local ARCH=x86-64
 make uninstall
 make install

This is how I do it.  This way you have unlimited variants, can
recall any of them, and can optionally set a default.  Also
it doesn't need a patch.

echo 'make PREFIX=/tmp PLATFORM=macosx $@'make.test
echo 'make PREFIX=/usr/local PLATFORM=macosx $@'  make.local
chmod +x make.test make.local
ln -s make.local make  # default make

./make.test
./make.test install
./make.test check
./make.test clean
./make uninstall
./make install

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] substring function and bounds checks

[Jim Ursetto]

On Feb 5, 2013, at 5:55 PM, Michele La Monaca wrote:

 What I can say... Well, maybe one day I will see the light, in the
 meanwhile I would just have preferred a more useful substring
 function. I really think that the one provided by chicken is simply
 not on par with other languages, sorry.

I'll get Sussman on the phone.

 The semantic of a
 commonly-found substring function give me at most N chars starting
 from a certain position in the string is the most useful according
 me.

Well, your Perl example did that, but the Ruby, Python and Chicken
ones all give you chars between START and END, not N chars from START.
So you would have to write some shim code anyway.

So while you're in there, just add a couple 'min' expressions.

(define (substring/n s start n)
  (let* ((start (min start (string-length s)))
 (end (min (string-length s) (+ start n
(substring s start end)))

 To me, this only means more bloated, unreadable code in the best case,
 unfriendly crashes in the worst one.


 (substring/n ciao 1 10)
  iao

Presto, now your code isn't bloated, and you have up to N
chars from START.

Jim

P.S. He sent me to voicemail.



___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] substring function and bounds checks

[Jim Ursetto]

On Feb 5, 2013, at 4:11 PM, Michele La Monaca wrote:

 Maybe this is not the right list for that, sorry. But is there a good
 reason for this [error on out-of-bounds substring access] behavior?

I think it's along the lines of (cdr '()) being an error in
Scheme instead of NIL as in Lisp.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix for #568

[Jim Ursetto]

On Feb 3, 2013, at 2:05 PM, Peter Bex wrote:

 On Sun, Feb 03, 2013 at 12:00:42PM -0800, Kon Lovett wrote:
 On Feb 3, 2013, at 11:50 AM, Peter Bex peter@xs4all.nl wrote:
 That reminds me: in posixunix.scm the read-line code sets some slot
 number 5.  I was unable to figure out what this was for.  It seems to
 update it to the current position in the buffer while it's scanning and
 then resets it to 0 at the end, but this isn't used anywhere I could see.
 
 ; 4row (fixnum)
 ; 5col (fixnum)
 
 Now the million dollar question is why other ports don't seem to be
 using this anymore.

They had better be using it, since it is relied on in
port-position, which worked when I tried it on a string
port and a file port yesterday...

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix for #568

[Jim Ursetto]

Gotcha.  I was using read-char exclusively.
I imagine that read-line should zero out the column, at least.
That shouldn't be hard.

On Feb 3, 2013, at 14:58, Peter Bex peter@xs4all.nl wrote:

 On Sun, Feb 03, 2013 at 02:54:04PM -0600, Jim Ursetto wrote:
 On Feb 3, 2013, at 2:05 PM, Peter Bex wrote:
 Now the million dollar question is why other ports don't seem to be
 using this anymore.
 
 They had better be using it, since it is relied on in
 port-position, which worked when I tried it on a string
 port and a file port yesterday...
 
 Only read-char advances both markers consistently.  Try opening a file,
 reading a few characters from it, then reading a line.  The column will
 not be 0.
 
 Cheers,
 Peter
 -- 
 http://sjamaan.ath.cx
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Make heap_size size_t instead of uint, permitting 4GB heap on 64-bit systems (#974)

[Jim Ursetto]

Fixes Arthur Maciel's crash/hang with large datasets.  This should also go in 
stability/4.8.0 in my opinion.



0001-Make-heap_size-size_t-instead-of-uint-permitting-4GB.patch
Description: Binary data
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] A native scheme install

[Jim Ursetto]

On Jan 29, 2013, at 9:35 AM, Peter Bex wrote:

 On Tue, Jan 29, 2013 at 04:15:13PM +0100, Michele La Monaca wrote:
 Doesn't this create a bootstrapping problem while installing Chicken?
 Chicken needs a working install to install the runtime system, but
 your install needs the runtime system to be able to run...
 
 If the build succeeds you have your runtime system under your feet. If
 the build fails you've got nothing to install.
 
 On many systems this requires extra jumping through hoops like messing
 with LD_LIBRARY_PATH to make it find the runtime library when it's not
 in the installed location yet.  Or building this install program
 statically.
 
 Also important: What happens in a cross-build environment?
 
 I can't tell if it works because you didn't provide a patch for the
 Makefiles to make the build system use this new program.  Perhaps I'm
 just seeing problems that don't exist!

Concurred, there is basically no way this change is going in as long
as it involves relying on Chicken before it is installed.  'make test'
doesn't even work in that case right now.

Anyway, my understanding is that the existing solution works on all
known platforms, while relying on uninstalled chicken will likely
segfault / break on several platforms.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] A native scheme install

[Jim Ursetto]

On Jan 29, 2013, at 11:20 AM, Michele La Monaca wrote:

 Anyway, you can always fall back to a
 different install program if needed. Just set INSTALL_PROGRAM to your
 favorite install command.

Which is why the existing solution works fine.

 No need to patch Makefiles to try. Just:
 
 LD_LIBRARY_PATH=. make INSTALL_PROGRAM=./install.scm

You've hit the nail on the head.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] A native scheme install

[Jim Ursetto]

On Jan 29, 2013, at 12:55 PM, Michele La Monaca wrote:

 Ehi, I am not saying let's switch to install.scm as the default
 installer (not for now at least). My proposition is: let's bundle
 install.scm in the tarball and let's give the user an extra chance to
 have a BSD-compatible install program.

Well, your proposition also includes adding a bunch of code to the
files unit (that relies on unit posix, which is likely
a no-go in and of itself).

Here's my humble suggestion: Move your file-install and file=? code
directly into your install.scm script, and we'll make the install.scm
script available from the downloads page as an option.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Warnings building on Solaris/suncc

[Jim Ursetto]

On Jan 29, 2013, at 1:00 PM, Peter Bex wrote:

 Attached is a patch against master fixing both issues.   I've fixed
 the calls to C_save_and_reclaim in the same way calls to C_reclaim
 had already been fixed: a straight up cast to (void *).  It feels a
 little shady, but it should work.

I don't think it's shady, as this is exactly what the code generated
by the Chicken compiler does.

I can sign off but give me a bit to build and test this first,
even though it's a trivial change.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] A native scheme install

[Jim Ursetto]

If you can demonstrate that some core code (such as chicken-install)
would be improved with the addition of file-install then it might
be worth adding to core (probably in setup-api though).

I still think putting the file-install code in install.scm is
a better solution for that particular script as it is then
not restricted to 4.8.2 or higher, and it doesn't require any
core code changes.  Then later you could drop this compat code
if and when it became available in core.
 
On Jan 29, 2013, at 1:31 PM, Michele La Monaca wrote:

 Well, your proposition also includes adding a bunch of code to the
 files unit (that relies on unit posix, which is likely
 a no-go in and of itself).
 
 Here's my humble suggestion: Move your file-install and file=? code
 directly into your install.scm script, and we'll make the install.scm
 script available from the downloads page as an option.
 
 Yes, that was an option I considered. In the end I preferred to
 include them in the library because I thought (and still think) they
 are general enough to be readily available.
 E.g. file-install might be used by chicken-install instead of those
 (command ~a ~a ~a... forks. Anyway, judging from your answers, you
 have a different opinion. No problem, I don't get personal on this
 kind of things.
 
 As regarding the specific problem (install on Solaris), I would be
 fine with a sane default in the Makefile which to me means
 '/usr/ucb/install'.
 
 Regards,
 mikele


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] use test -f instead of test -e (#965)

[Jim Ursetto]

Pushed.

On Jan 21, 2013, at 2:13 PM, Felix wrote:

 A change needed for Solaris. Reported by Mikele.
 
 
 cheers,
 felix
 From 7dbc4bbd71badd8f71107304f5789bde015c43ee Mon Sep 17 00:00:00 2001
 From: felix fe...@call-with-current-continuation.org
 Date: Mon, 21 Jan 2013 21:11:02 +0100
 Subject: [PATCH] Use test -f instead of test -e in identify.sh, as the sh(1) 
 variant of
 Solaris doesn't support -f.
 
 Reported by mikele, fixed #965.
 ---
 identify.sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/identify.sh b/identify.sh
 index 0d41da3..ac9d052 100755
 --- a/identify.sh
 +++ b/identify.sh
 @@ -6,7 +6,7 @@
 
 
 # make sure file exists anyway, since branchname is a special case
 -if test \! -e buildbranch; then
 +if test \! -f buildbranch; then
 touch buildbranch
 fi
 
 -- 
 1.7.0.4
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] stability/4.8.0 test release available

[Jim Ursetto]

I've uploaded a test distribution tarball of stability/4.8.0 [1].  This should 
contain everything
that will go into 4.8.0.1 unless we find a problem.  If anyone would like to 
test it,
it would be appreciated.  I also pushed the patches to the throw-away 
tmp/stability/4.8.0 branch [2] in my github account.

You can see what's included by looking at NEWS [3] or NEWS.stability. [4]

[1] http://3e8.org/pub/chicken/stability-tmp/chicken-4.8.0-c4edbf1.tar.gz
[2] https://github.com/ursetto/chicken-core-stability/tree/tmp/stability/4.8.0
[3] 
https://raw.github.com/ursetto/chicken-core-stability/tmp/stability/4.8.0/NEWS
[4] 
https://raw.github.com/ursetto/chicken-core-stability/tmp/stability/4.8.0/NEWS.stability
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Updating stability...

[Jim Ursetto]

I've backported and/or applied these to my tree, with the exception of these so 
far:

  # c2ea63b (uint64 fix) depends on 09bfacd1 (Windows 64 bit patch)
  c2ea63b340995b1882d9ed400db0019c1686aa11

  # 67ca64e (clang warnings) depends on 09bf6acd1 (Windows 64 bit patch)
  67ca64e751451880c89af7c7aa0a233ded34ed09

  # 709a4ea depends on 335a0d2e23 (flymake/elisp); also files are not in 
manifest
  709a4ea4e2fe3008c890d80a5b102bc62e9ba306

  # symbol GC, instructed to skip
  # f97a4e630c1390372c168327ee97838f633d0eac

The ones that depend on the Win 64 bit patch could be rewritten to apply 
without it,
but it's a little hairy.  Can someone vouch for the patch?  Otherwise I will
probably defer those changes.

The patch depending on flymake/elisp could have the latter added with no 
problem,
but those files aren't ever added to the manifest, so this change would have no
effect in a distribution tarball.  [I consider this change to be user-invisible
as far as stability goes anyway, as it has no functional effect and can be
retrieved from git if someone wants it.]  If people still want it in stability,
we need to patch the manifest in master.

The symbol GC patch is skipped as per C-Keen.  In fact given the troubles with
symbol GC, I am fine with declaring symbol GC as WONTFIX in 4.8.0.x and
disabling the stupid test, at least until it's absolutely rock solid.

Kon's hash patches are skipped for this release but could be reexamined later
if the lack of them is causing a problem.

I want to note that although I did apply nearly everything since
Peter was kind enough to find appropriate patches, I think it is not 
really necessary to put so many patches into stability, just because it
is a lot of work for everybody.  (We have already hit 50, exceeding the number 
of
patches in 4.7.0 - 4.7.0.6.  Perhaps I wasn't very thorough in 4.7.0.x, although
nobody really complained.)  Especially more trivial stuff like comments,
reformatting and even wiki syncs to the manual -- although the intent is to
make later patching easier, many times these patches cause conflicts themselves.
Even a patch that just removes warnings isn't really *that* important in my
opinion.  I don't mind applying these, even though I don't think they are that
valuable; perhaps others disagree.  

Finally, I was kind of hesitant to apply the POSIX poll() fix, since it's an
intrusive change and since we already have a defense against it (ulimit),
and there's not really a test suite for it I think, and it is 
platform-dependent.
But in the end I applied it.

Jim

On Jan 6, 2013, at 7:00 AM, Peter Bex wrote:

 Hi all,
 
 It'd be nice if we can make a stability release.  I propose to merge the
 attached list of changesets.  IMO it's reasonably conservative, I avoided
 adding large non-bugfix changes.
 
 Cheers,
 Peter
 -- 
 http://sjamaan.ath.cx
 stability-changes.txt___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Simple fix to get rid of the openbsd linker warnings (#923)

[Jim Ursetto]

Also prevents the clang warnings on OS X from causing a failing test.

On Sep 14, 2012, at 3:58 AM, Peter Bex wrote:

 Hi all,
 
 I think this trivial patch could make it into the release.  This runs
 the scrutiny tests only in analysis mode.  We don't need to generate
 C code and we certainly don't need to link the program, and that's
 what causes the warnings.
 
 Christian has confirmed that this causes make check to get past this
 particular test.  There are still issues with the deployments tests,
 though.
 
 Cheers,
 Peter
 -- 
 http://sjamaan.ath.cx
 --
 The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music.
   -- Donald Knuth
 0001-Run-scrutiny-tests-in-analyze-only-mode.patch___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Re: OS X: clang's failing 'make check' w/ 4.8.0rc3 tarball

[Jim Ursetto]

This patch trivally silences the errors (also see #917).



0001-Silence-clang-return-type-warnings-by-removing-else-.patch
Description: Binary data


On Sep 9, 2012, at 5:21 PM, Derrell Piper wrote:

 Peter,
 
 Hum, okay.  Let me attach the complete log just to be clear...
 
 Thanks,
 
 Derrell
 make PLATFORM=macosx C_COMPILER=clang check
 make -f ./Makefile.macosx CONFIG= check
 cd tests; sh runtests.sh
  compiler tests ...
 ../chicken compiler-tests.scm -output-file a.c -verbose -include-path ..
 
 Note: global variable `bla#blabla' is only locally visible and never used
 
 Note: global variable `foo#bar' is only locally visible and never used
 clang a.c -o a.o -c  -no-cpp-precomp -fno-strict-aliasing -fwrapv -fno-common 
 -DHAVE_CHICKEN_CONFIG_H -m64 -DC_ENABLE_PTABLES -Os -fomit-frame-pointer -I.. 
 -I/usr/local/include/chicken
 In file included from a.c:11:
 ../chicken.h:2292:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 ../chicken.h:2299:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 ../chicken.h:2336:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 ../chicken.h:2344:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 4 warnings generated.
 rm a.c
 clang a.o -o a.out -m64 -L.. -L/usr/local/lib -lchicken -lm
 install_name_tool -change libchicken.dylib /usr/local/lib/libchicken.dylib 
 a.out
 rm a.o
 12
 12
 12
 12
 12
 bar
 1 2 3 
 1 2 3 :1:2:3
 1 2 3 
 Good, unrepresentable C strings cause errors
  compiler inlining tests  ...
 ../chicken inlining-tests.scm -output-file a.c -verbose -include-path .. 
 -optimize-level 3
 clang a.c -o a.o -c  -no-cpp-precomp -fno-strict-aliasing -fwrapv -fno-common 
 -DHAVE_CHICKEN_CONFIG_H -m64 -DC_ENABLE_PTABLES -Os -fomit-frame-pointer -I.. 
 -I/usr/local/include/chicken
 In file included from a.c:11:
 ../chicken.h:2292:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 ../chicken.h:2299:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 ../chicken.h:2336:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 ../chicken.h:2344:1: warning: control may reach end of non-void function 
 [-Wreturn-type]
 }
 ^
 4 warnings generated.
 rm a.c
 clang a.o -o a.out -m64 -L.. -L/usr/local/lib -lchicken -lm
 install_name_tool -change libchicken.dylib /usr/local/lib/libchicken.dylib 
 a.out
 rm a.o
  scrutiny tests ...
 ../chicken typematch-tests.scm -output-file a.c -verbose -include-path .. 
 -specialize -no-warnings
 clang a.c -o a.o -c  -no-cpp-precomp -fno-strict-aliasing -fwrapv -fno-common 
 -DHAVE_CHICKEN_CONFIG_H -m64 -DC_ENABLE_PTABLES -Os -fomit-frame-pointer -w 
 -I.. -I/usr/local/include/chicken
 rm a.c
 clang a.o -o a.out -m64 -L.. -L/usr/local/lib -lchicken -lm
 install_name_tool -change libchicken.dylib /usr/local/lib/libchicken.dylib 
 a.out
 rm a.o
 check fixnum 123
 check string abc
 check symbol (quote abc)
 check char x
 check boolean #t
 check number (+ 1 2)
 check (list fixnum) (quote (1))
 check (list symbol) (quote (a))
 check (list fixnum) (list 1)
 check pair (quote (1 . 2))
 check procedure +
 check vector (quote #(1))
 check null (quote ())
 check input-port (current-input-port)
 check blob (make-blob 10)
 check pointer (address-pointer 0)
 check pointer-vector (make-pointer-vector 1)
 check locative (make-locative a)
 check (struct promise) (##sys#make-structure (quote promise))
 check (pair fixnum float) (quote (1 . 2.3))
 check (vector symbol) (quote #(a))
 check (list string) (quote (ok))
 specialize fixnum
 specialize not fixnum
 specialize string
 specialize not string
 specialize symbol
 specialize not symbol
 specialize char
 specialize not char
 specialize boolean
 specialize not boolean
 specialize (list fixnum)
 specialize not (list fixnum)
 specialize pair
 specialize not pair
 specialize procedure
 specialize not procedure
 specialize (vector fixnum)
 specialize not (vector fixnum)
 specialize null
 specialize not null
 specialize undefined
 specialize not undefined
 specialize input-port
 specialize not input-port
 specialize blob
 specialize not blob
 specialize pointer
 specialize not pointer
 specialize pointer-vector
 specialize not pointer-vector
 specialize locative
 specialize not locative
 specialize (struct promise)
 specialize not (struct promise)
 specialize (pair fixnum float)
 specialize not (pair fixnum float)
 specialize (vector symbol)
 specialize not (vector symbol)
 specialize (or (list fixnum) symbol)
 specialize not (or (list fixnum) symbol)
 specialize (list fixnum)
 specialize not (list fixnum)
 specialize (or null pair)
 specialize not (or null pair)
 check predicate boolean boolean?
 check predicate boolean boolean?
 check predicate pair pair?
 check predicate null null?
 check predicate 

Re: [Chicken-hackers] [PATCH] chicken.h: define C_noret as __attribute__ ((noreturn)) for clang too

[Jim Ursetto]

As mentioned in #917, that conditional is in there deliberately
because the clang build was observed to break with it in.  Felix added
it originally when he was building with an ancient clang.  When I was
getting clang working again, I left it alone because I still saw breakage
(or at least it was warning about attribute ignored, I can't remember)
when trying to enable it.

Now, I just tested it and it does indeed appear to work with
Apple clang 3.1 (xcode 4.3.2).  But I don't have the earlier
version any more to test with.

So I would recommend applying this patch after 4.8.0 and, if
someone complains about breakage, we can probably make it
conditional on clang version.

P.S. This change affects the code output for the better,
it's not just aesthetic.

On Sep 7, 2012, at 12:29 PM, Mario Domenech Goulart wrote:

 On Fri, 7 Sep 2012 19:30:03 +0200 Peter Bex peter@xs4all.nl wrote:
 
 On Thu, Sep 06, 2012 at 09:18:38PM -0400, Mario Domenech Goulart wrote:
 
 Christian Lask reported on #chicken that make check fails when Chicken
 is built with clang (see #917).
 
 The attached patch seems to fix that problem (tested with clang 3.0).
 
 I wonder if this will work with older versions of Clang
 (notably XCode's).  I'm assuming this #ifdef wasn't added just for
 the hell of it.
 
 Yeah, that's my concern too.
 
 
 In the end, it just silents some warnings that break tests that rely on
 diff.
 
 Even if it is the proper fix, feel free to postpone it to after 4.8.0.
 
 Perhaps the best thing to do.
 
 I agree.
 
 Mario
 -- 
 http://parenteses.org/mario
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] deep-stack option, declaration and build-mode

[Jim Ursetto]

On Aug 1, 2012, at 7:07 AM, Felix wrote:

 Enabling this mode by default should IMHO be avoided, since runaway
 recursions (which is the usual reason for stack-exhaustion) will
 consume all available memory and thus may bring the machine to a halt.

I think it will hit the stack ulimit (probably 4-8MB) and segfault,
so there is no danger of exhaustion.

Jim

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] deep-stack option, declaration and build-mode

[Jim Ursetto]

On Aug 1, 2012, at 1:59 PM, Jim Ursetto wrote:

 On Aug 1, 2012, at 7:07 AM, Felix wrote:
 
 Enabling this mode by default should IMHO be avoided, since runaway
 recursions (which is the usual reason for stack-exhaustion) will
 consume all available memory and thus may bring the machine to a halt.
 
 I think it will hit the stack ulimit (probably 4-8MB) and segfault,
 so there is no danger of exhaustion.

Never mind, ignore this post, I am an idiot.  That's how it behaves
now obviously, deep-stack will remove this safety valve.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] tcp-shutdown

[Jim Ursetto]

If you close the input or output port (e.g. with close-output-port) then the 
tcp unit will shutdown that half of the conversation.  Does that not work?
Jim

On Jul 25, 2012, at 12:18, Seth Alves al...@hungry.com wrote:

 
 I have some code that uses the openssl egg.  I'm not able to find a way (as a 
 client) to send eof to the server.  Neither the openssl egg nor the tcp 
 module provide any sort of shutdown.  The socket egg provides shutdown, but 
 the openssl egg is based on tcp.
 
 With this patch
 
  http://paste.lisp.org/display/130677
 
 I can do something like
 
  (tcp-shutdown (ssl-port-tcp-port (cadr ssl-sock)) 1)
 
 I cargo-culted this patch, so I wont be surprised if it has problems.
 
-seth
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] limit number of live finalizers

[Jim Ursetto]

Here's some background information from when this problem
first reared its head six years ago.

http://lists.gnu.org/archive/html/chicken-users/2006-01/msg00082.html

Summary.  Although the GC is capable of queuing only a subset of
pendable finalizers (in case the pending buffer is fixed-size
and too small) at each major GC, this may result in a space leak
in tight loops that allocate a lot of finalizable objects.
Ideally we would ensure pending buffer size  live finalizers, so
all finalizers can be invoked in one shot if needed.  To help with this,
a major GC is forced whenever a new finalizer is registered AND
the total number of active finalizers is greater than the pending
buffer size.  This MAY free up some of the live finalizers and
bring the total below the pending buffer size, satisfying our
condition.  Note that the actual fullness of the pending buffer is
not considered in this solution.

Unfortunately, though this helps for short-lived objects it
loses for long-lived ones: if live finalizers  pending buffer size,
but all those finalizable objects are in use, the major GC does
no useful work, but will still be called every for every new registered
finalizer.  This is a gigantic performance hit, of course.
That's why the pending array was made resizable, and it fixes
both cases.  So I'm crossing my fingers that there is not an
unfixable flaw in the resizing solution.

Jim

On Jun 23, 2012, at 7:53 AM, Peter Bex wrote:

 On Sat, Jun 23, 2012 at 02:47:49PM +0200, Felix wrote:
 This patch limits the number of available finalizers (currently to
 4096) and removes the dynamic resizing of the pending finalizers
 vector, which is IMHO the cause of crashes when finalizers are
 created excessively. Contrary to an earlier e-mail I do now think that
 this problem needs to be fixed right now and should not be postponed
 to a later release (and I do not see any other solution in the
 moment). 
 
 I agree it must be fixed in the upcoming release.
 
 User programs can override the finalizer limit using the -:f runtime
 option if a large number of finalizations are expected or required in 
 specific applications.
 
 I'd like a little more time to investigate the bug.  This patch can
 always be applied.  It would be a shame if we can come up with a better
 fix after this makes it into the release.
 
 Cheers,
 Peter
 -- 
 http://sjamaan.ath.cx
 --
 The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music.
   -- Donald Knuth
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dynamic resizing of finalizer vector

[Jim Ursetto]

Hi Felix,

On Jun 19, 2012, at 1:03 PM, Felix wrote:

 From: Jim Ursetto zbignie...@gmail.com
 Might I suggest that these nice thorough explanations be put in the
 patch message itself (preceded by a blank line), so we always
 have them at hand.
 
 Sure. Do you want one blank line or two? I can add some ASCII-art, too,
 if you like that sort of thing.

The blank line is a git convention so that it separates the summary
from the long description in git log --oneline.  You can add an
extra blank line if you feel particularly saucy that day.
ASCII-art would be acceptable too, I miss the old banners.

 On the other hand: feel free to sign off
 the patch and have a go yourself.

I thought it was ok to comment on patches without signing off.
I would have signed off if I felt qualified to review it.

 But yes, I will keep this in mind for the patch after the next.

Cool, thanks!

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] #870: SRFI-13's string comparison procedures return integers

[Jim Ursetto]

Attached patch fixes ticket #870.

From 72b4138d0fd1f314f9129ea1bf54f67892e25d38 Mon Sep 17 00:00:00 2001
From: Jim Ursetto zbignie...@gmail.com
Date: Mon, 18 Jun 2012 20:16:24 -0500
Subject: [PATCH] Ensure that srfi-13 string= and its string-comparison
 friends return booleans on success

This corrects a deficiency which exists in the reference implementation
and fixes ticket #870.

---
 srfi-13.scm |   36 ++--
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/srfi-13.scm b/srfi-13.scm
index 615cbb7..e4a0509 100644
--- a/srfi-13.scm
+++ b/srfi-13.scm
@@ -783,7 +783,7 @@
 (or (and (eq? s1 s2) (= start1 start2)); Fast path
 (%string-compare s1 start1 end1 s2 start2 end2 ; Real test
  (lambda (i) #f)
- values
+ (lambda (i) (if i #t #f))
  (lambda (i) #f))
 
 (define (string s1 s2 . maybe-starts+ends)
@@ -792,9 +792,9 @@
 (or (not (= (- end1 start1) (- end2 start2)))  ; Fast path
(and (not (and (eq? s1 s2) (= start1 start2)))  ; Quick filter
 (%string-compare s1 start1 end1 s2 start2 end2 ; Real test
- values
+ (lambda (i) (if i #t #f))
  (lambda (i) #f)
- values)
+ (lambda (i) (if i #t #f)))
 
 (define (string s1 s2 . maybe-starts+ends)
   (let-string-start+end2 (start1 end1 start2 end2) 
@@ -803,7 +803,7 @@
( end1 end2)
 
(%string-compare s1 start1 end1 s2 start2 end2  ; Real test
-values
+(lambda (i) (if i #t #f))
 (lambda (i) #f)
 (lambda (i) #f)
 
@@ -816,7 +816,7 @@
(%string-compare s1 start1 end1 s2 start2 end2  ; Real test
 (lambda (i) #f)
 (lambda (i) #f)
-values
+(lambda (i) (if i #t #f))
 
 (define (string= s1 s2 . maybe-starts+ends)
   (let-string-start+end2 (start1 end1 start2 end2) 
@@ -825,8 +825,8 @@
(= end1 end2)
 
(%string-compare s1 start1 end1 s2 start2 end2  ; Real test
-values
-values
+(lambda (i) (if i #t #f))
+(lambda (i) (if i #t #f))
 (lambda (i) #f)
 
 (define (string= s1 s2 . maybe-starts+ends)
@@ -837,8 +837,8 @@
 
(%string-compare s1 start1 end1 s2 start2 end2  ; Real test
 (lambda (i) #f)
-values
-values
+(lambda (i) (if i #t #f))
+(lambda (i) (if i #t #f))
 
 (define (string-ci= s1 s2 . maybe-starts+ends)
   (let-string-start+end2 (start1 end1 start2 end2) 
@@ -847,7 +847,7 @@
 (or (and (eq? s1 s2) (= start1 start2)); Fast path
 (%string-compare-ci s1 start1 end1 s2 start2 end2  ; Real test
 (lambda (i) #f)
-values
+(lambda (i) (if i #t #f))
 (lambda (i) #f))
 
 (define (string-ci s1 s2 . maybe-starts+ends)
@@ -856,9 +856,9 @@
 (or (not (= (- end1 start1) (- end2 start2)))  ; Fast path
(and (not (and (eq? s1 s2) (= start1 start2)))  ; Quick filter
 (%string-compare-ci s1 start1 end1 s2 start2 end2  ; Real test
-values
+(lambda (i) (if i #t #f))
 (lambda (i) #f)
-values)
+(lambda (i) (if i #t #f)))
 
 (define (string-ci s1 s2 . maybe-starts+ends)
   (let-string-start+end2 (start1 end1 start2 end2) 
@@ -867,7 +867,7 @@
( end1 end2)
 
(%string-compare-ci s1 start1 end1 s2 start2 end2   ; Real test
-   values
+   (lambda (i) (if i #t #f))
(lambda (i) #f)
(lambda (i) #f)
 
@@ -880,7 +880,7 @@
(%string-compare-ci s1 start1 end1 s2 start2 end2   ; Real test
(lambda (i) #f)
(lambda (i) #f)
-   values
+   (lambda (i) (if i #t #f))
 
 (define (string-ci= s1 s2 . maybe-starts+ends)
   (let-string-start+end2 (start1 end1 start2 end2) 
@@ -889,8 +889,8 @@
(= end1 end2)
 
(%string-compare-ci s1 start1 end1 s2 start2 end2   ; Real test
-   values
-   values

Re: [Chicken-hackers] [PATCH] Change setjmp/longjmp to _setjmp/_longjmp to avoid overhead and fix signal masking bug

[Jim Ursetto]

On Jun 13, 2012, at 7:28 PM, Mario Domenech Goulart wrote:

 Unfortunately I could not observe any improvement on Linux x86.  The
 performance is actually slightly worse with your patch (using master,
 c48a109d668f3186bb4a213940c0b0b81a1ad03d).  I run the benchmarks with no
 csc options and with -O3.  Here are the results ([2] is the chicken with
 the _setjmp/_longjmp patch):

There won't be any improvement on Linux because _setjmp == setjmp;
Linux doesn't save the signal mask on setjmp() unless the obscure __FAVOR_BSD
is #defined.  The performance regression you observed could just be
statistical noise as well -- but, sometimes gcc will inline known calls
and it might do that for setjmp and not _setjmp, even though setjmp is
just a macro alias for _setjmp.  Only way to be sure is to look at the
assembly output.

Other than figuring that out, it would be a good idea to test on mingw
and OS X (I was going to do this).  However testing on other platforms
like cygwin or Solaris (or more obscure?) is problematic.  It is not
really a question of whether _setjmp works but if every platform supports
_setjmp.  I don't know if this is something to throw in before the
release, if one is coming soon, unless we are going to test every
supported platform before release.  Anyone else?

JIm

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Change setjmp/longjmp to _setjmp/_longjmp to avoid overhead and fix signal masking bug

[Jim Ursetto]

On Jun 13, 2012, at 8:51 PM, John Cowan wrote:

 On Cygwin, _setjmp and _longjmp are supported.  I can test, but probably
 not until next week.

Cool, thanks.  We can probably assume that if it compiles, it works fine.

 On Solaris, _setjmp and _longjmp don't manipulate the signal mask,
 whereas setjmp and longjmp do, according to the man pages.  I can't test
 on Solaris.

Peter mentioned to me that _setjmp is supported on Solaris but not on very
old Solaris (like, 2.5).  Question is, are there any supported
systems that don't support _setjmp at all.  We believe that, if a system
does support _setjmp, it will do the right thing.

Jim


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] tcp-connect looses socket-fd upon timeout

[Jim Ursetto]

Applied to master and stability, thanks.  I verified the behavior manually with 
lsof.  

Note that this was only an issue if tcp-connect-timeout is set, which is not 
the case by default; if the OS itself times out the connection, it got properly 
closed.

On May 16, 2012, at 10:13 AM, Jörg F. Wittenberger wrote:

 this should help:
 
 ===
 --- tcp.scm
 +++ tcp.scm
 @@ -612,10 +612,11 @@
 ##sys#current-thread
 (+ (current-milliseconds) tmc) ) )
  (##sys#thread-block-for-i/o! ##sys#current-thread s 
 #:all)
  (yield)
  (when (##sys#slot ##sys#current-thread 13)
 +  (##net#close s)
(##sys#signal-hook
 #:network-timeout-error
 'tcp-connect
 connect operation timed out tmc s) )
  (loop2) ) ) ))
 ...
 
 
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Patch to use better PRNG on BSD's

[Jim Ursetto]

Currently the only reason a better PRNG is needed in core
is because of the new hash table randomization stuff that
is also in core (as of the upcoming Chicken 4.8).
User code can use any one of the random eggs.
Cryptographic quality is probably overkill.

On Apr 11, 2012, at 6:21 AM, Thomas Chust wrote:

 If we really wanted to include a PRNG in the CHICKEN distribution that
 should satisfy any definition of good, I would suggest to use a modern
 stream cipher with high throughput, for example SOSEMANUK [1]. But I'm
 not sure whether a suite of cryptographic functions is really something
 that must be included in a language's standard library.


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Patch to use better PRNG on BSD's

[Jim Ursetto]

We've been through this conversation multiple times.  For example,
I already proposed a patch using random -- which is way more portable
than arc4random (!!) -- and it was rejected.

The ultimate solution is a self-contained PRNG of reasonable
quality in core.

Or users may use the random-bsd egg in the meantime.

On Apr 10, 2012, at 3:18 PM, Peter Bex wrote:

 On Tue, Apr 10, 2012 at 07:15:44PM +0300, Timo Myyrä wrote:
 I noticed that chicken uses old rand / srand functions when better
 alternatives are present.
 Patch makes BSD's use arc4random instead of rand.
 
 NetBSD doesn't have arc4random_uniform either, so that'd need to be added
 to the test.
 
 I think a cleaner and more robust way is to actually put a PRNG inside
 Chicken itself.  That way all platforms benefit from a good random
 generator instead of it being a hit-and-miss situation.  Chicken ought
 to provide as good an abstraction over nasty annoying OS details as it
 can.
 
 Having said that, your patch is an unmistakable improvement over the
 current situation, especially on MacOS X, assuming they bothered to
 implement arc4random properly this time...
 
 I'm not 100% sure this is correct so test, at least the Mac OS X part
 as it doesn't have arc4random_uniform() function.
 Builds and seems to work OK on OpenBSD when applied to 4.7.0 version.
 
 Your patch got mangled somewhere along the way.  I think it might be the
 mailinglist software at nongnu.org that did that.  Please put patches in
 your mail as a separate attachment instead of inlining them.
 
 Cheers,
 Peter
 -- 
 http://sjamaan.ath.cx
 --
 The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music.
   -- Donald Knuth
 
 ___
 Chicken-hackers mailing list
 Chicken-hackers@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-hackers


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Patch to use better PRNG on BSD's

[Jim Ursetto]

E.g.: http://bugs.call-cc.org/ticket/218

On Apr 10, 2012, at 3:47 PM, Jim Ursetto wrote:

 We've been through this conversation multiple times.  For example,
 I already proposed a patch using random -- which is way more portable
 than arc4random (!!) -- and it was rejected.
 
 The ultimate solution is a self-contained PRNG of reasonable
 quality in core.
 
 Or users may use the random-bsd egg in the meantime.


___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] random returns the same number on x86_64 all the time

[Jim Ursetto]

On Mar 4, 2012, at 12:42 AM, John Cowan wrote:

 That makes no sense when you are asking for an integer between 0 and 2^62-1.
 
 In that case the underlying interface should be asked to deliver two 32-bit
 values.

That gets you up to 53 bits due to the (double) scaling, but the bottom bits 
will still be zero.

On Mar 3, 2012, at 11:02 PM, John Cowan wrote:

 This is why Common Lisp doesn't provide an interface giving you a random
 integer, only a random integer in the range 0 to n for a given n.

Chicken does the same thing.

In fact if you just want to fill all 62 bits then you are better off with an 
interface giving you a random integer.  Something like

#define C_random_exact() C_fix(((rand()  0x7fff)  31) | (rand()  
0x7fff))  

assuming RAND_MAX = 0x7fff.

But the question is what are you going to do with those bits, and I don't know 
how the hash table randomization works.  I am simply letting Peter know that 
the bottom bits are currently zero and should not be used, and if only 30 bits 
are needed during the randomization, you might as well do (random 2^30-1) 
instead of (random most-positive-fixnum) anyway.

Obviously the non-randomness of rand() is another limiting factor.

Jim
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers