Re: Not compiling statically

[Jim Ursetto]

On Feb 22, 2023, at 4:20 AM, felix.winkelm...@bevuta.com wrote:
> 
>> Hi everyone. Sorry if this is an obvious question, but can I *not* compile 
>> an extension statically?
> 
> I think this may require a csc option (to override the
> default setting). I can look into this, but currently it
> is not supported.

Thanks Felix, I wouldn’t really worry about it. It is just making CI take 
longer than expected, but that is not a big deal.

Jim

Not compiling statically

[Jim Ursetto]

Hi everyone. Sorry if this is an obvious question, but can I *not* compile an 
extension statically?

In other words, I’m trying to build chickadee, and I believe it's taking around 
twice as long as expected because it is building every egg dependency 
dynamically and then again statically.

Is it possible to not do this? This seems to be controlled by 
`default-extension-linkage` and by each individual extension with the `linkage` 
property, but there doesn’t seem to be a way to control this at runtime or 
build a whole set of dependencies dynamically only.

Jim

Re: After upgrade to 5.3.0 chickadee is broken

[Jim Ursetto]

This does look suspicious. I don’t remember seeing this in 5.2 though (you had 
opened this ticket 16 months ago). Did this just manifest itself suddenly?

> On Dec 24, 2021, at 11:06, Kon Lovett  wrote:
> 
> similar - https://bugs.call-cc.org/ticket/1721
> 
>> On Dec 24, 2021, at 8:49 AM, T. Kurt Bond  wrote:
>> 
>> Ok, I've figured out what went wrong, but I'm not sure why that happened.  
>> Again, this is happening on macOS using homebrew to install CHICKEN Scheme 
>> 5.3.0.  
>> 
>> The chickadee.install.sh commands that create .../share/chicken and copy the 
>> directory chickadee to it use 
>> /usr/local/Cellar/chicken/5.3.0/usr/local/Cellar/chicken/5.3.0/share/chicken 
>> instead of /usr/local/Cellar/chicken/5.3.0/share/chicken.  That is, it 
>> repeats the /usr/local/Cellar/chicken/5.3.0/ part, so the files end up in 
>> the wrong place.
>> 
>> Here are the commands from chickadee.install.sh:
>> 
>> mkdir -p 
>> "${DESTDIR}"'/usr/local/Cellar/chicken/5.3.0/usr/local/Cellar/chicken/5.3.0/share/chicken'
>> cp -v -r '/Users/tkb/.cache/chicken-install/chickadee/chickadee' 
>> "${DESTDIR}"'/usr/local/Cellar/chicken/5.3.0/usr/local/Cellar/chicken/5.3.0/share/chicken'
>> 
>> So, something is going wrong when chickadee.install.sh is generated.
>> 
>> I've added an issue in the chickadee github repository: 
>> https://github.com/ursetto/chickadee/issues/1
>> 
>> On Thu, Dec 23, 2021 at 12:30 PM T. Kurt Bond  wrote:
>>> I'm using macOS with chicken from homebrew.
>>> 
>>> I installed chicken-doc and then chickadee, but now when I run "chickadee 
>>> serve" I get the following message:
>>> 
>>> $ chickadee  serve
>>> 
>>> Error: (change-directory) cannot change current directory - No such file or 
>>> directory: "/usr/local/Cellar/chicken/5.3.0/share/chicken/chickadee"
>>> 
>>> Call history:
>>> 
>>> spiffy.scm:548: chicken.condition#with-exception-handler
>>> spiffy.scm:548: ##sys#call-with-values
>>> spiffy.scm:548: scheme#eval
>>>   (let () (import openssl) ssl-port?)
>>>   (##core#let () (import openssl) ssl-port?)
>>> spiffy.scm:548: k691
>>> spiffy.scm:547: g694
>>> spiffy.scm:610: dynamic-import
>>> spiffy.scm:548: scheme#call-with-current-continuation
>>> spiffy.scm:548: chicken.condition#with-exception-handler
>>> spiffy.scm:548: ##sys#call-with-values
>>> spiffy.scm:548: scheme#eval
>>>   (let () (import openssl) ssl-port->tcp-port)
>>>   (##core#let () (import openssl) ssl-port->tcp-port)
>>> spiffy.scm:548: k691
>>> spiffy.scm:547: g694   <--
>>> 
>>> And, indeed, that directory is missing.  I've uninstalled chickadee and 
>>> installed it again, but that made no difference. 
>>> 
>>> Any idea of what is going wrong?
>>> -- 
>>> T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
>> 
>> 
>> -- 
>> T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
> 

Re: Reository Path, FAQ, and Index Questions

[Jim Ursetto]

> On Nov 15, 2021, at 8:06 AM, Christian Himpe 
>  wrote:
> 
> Lastly, I would like to ask if CHICKEN Scheme has a function/symbol index, as 
> for example Chez Scheme has:
> 
> https://www.scheme.com/csug8/csug_1.html

https://api.call-cc.org/5/doc  might do what you 
want. Although not a single-page index, you can search for any identifier, and 
you can get a list (“contents") of all identifiers documented in an egg. This 
documentation is sourced from the wiki, just presented in a different format.

As others suggested, it is possible to run a copy of chickadee (web) or 
chicken-doc (backend) locally. But the web version is convenient and needs no 
setup.

Jim

Re: new egg: cmark

[Jim Ursetto]

> On Nov 3, 2021, at 3:44 PM, Harley Swick  wrote:
> 
> There is a different cmark egg for Chicken 4. Since my additions are 
> significantly larger than
> the total of the old egg, I didn't feel it was fair to drop a bunch of 
> strange code on someone
> who may not want to be stuck maintaining it. I have added aliases to make 
> this egg
> a compatible replacement for users upgrading from 4 to 5. I don't foresee any 
> issues with conflicts since
> this egg only works with Chicken 5.

Harley,

Welcome. I would recommend adding a similar explanation to your wiki page, just 
that the 5 egg is a totally new codebase but has backwards-compatibility via 
aliases. Probably not critical since 4.x is old now, but might be nice if 
anyone is curious.

It’s also customary to add license information and a simple changelog / version 
history inline. In this case it would just be e.g. “0.1.0 Initial release for 
Chicken 5” or something like that. Check out other eggs for details.

Jim

Re: Make the args egg stop truncating long options in args:usage

[Jim Ursetto]

> On Sep 9, 2021, at 3:00 PM, T. Kurt Bond  wrote:
> 
> I know that you can parameterize args:width to change the width of the
> options display, but wouldn't it be better to NOT truncate things if
> args:width is too narrow, and instead output the whole option display,
> end the line, and then output the docstring on the next line, like
> this:

Applied in args 1.6.2. —Jim

Re: chicken-doc instructions recommend extracting tar file as root

[Jim Ursetto]

Hi there,

Thanks for your interest. I recommend checking out a copy of the svn wiki repo 
and using chicken-doc-admin to import it, instead of using the tarball. For 
details see the Quick Start section in 
https://api.call-cc.org/5/doc/chicken-doc-admin.

Or, extract the tarball somewhere in your home directory with normal user 
permissions, and set CHICKEN_DOC_REPOSITORY to the extraction path, as 
mentioned in the documentation.

You may also use the public server https://api.call-cc.org if browser based 
docs are ok.

Jim

> On May 8, 2021, at 2:49 PM, Lassi Kortela  wrote:
> 
> Currently https://wiki.call-cc.org/eggref/5/chicken-doc instructs users to 
> run:
> 
> curl https://3e8.org/pub/chicken-doc/chicken-doc-repo-5.tgz | sudo tar zx
> 
> in a directory that's often located within /usr. This is not ideal from a 
> security perspective, especially given that that the remote file changes 
> daily so some users can be expected to repeat the command lots of times.
> 
> An immediate safeguard is to edit the wiki page to add the verbose flag to 
> the suggested tar command, causing it to show the pathnames of all the files 
> it extracts.
> 
> For a proper fix, could chicken-doc be modified to download the tar file, 
> sanity-check its contents, and unpack it safely into the user's home 
> directory instead?
> 
> Alternatively, if the documentation is shipped in some kind of file format 
> with an index for fast lookup, it doesn't need to be extracted into multiple 
> files at all. There are reasonably simple databases like CDB and Berkeley DB 
> for jobs like this.
> 
> -l
> 

Re: Docker container of Chicken's git master

[Jim Ursetto]

Neat, I started something like this for Chicken and Chickadee about a year ago 
and never released it.
Feel free to mine my code on the slight chance there is anything useful.

https://github.com/ursetto/chicken-docker 

https://github.com/ursetto/chickadee-docker 



> On May 3, 2020, at 11:05 AM, Lassi Kortela  wrote:
> 
> docker run -it schemers/chicken:head
> 
> Currently updated manually. The release containers also continue to be 
> maintained:
> 
> docker run -it schemers/chicken:4
> docker run -it schemers/chicken:5
> 

[Chicken-users] cenv -- Chicken 5 virtual environments

[Jim Ursetto]

Hola, amigos. I’ve written a little script, cenv, which takes the pain out of 
using user repositories. It's called cenv because coops was taken. It’s modeled 
somewhat on Python virtualenv, though it’s more simplistic.

See https://github.com/ursetto/cenv , or 
simply curl -O https://raw.githubusercontent.com/ursetto/cenv/master/cenv.scm 
 .

## Description

A single `csi` script, `cenv.scm`, which creates a self-contained Chicken 5 
environment in a specified directory. It remembers which Chicken you used to 
create it, and it keeps its own repository of eggs, which extends that base 
Chicken.

When the environment is active, `csi` and `csc` and compiled programs use this 
repository, falling back to the base repository if an extension does not exist. 
`chicken-install` installs eggs into this new repository. `chicken-uninstall` 
is limited to the new repository, and `chicken-status` shows both. Generally, 
everything behaves as you expect.

`cenv` could be useful if:

- You are a regular user using the system Chicken and you have no permissions 
to, or don't want to, install eggs systemwide.
- You want to test or switch between different versions of eggs, without 
creating an entire Chicken installation to house them.___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Bug with #:optional in args egg?

[Jim Ursetto]

On Jun 19, 2017, at 4:25 PM, Diego A. Mundo  wrote:
> 
> With the example on the args eggref 
> (http://wiki.call-cc.org/eggref/4/args#examples 
> ) slightly modified to this:
> 
…

> You can see how the behavior of using required arguments (-e or --elephant) 
> differs from using optional arguments (-d or --depth). More specifically, -e 
> and --elephant work, parsing their arguments as expected, whereas -d produces 
> #f except when the option is passed directly after the flag with no spaces 
> (-d10, for example), and --depth always returns #f.

Basically, SRFI-37 is a bit broken and, as a thin layer on top of it, the args 
egg should probably be considered deprecated because of that (although, it does 
work in a pinch). Not to mention the questionable use of macro syntax the args 
egg demands.

The issues you mention are documented, in a sense, in args-examples.scm in the 
SVN repository. Unfortunately it looks like I didn’t actually put this in the 
wiki documentation proper:

;;; Note that missing required args can only be detected if their option 
appears last,
;;; and optional args must not be separated from their option by a space
;;; (e.g. -d2 or --debug=2, not -d 2 or --debug 2).

Optional arguments are a little iffy in the first place. To avoid confusion in 
parsing, you basically have to implement them as in SRFI-37, requiring an = or 
no interceding space, because otherwise it’s too easy to interpret an operand 
or option as an optional argument value. The SRFI specifies that operands and 
options can be intermingled in any order, making this even more important.

Another problem with SRFI-37 is that (as mentioned above) missing required 
arguments can only be detected if they come last on the command line — because 
the reference implementation, at least, will consider “--foo --bar” to be an 
option of “--foo” with a value of “--bar”, so the value can never be missing! 
It’s possible the SRFI-37 implementation could be rewritten to consider “--bar” 
to always be an option, never an argument, unless occurring after the “--“ end 
of option string.

Anyway, I would avoid using the args egg because the behavior of SRFI-37 as 
specified is not really what we expect from modern argument parsers.

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

Re: [Chicken-users] example from rpc egg crashes at around 2k calls for me ....

[Jim Ursetto]

It would coincide with a typical fd ulimit of 2048.  If the issue is actually 
too many tcp connections, I can't see why, as both the client and server should 
close the connection after completion. And, you are running these client 
connections serially. Maybe try dummying out the database calls. I think Peter 
is right that it's trying to serialize a database exception and failing. One 
option would be to handle the db open or query exception yourself in your 
server and print out the exception (before reraising it).
Jim

> On Dec 8, 2015, at 17:42, Matt Welland  wrote:
> 
>> On Tue, Dec 8, 2015 at 12:44 AM, Peter Bex  wrote:
>> On Mon, Dec 07, 2015 at 10:38:33PM -0700, Matt Welland wrote:
>> > I don't understand why this is crashing. I'm guessing I'm failing to close
>> > a connection or finalize something. I also saw the same problem when I used
>> > sqlite3 instead of sql-de-lite. Any help or suggestions of where to look
>> > would be appreciated.
>> 
>> From the call chain, it looks like something broke during query execution
>> and it's trying to serialize the exception object, which probably contains
>> a reference to the database connection (which is a pointer).
>> 
>> Try catching all exceptions and raising a placeholder exception with a
>> simple (error "foo")
> 
> Thanks Peter. I'm not sure where to add this but I'll experiment with it 
> tonight.
> 
> I did test on a different system today and it kept going past 6k calls. 
> However running "netstat|wc -l" showed a rapidly increasing number of TCP 
> connections. It seems likely I'm not closing the connection but I don't see 
> where to add the close.
>  
>> 
>> Cheers,
>> Peter
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] regex to be actively deprecated some day?

[Jim Ursetto]

Well, shoot.  Other fearless Chickeneers already noticed this bug and marked it 
as invalid in (http://bugs.call-cc.org/ticket/1189#comment:2 
<http://bugs.call-cc.org/ticket/1189#comment:2>) due to order of operations.  
Basically, in “1” the backslash is itself backslashed, so it becomes the 
text \1.

Anyway, the upshot is, the irregex version is better.

Jim

> On Sep 9, 2015, at 23:24, Jim Ursetto  wrote:
> 
> Matt,
> 
> In fact, there might be a bug in the \1 substitution mechanism, so it is not 
> a bad idea to use the irregex-style replacement anyway, even if you are 
> sticking with POSIX REs.  I noticed this a few days ago when attempting to 
> escape characters using a backslash.  On the other hand, I could just be 
> doing it wrong.
> 
> This is correct:
> 
> #;354> (print (irregex-replace/all "([:@{}>])" "{foo:}" "\\" 1))
> \{foo\:\}   
> 
> This is obviously not correct:
> 
> #;355> (print (string-substitute "([:@{}>])" "1" "{foo:}" #t))  
> \\1foo\\1\\1   
> 
> But, when prefixing the character with something other than backslash, \1 
> works fine:
>   
> #;356> (print (string-substitute "([:@{}>])" "^\\1" "{foo:}" #t))   
> ^{foo^:^}   
> 
> This is with 4.8.0.6 (although I don’t think it matters) and the latest regex.
> 
> Jim
> 
>> On Sep 7, 2015, at 21:07, Matt Welland > <mailto:mattrwell...@gmail.com>> wrote:
>> 
>> Ok, I sort of panicked when I saw what looked like regex being deprecated 
>> (read my original message below if you wish). After re-reading the irregex 
>> egg wiki page a few times it looks like all is well assuming these two 
>> things:
>> 
>> 1. irregex unit will continue to support reading the pcre syntax
>> 2. those using the backslash substitution destination string syntax be 
>> prepared to write a parser/converter.
>> 
>> As a request to the developers - please consider adding the function from 
>> the regex egg that parses the \N type dest strings to irregex.
>> 
>> Thanks.
>> 
>> Matt
>> -=-
>> == my original "panicked"message =
>> 
>> From a comment to Chicken-janitors regarding bug #1189 I saw this: 
>> 
>> "This seems to be an undocumented feature of the substring-replace
>>  function, which allows you to escape the backslash. I would recommend
>>  using irregex, the regex egg's API is kind of deprecated anyway, and it's
>>  also not very efficient."
>> 
>> Then in the regex egg wiki page I see:
>> 
>> "It is a thin wrapper around the functionality provided by irregex 
>> <http://wiki.call-cc.org/man/4/Unit%20irregex> and is mostly intended to 
>> keep old code working."
>> 
>> These statements leave me a little concerned as I use the regex egg a fair 
>> amount and I don't have the energy to learn yet another abstraction or to go 
>> back and rewrite old code. More importantly I expose the use of regexes to 
>> users of Megatest and logpro and they have no tolerance for doing something 
>> considered a "standard" in a different way, especially if it means using 
>> something that looks like Scheme.
>> 
>> From re-reading the irregex egg wiki page I think the only thing I rely on 
>> that is missing is the \1 substitution mechanism. Is there an alternative 
>> syntax? All I see is the following:
>> (irregex-replace "(.)(.)" "ab" 2 1 "*")
>> Which would be implemented using a destination of "\2\1*" in 
>> string-substitute. Converting an old-style destination string to the list of 
>> numbers and strings would not be too hard I suppose.
>> 
>> Thanks,
>> 
>> Matt
>> -=-
>> 
>> 
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org <mailto:Chicken-users@nongnu.org>
>> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 

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

Re: [Chicken-users] regex to be actively deprecated some day?

[Jim Ursetto]

Matt,

In fact, there might be a bug in the \1 substitution mechanism, so it is not a 
bad idea to use the irregex-style replacement anyway, even if you are sticking 
with POSIX REs.  I noticed this a few days ago when attempting to escape 
characters using a backslash.  On the other hand, I could just be doing it 
wrong.

This is correct:

#;354> (print (irregex-replace/all "([:@{}>])" "{foo:}" "\\" 1))
\{foo\:\}   

This is obviously not correct:

#;355> (print (string-substitute "([:@{}>])" "1" "{foo:}" #t))  
\\1foo\\1\\1  

But, when prefixing the character with something other than backslash, \1 works 
fine:
  
#;356> (print (string-substitute "([:@{}>])" "^\\1" "{foo:}" #t))   
^{foo^:^}   

This is with 4.8.0.6 (although I don’t think it matters) and the latest regex.

Jim

> On Sep 7, 2015, at 21:07, Matt Welland  wrote:
> 
> Ok, I sort of panicked when I saw what looked like regex being deprecated 
> (read my original message below if you wish). After re-reading the irregex 
> egg wiki page a few times it looks like all is well assuming these two things:
> 
> 1. irregex unit will continue to support reading the pcre syntax
> 2. those using the backslash substitution destination string syntax be 
> prepared to write a parser/converter.
> 
> As a request to the developers - please consider adding the function from the 
> regex egg that parses the \N type dest strings to irregex.
> 
> Thanks.
> 
> Matt
> -=-
> == my original "panicked"message =
> 
> From a comment to Chicken-janitors regarding bug #1189 I saw this: 
> 
> "This seems to be an undocumented feature of the substring-replace
>  function, which allows you to escape the backslash. I would recommend
>  using irregex, the regex egg's API is kind of deprecated anyway, and it's
>  also not very efficient."
> 
> Then in the regex egg wiki page I see:
> 
> "It is a thin wrapper around the functionality provided by irregex 
>  and is mostly intended to keep 
> old code working."
> 
> These statements leave me a little concerned as I use the regex egg a fair 
> amount and I don't have the energy to learn yet another abstraction or to go 
> back and rewrite old code. More importantly I expose the use of regexes to 
> users of Megatest and logpro and they have no tolerance for doing something 
> considered a "standard" in a different way, especially if it means using 
> something that looks like Scheme.
> 
> From re-reading the irregex egg wiki page I think the only thing I rely on 
> that is missing is the \1 substitution mechanism. Is there an alternative 
> syntax? All I see is the following:
> (irregex-replace "(.)(.)" "ab" 2 1 "*")
> Which would be implemented using a destination of "\2\1*" in 
> string-substitute. Converting an old-style destination string to the list of 
> numbers and strings would not be too hard I suppose.
> 
> Thanks,
> 
> Matt
> -=-
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Inserting Binary Data with sql-de-lite

[Jim Ursetto]

Andy,
What if you convert the string to a blob before passing it in?
Jim

> On Jun 22, 2015, at 12:16, Andy Bennett  wrote:
> 
> Hi,
> 
> I'm using a parameterized statement to insert binary data into sql-de-lite 
> (0.6.6) on CHICKEN 4.10rc1.
> 
> When I call sql-de-lite's exec procedure I get:
> 
> -
> Error: (##sys#make-c-string) cannot represent string with NUL bytes as C 
> string: "╴╴\x00...
> 
> ...
> 
>Call history:
> 
>sql-de-lite.scm:459: lru-cache#lru-cache-capacity
>sql-de-lite.scm:188: ##sys#block-set!
>sql-de-lite.scm:461: lru-cache#lru-cache-set!
>sql-de-lite.scm:175: ##sys#block-set!
>sql-de-lite.scm:567: bind-parameter-count
>sql-de-lite.scm:581: keyword?
>sql-de-lite.scm:583: bind
>sql-de-lite.scm:594: %bind-int
>sql-de-lite.scm:605: bind-parameter-count
>sqlite3-api.scm:155: ##sys#make-c-string
>sql-de-lite.scm:584: loop
>sql-de-lite.scm:581: keyword?
>sql-de-lite.scm:583: bind
>sql-de-lite.scm:594: %bind-int
>sql-de-lite.scm:605: bind-parameter-count
>sqlite3-api.scm:155: ##sys#make-c-string<--
> -
> 
> 
> What's the recommended way to do or fix this? In the CHICKEN 4.7 days I have 
> taken binary data *out* of SQLite but I've not done it since the NUL-string 
> problems were addressed.
> 
> The data gets into CHICKEN by reading it from a port using http-client.
> 
> 
> Thanks for your help.
> 
> Sorry I'm light on details: I can send more sensible stuff on request.
> 
> 
> 
> -- 
> andy...@ashurst.eu.org
> http://www.ashurst.eu.org/
> http://www.gonumber.com/andyjpb
> 0x7EBA75FF
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Minor problem with args egg

[Jim Ursetto]

> On May 13, 2015, at 11:55, Jim Ursetto  wrote:
> 
> #t does seem to make sense ... the existing behavior comes from the srfi-37 
> implementation which sets the value to #f for #:none args.  I could modify 
> the args egg to change #f to #t in this case; I don't think this would cause 
> any problems.  Will think it over tonight.
> 

In args 1.5.1, #:none options now return a value of #t instead of the srfi-37 
default of #f, so they are effectively booleans.  This would also set up the 
possibility for —no-xx options which set option ‘xx' to #f; naturally, 
that is not yet implemented.

#:optional options will still return #f when an argument is not provided, since 
it is not nice to explicitly test against #t to distinguish between argument 
provided and not.  Also, optional arguments should not be boolean in my 
opinion.  An argument value of #f allows you to implement a default of “1" by 
placing this in the body:

 (set! arg (or arg “1”))

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

Re: [Chicken-users] Minor problem with args egg

[Jim Ursetto]

On Wed, May 13, 2015 at 4:52 AM, Peter Bex  wrote:

> On Wed, May 13, 2015 at 03:38:41AM -0600, Matt Gushee wrote:
> > Anyway, it seems that if you specify an option with no arguments, e.g.
> >
> >(args:make-option (v version) #:none
> >   "Display compiled versions.")
> >
> > ... then when the user invokes the program with that option, you get:
> >
> >'((v . #f) (version . #f))
> >
> > ... which means that alist-ref will not tell you whether the user passed
> > that option, or it simply isn't present. I wonder if it wouldn't be
> better
> > for a no-arg option to produce a symbol, #:undefined perhaps?
>
> I would expect #t to be present if the user passed the option.  This
> allows for easy presence-checking, and it's similar to an option that
> accepts "yes" or "no".
>

#t does seem to make sense ... the existing behavior comes from the srfi-37
implementation which sets the value to #f for #:none args.  I could modify
the args egg to change #f to #t in this case; I don't think this would
cause any problems.  Will think it over tonight.

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

Re: [Chicken-users] Termbox using

[Jim Ursetto]

Hi frad,

If I may make a suggestion. Lists are not random-access like arrays are. 
Similarly, checking a list's length traverses the whole list.

You should always iterate over a list by using car and cdr, not list-ref. So, 
to your "do" loop, you could add another loop variable over the list called L, 
iterate over it using cdr, and as the termination condition, test with null?. 
Then your list-ref becomes car. The way you have it, the algorithm is O(n^2). 
If you need random access you should use a vector, however that is not 
necessary for your test program.

Jim

> On May 2, 2015, at 07:34, f...@indexi.net wrote:
> 
> Hi,
> 
> (Sorry for my English)
> 
> Newbie with Scheme, i try to use the termbox egg.
> It seems me a very nice and cool library and the documentation helps me a lot.
> I am learning Scheme and appreciate Chicken implementation.
> Here a little piece of code to print a simple text menu.
> But this code isn't in the functionnal way (very iterative).
> 
> 
> (use termbox)
> (init)
> 
> (define running (make-parameter #t))
> (define choice 1)
> 
> (define (menu x y lst)
>  (let loop ()
>(if (> choice (length lst)) (set! choice 1))
>(if (< choice 1) (set! choice (length lst)))
>(do ((i 0 (+ i 1)))
>((= i (length lst)))
>(if (= choice (+ i 1))
>(bprintf x (+ y i) (style black) (style white) (list-ref lst i))
>(bprintf x (+ y i) (style white) (style black) (list-ref lst i
>(present)
>(poll (lambda (mod key ch)
>  (cond
>((eq? key key-arrow-down) (set! choice (+ choice 1)))
>((eq? key key-arrow-up) (set! choice (- choice 1)))
>((eq? key key-enter) (running #f
>  (lambda (w h) (loop)))
>(when (running) (loop
> 
> ;; an example
> (menu 5 8 '("Choice 1" "Choice 2" "Choice 3" "Other"))
> 
> (shutdown)
> 
> (printf "Your choice: ~a\n" choice)
> 
> 
> Maybe, someone could give me some advices or corrections to make it better.
> 
> Regards,
>  frad
> 
> http://blog.indexi.net
> 
> 
> 
> 
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] about egg/pty

[Jim Ursetto]

1024 is the default value of FD_SETSIZE i.e. the largest fd one can use with 
select(), so I think you have the right idea.  Use of a magic constant might be 
reconsidered though.  Could also convert the code to use poll() like Chicken 
core was some time ago.
Jim


> On Feb 20, 2015, at 02:27, Christian Kellermann  wrote:
> 
> Hi!
> 
> Chaos Eternal  writes:
> 
>> uses a magic number 1024 , which used to pack master fd and slave fd
>> into one integer to return.
>> 
>> but why 1024 and what happens when the slave fd is greater than 1024?
> 
> I am not the author but 1024 happens to be the default maximum number of
> open files for most systems(tm).
> 
> And yes if that assumption is wrong it will break and do strange things.
> 
> As I see it it's just a quick hack to get both values out of C without
> further FFI tricks. Maybe I am wrong and Alex can explain the rationale
> behind it, if there is any.
> 
> Kind regards,
> 
> Christian
> 
> -- 
> May you be peaceful, may you live in safety, may you be free from
> suffering, and may you live with ease.
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Help with udp6 / socket

[Jim Ursetto]

I’ve documented the family parameter to udp-open-socket and fleshed out the 
examples (including a daytime client/server pair).  
Hope this helps.

http://api.call-cc.org/doc/udp6

Jim

> On Feb 17, 2015, at 03:56, Scott McCoid  wrote:
> 
> Hi Jim,
> 
> This completely worked for me, thanks for the clear example! I didn't even 
> think to check if (udp-open-socket) also accepted extra arguments. 
> 
> Thanks again!
> Scott
> 
> On Tue, Feb 17, 2015 at 4:17 AM, Jim Ursetto  <mailto:zbignie...@gmail.com>> wrote:
> Scott,
> 
> This works on my system (10.10.2, CHICKEN 4.8.0.6).  Note the undocumented 
> argument to udp-open-socket… not sure what I was thinking.
> If this works for you, I will document the argument and add the example to 
> the wiki.
> 
> 
> (use udp6)
> 
> (define s (udp-open-socket 'inet6))
> (udp-bind! s "::" 1337);; unspecified address; accept both ipv4 and ipv6
> (let loop ()
>   (receive (len str host port) (udp-recvfrom s 1024)
> (print "received " len " bytes from [" host "]:" port " : " str))
>   (loop))
> (udp-close-socket s)
> 
> 
> ;; Then we can run netcats using IPv4 and IPv6:
> 
> $ nc -6 -u localhost 1337
> hello
> ^C
> 
> $ nc -4 -u localhost 1337
> hi
> ^C
> 
> ;; And you should get the following output:
> 
> received 6 bytes from [::1]:62028 : hello
> received 3 bytes from [:::127.0.0.1]:61031 : hi
> 
> 
>> On Feb 16, 2015, at 07:06, Scott McCoid > <mailto:mccoid.sc...@gmail.com>> wrote:
>> 
>> Hi Christian!
>> 
>> Thanks for the quick help and netcat tip. I was able to send from my script 
>> and receive with netcat (for example: nc -u -6 -l 8000) without any 
>> problems. (sending to port 8000 in my script)
>> 
>> I've tried doing the reverse situation, where I receive on the script side 
>> and send using netcat, but I haven't been able to get this to work. I don't 
>> have any errors, but I'm not receiving anything for some reason. 
>> 
>> I'll work on some chicken scripts that talk to each other and see if I can 
>> get this to work properly. 
>> 
>> Thanks again for your help!
>> Scott
>> 
>> On Mon, Feb 16, 2015 at 11:49 AM, Christian Kellermann > <mailto:ck...@pestilenz.org>> wrote:
>> Hi Scott!
>> 
>> Scott McCnoid mailto:mccoid.sc...@gmail.com>> 
>> writes:
>> 
>> > I'm reasonably new to chicken-scheme (and scheme in general), and I'm
>> > having trouble with the udp6 (and likewise, socket) eggs. I'm trying to run
>> > the example code, but the connection is always refused.
>> >
>> > *Error: (socket-receive!) cannot read from socket - Connection refused:
>> > #*
>> >
>> > I looked into the socket code and it seems that this is probably not the
>> > fault of these eggs per se, but probably something I'm doing wrong. For
>> > example, the *%socket-receive!* function makes a call to the 
>> > *recv* function, which always returns -1. I've tried using other port
>> > numbers to connect to, but this doesn't seem to make a difference.
>> >
>> > I'm on Mac OS *10.10.2* using chicken scheme v.* 4.9.0.1 *(stability/4.9.0)
>> > (rev 8b3189b)
>> >
>> > I'm happy to help track this down if it's a bug, just let me know.
>> 
>> The most likely reason is that on Mac OS X there is noone listening on
>> port 13.
>> 
>> You can check that manually with "nc localhost 13".
>> 
>> The next problem is that noone is actually listening on ipv6 for that
>> port. I ran into this when trying to simulate the datetime service with:
>> 
>> "date | sudo nc -u -l -p 13"
>> 
>> Connecting with v4 works, with v6 it doesn't.
>> 
>> My suggestion is to test this with a known open service on your system
>> or by creating a server explicitly bound to a v6 address.
>> 
>> Please don't hesitate to report further issues and troubles!
>> 
>> Kind regards,
>> 
>> Christian
>> 
>> --
>> May you be peaceful, may you live in safety, may you be free from
>> suffering, and may you live with ease.
>> 
>> 
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org <mailto:Chicken-users@nongnu.org>
>> https://lists.nongnu.org/mailman/listinfo/chicken-users 
>> <https://lists.nongnu.org/mailman/listinfo/chicken-users>
>> 
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org <mailto:Chicken-users@nongnu.org>
>> https://lists.nongnu.org/mailman/listinfo/chicken-users 
>> <https://lists.nongnu.org/mailman/listinfo/chicken-users>
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Help with udp6 / socket

[Jim Ursetto]

Scott,

This works on my system (10.10.2, CHICKEN 4.8.0.6).  Note the undocumented 
argument to udp-open-socket… not sure what I was thinking.
If this works for you, I will document the argument and add the example to the 
wiki.


(use udp6)

(define s (udp-open-socket 'inet6))
(udp-bind! s "::" 1337);; unspecified address; accept both ipv4 and ipv6
(let loop ()
  (receive (len str host port) (udp-recvfrom s 1024)
(print "received " len " bytes from [" host "]:" port " : " str))
  (loop))
(udp-close-socket s)


;; Then we can run netcats using IPv4 and IPv6:

$ nc -6 -u localhost 1337
hello
^C

$ nc -4 -u localhost 1337
hi
^C

;; And you should get the following output:

received 6 bytes from [::1]:62028 : hello
received 3 bytes from [:::127.0.0.1]:61031 : hi


> On Feb 16, 2015, at 07:06, Scott McCoid  wrote:
> 
> Hi Christian!
> 
> Thanks for the quick help and netcat tip. I was able to send from my script 
> and receive with netcat (for example: nc -u -6 -l 8000) without any problems. 
> (sending to port 8000 in my script)
> 
> I've tried doing the reverse situation, where I receive on the script side 
> and send using netcat, but I haven't been able to get this to work. I don't 
> have any errors, but I'm not receiving anything for some reason. 
> 
> I'll work on some chicken scripts that talk to each other and see if I can 
> get this to work properly. 
> 
> Thanks again for your help!
> Scott
> 
> On Mon, Feb 16, 2015 at 11:49 AM, Christian Kellermann  > wrote:
> Hi Scott!
> 
> Scott McCnoid mailto:mccoid.sc...@gmail.com>> writes:
> 
> > I'm reasonably new to chicken-scheme (and scheme in general), and I'm
> > having trouble with the udp6 (and likewise, socket) eggs. I'm trying to run
> > the example code, but the connection is always refused.
> >
> > *Error: (socket-receive!) cannot read from socket - Connection refused:
> > #*
> >
> > I looked into the socket code and it seems that this is probably not the
> > fault of these eggs per se, but probably something I'm doing wrong. For
> > example, the *%socket-receive!* function makes a call to the 
> > *recv* function, which always returns -1. I've tried using other port
> > numbers to connect to, but this doesn't seem to make a difference.
> >
> > I'm on Mac OS *10.10.2* using chicken scheme v.* 4.9.0.1 *(stability/4.9.0)
> > (rev 8b3189b)
> >
> > I'm happy to help track this down if it's a bug, just let me know.
> 
> The most likely reason is that on Mac OS X there is noone listening on
> port 13.
> 
> You can check that manually with "nc localhost 13".
> 
> The next problem is that noone is actually listening on ipv6 for that
> port. I ran into this when trying to simulate the datetime service with:
> 
> "date | sudo nc -u -l -p 13"
> 
> Connecting with v4 works, with v6 it doesn't.
> 
> My suggestion is to test this with a known open service on your system
> or by creating a server explicitly bound to a v6 address.
> 
> Please don't hesitate to report further issues and troubles!
> 
> Kind regards,
> 
> Christian
> 
> --
> May you be peaceful, may you live in safety, may you be free from
> suffering, and may you live with ease.
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/chicken-users 
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] csc/csi man pages deficient

[Jim Ursetto]

If you have chicken-doc installed, another option is to run e.g.

chicken-doc csi

or consult either of these links, from which the above is taken:

http://api.call-cc.org/doc/csi
http://wiki.call-cc.org/man/4/Using%20the%20interpreter

> On Jan 12, 2015, at 12:57, Evan Hanson  wrote:
> 
> Hi Andrew,
> 
> Of course you're right. I've created a ticket[1] to track this issue
> (really, a feature request for "normal" man pages).
> 
> Best regards,
> 
> Evan
> 
> [1]: https://bugs.call-cc.org/ticket/1177
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] sxml and more

[Jim Ursetto]

I've got a couple of blog posts on SXML and namespaces, if you haven't already 
seen them:

http://3e8.org/blog/2010/07/30/namespaces-in-sxml-part-1/
http://3e8.org/blog/2010/07/31/namespaces-in-sxml-part-2/
http://3e8.org/blog/2010/08/01/default-namespaces-in-sxml/

but these are higher-level and so perhaps not useful to you.

There's definitely very little documentation and only marginally more code 
examples.  Most of this I reverse engineered from docs I pieced together and 
the original code itself.  Peter did a great job at adding a lot of 
documentation, for example to the sxpath low-level functions, but there are 
still large gaps.  There's also bugs and missing functionality.  And as noted, 
it's a grab-bag of parts which don't necessarily work together, or provide an 
80% solution.  Case in point, the lack of namespace support in sxml-modify.

If you have specific questions you could try asking here, or on the Sourceforge 
list.  I haven't used sxml-modify myself.  Which low-level tools did you want 
to learn about?

On Jul 25, 2014, at 1:54 PM, Nathaniel Rudavsky-Brody  wrote:

> Hello,
> 
> Since this is my first post, let me say how happy I've been since I 
> discovered Chicken: thanks everyone for creating such a well-thought-out 
> environment.
> 
> I've got a general question about the sxml tools. I've been using the 
> top-level functions for a while now, for tasks I could do in XSLT, but prefer 
> doing in Scheme. I've always found the lower-level interface(s) a bit 
> intimidating. 
> 
> But recently I got stuck on the lack of namespaces in sxml-modify, and 
> started wondering if it would be possible to rewrite it, and then... well 
> more generally, whether it's worth learning how to use the low-level tools, 
> and what I could do with them. Or are pre-post-order and sxpath and sxml-path 
> as good as it gets, for an average user like me? When I search around the 
> web, I can't seem to find examples of more advanced uses of the tools (or at 
> least, well-documented ones...).
> 
> Many thanks for your thoughts,
> 
> Nathaniel
> 
> 
> 
> -- 
> Caractères mobiles
> production ebook artisanale
> http://studio.cm
> +32 (0) 485 136 458
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] CHICKEN 4.9.0rc1 is available

[Jim Ursetto]

Success--

Operating system: Mac OS X 10.9.2
Hardware platform: x86-64
C Compiler: Xcode 5.0.2 gcc -- Apple LLVM version 5.0 (clang-500.2.79) (based 
on LLVM 3.3svn)
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes (pastiche, chickadee)
Execution of eggs works?: yes (chicken-doc-admin, chickadee)

On Apr 18, 2014, at 8:12 AM, Mario Domenech Goulart  
wrote:

> Hi,
> 
> The first release candidate for CHICKEN 4.9.0 has been released.  It's
> available at
> http://code.call-cc.org/dev-snapshots/2014/04/17/chicken-4.9.0rc1.tar.gz
> 
> See http://code.call-cc.org/dev-snapshots/2014/04/17/NEWS for the list
> of changes.
> 
> Please, give it a test and report back to the mailing list your
> findings.
> 
> Here's a suggested test procedure:
> 
>  $ make PLATFORM= PREFIX= install check
>  $ /bin/chicken-install pastiche
> 
> If you want to build CHICKEN with a compiler other than the default one,
> just use C_COMPILER= (e.g., C_COMPILER=clang) on the make
> invocation.
> 
> Of course, feel free to explore other supported build options (see the
> README file for more information) and actually use CHICKEN 4.9.0rc1 for
> your software.
> 
> If you can, please let us know the following information about the
> environment you tested the RC tarball on:
> 
> Operating system: (e.g., FreeBSD 10.0, Debian 7, Windows XP mingw-msys)
> Hardware platform: (e.g., x86, x86-64, PPC)
> C Compiler: (e.g., GCC 4.8.1, clang 3.0-6.2)
> Installation works?: yes or no
> Tests work?: yes or no
> Installation of eggs works?: yes or no
> 
> Thanks in advance.
> 
> The CHICKEN Team
> -- 
> http://www.call-cc.org
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] 4.8.0.5 syntax weirdness

[Jim Ursetto]

Ok. May not be able to make a full release for a few days but will push out the 
change Wednesday, at least.

> On Mar 11, 2014, at 2:31, Peter Bex  wrote:
> 
>> On Mon, Mar 10, 2014 at 11:22:53PM -0500, Jim Ursetto wrote:
>> This is the fix:
>> 
>> commit f8230a466ce3a86f360178f115fb62ee124448b9
>> Author: Peter Bex 
>> Date:   Sun Jun 30 18:50:09 2013 +0200
>> 
>>Fix meta-evaluation to actually take place in the meta environment and 
>> add tests
>> 
>>Signed-off-by: Christian Kellermann 
>> 
>> 
>> It seems pretty simple and applies cleanly to stability and tests out ok.  
>> Do you think I should apply it?
> 
> Thanks for checking that, Jim!
> 
> Considering we have a few other post-4.8.0.5 patches, it might be worth
> tagging a 4.8.0.6 release.  That will be quicker than waiting for the two
> remaining patches, starting the release cycle with release candidates,
> having periods of testing etc.
> 
> Cheers,
> Peter
> -- 
> http://www.more-magic.net

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

Re: [Chicken-users] 4.8.0.5 syntax weirdness

[Jim Ursetto]

This is the fix:

commit f8230a466ce3a86f360178f115fb62ee124448b9
Author: Peter Bex 
Date:   Sun Jun 30 18:50:09 2013 +0200

Fix meta-evaluation to actually take place in the meta environment and add 
tests

Signed-off-by: Christian Kellermann 


It seems pretty simple and applies cleanly to stability and tests out ok.  Do 
you think I should apply it?

Jim

On Mar 10, 2014, at 2:08 PM, Peter Bex  wrote:

> On Mon, Mar 10, 2014 at 07:37:36PM +0100, Sandra Snan wrote:
>> I couldn't quite get this to work:
>> 
>> It still can't find s-contains.
>> If I move the entire (define-syntax create-tickets ...) sexp to the end
>> of begin-for-syntax, it can't find create-tickets when called later.
> 
> This is unfortunate: I just tested your code and it works with 4.8.4, but
> not with 4.8.0.5.  Most likely this was a large change we considered too
> "dangerous" to include in the stability branch.  I'm not sure which of
> the many changes it was that fixed this.
> 
> I'm afraid your only options are to stick with 4.7.0 or use the
> 4.8.4 development snapshot (or git master) until 4.9.0 has been
> released. The good news is that both the development snapshot and
> master should be pretty stable since we're this close to a release.
> 
> Cheers,
> Peter
> -- 
> http://www.more-magic.net
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Keep `csi` open after reading from pipe

[Jim Ursetto]

One possibility:

$ ( echo '(define (foo x) (+ x 1))' ; cat ) | csi -:c
#;1> #;2> (foo 3)
4

On Jan 20, 2014, at 7:41 PM, Quint Guvernator  wrote:

> Hello All,
> 
> I am not subscribed to this list, so please CC me if you respond.
> 
> I am trying to find a way to keep the chicken scheme interpreter open
> even after it finishes running my input file (via a unix pipe) so I
> can play with the functions I define in the interpreter. Is there a
> simple solution?
> 
> Cheers,
> Quint
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Declare large expressions as read-only and not gc-able?

[Jim Ursetto]

Not sure why this message got truncated, but it was in reference to moving an 
object back into the heap, in other words unevicting it.

Felix says object-evict! is considered harmful, so keep that in mind.  (It 
works fine in the limited context I have used it.)

On Jan 5, 2014, at 15:27, Jim Ursetto  wrote:

> On Jan 5, 2014, at 11:48, Peter Bex  wrote:
> 
>> Perhaps you can use object-evict!, but [message truncated by my mail client]
> 
> http://api.call-cc.org/doc/lolevel/object-unevict
> 
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Declare large expressions as read-only and not gc-able?

[Jim Ursetto]

On Jan 5, 2014, at 11:48, Peter Bex  wrote:

> Perhaps you can use object-evict!, but
>> 
> that means it won't ever be reclaimed by the GC.  I haven't used
> this myself yet, so I don't know if there's a way to "un-evict" the
> object when it can be GC'ed.
> 

http://api.call-cc.org/doc/lolevel/object-unevict

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

Re: [Chicken-users] Declare large expressions as read-only and not gc-able?

[Jim Ursetto]

I'll bet if you define a 100MB literal, the resulting C file would be at least 
a gigabyte and neither CHICKEN nor gcc would be able to handle it.  You could 
try it and let us know.

You could evict it theoretically, but for something that big, you may have to 
create your own data structure in C and malloc it.

I'm curious what this expression is for.

On Jan 5, 2014, at 11:07, Sven Hartrumpf  wrote:

> Hi all.
> 
> Is there a recommended way to declare some large expressions (> 100 MB)
> in a compiled program as read-only and more importantly
> as not gc-able (the garbage collector should be saved from traversing
> these large structures again and again)?
> Should the constant value be compiled in or should it be read from a file?
> Is define-constant the right way to go?
> (How do other Scheme implementation handle such cases?)
> 
> Ciao
> Sven
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Nevermind--Re: Problem with read-line

[Jim Ursetto]

The http://api.call-cc.org/doc/big-chicken extension is good for times like 
these.
Jim

> On Dec 5, 2013, at 16:50, Dan Wilckens  wrote:
> 
>> On 12/4/2013 7:01 PM, Dan Wilckens wrote:
>> Hi,
>> 
>> I built Chicken 4.8.0.5 from source on the mingw-msys platform (under 
>> windows vista).  After attempting to port and debug a program I wrote 
>> originally for Gambit scheme it seems that I've run into an issue with the 
>> read-line command.  Specifically, if I type
>> 
>> (display read-line)
>> 
>> in the interpreter it prints ## as you would expect.  But if 
>> I write the exact same command into a blank file, Test.scm, and compile it 
>> with gsc, running it only prints:
>> 
>> Error: unbound variable: read-line
>> 
>> I really can't figure this out if it's anything other than a bug. FWIW I 
>> chicken-installed sfri-34.  I think the other two extensions I use (sfri-69 
>> and irregex) were already installed. Thanks for any help you can provide!
>> 
>> Dan
> Apparently I had to (require-extension extras) since those functions are not 
> included in csc by default as the are in csi.
> I didn't catch that at first in the documentation.  It's a little bit 
> confusing though to have it work in csi but not csc.  Sorry for any effort 
> you might have expended...
> Dan
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Bug in socket egg and patch

[Jim Ursetto]

Patch looks good, applied in socket 0.2.5.  Thanks.
Jim

On Nov 27, 2013, at 2:29 AM, Jonathan Chan  wrote:

> Hello,
> 
> While writing a socket server in Chicken for kicks I think I run into a
> bug in the sockets egg where socket-accept would not handle the error
> generated by select() if the listener socket had been closed - the error
> is already handled in the egg when selecting for writing.
> 
> I am not sure how the procedure for reporting bugs for eggs or
> submitting patches works and am still very new to Chicken, but the
> chicken-install utility has been very nice so far and has made it very
> easy to test modifications (with -R and just chicken-install to
> reinstall a local version). Thanks for that, for the useful
> implementation, and for the egg!
> 
> I have attached a patch that I believe fixes the bug.
> 
> Regards,
> -- 
>  Jonathan Chan
>  j...@fastmail.fm
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Bug in socket egg and patch

[Jim Ursetto]

Thanks. I'll take a look this weekend.
Jim

> On Nov 27, 2013, at 2:29, Jonathan Chan  wrote:
> 
> Hello,
> 
> While writing a socket server in Chicken for kicks I think I run into a
> bug in the sockets egg where socket-accept would not handle the error
> generated by select() if the listener socket had been closed - the error
> is already handled in the egg when selecting for writing.
> 
> I am not sure how the procedure for reporting bugs for eggs or
> submitting patches works and am still very new to Chicken, but the
> chicken-install utility has been very nice so far and has made it very
> easy to test modifications (with -R and just chicken-install to
> reinstall a local version). Thanks for that, for the useful
> implementation, and for the egg!
> 
> I have attached a patch that I believe fixes the bug.
> 
> Regards,
> -- 
>  Jonathan Chan
>  j...@fastmail.fm
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] html->sxml (html-parser egg) does not decode entities in html attributes, ideas why?

[Jim Ursetto]

Alex,

Looks like there's a regression of sorts in html-parser 0.5.1.

0.5.0

#;> (html->sxml "")
(*TOP* (foo (@ (bar

0.5.1

#;> (html->sxml "")
Error: (cadr) bad argument type: ()

Arguably, empty attributes should result in a value of "" as per 
http://dev.w3.org/html5/markup/syntax.html#syntax-attr-empty ; for example,

#;> (html->sxml "")
(*TOP* (foo (@ (bar ""

although I'd also be satisfied with a return to the status quo ante, in which a 
null cdr signifies empty.

Jim

On Sep 8, 2013, at 7:30 AM, Alex Shinn  wrote:

> On Thu, Sep 5, 2013 at 12:39 AM, Philip Kent  wrote:
> Hi Alex,
> 
> Excellent! Thanks for looking into it and for the tip re custom parsers - I 
> was trying to understand that code!
> 
> It should work now, let me know if you have any problems.
> 
> -- 
> Alex
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] schemish/chickenish way to make configurable executables?

[Jim Ursetto]

There is also the feature-test egg which is useful in combination with the FFI.
Jim

> On Nov 3, 2013, at 9:56, Matt Welland  wrote:
> 
> Hi Peter,
> 
> It looks like cond-expand does enough to achieve what I want. Thanks!
> 
> Matt
> -=-
> 
> 
>> On Sun, Nov 3, 2013 at 2:58 AM, Peter Bex  wrote:
>> On Sat, Nov 02, 2013 at 11:35:22PM -0700, Matt Welland wrote:
>> > I'm curious to hear opinions on conditional complication and configuration
>> > using Chicken scheme.
>> >
>> > Say for example I want to enable or disable the use of a particular library
>> > or feature and I want there to be no trace of it in the executable.
>> >
>> > I can use a preprocessor such as cpp but I imagine there is a better way.
>> > Any strategies or methodologies you all can share? Are macros good for 
>> > this?
>> 
>> Hi Matt,
>> 
>> Usually when I want to do something like this, I use cond-expand and
>> provide the feature via -feature provide-foo:
>> 
>> (define (foo)
>>   (cond-expand
>> (provide-foo (do-whatever-foo-does))
>> (else (error "support for foo is disabled"
>> 
>> This is used extensively by the "crypt" egg to select which
>> fallback implementations need to be provided and for which
>> implementations it can use the one provided by libc.
>> 
>> This is of course only available when compiling from Scheme.
>> If you want to ship precompiled C files (so you'll only need
>> a C compiler and libchicken), you'd have to use C preprocessor
>> and/or conditional compilation of various different implementation
>> files through Make like CHICKEN itself does (for posixunix/posixwin,
>> and for things like HAVE_POSIX_POLL).  This is a lot trickier to
>> do right, and I wouldn't recommend it unless you really have to.
>> 
>> Cheers,
>> Peter
>> --
>> http://www.more-magic.net
> 
> 
> 
> -- 
> Matt
> -=-
> 90% of the nations wealth is held by 2% of the people. Bummer to be in the 
> majority...
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] 4.8.0.5 "compiled ... on" message not quite correct

[Jim Ursetto]

I've changed the build process for stability so that release tarballs have 
their build tag made more generic and more accurate.  This was the easiest 
workaround, I hope the wording is ok.  There's no provision in the build for 
recording C compilation, just Scheme->C compilation.  However, you can override 
the build tag manually as described below if you'd like to record your C 
compile environment.
Jim

CHICKEN
(c) 2008-2013, The Chicken Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
macosx-unix-clang-x86-64 [ 64bit manyargs dload ptables ]
bootstrapped 2013-10-31

On Oct 30, 2013, at 8:36 PM, Jim Ursetto  wrote:

> Matt,
> 
> Easiest way to fix this in the tarball is, prior to `make`:
> 
> echo "#define C_BUILD_TAG \"compiled $(date +%Y-%m-%d) on $(hostname)\"" > 
> buildtag.h
> 
> or
> 
> echo '#define C_BUILD_TAG ""' > buildtag.h
> 
> or whatever you want in that line.
> 
> You can't currently remove or truncate that file to get an empty buildtag; 
> you have to define C_BUILD_TAG to "".  The code could be updated to accept a 
> missing build tag (and/or to remove the resulting blank line); I can provide 
> a patch if you like.
> 
> Jim
> 
> On Oct 30, 2013, at 3:11 PM, Jim Ursetto  wrote:
> 
>> There was some noise on the list a few months ago in re changing the 
>> compilation message to reflect where the .c to .o compile occurred. Not sure 
>> if it went anywhere.
>> 
>> I don't really care either way, it is basically cosmetic IMO.
>> 
>>> On Oct 30, 2013, at 11:02, Mario Domenech Goulart  
>>> wrote:
>>> 
>>> Hi Matt,
>>> 
>>>> On Wed, 30 Oct 2013 08:57:26 -0700 Matt Welland  
>>>> wrote:
>>>> 
>>>> When I compiled 4.8.0.5 from the tar this morning I get a curious
>>>> message on starting csi:
>>>> 
>>>>> csi
>>>> 
>>>> CHICKEN
>>>> (c) 2008-2013, The Chicken Team
>>>> (c) 2000-2007, Felix L. Winkelmann
>>>> Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
>>>> linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
>>>> compiled 2013-10-03 on aeryn.xorinia.dim (Darwin) < Not true :)
>>> 
>>> That's where the Scheme->C compilation took place.  When you built the
>>> code from the release tarball, you actually only compiled the C code.
>>> 
>>> Yes, the banner is a bit misleading.
>>> 
>>> Best wishes.
>>> Mario
>>> -- 
>>> http://parenteses.org/mario
>>> 
>>> ___
>>> Chicken-users mailing list
>>> Chicken-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 


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

Re: [Chicken-users] 4.8.0.5 "compiled ... on" message not quite correct

[Jim Ursetto]

Matt,

Easiest way to fix this in the tarball is, prior to `make`:

echo "#define C_BUILD_TAG \"compiled $(date +%Y-%m-%d) on $(hostname)\"" > 
buildtag.h

or

echo '#define C_BUILD_TAG ""' > buildtag.h

or whatever you want in that line.

You can't currently remove or truncate that file to get an empty buildtag; you 
have to define C_BUILD_TAG to "".  The code could be updated to accept a 
missing build tag (and/or to remove the resulting blank line); I can provide a 
patch if you like.

Jim

On Oct 30, 2013, at 3:11 PM, Jim Ursetto  wrote:

> There was some noise on the list a few months ago in re changing the 
> compilation message to reflect where the .c to .o compile occurred. Not sure 
> if it went anywhere.
> 
> I don't really care either way, it is basically cosmetic IMO.
> 
>> On Oct 30, 2013, at 11:02, Mario Domenech Goulart  
>> wrote:
>> 
>> Hi Matt,
>> 
>>> On Wed, 30 Oct 2013 08:57:26 -0700 Matt Welland  wrote:
>>> 
>>> When I compiled 4.8.0.5 from the tar this morning I get a curious
>>> message on starting csi:
>>> 
>>>> csi
>>> 
>>> CHICKEN
>>> (c) 2008-2013, The Chicken Team
>>> (c) 2000-2007, Felix L. Winkelmann
>>> Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
>>> linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
>>> compiled 2013-10-03 on aeryn.xorinia.dim (Darwin) < Not true :)
>> 
>> That's where the Scheme->C compilation took place.  When you built the
>> code from the release tarball, you actually only compiled the C code.
>> 
>> Yes, the banner is a bit misleading.
>> 
>> Best wishes.
>> Mario
>> -- 
>> http://parenteses.org/mario
>> 
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] 4.8.0.5 "compiled ... on" message not quite correct

[Jim Ursetto]

There was some noise on the list a few months ago in re changing the 
compilation message to reflect where the .c to .o compile occurred. Not sure if 
it went anywhere.

I don't really care either way, it is basically cosmetic IMO.

> On Oct 30, 2013, at 11:02, Mario Domenech Goulart  
> wrote:
> 
> Hi Matt,
> 
>> On Wed, 30 Oct 2013 08:57:26 -0700 Matt Welland  wrote:
>> 
>> When I compiled 4.8.0.5 from the tar this morning I get a curious
>> message on starting csi:
>> 
>>> csi
>> 
>> CHICKEN
>> (c) 2008-2013, The Chicken Team
>> (c) 2000-2007, Felix L. Winkelmann
>> Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
>> linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
>> compiled 2013-10-03 on aeryn.xorinia.dim (Darwin) < Not true :)
> 
> That's where the Scheme->C compilation took place.  When you built the
> code from the release tarball, you actually only compiled the C code.
> 
> Yes, the banner is a bit misleading.
> 
> Best wishes.
> Mario
> -- 
> http://parenteses.org/mario
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Timezone bugs in the posix module

[Jim Ursetto]

Posix is pretty much useless for handling timezones correctly; behavior varies 
greatly based on the OS, and I am fairly sure the direction of the wind plays a 
part as well.
Jim 

> On Sep 29, 2013, at 12:28, Andy Bennett  wrote:
> 
> Hi,
> 
> There seem to be some inconsistencies in the timezone handling in the
> posix module.
> 
> 
> http://api.call-cc.org/doc/library/current-seconds
> -
> (current-seconds) procedure
> 
>Returns the number of seconds since midnight, Jan. 1, 1970.
> -
> 
> This seems to be true and it appears to be in Zulu time.
> 
> On a machine in BST:
> 
> -
> $ date; csi -p '(use posix) (current-seconds)'
> Sun Sep 29 18:06:50 BST 2013
> #
> 1380474410.0
> -
> 
> On a machine in CDT:
> 
> -
> $ date; csi -p '(use posix) (current-seconds)'
> Sun Sep 29 12:06:50 CDT 2013
> #
> 1380474410.0
> -
> 
> ...we get the same value. All is well.
> 
> 
> 
> However,
> 
> http://api.call-cc.org/doc/posix/seconds-%3Estring
> -
> (seconds->string [SECONDS]) procedure
> 
>Converts the local time represented in SECONDS into a string of the
> form "Tue May 21 13:46:22 1991". SECONDS defaults to the value of
> (current-seconds).
> -
> 
> ..seems to be misleading as [SECONDS] is in Zulu time (as shown above).
> It is seconds->string itself which does the conversion to local time for
> the resulting string:
> 
> -
> $ date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 12:08:15 CDT 2013
> #
> Wed Dec 31 18:00:00 1969
> -
> 
> 
> However, there's also a bug as I get the following on a machine in BST:
> 
> -
> $ date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 18:09:02 BST 2013
> #
> Thu Jan  1 01:00:00 1970
> -
> 
> 
> ...and if I force that machine into BST:
> 
> -
> $ export TZ=BST; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:21:34 BST 2013
> #
> Thu Jan  1 00:00:00 1970
> -
> 
> 
> ...and UTC:
> -
> $ export TZ=UTC; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:09:46 UTC 2013
> #
> Thu Jan  1 00:00:00 1970
> -
> 
> 
> ...and Europe/London:
> 
> -
> $ export TZ=Europe/London; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 18:21:50 BST 2013
> #
> Thu Jan  1 01:00:00 1970
> -
> 
> 
> ...and a definitely bogus timezone:
> 
> -
> $ export TZ=rubbish; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:25:47 rubbish 2013
> #
> Thu Jan  1 00:00:00 1970
> -
> 
> ...so seconds->string sometimes ignores the timezone and doesn't throw
> an error.
> 
> -
> $ wdate
> Sun Sep 29 12:15:19 CDT 2013 (America/Chicago)
> Sun Sep 29 17:15:19 UTC 2013 (UTC)
> Sun Sep 29 18:15:19 BST 2013 (Europe/London)
> Sun Sep 29 19:15:19 CEST 2013 (Europe/Rome)
> Mon Sep 30 06:15:19 NZDT 2013 (NZ)
> -
> 
> 
> 
> 
> On the machine in BST:
> 
> -
> $ export TZ=CDT; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:10:58 CDT 2013
> #
> Thu Jan  1 00:00:00 1970
> -
> 
> -
> $ export TZ=America/Chicago; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 12:11:43 CDT 2013
> #
> Wed Dec 31 18:00:00 1969
> -
> 
> ...so it seems that the posix unit does not support the same names for
> timezones as the underlying operating system / date command (Linux in
> this case).
> 
> 
> -
> $ export TZ=Europe/Rome; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 19:12:52 CEST 2013
> #
> Thu Jan  1 01:00:00 1970
> 
> $ export TZ=CEST; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:13:10 CEST 2013
> #
> Thu Jan  1 00:00:00 1970
> 
> $ export TZ=NZ; date; csi -p '(use posix) (seconds->string 0)'
> Mon Sep 30 06:14:00 NZDT 2013
> #
> Thu Jan  1 12:00:00 1970
> 
> $ export TZ=NZDT; date; csi -p '(use posix) (seconds->string 0)'
> Sun Sep 29 17:14:15 NZDT 2013
> #
> Thu Jan  1 00:00:00 1970
> -
> 
> 
> 
> 
> 
> 
> Regards,
> @ndy
> 
> -- 
> andy...@ashurst.eu.org
> http://www.ashurst.eu.org/
> 0x7EBA75FF
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] (no subject)

[Jim Ursetto]

The doc is erroneous -- you have to add (use ports) after (use args).
Jim

On Aug 28, 2013, at 10:20 AM, Matthew Phillips  wrote:

> Im playing with this egg example:  http://wiki.call-cc.org/eggref/4/args. It 
> compiles fine, but when I run it with the -h flag I get this strange error:
> 
>  Error: unbound variable: with-output-to-port
> 
> However if I load it from csi it works fine... and from csi i can clearly see 
> that with-output-to-port exists. So I am thinking that in compiling it the 
> reference is lost somehow. 
> 
> From the documentation on unit ports: 
> http://wiki.call-cc.org/man/4/Unit%20ports it says: 
> 
>  This unit contains various extended port definitions. This unit is used 
> by default, unless the program is compiled with the -explicit-use option.
> 
> I am not passing that option, or any option. Any idea on what is going on 
> here?
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] (no subject)

[Jim Ursetto]

For whatever reason the docs are outdated and the example is too. You have to 
(use ports) if you want to compile it.
Jim

On Aug 28, 2013, at 10:20, Matthew Phillips  wrote:

> Im playing with this egg example:  http://wiki.call-cc.org/eggref/4/args. It 
> compiles fine, but when I run it with the -h flag I get this strange error:
> 
>  Error: unbound variable: with-output-to-port
> 
> However if I load it from csi it works fine... and from csi i can clearly see 
> that with-output-to-port exists. So I am thinking that in compiling it the 
> reference is lost somehow. 
> 
> From the documentation on unit ports: 
> http://wiki.call-cc.org/man/4/Unit%20ports it says: 
> 
>  This unit contains various extended port definitions. This unit is used 
> by default, unless the program is compiled with the -explicit-use option.
> 
> I am not passing that option, or any option. Any idea on what is going on 
> here?
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Lowdown & sxml-serializer not working together

[Jim Ursetto]

On Aug 24, 2013, at 5:25 PM, Jim Ursetto  wrote:

> Unfortunately it doesn't declare the default namespace for html.  You can 
> work around this by providing a default namespace prefix *and* using the 
> actual prefix (below, xhtml:) on your elements.  This is kind of ugly.  
> However, the stock serializer didn't even support default namespaces (!) so I 
> may have simply overlooked this case when adding support.  I'll see if I can 
> look into it further.

I've added support for the default (unqualified) namespace ID in the source 
SXML now; the code is available at https://github.com/ursetto/sxml-serializer 
while I run a couple more tests.  Formerly, you could render to unqualified 
names but not use them properly in the source.

[Note: below, unqualified names are rendering to the xhtml: namespace, because 
there is a list of default namespace URI -> ID mappings, called 
conventional-ns-prefixes.  To override this and render them without 
qualification, add *default* as the 3rd arg of the namespace association (as 
the "original prefix").  The word "original" is used as if the XML document was 
the original source and you had parsed it to SXML; the SXML prefix and XML 
prefix are permitted to differ.]


(use sxml-serializer)

(print
 (serialize-sxml
 '(*TOP*
   (@ (*NAMESPACES*
   (*default* "http://www.w3.org/1999/xhtml";)
   (cvt "http://xmlns.therebetygers.net/civet/0.1";)))
   (*PI* xml "version=\"1.0\" encoding=\"utf-8\"")
(html
 (@ (xml:lang "en") (lang "en"))
 (cvt:template
  (cvt:head
   (cvt:locale (@ (lang "en") (country "US") (encoding "utf-8"
(cvt:block (@ (name "headerContent"))
 #\< Single #\space (#\a #\r #\t #\i #\c #\l #\e)
 #\space "page>"
  ))


http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
  http://xmlns.therebetygers.net/civet/0.1";>

  

<Single article page>
  



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

Re: [Chicken-users] Lowdown & sxml-serializer not working together

[Jim Ursetto]

On Aug 23, 2013, at 11:24 PM, Matt Gushee  wrote:

> Hello again--
> 
> Well, I'm running into a new problem with SRV:send-reply. By following
> the documentation, I managed to create a rule set that escaped problem
> characters i the manner I want. But now, working with the complete
> document, I discover that some of the non-element nodes are not
> handled properly. The SXML form of my document starts like this:
> 
>  (*TOP*
>(@ (*NAMESPACES*
>  (#f "http://www.w3.org/1999/xhtml";)
>  (cvt "http://xmlns.therebetygers.net/civet/0.1";)))
>(*PI* xml "version=\"1.0\" encoding=\"utf-8\"")
>(html
>  (@ (xml:lang "en") (lang "en"))
> 
> But when I serialize it with (SRV:send-reply (pre-post-order tree
> )), the output begins like this:
> 
>  <*TOP*
>  *NAMESPACES*="http://www.w3.org/1999/xhtml
>   cvt="http://xmlns.therebetygers.net/civet/0.1"";>
>  <*PI*>xmlversion="1.0" encoding="utf-8"
>  

This should serialize reasonably correctly with sxml-serializer.

(use sxml-serializer)

(print
 (serialize-sxml
 '(*TOP*
   (@ (*NAMESPACES*
   (#f "http://www.w3.org/1999/xhtml";)
   (cvt "http://xmlns.therebetygers.net/civet/0.1";)))
   (*PI* xml "version=\"1.0\" encoding=\"utf-8\"")
(html
 (@ (xml:lang "en") (lang "en"))
 (cvt:template
  (cvt:head
   (cvt:locale (@ (lang "en") (country "US") (encoding "utf-8"
   (cvt:block (@ (name "headerContent"))
 #\< Single #\space (#\a #\r #\t #\i #\c #\l #\e) #\space "page>"))



  http://xmlns.therebetygers.net/civet/0.1";>

  


  


Unfortunately it doesn't declare the default namespace for html.  You can work 
around this by providing a default namespace prefix *and* using the actual 
prefix (below, xhtml:) on your elements.  This is kind of ugly.  However, the 
stock serializer didn't even support default namespaces (!) so I may have 
simply overlooked this case when adding support.  I'll see if I can look into 
it further.

(print
 (serialize-sxml
 '(*TOP*
   (@ (*NAMESPACES*
   (xh "http://www.w3.org/1999/xhtml";)
   (cvt "http://xmlns.therebetygers.net/civet/0.1";)))
   (*PI* xml "version=\"1.0\" encoding=\"utf-8\"")
(xh:html
 (@ (xml:lang "en") (lang "en"))
 (cvt:template
  (cvt:head
   (cvt:locale (@ (lang "en") (country "US") (encoding "utf-8"
(cvt:block (@ (name "headerContent"))
 #\< Single #\space (#\a #\r #\t #\i #\c #\l #\e)
 #\space "page>"
 ns-prefixes: '((*default* . "http://www.w3.org/1999/xhtml";))
  ))


http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
  http://xmlns.therebetygers.net/civet/0.1";>

  


  



Namespaces can be tricky.  Check my blog posts on the subject and feel free to
ask for help.

http://3e8.org/blog/2010/07/30/namespaces-in-sxml-part-1/
http://3e8.org/blog/2010/07/31/namespaces-in-sxml-part-2/
http://3e8.org/blog/2010/08/01/default-namespaces-in-sxml/

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

Re: [Chicken-users] Lowdown & sxml-serializer not working together

[Jim Ursetto]

Matt,

On Aug 22, 2013, at 3:28 PM, Matt Gushee  wrote:

> Sounds good. I was actually hoping to be able to blame lowdown for
> this, since I don't really like the way it makes every word and every
> space a separate text node. But maybe that's more efficient? And
> actually, I'm wondering if that character-in-list construction:
> 
>  '(#\space)
> 
> is really allowed by the SXML spec. The narrative documentation
> doesn't address that, and I'm a bit out of practice reading EBNF, but
> maybe I can puzzle it out.

I've modified sxml-serializer in 0.3 to accept chars, symbols and nulls as text 
nodes, and to accept text nodes in list head position.  This should allow it to 
parse lowdown's variant of SXML.

> I note that lowdown
> outputs the '&' and '<' in string form, whereas the '>' becomes #\>.
> That seems like a peculiar inconsistency, but I suppose there's some
> reason for it.

Probably lowdown is using (abusing?) the fact that the 
universal-conversion-rules only escape string text nodes, whereas characters 
etc. are output verbatim; it's generally not necessary to escape the > sign.

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

Re: [Chicken-users] Lowdown & sxml-serializer not working together

[Jim Ursetto]

I don't remember offhand what the rationale was for this in sxml-serializer -- 
I can take a look but it might not be until this weekend.

On Aug 21, 2013, at 22:38, Matt Gushee  wrote:

> Hi, chickeneers--
> 
> I am working on an application that uses the lowdown egg to process
> *some* of the input, and sxml-serializer to render the output. I'm
> running into an issue ... I'm not sure if it's really a bug, but it's
> at least an compatibility problem:
> 
> markdown->sxml converts whitespace in the input to character objects,
> or lists of character objects, e.g.:
> 
>   '(#\space)
>   #\newline
> 
> ... but serialize-sxml can't handle these: evidently it wants either
> strings or symbols. I haven't found any arguments or parameters in
> either egg that seem to be able to affect this behavior.
> 
> So, is there something that needs to be fixed in one of these eggs, or
> do I just need to convert the markdown->sxml output to something that
> serialize-sxml can handle? Please advise.
> 
> --
> Matt Gushee
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Strange problems with args egg

[Jim Ursetto]

No problem. The fix is now in args 1.4.4.

On Aug 5, 2013, at 21:54, Jonathan Chan  wrote:

> Sorry for the delayed reply - I missed your message for some reason. The
> patch does work! Thanks for the help and for the useful egg.
> 
> -- 
> Jonathan Chan
> 
> On Sun, Aug 4, 2013, at 06:43 AM, Jim Ursetto wrote:
>> Did you try my patch?  You don't have to rewrite anything, it's a bug in
>> the args egg.
>> 
>> On Aug 4, 2013, at 2:13 AM, Jonathan Chan  wrote:
>> 
>>> Thank you for the help! This is definitely a very interesting language to 
>>> learn.
>>> 
>>> On 08/03/2013 09:06 AM, John Cowan wrote:
>>>> Jonathan Chan scripsit:
>>>> 
>>>>> Here is the smallest amount of args-using Chicken that will cause the
>>>>> problem:
>>>>> 
>>>>> (define-syntax test
>>>>>  (syntax-rules ()
>>>>>((test)
>>>>> (begin
>>>>>   (define opts (list (args:make-option (h help) #:none "display
>>>>>   this text" (print "foo"
>>>>>   (write (args:parse (command-line-arguments) opts))
>>>> [...]
>>>> 
>>>>> The strange thing is that h and help seem to have turned into ("h390"
>>>>> "help391"), causing problems.
>>>> This is not a Chicken-specific problem, but a general problem
>>>> with non-hygienic macros.  You are using the non-hygienic macro
>>>> "args:make-option" within a hygienic macro.  The syntax-rules transformer
>>>> doesn't know that "h" and "help" are being used literally here (because
>>>> it cannot tell what args:make-option does), so it systematically renames
>>>> them to avoid collisions.
>>>> 
>>>>> Is there something I need to change to fix the problem? Sorry for many
>>>>> misunderstandings.
>>>> You can rewrite test as a non-hygienic (explicit renaming or implicit
>>>> renaming) macro.
>>> 
>>> -- 
>>> Jonathan Chan
>>> j...@fastmail.fm
>>> 
>>> 
>>> ___
>>> Chicken-users mailing list
>>> Chicken-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/chicken-users
>> 

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

Re: [Chicken-users] Strange problems with args egg

[Jim Ursetto]

Did you try my patch?  You don't have to rewrite anything, it's a bug in the 
args egg.

On Aug 4, 2013, at 2:13 AM, Jonathan Chan  wrote:

> Thank you for the help! This is definitely a very interesting language to 
> learn.
> 
> On 08/03/2013 09:06 AM, John Cowan wrote:
>> Jonathan Chan scripsit:
>> 
>>> Here is the smallest amount of args-using Chicken that will cause the
>>> problem:
>>> 
>>> (define-syntax test
>>>   (syntax-rules ()
>>> ((test)
>>>  (begin
>>>(define opts (list (args:make-option (h help) #:none "display
>>>this text" (print "foo"
>>>(write (args:parse (command-line-arguments) opts))
>>> 
>> [...]
>> 
>>> The strange thing is that h and help seem to have turned into ("h390"
>>> "help391"), causing problems.
>> This is not a Chicken-specific problem, but a general problem
>> with non-hygienic macros.  You are using the non-hygienic macro
>> "args:make-option" within a hygienic macro.  The syntax-rules transformer
>> doesn't know that "h" and "help" are being used literally here (because
>> it cannot tell what args:make-option does), so it systematically renames
>> them to avoid collisions.
>> 
>>> Is there something I need to change to fix the problem? Sorry for many
>>> misunderstandings.
>> You can rewrite test as a non-hygienic (explicit renaming or implicit
>> renaming) macro.
>> 
> 
> -- 
> Jonathan Chan
> j...@fastmail.fm
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Strange problems with args egg

[Jim Ursetto]

This patch to the args egg should fix things -- could you try it?
Jim
Index: args.scm
===
--- args.scm(revision 29488)
+++ args.scm(working copy)
@@ -268,7 +268,7 @@
  )
 
   (let* ((srfi37-names (map (lambda (name)
- (let ((str (->string name)))
+ (let ((str (symbol->string (strip-syntax 
name
(if (= (string-length str) 1)
(string-ref str 0)
str)))


On Aug 3, 2013, at 6:56 AM, Jonathan Chan  wrote:

> Hello all,
> 
> First off, I am very new to Chicken. I recently tried using the args egg
> and wrote a syntax-rules macro to let me clarify a bunch of copy-paste
> declarations, but seem to be running into some strange problem where
> numbers are appended to the names of certain symbols.
> 
> Here is the smallest amount of args-using Chicken that will cause the
> problem:
> 
> (define-syntax test
>  (syntax-rules ()
>((test)
> (begin
>   (define opts (list (args:make-option (h help) #:none "display
>   this text" (print "foo"
>   (write (args:parse (command-line-arguments) opts))
> 
> (test)
> 
> ... and to a local copy I made of the args egg I added the following at
> the beginning of the definition of the args:parse function (included):
> 
> (define (args:parse args options-list . optionals)
>  (for-each (lambda (o)
>  (write (option-names (args:option-option o
>options-list)
>  (newline)
> 
> The strange thing is that h and help seem to have turned into ("h390"
> "help391"), causing problems.
> 
> Is there something I need to change to fix the problem? Sorry for many
> misunderstandings.
> 
> Here is the Chicken version I am running:
> 
> CHICKEN
> (c) 2008-2013, The Chicken Team
> (c) 2000-2007, Felix L. Winkelmann
> Version 4.8.0.4 (stability/4.8.0) (rev 578619b)
> linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
> compiled 2013-07-15 on aeryn.xorinia.dim (Darwin)
> 
> Thanks,
> -- 
> Jonathan Chan
> j...@fastmail.fm
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] new eggs

[Jim Ursetto]

On Jul 29, 2013, at 11:33, Mario Domenech Goulart  
wrote:

> I don't see why we should have/allow core units in .meta's forms.  Maybe
> I'm overlooking something.  If that's the case, please let me know.

There's one reason I can think of -- it makes it easier to move a core unit 
into an egg, without updating every dependent egg.

But I think it is a bit ugly overall, and you're prone to forget to add certain 
units anyway.

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

Re: [Chicken-users] replacement for rlwrap on MS Windows, MinGW

[Jim Ursetto]

If you're going to go the Emacs route, it's probably even better to use 
run-scheme from cmuscheme.el, as you may then evaluate Scheme expressions from 
any buffer in the interpreter of your choice.  I'm pretty sure this works on 
Windows.  Well, I hope it does.

On Jul 25, 2013, at 10:37 PM, Michael Maul  wrote:

> On the emacs front. You don't have to even set up slime, if all you want is 
> csi w/command history.
> Just start Emacs, Alt-X shell , type csi and your good to go. Ctrl-Up Arrow 
> to access history.
> 
> Setting up Slime is worth the effort, but not necessary.
> 
> 
> On Fri, Jul 26, 2013 at 3:04 AM, Claude Marinier  wrote:
> Using csi with parley works well on Linux (Debian Wheezy).
> 
> On MS Windows, Cygwin and MinGW are stepping on each other's toes. I have to 
> clean-up the mess.
> 
> Time to re-visit the choice between Cygwin and MinGW. The concern some people 
> have about the Cygwin DLL and the GPL does not affect me for now. If I 
> publish, I will likely use a three clause BSD license which is compatible, 
> right? The obvious technical reason to choose one over the other is POSIX 
> support. Are there others?
> 
> 
> Hum ... maybe I should stick with Linux. :-)
> 
> 
> 
> On Thu, Jul 25, 2013 at 7:34 PM, Claude Marinier  wrote:
> 
> On Thu, 25 Jul 2013, Christian Kellermann wrote:
> * Christian Kellermann  [130725 10:48]:
> * Christian Kellermann  [130725 10:29]:
> * Peter Bex  [130725 08:59]:
> On Wed, Jul 24, 2013 at 06:57:56PM -0400, Claude Marinier wrote:
> Just to make sure we are talking about the same thing. The context is
> using the REPL on MS Windows. I prefer to use MinGW instead of Cygwin.
> 
> Are you saying that csi can be built to use parley to provide better
> history and line editing?
> 
> That's not neccessary; you can simply build parley and load it into
> your csirc startup file and it will take care of the rest.  See the
> parley manual page for more info on how to do that.
> 
> Can this also be done on MS Windows?
> 
> I don't see why it shouldn't work, but it probably hasn't been tested yet.
> Just give it a go and see how far you get.
> 
> I see that stty needs some patching, I will see what I can do. Alex,
> have you got a stty version that's known to work on windows?
> 
> Ok, as a quick fix you need to chicken-install -r stty and comment
> out three occasions of ECHOPRT. At least parley should work then
> as this flag isn't used.
> 
> Please tell me how far you get.
> 
> I retrieved the stty code, commented out the lines which reference ECHOPRT, 
> and tried to build & install stty. I am not sure how to proceed from there. I 
> expect chicken-install has a switch to build and install from the current 
> directory.
> 
> Trying 'chicken-install stty' produced much activity as dependencied were 
> handles, then it died with the following error.
> 
> stty.c:13:21: fatal error: termios.h: No such file or directory
> compilation terminated.
> 
> -- 
> Claude Marinier
> 
> 
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Big integers as statement parameters in sql-de-lite

[Jim Ursetto]

It's not that the values are too large, it's that srfi 19 represents them as 
bignums, which is not currently supported by sql-de-lite. However, they work as 
floats (they will be converted to integers before being passed to the database, 
due to the column type).  Even on 32-bit systems, we fully support handling 53 
bit integers in the database in this way.

The easiest way to do this is by calling exact->inexact on the result to force 
it to floating point. Such a small value need not be a flonum on 64-bit system, 
but it will still work correctly, and it's the easiest way to ensure it is not 
a bignum.  You can confirm the value was stored as an integer by using the 
typeof() SQL function, e.g. select typeof(date) from foo;

Or you can just store the UNIX timestamp obtained from the posix unit, which 
should be a lot easier ;)

Jim

On Jul 22, 2013, at 18:18, Matt Gushee  wrote:

> Hi, Kon--
> 
> On Mon, Jul 22, 2013 at 4:34 PM, Kon Lovett  wrote:
> 
>> Do you need the range a SRFI-19 datetime provides? Maybe an epoch based 
>> approach, like provided by the posix module.
> 
> No, I don't need the range. In fact, my project is a lightweight
> blogging platform, and the date-times in question are creation and
> modification times for the content, which will normally be displayed
> to site visitors--possibly in localized formats; and other values
> having to do with authentication and sessions, which will normally be
> invisible. So I think it is safe to assume that all values that will
> ever be used will fall within a couple of decades beginning with 2013.
> 
> I'm not sure if I need to use SRFI-19. For some reason I thought that
> it would be preferable from the POV of  localized formatting and time
> zone conversions, but looking again at the docs it doesn't seem like
> that is necessary.
> 
> But I notice that the posix date/time functions work with values
> representing seconds, much like the values that are not working for
> me--except that in posix they are floats instead of integers. So maybe
> they won't cause errors? I'll give that a try.
> 
> --
> Matt Gushee
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Building 32-bit chicken scheme on OS X

[Jim Ursetto]

Thanks.  Nicholas confirmed 32-bit Macs work so I'm going to officially release 
4.8.0.4.

Jim

On Jul 15, 2013, at 11:12 PM, "Daniel P. Wright"  wrote:

> Hello,
> 
> 2013/7/16 Jim Ursetto 
> I put the tarball here:
> http://3e8.org/pub/chicken/stability-tmp/chicken-4.8.0.3-b39ebad.tar.gz
> 
> Thanks!
>  
> On Jul 15, 2013, at 5:56 PM, Jim Ursetto  wrote:
> 
> > Hi there.
> >
> > The culprit appears to be a bug in our use of sigsetjmp, which is actually 
> > already fixed in recent stability/4.8.0 (after 4.8.0.3) but is as yet 
> > unreleased.  I verified 32-bit builds now work on a 64-bit Mac.
> >
> > If anyone has a 32-bit Mac (for example, an original Core Duo) could you 
> > verify it works on your system as well?  You will need to build 
> > stability/4.8.0 from git, or I can make a tarball if you aren't set up to 
> > build from git.
> 
> My Mac is 64-bit, but for what it's worth I downloaded and built the tarball 
> you put up, and I can confirm that it works in my case also -- the problems 
> that led to my initial post have gone away.
> 
> I'll have a hunt around and see if I can find a 32-bit Mac to test on, but 
> I'm afraid I don't have one to hand right now.
> 
> -Dani.

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

Re: [Chicken-users] Building 32-bit chicken scheme on OS X

[Jim Ursetto]

I put the tarball here:
http://3e8.org/pub/chicken/stability-tmp/chicken-4.8.0.3-b39ebad.tar.gz

On Jul 15, 2013, at 5:56 PM, Jim Ursetto  wrote:

> Hi there.
> 
> The culprit appears to be a bug in our use of sigsetjmp, which is actually 
> already fixed in recent stability/4.8.0 (after 4.8.0.3) but is as yet 
> unreleased.  I verified 32-bit builds now work on a 64-bit Mac.
> 
> If anyone has a 32-bit Mac (for example, an original Core Duo) could you 
> verify it works on your system as well?  You will need to build 
> stability/4.8.0 from git, or I can make a tarball if you aren't set up to 
> build from git.
> 
> Jim
> 
> (P.S. On a 32-bit system it is redundant to add any options like ARCH or 
> *_OPTIONS; `make PLATFORM=macosx` will suffice.)
> 
> On Jan 11, 2013, at 2:21 AM, Daniel P. Wright  wrote:
> 
>> Jim Ursetto (Thu, Jan 10, 2013 at 12:20:05PM -0600) >>
>>> Dani,
>>> 
>>> ASSEMBLER_OPTIONS is missing:
>>> 
>>> make PLATFORM=macosx ARCH=x86 C_COMPILER_OPTIONS="-no-cpp-precomp 
>>> -fno-strict-aliasing -fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -m32" 
>>> ASSEMBLER_OPTIONS="-m32" LINKER_OPTIONS="-m32"
>> 
>> Seems obvious now you mention it!  Thanks, I also managed to build
>> successfully with these build options.  But,
>> 
>>> The resulting chicken gives me a bus error though and I don't know how to 
>>> fix that.
>> 
>> Me too.
>> 
>> I have had the same bus error when building chicken on an old os x
>> machine without specifying ARCH=x86-64, which I think was defaulting to
>> a 32-bit build.  Perhaps 32-bit builds just don't play nicely on 64-bit
>> macs?  I don't suppose it's a common use-case.
>> 
>> Thanks for your input!  I guess I'll look into it a little further and
>> see if I can get anywhere with it.  What is a bus error?
>> 
>> Thanks,
>> 
>> Dani.
> 


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

Re: [Chicken-users] Building 32-bit chicken scheme on OS X

[Jim Ursetto]

Hi there.

The culprit appears to be a bug in our use of sigsetjmp, which is actually 
already fixed in recent stability/4.8.0 (after 4.8.0.3) but is as yet 
unreleased.  I verified 32-bit builds now work on a 64-bit Mac.

If anyone has a 32-bit Mac (for example, an original Core Duo) could you verify 
it works on your system as well?  You will need to build stability/4.8.0 from 
git, or I can make a tarball if you aren't set up to build from git.

Jim

(P.S. On a 32-bit system it is redundant to add any options like ARCH or 
*_OPTIONS; `make PLATFORM=macosx` will suffice.)

On Jan 11, 2013, at 2:21 AM, Daniel P. Wright  wrote:

> Jim Ursetto (Thu, Jan 10, 2013 at 12:20:05PM -0600) >>
>> Dani,
>> 
>> ASSEMBLER_OPTIONS is missing:
>> 
>> make PLATFORM=macosx ARCH=x86 C_COMPILER_OPTIONS="-no-cpp-precomp 
>> -fno-strict-aliasing -fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -m32" 
>> ASSEMBLER_OPTIONS="-m32" LINKER_OPTIONS="-m32"
> 
> Seems obvious now you mention it!  Thanks, I also managed to build
> successfully with these build options.  But,
> 
>> The resulting chicken gives me a bus error though and I don't know how to 
>> fix that.
> 
> Me too.
> 
> I have had the same bus error when building chicken on an old os x
> machine without specifying ARCH=x86-64, which I think was defaulting to
> a 32-bit build.  Perhaps 32-bit builds just don't play nicely on 64-bit
> macs?  I don't suppose it's a common use-case.
> 
> Thanks for your input!  I guess I'll look into it a little further and
> see if I can get anywhere with it.  What is a bus error?
> 
> Thanks,
> 
> Dani.


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

Re: [Chicken-users] Exact flownums not properly displayed in mingw

[Jim Ursetto]

Heh.  That is pretty amusing, but more a formatting issue on the part of 
chicken-status.  Or you could chalk it up to the egg's use of a flonum instead 
of a string or symbolic version number (0.2.3 is read as a symbol, whereas 0.2 
is read as a number).  For example, were you to use (version 1.00), it would 
read as a flonum and display "1.0" on UNIX, which is just as incorrect as "1." 
in my opinion.

One way to quickly fix this for your case is to change (version 1.0) to 
(version "1.0") in your .setup file.  I try to use string version numbers 
exclusively now for consistency's sake.

Jim

On Jul 9, 2013, at 12:12 PM, Michele La Monaca  
wrote:

> On Tue, Jul 9, 2013 at 6:31 PM, Jim Ursetto  wrote:
>> If you're really concerned about this (which is ultimately aesthetic)
> 
> Is this acceptable?
> 
> C:\TMP>chicken-status | tail -3
> socket ... version: 0.2.3
> srfi-37 .. version: 1.3.1
> win32-msgbox  version: 1.
> 
>> then you should consider setting flonum-print-precision to 17, which will
>> make an actual difference in rare
>> cases.  http://api.call-cc.org/doc/library/flonum-print-precision
> 
> It doesn't seem to do any difference (in this case at least). Thanks, anyway.
> 
> Michele


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

Re: [Chicken-users] Exact flownums not properly displayed in mingw

[Jim Ursetto]

If you're really concerned about this (which is ultimately aesthetic) then you 
should consider setting flonum-print-precision to 17, which will make an actual 
difference in rare cases.  
http://api.call-cc.org/doc/library/flonum-print-precision

On Jul 9, 2013, at 10:15 AM, Michele La Monaca  
wrote:

> On Tue, Jul 9, 2013 at 3:44 PM, John Cowan  wrote:
> 
>> Chicken uses the local C's idea of number-to-string conversion.
> 
> Not the best approach I think. I would rather prefer a consistent behavior.
> 
>> Since "1." is a valid Scheme inexact number, that's perfectly fine.
> 
> Being a valid Scheme number it's not a valid reason to dislay it as it is, 
> IMHO.
> 
> Michele
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] my errors with eval

[Jim Ursetto]

You can't access internal defines in an eval, just as you can't access the 
lexical variable "a".

To get around this you could use set! instead to "define" the variables at 
toplevel.

(let ((a 1))
 (set! inc (lambda () (set! a (+ 1 a)) (print a)))
 (set! runTwice (lambda (op) (op) (op)))
 (eval '(runTwice inc)))
(inc)
;; prints: 2 3 4

Notice `inc` is accessible outside the `let` here.

Otherwise you have to use something like the currently nonfunctional 
`environments` egg.

On Jul 2, 2013, at 2:26 PM, "Daniel Ajoy"  wrote:

> Hi,
> 
> Both this
> 
> (let ((a 1) )
>  (define (inc)
>   (set! a (+ 1 a ) ) )
>  (define (runTwice op )
>   (op)
>   (op) )
>  (eval '(runTwice inc ) )
>  )
> 
> and this
> 
> (let* ((a 1) )
>  (define (inc)
>   (set! a (+ 1 a ) ) )
>  (define (runTwice op )
>   (op)
>   (op) )
>  (eval '(runTwice inc ) )
>  )
> 
> Give me the error:
> 
> Error: unbound variable: runTwice
> 
> I'm defining runTwice right before running the eval. What am I not 
> understanding?
> 
> Daniel
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] pressed Ctrl-\ and got segmentation fault

[Jim Ursetto]

Ah, so the segfault also occurs with plain old `cat` then?  I think we can 
close this bug ;) Thanks for tracking this down further.

On Jun 23, 2013, at 7:14, Moritz Wilhelmy  wrote:

> On 21.06.2013 22:34, John Cowan wrote:
>> I can confirm that on 32-bit Linux.  On Cygwin, however, typing ^\ does
>> trigger a SIGSEGV with dumped core (except that it doesn't actually dump
>> core because the Windows kernel can't do that).  Both systems are running
>> version 4.8.2 (rev ea02c9a), and there is no .csirc file.  Readline is
>> not involved: the config line says "manyargs dload ptables" only.
> 
> Right.
> 
> $ cat
> ^\
> Segmentation fault (core dumped)
> 
> But:
> $ cat test.c
> #include 
> #include 
> #include 
> 
> void sighandler(int sig)
> {
>printf("Caught signal: %d\n", sig);
> }
> 
> main()
> {
>struct sigaction s;
>memset(&s, 0, sizeof(s));
>s.sa_handler = sighandler;
>
>sigaction(SIGSEGV, &s, 0);
>sigaction(SIGQUIT, &s, 0);
> 
>while (1)
>sleep(1);
> 
>return 0;
> }
> $ ./test &
> [2] 3720
> $ kill -QUIT %2
> Caught signal: 3
> $ kill -SEGV %2
> Caught signal: 11
> $ ./test
> ^\
> Caught signal: 3
> 
> If you comment out sigaction(SIGQUIT, &s, 0); it prints
> Segmentation fault (core dumped)
> although it is actually killed by SIGQUIT, not SIGSEGV.
> 
> This leads me to believe that something inside Cygwin just prints the
> wrong string for some reason, like for instance Windows or Cygwin
> returning a bogus value for WTERMSIG in the wait-syscall the shell
> makes, and that this is not a Chicken bug.
> 
> However, this puzzles me:
> $ find >/dev/null
> ^\
> Quit (core dumped)
> $ cat >/dev/null
> ^\
> Segmentation fault (core dumped)
> $ cat /dev/zero >/dev/null
> ^\
> Quit (core dumped)
> 
> So it might be that processes which are killed while doing I/O print
> "Quit" and "Segmentation fault" otherwise.
> 
> 
> Best regards,
> 
> Moritz
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Issues with socket egg

[Jim Ursetto]

On Jun 17, 2013, at 12:10 PM, Michele La Monaca  
wrote:

> On Sat, Jun 15, 2013 at 1:00 AM, Jim Ursetto  wrote:
>> I believe this should fix the Cygwin problem.
> 
> Yes, it does. Thanks.
> 
> If you care, in Mingw/Msys installation works but it does complain
> about the redefinition of EINVAL and errno by socket.h

Indeed, these are both intentional redefinitions.  Thanks for testing this.

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

Re: [Chicken-users] Issues with socket egg

[Jim Ursetto]

On Jun 14, 2013, at 6:07 PM, John Cowan  wrote:

> 
> You have to be a local Windows admin to set SO_EXCLUSIVEADDRUSE
> on at least some versions of Windows.

I know.  It falls back to SO_REUSEADDR in that case, which is broken on Windows 
but better than nothing.

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

Re: [Chicken-users] Issues with socket egg

[Jim Ursetto]

On May 8, 2013, at 8:48 AM, Michele La Monaca  
wrote:

> 
> 2) The egg doesn’t install on Cygwin due to the unbound identifier
> 'SO_EXCLUSIVEADDRUSE' (mingw only?). Dropping the related option
> (so/exclusiveaddruse) solves the problem.

When you get a chance, can you check out this repository (a superset of socket, 
tcp6 and udp6):

https://bitbucket.org/ursetto/rfc2553

and run `chicken-install socket.setup` from the checkout directory to install 
it?

I believe this should fix the Cygwin problem.

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

Re: [Chicken-users] socket egg: socket-receive blocks?

[Jim Ursetto]

On Jun 14, 2013, at 4:29 PM, Michele La Monaca  
wrote:
> 
> I've already reported this issue in the list:
> 
> http://lists.nongnu.org/archive/html/chicken-users/2013-05/msg00025.html

Sorry, it got lost in the shuffle.
Could you create a ticket for the other two issues you reported?  I don't have 
Solaris or Cygwin but I can try to fix it.

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

Re: [Chicken-users] socket egg: socket-receive blocks?

[Jim Ursetto]

Should be fixed in 0.2.3.  Let me know.

Jim

On Jun 14, 2013, at 3:24 PM, Jim Ursetto  wrote:

> Hi,
> 
> It's a bug in the socket egg; nonblocking mode is only set during a 
> socket-connect or socket-accept, which won't be called for UDP.
> 
> Temporary workaround: (use posix) and then, after creating the socket, do 
> either:
> 
> (##sys#file-nonblocking! (socket-fileno *socket*))
> 
> or equivalently
> 
> (file-control fcntl/setfl (socket-fileno *socket*)
>  (bitwise-ior (file-control fcntl/getfl (socket-fileno *socket*))
>   open/nonblock))
> 
> Neither workaround will work on Windows.
> 
> Permanent fix: We should probably make all sockets nonblocking at creation 
> time instead, since our machinery assumes nonblocking sockets.  We could 
> expose the set-nonblocking operation to the user, but since TCP is always 
> nonblocking, doing this only for UDP would be strange.  Thoughts?
> 
> Jim
> 
> On Jun 14, 2013, at 11:01 AM, Kristian Lein-Mathisen  
> wrote:
> 
>> 
>> Hi Chickeners!
>> 
>> I have come across a problem with multiple srfi-18 threads when tryping to 
>> listen to UDP sockets:
>> 
>> (use socket)
>> (set! *socket* (socket af/inet sock/dgram ))
>> (set! (so-reuse-address? *socket*) #t)
>> (socket-bind *socket* (inet-address "0.0.0.0" 5055))
>> ;; (socket-receive ..) here blocks the prints below
>> ;; after 1 s (about 10 hello's)
>> (thread-start! (lambda ()
>>  (thread-sleep! 1)
>>  (print "receiving ...")
>>  (print (socket-receive *socket* 1024))
>>  (print "done")))
>> 
>> (let loop ()
>>  (print "hello from main-thread!")
>>  (thread-sleep! .1)
>>  (loop))
>> 
>> ;; the hello's from the main thread continue after sending a udp packet:
>> ;; $ echo test `date` | socat - UDP-DATAGRAM:127.0.0.1:5055,broadcast
>> 
>> 
>> The documentation for socket clearly states that socket-receive should not 
>> block:
>> This call will block until data is available, but other threads can proceed.
>> 
>> What is wrong with my socket fd?
>> 
>> K.
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 

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

Re: [Chicken-users] socket egg: socket-receive blocks?

[Jim Ursetto]

Hi,

It's a bug in the socket egg; nonblocking mode is only set during a 
socket-connect or socket-accept, which won't be called for UDP.

Temporary workaround: (use posix) and then, after creating the socket, do 
either:

(##sys#file-nonblocking! (socket-fileno *socket*))

or equivalently

(file-control fcntl/setfl (socket-fileno *socket*)
 (bitwise-ior (file-control fcntl/getfl (socket-fileno *socket*))
  open/nonblock))

Neither workaround will work on Windows.

Permanent fix: We should probably make all sockets nonblocking at creation time 
instead, since our machinery assumes nonblocking sockets.  We could expose the 
set-nonblocking operation to the user, but since TCP is always nonblocking, 
doing this only for UDP would be strange.  Thoughts?

Jim

On Jun 14, 2013, at 11:01 AM, Kristian Lein-Mathisen  
wrote:

> 
> Hi Chickeners!
> 
> I have come across a problem with multiple srfi-18 threads when tryping to 
> listen to UDP sockets:
> 
> (use socket)
> (set! *socket* (socket af/inet sock/dgram ))
> (set! (so-reuse-address? *socket*) #t)
> (socket-bind *socket* (inet-address "0.0.0.0" 5055))
> ;; (socket-receive ..) here blocks the prints below
> ;; after 1 s (about 10 hello's)
> (thread-start! (lambda ()
>  (thread-sleep! 1)
>  (print "receiving ...")
>  (print (socket-receive *socket* 1024))
>  (print "done")))
> 
> (let loop ()
>  (print "hello from main-thread!")
>  (thread-sleep! .1)
>  (loop))
> 
> ;; the hello's from the main thread continue after sending a udp packet:
> ;; $ echo test `date` | socat - UDP-DATAGRAM:127.0.0.1:5055,broadcast
> 
> 
> The documentation for socket clearly states that socket-receive should not 
> block:
> This call will block until data is available, but other threads can proceed.
> 
> What is wrong with my socket fd?
> 
> K.
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] problem building chicken 4.8.0.3 on mac 10.4

[Jim Ursetto]

Was that prior to the makefiles being completely rewritten, though?

Maybe the rewrite uses a feature not available until 3.81, rather than being a 
bug in 3.80.

On Jun 4, 2013, at 9:46, Felix  wrote:

> Hi!
> 
> Using GNU Make 3.81 indeed solves the problem. Still I wonder what the problem
> is. This used to work, especially on said machine...
> 
> 
> cheers,
> felix
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

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

[Jim Ursetto]

On May 29, 2013, at 3:53 PM, Peter Bex  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-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [Chicken-hackers] [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  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-hack...@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-hackers


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

Re: [Chicken-users] Named let*

[Jim Ursetto]

On May 29, 2013, at 3:20 PM, Patrick Li  wrote:

> Hi Michele,
> 
> I realized after posting my version of named-let*, that you actually *cannot* 
> use it to accomplish all of what you want. For that you do need loop to be a 
> syntactic extension, as mentioned by Jorg.
> 
> For instance, my named-let* macro would not simplify the example you posted 
> earlier:
> 
> (let loop ((i (some-function)) (ch (string-ref buf (some-function
>   (do-something)
>   (if (some-condition-is-true)
> (loop (+ i 1)
>   (string-ref buf (+ i 1)
> 
> The key issue underlying this is, when you call (loop), would you like to 
> call it with one or two arguments?

This is why my solution takes one argument, and does not need named-let*: as 
the second argument is computed from the first, there is no reason to pass it 
into the loop procedure, as you would not do this when calling a procedure 
normally.  Passing in a second argument with an unused initial value just 
confuses things.

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

Re: [Chicken-users] Named let*

[Jim Ursetto]

On May 27, 2013, at 4:14 PM, Michele La Monaca  
wrote:

> So writing down the options, we have:
> 
> (let* loop ((i (random N)) (ch (string-ref buf i)))
>  (do-something)
>  (if (some-condition-is-true)
>(loop (+ i 1)
>  (string-ref buf (+ i 1)
> 
> vs.
> 
> (let ((start (random N)))
>  (let loop ((i start) (ch (string-ref buf start)))
>(do-something)
>(if (some-condition-is-true)
>  (loop (+ i 1)
>(string-ref buf (+ i 1))
> 
> vs.
> 
> (let ((ch '()))
>  (let loop ((i (random N)))
>(set! ch (string-ref buf i))
>(do-something)
>(if (some-condition-is-true)
>  (loop (+ i 1)


Why not

(let loop ((i (random N)))
 (let ((ch (string-ref buf i)))
  (do-something)
  (if (some-condition-is-true)
  (loop (+ i 1)


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

Re: [Chicken-users] Passing floats to and from foreign functions

[Jim Ursetto]

Hi pluijzer .,

You did not declare a prototype in test.scm (technically, test.c) for the 
functions in wrapper.c.  I believe return values default to int if there is no 
prototype, and the float arg is promoted to double, but I'm not positive.

Anyway, simply add the following to the top of test.scm:

#>
float testGet();
void testSet(float);
<#

Alternatively, put those declarations in wrapper.h and #include it from 
test.scm.

#> #include "wrapper.h" <#

By the way, you don't need easyffi in your test, as you're not using it.

Jim

P.S.

Passing -Wall to the compiler might help discover these errors.  By default, 
clang gives the following output:

test.c:31:19: warning: implicit declaration of function 'testGet' is invalid in 
C99 [-Wimplicit-function-declaration]
C_r=C_flonum(&C_a,testGet());
  ^
test.c:39:1: warning: implicit declaration of function 'testSet' is invalid in 
C99 [-Wimplicit-function-declaration]
testSet(t0);

On May 11, 2013, at 7:14 PM, "pluijzer ."  wrote:

> Hello everybody,
> I'm having trouble passing floating point numbers to and from foreign 
> functions.
> 
> This is what I'm doing:
> 
> -- test.scm --
> 
> (require-extension easyffi)
> (print ((foreign-lambda float "testGet")))
> ((foreign-lambda void "testSet" float) 4.0)
> (print ((foreign-lambda float "testGet")))
> 
> -- wrapper.c --
> 
> float a = 5.0;
> void testSet(float value) { a = value; }
> float testGet(void) { return a; }
> 
> What I get is this:
> 
> > csc -X easyffi wrapper.c test.scm
> > ./test
> -1080529876.0
> -1080533140.0
> 
> But I expected the output to be:
> 4.0
> 5.0
> 
> I'm I doing something wrong/forgetting something?
> When I use integers instead of floats I do get the desired result.
> 
> Thank you in advance,
> Righard
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Missing "file-type" in posix import

[Jim Ursetto]

I also pushed this to stability.  Thanks.
Jim

On Apr 24, 2013, at 2:40 AM, Christian Kellermann wrote:

> Hi Jules,
> 
> * J Altfas  [130424 08:52]:
>> When I was trying to use (file-type ...) in a compiled module, it was a
>> big surprise when csc instantly ground to a halt, issuing an error
>> saying "file-type" was an unknown identifier.  (And no, I didn't forgot to
>> put (import posix) in the module.)
>> 
>> Checking "posix.import.scm" sure enough showed "file-type" was not among
>> the exported identifiers.  Adding it to the list of exports, recompiling and
>> reinstalling Chicken was the solution.
> 
> Thanks for reporting this issue, I have pushed your proposed fix
> to master.
> 
> Kind regards,
> 
> Christian
> 
> -- 
> In the world, there is nothing more submissive and weak than
> water. Yet for attacking that which is hard and strong, nothing can
> surpass it. --- Lao Tzu
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

[Chicken-users] egg documentation with subpages

[Jim Ursetto]

Hi,

It is now possible to break up egg documentation into several pages.  This was 
previously possible on the wiki, but is now supported by chicken-doc as well.

Procedure: instead of creating a file, create a directory and populate it with 
subpage files.  To document the main page, call the page "index".

Example:
  allegro/color
  allegro/display
  allegro/index

chicken-doc-admin supports directories and will automatically recurse.  It also 
works with the host-installed eggs option.

Notes:

- You should probably create at least a stub "index" file because otherwise the 
main page will 404.
- It's a good idea to place links to the subpages on the main page.  chickadee 
will automatically pick up subpages and place them in the contents bar, but the 
wiki will not.
- All subpages are considered "eggs", which means:
   - It may confuse users who expect each doc page to correspond to exactly one 
egg, unit or module -- there is no "allegro color" egg for example.
   - Subpages will show up in a chicken-doc identifier or egg search, which may 
be confusing or annoying.

There may eventually need to be a way to tag a page as something other than an 
egg for chicken-doc, but that doesn't exist yet.

Jim



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

Re: [Chicken-users] Civet egg ready for release

[Jim Ursetto]

Two reasons:

1) You didn't tag version 0.2.1
2) Your tags say release-0.2 instead of 0.2, so you have to change

(uri targz "https://github.com/mgushee/{egg-name}/tarball/{egg-release}";)
to
(uri targz 
"https://github.com/mgushee/{egg-name}/tarball/release-{egg-release}";)

I think this should work.

On Apr 3, 2013, at 1:25 PM, Matt Gushee wrote:

> Thanks, Mario! However, there seems to be something wrong. I tried
> 'chicken-install civet', and get an error saying there is no .meta
> file. There certainly is one, but somehow it is not being recognized.
> When I try 'chicken-install -r civet, I get:
> 
>  civet/
>  tags/
> 
> That's it. No files in either directory (and the tags directory is not
> one that I created ... I'm guessing it's a GitHub artifact.
> 
> Any idea what the problem is?
> 
> On Wed, Apr 3, 2013 at 11:01 AM, Mario Domenech Goulart
>  wrote:
>> On Wed, 3 Apr 2013 10:04:39 -0600 Matt Gushee  wrote:
>> 
>>> I am pleased to announce that my 'civet' template engine is now ready
>>> for release as an egg. Would Mario or someone be kind enough to add it
>>> to the directory? The release-info file is at:
>>> 
>>> https://raw.github.com/mgushee/civet/master/civet.release-info
>>> 
>>> and documentation is at:
>>> 
>>> https://wiki.call-cc.org/eggref/4/civet
>>> 
>>> Thanks to all!
>> 
>> Thank you, Matt.  I've added your egg to the coop.
>> 
>> Best wishes.
>> Mario
>> --
>> http://parenteses.org/mario
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] local egg documentation (experimental)

[Jim Ursetto]

Hi Matt.

On Apr 2, 2013, at 4:13 PM, Matt Gushee wrote:

> I wonder if there is a program that converts Markdown to Chicken Wiki format?

There is not, mostly because markdown is not really extensible and doesn't 
support marking up procedure identifiers and so on (without terrible hacks).  
There's also the issue of markdown dialects, for example 
https://help.github.com/articles/github-flavored-markdown.  Everybody handles 
syntax highlighting in a different way, like via ```ruby (github) or :::python 
(pymarkdown).  Python does have a fully-fleshed out extension API, which of 
course only works with Python.  Finally, it's somewhat difficult to maintain N 
different X->wiki converters, and I am reluctant to open that box yet.

[Copied from another message:]
> But how about this for a utopian vision: some future version of
> chicken-install has the ability to find the documentation for whatever
> version of an egg you are installing, and downloads it and
> automatically updates your Chickadee repo with the new doc? If we
> could do that I'd feel a lot better about the whole thing.

It is technically possible now to keep your (svnwiki format) documentation 
inside your egg source.  I only recommend doing this for unofficial or 
experimental eggs, though; in other words eggs that are not globally 
installable by chicken-install.  Details are at 
http://api.call-cc.org/doc/chicken-doc-admin#sec:Locally_installed_egg_documentation,
 but briefly:

You can put a wiki doc in /eggname.wiki and install it by adding it to the 
install-extension clause in your .setup file.  After installing it, the user 
can (manually) call "chicken-doc-admin -H" to scan for and update 
locally-installed documentation.  This is experimental right now and could 
change.  We can't really have chicken-install do this step because 
chicken-doc-admin is typically not installed and also chicken-install is part 
of the core and won't be updated until the next major release.

One interesting possibility is to include the chicken-doc-admin call at the end 
of your .setup file.  For example,

 (install-extension
   'inane
'("inane.so" "inane.import.so" "inane.wiki") ;; add wiki doc here
'((version "nan.0")))
 (system "chicken-doc-admin -H inane")

This will not cause an error if chicken-doc-admin fails, you just get a warning 
message on the console.

Alternatively, you could invoke chicken-doc-admin directly on the file in the 
egg source, instead of installing it.  Disadvantage is it won't be there if the 
user wipes out his or her repo, installs chicken-doc later, etc.:

 (install-extension
   'inane
'("inane.so" "inane.import.so")  ;; no wiki doc
'((version "nan.0")))
 (system "chicken-doc-admin -E inane.wiki")

The overall problem with local egg documentation is that NO ONE is using 
chicken-doc-admin except possibly you and me.  Everybody else just pulls the 
database tarball from my homepage, and this will not contain your local docs; 
neither will the wiki or api.call-cc.org.  This is why I recommend using this 
only for unofficial, private or experimental eggs; official eggs should go in 
the wiki for now.

Jim


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

Re: [Chicken-users] Access to wiki

[Jim Ursetto]

John,

I tried in a bunch of different browsers (google search "Chicken Scheme", click 
on result associated with "wiki.call-cc.org/manual/index", and still can't 
reproduce the problem:

OS X 10.7, Safari 6
OS X 10.7, Firefox 19
Windows XP, IE 6.0
Windows XP, IE 8.0
Windows XP, Firefox 3.0

They all send me to either one of:

http://wiki.call-cc.org/man/4/The%20User%27s%20Manual
http://wiki.call-cc.org/man/4/The User's Manual

depending on browser (either is correct).  This is just a redirection from 
wiki.call-cc.org/manual/index:

 $ curl -I wiki.call-cc.org/manual/index
 HTTP/1.1 302 Found
 Location: http://wiki.call-cc.org/man/4/index

 $ curl -I wiki.call-cc.org/man/4/index
 HTTP/1.1 302 Found
 Location: http://wiki.call-cc.org/man/4/The%20User%27s%20Manual

So I have to guess you have a bad proxy or addon in the way.

Jim

On Mar 8, 2013, at 10:48 AM, John Sampson wrote:

> Hello -
> 
> With Internet Explorer, searching on "Chicken Scheme" and clicking on 
> "wiki.call-cc.org/manual/index" I get
> 'Internet Explorer cannot display the webpage'.
> 
> With Firefox as default browser if I click on the link 
> "wiki.call-cc.org/manual/index" from my email message it
> opens "wiki.call-cc.org/man/4/The User's Manual" which is the right page but 
> with a different URL. So it depends
> on guessing the right approach.
> 
> Regards
> 
> John Sampson
> 
> On 08/03/2013 15:22, Matt Gushee wrote:
>> Hi, John--
>> 
>> I don't have time for thorough testing this morning, but I've tried the URL 
>> you mention and a couple of others in Chrome, Firefox, and Opera on my Linux 
>> box, and am not seeing any problem.
>> 
>> It might be useful to know if this happens with other browsers on your 
>> system.
>> 
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] New string manipulation module

[Jim Ursetto]

On Feb 21, 2013, at 2:04 PM, John Cowan wrote:

> I've proposed a new type of import specifier to go with "prefix", namely
> "drop-prefix".  Rather than prefixing all names, this removes the prefix
> from any names that have it.  This would be a Good Thing to add to Chicken;
> Chibi already has it, and it is part of a proposal for R7RS-large.

I think regex rename would be more general.

Jim

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

Re: [Chicken-users] New string manipulation module

[Jim Ursetto]

On Feb 21, 2013, at 1:50 PM, Jörg F. Wittenberger wrote:

> On Feb 20 2013, Mario Domenech Goulart [well, actually, I, Jim] wrote:
> 
>>> "join-strings", and "string-match" or "match-string".  Another is to
>>> keep the s- prefix, which is a natural grouping.  Or you could
>>> require the user to prefix on import, but if that's always needed due
>>> to conflicts, why make them go through the extra step?
> 
> I'd disagree.
> 
> I feel that using the (personally *much* appreciated) rename feature
> chicken provides to disambiguate at the users choice would be the
> best way to deal with this kind of matter.

You're totally free to do so, it seems there is no one right
answer, and my opinion has changed even between eggs.

> Adding this simple statement doesn't make much of a difference to
> your source code.  However *not* having the feature at hand and
> have to rename all identifiers manually when you want to exchange
> one implementation for another is a real burden.

In this case the implementation is essentially of the s.el API, not
a generic strings library, and so an alternate implementation
of the API could just as easily be prefixed s-* to indicate the s.el
API with different underlying code.

Jim


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

Re: [Chicken-users] New string manipulation module

[Jim Ursetto]

I think it sounds good as an official egg; although there's a lot of overlap 
with SRFI-13 it's not bad to have another API.

The main thing I'd suggest if making it official is that, as a port of the s 
library, to name it something like "s" or "s-strings" instead of "strings", 
since the latter sounds like it would be the de-facto strings library for 
chicken.  By convention as a port of s.el I think "s" is the most appropriate 
name.  But I'm not sure if anyone else would agree.  (Just don't name it 
"slib"!)

I also think it's ok to keep the explicit s- prefix on your procedures.  
Although Chicken does support module prefixing, having procedures like "join", 
"matches?", "equals?" and "match" in the first place is not very descriptive, 
and may conflict with commonly-used names.  However, "titlecase" is immediately 
obvious.  One option is to disambiguate the names, like "string-join" or 
"join-strings", and "string-match" or "match-string".  Another is to keep the 
s- prefix, which is a natural grouping.  Or you could require the user to 
prefix on import, but if that's always needed due to conflicts, why make them 
go through the extra step?  Ultimately, since there are no official guidelines 
for naming, it's up to you and your users.

Jim

On Feb 20, 2013, at 11:36 AM, Nicholas Van Horn wrote:

> I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. 
> I've been working on several text processing projects for which I've ported 
> an Emacs-lisp string manipulation library to Chicken.
> 
> The "strings" module provides many convenient string manipulation procedures 
> (including new procedures not ported from the original elisp library). Each 
> procedure is documented with examples. Beyond their immediate convenience, (I 
> think) they present the user with a consistent API for working with strings. 
> 
> I am eager to share this as an "official" egg, but being new to scheme I have 
> likely violated common practices. I share the preliminary module here in the 
> hopes that someone will find it useful. I welcome any feedback with respect 
> to changes in implementation/behavior, as well as missing functionality that 
> you would like to see added.
> 
> The module is packaged to be distributed as an egg, but it is currently only 
> available at:
> 
> https://github.com/n3mo/strings
> 
> Thanks,
> Nicholas Van Horn
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] posix-extras sleep

[Jim Ursetto]

On Feb 20, 2013, at 3:57, J Altfas  wrote:

> On Tues, 19 Feb 2013 15:13:30 -0600> Jim Ursetto wrote: 
> 
> > Hmm, I just realized scheduler.scm relies on nanosleep(3) on UNIX, so I 
> > guess it is safe to use in posix-extras as well. I'll change posix-extras 
> > to use nanosleep shortly. 
> > 
> 
> After all the discussion and further study the merits of nanosleep are 
> clearer, and it nicely accommodates the fractional time specifier idea--it 
> really is a good match. 
> 
> Because the idea was interesting I took the liberty to attempt a simple 
> implementation of a nanosleep-based scheme sleep function: 

Indeed, yesterday I changed posix-extras' sleep to use nanosleep() in 0.1.5.  
The implementation is essentially the same as yours but it also uses Sleep() on 
Windows.  

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

Re: [Chicken-users] posix-extras sleep

[Jim Ursetto]

Hmm, I just realized scheduler.scm relies on nanosleep(3) on UNIX, so I guess 
it is safe to use in posix-extras as well.  I'll change posix-extras to use 
nanosleep shortly.

On Feb 19, 2013, at 2:24 AM, Jim Ursetto wrote:

> On Feb 18, 2013, at 2:36 PM, Jim Ursetto wrote:
> 
>> I would be ok with adding usleep to the posix-extras egg if you want.  I'm 
>> not sure if it should be a separate function or just override (sleep) to 
>> accept fractional values.  I'm thinking the latter.
> 
> Although not exactly what you asked for in your later message, I've 
> implemented a fractional-second sleep in posix-extras 0.1.4.  Simply (use 
> posix-extras), and e.g. (sleep 1.4) works on Unix and Windows.  On Windows it 
> uses Sleep(), on UNIX it uses usleep() + sleep() (since usleep > 1 sec is 
> illegal).
> 
> Jim


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

Re: [Chicken-users] posix-extras sleep

[Jim Ursetto]

On Feb 18, 2013, at 2:36 PM, Jim Ursetto wrote:

> I would be ok with adding usleep to the posix-extras egg if you want.  I'm 
> not sure if it should be a separate function or just override (sleep) to 
> accept fractional values.  I'm thinking the latter.

Although not exactly what you asked for in your later message, I've implemented 
a fractional-second sleep in posix-extras 0.1.4.  Simply (use posix-extras), 
and e.g. (sleep 1.4) works on Unix and Windows.  On Windows it uses Sleep(), on 
UNIX it uses usleep() + sleep() (since usleep > 1 sec is illegal).

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

Re: [Chicken-users] (file-select ...) and compiler warnings

[Jim Ursetto]

On Feb 18, 2013, at 3:58 AM, J Altfas wrote:

> Certainly agree that leaving out usleep was an oversight, considering how 
> simple it is to include it. While I'm pretty sure many of the posix functions 
> are not optimum in an srfi-18 threaded environment, file-select, sleep, and 
> friends are still part of Chicken for good reasons. In that sense, I don't 
> think thread-sleep! would be a universal drop-in replacement for posix 
> usleep, et. al. 

It's probably not an oversight, just that as Felix said there was probably no 
usleep(3) in Windows and the equivalent was never implemented.  Also since 
file-select works, there was probably no impetus to fix it.

I would be ok with adding usleep to the posix-extras egg if you want.  I'm not 
sure if it should be a separate function or just override (sleep) to accept 
fractional values.  I'm thinking the latter.  I would ideally want to get it to 
work on Windows, maybe using John Cowan's suggestion (which gives at most 
millisecond precision, so "usleep" is not a good name) or 
QueryPerformanceCounter (?).  By the way, on Windows, (sleep t) is currently 
implemented as Sleep(t*1000), but the argument is artificially constrained to 
be an integer.

If you just want a direct interface to usleep, I would honestly just wrap it in 
a foreign-lambda in your code as you suggested.  I don't think it's a bad 
approach.

> As long as file-select is available in Chicken, people are going to have uses 
> for it. As it is, the current types.db declaration for file-select produces 
> several warnings. I was a little concerned the warnings might be distressing 
> for new Chicken users, though more a matter of technical details than truly 
> having dire consequences for the compiled output. 

Yes, erroneous warnings should definitely be fixed.  I didn't intend to address 
that in my reply.  file-select is actually a reasonable solution if you want a 
blocking sub-second sleep, although it too doesn't work on Windows.

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

Re: [Chicken-users] (file-select ...) and compiler warnings

[Jim Ursetto]

On Feb 17, 2013, at 4:18 PM, J Altfas wrote:

> Hello, 
> 
> Using 'file-select' as a sub-second sleep procedure works without hitch under 
> csi: 
> 
> (define (sleeper tm) 
> (let ((currms (current-milliseconds))) 
> (let-values (((_ __) (file-select #f #f tm))) 
> (print (- (current-milliseconds) currms)  
> 
> ;1> (sleeper 0.05) 
> 50.0 

Perhaps better is to use thread-sleep!, which does a select or poll behind the 
scenes, but does not block other threads.  file-select will block all threads 
until the timeout occurs.

(use srfi-18)
(define (sleeper tm) 
 (let ((currms (current-milliseconds))) 
  (thread-sleep! tm)
  (print (- (current-milliseconds) currms

You can test this by running a thread in the background:

(thread-start! (lambda () (let lp () (print 'ping) (thread-sleep! 2) (lp
(sleeper 5.5)

> Of course, having a "real" usleep function would be cleaner than faking it 
> with file-select, especially as implementing a usleep procedure is pretty 
> trivial: 
> 
> (define usleep (foreign-lambda int "usleep" unsigned-integer32)) 

I don't know why sleep(3) was implemented in the posix unit and usleep(3) was 
not.  thread-sleep! is preferable to either, though, in my opinion.

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

Re: [Chicken-users] Passing zero-length (sub-)buffers to C functions

[Jim Ursetto]

On Feb 17, 2013, at 2:01 AM, Florian Zumbiehl wrote:

> Here is a trivial example that would seem like a natural way to wrap the
> write() syscall (ignoring error handling for the moment) that fails due to
> this mismatch:
> 
> | (define (sys-write fd buf)
> |   ((foreign-lambda int "write" int c-pointer int)
> | fd
> | (make-locative buf)
> | (string-length buf)))
> | 
> | (sys-write 0 "hello world\n")
> | (sys-write 0 "")
> 
> Which gives this output:
> 
> | hello world
> | 
> | Error: (make-locative) out of range

scheme-pointer is a better choice here.

(define (sys-write fd buf)
   ((foreign-lambda int "write" int scheme-pointer int)
 fd
 buf
 (string-length buf)))


> OpenSSL's EVP_CipherFinal_ex() expects a pointer where it puts any
> remaining output that's produced by padding and encrypting the last partial
> plaintext block that OpenSSL holds in its internal buffer. The natural way
> to use that is by adding the amount of output data received so far to the
> pointer to the start of the destination buffer, which gives you a pointer
> to the remaining free space.  Now, if you are using a stream cipher or a
> block cipher with some stream cipher mode, there is zero remaining free
> space, but there is also zero remaining output, so that is still perfectly
> compatible with this approach: You pass the pointer that points "one past
> the end" of the destination buffer (which is guaranteed to be legal in C,
> you just may not dereference it), and EVP_CipherFinal_ex() does not
> dereference it, and everything is fine.

Instead of binding to EVP_CipherFinal_ex() directly, create a small
wrapper in C which takes a pointer to beginning of buffer and an offset,
add them together, and call EVP_CipherFinal_ex().  We do not have a way
to create a shared subslice of a bytevector-like object right now, so
you have to fudge it.

(define (evp-cipher-final buf offset)
 ((foreign-lambda* int ((scheme-pointer ptr) (int offset))
  "return EVP_CipherFinal_ex(ptr+offset);")
  buf offset)
  
(untested, but typical pattern)

I assume you have no need to check that offset <= size buf, as you are somehow
guaranteed this by the algorithm.

By the way, the best way to figure out how to do stuff like this (other than
asking here of course) is to study existing eggs, many of which naturally
have encountered the same problem countless times.  For example, the sendfile
egg answers both your questions in one place:

(let ((write/offset
 (foreign-lambda* int ((int dst) (nonnull-scheme-pointer buff)
   (unsigned-integer write_offset) (unsigned-integer bytes))
   "C_return(write(dst,buff + write_offset,bytes));")))
 ...)

Jim


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

Re: [Chicken-users] new eggs

[Jim Ursetto]

Holy cow! Great job.
Jim

On Feb 16, 2013, at 8:26, Andrei Barbu  wrote:

> Hi,
> 
> I've got a bunch of eggs that are ready to go.
> 
> 
> These have documentation and are meant as end-user libraries:
> 
> nondeterminism - carry out nondeterministic computations with a more
> flexible interface than the amb egg
>https://github.com/abarbu/nondeterminism
> csp - constraint satisfaction solvers built on top of the above
>https://github.com/abarbu/csp
> AD - performs automatic differentiation, takes a function over real
> numbers and augments it to return the derivative along with its result
>https://github.com/abarbu/AD
> define-structure - a record which provides stateful operations that
> are safe in nondeterministic computations, automatic exports, default
> reader and printer, and qobischeme-compatible accessor functions
>https://github.com/abarbu/define-structure
> 
> These are more infrastructure-oriented and for now come with less 
> documentation:
> 
> traversal - various list and vector traversal functions
>https://github.com/abarbu/traversal
> linear-algebra - operations on vectors and matrices
>https://github.com/abarbu/linear-algebra
> scheme2c-compatibility - misc stuff to make Chicken more compatible
> with Scheme->C
>https://github.com/abarbu/scheme2c-compatibility
> 
> They all come with associated wiki pages.
> 
> Much of this was written in large part by Jeffrey Mark Siskind (much
> of it as part of QobiScheme) along with Siddharth Narayanaswamy and
> myself.
> Could someone make these accessible via chicken-install? Thanks!
> 
> 
> 
> 
> Thanks!
> Andrei
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Segfault with large data-structures (bug)

[Jim Ursetto]

On Feb 4, 2013, at 2:28 PM, Felix wrote:

> 
> Perhaps, but I really don't see a problem of allowing a limit
> on heap allocation in the runtime system.

I think a segfault is an appropriate response to OOM, but I wonder
if it's possible to panic() instead if the heap size can't be increased
as needed.

I also wonder why csi hangs at 100% CPU instead of segfaulting.
Seems like a further indication that panic() should be used.

Currently a panic() is done if heap size is fixed, but not
if it hits the max -- fixed is probably a special case of max,
but I haven't looked very closely.

Jim

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

Re: [Chicken-users] [patch] remove the initial check on directory existance

[Jim Ursetto]

Well, there is another option, which is to put an atomic
implementation in, say, the posix-extras egg, and then the
user may import it under a different name or overwrite
posix's create-directory with it.

On Feb 3, 2013, at 9:26 AM, Peter Bex wrote:

> On Sun, Feb 03, 2013 at 10:22:45AM -0500, John Cowan wrote:
>> Peter Bex scripsit:
>> 
>>> Better to either keep it the way it is, change the semantics and
>>> breaking compat (so be it), or convert to keyword args and make it an
>>> optional feature (my least favorite alternative).
>> 
>> I'm not a big fan of keyword args either, but an optional second argument
>> that makes it atomic wouldn't kill anybody.
>> 
>> (create-directory pathname [ atomic? ] )
> 
> It already takes an optional second arg.  The current signature is:
> 
> (create-directory pathname [ parents? ] )
> 
> This optional parameter tells it to create parent directories if they
> don't exist.  Of course we could make it look like:
> 
> (create-directory pathname [ parents? [ atomic? ] ] )
> 
> This is probably the cleanest backwards-compatible solution.
> 
> Cheers,
> Peter
> -- 
> http://sjamaan.ath.cx
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Segfault with large data-structures (bug)

[Jim Ursetto]

OK, I patched the core and the program runs to completion.  Patch forthcoming.

$ ./list-partials -:d -:hm16G
[debug] application startup...
[debug] heap resized to 1048576 bytes
[debug] stack bottom is 0x7fff6f80f4b0.
[debug] entering toplevel toplevel...
[debug] entering toplevel library_toplevel...
[debug] entering toplevel build_2dversion_toplevel...
[debug] entering toplevel eval_toplevel...
[debug] resizing mutation-stack from 8k to 16k ...
[debug] entering toplevel expand_toplevel...
[debug] entering toplevel modules_toplevel...
[debug] resizing mutation-stack from 16k to 32k ...
[debug] entering toplevel chicken_2dsyntax_toplevel...
[debug] entering toplevel srfi_2d69_toplevel...

 Hash-tables - Inserting edges
[debug] resizing heap dynamically from 1024k to 2048k ...
[debug] resizing heap dynamically from 2048k to 4096k ...
[debug] resizing heap dynamically from 4096k to 8192k ...
[debug] resizing heap dynamically from 8192k to 16384k ...
[debug] resizing heap dynamically from 16384k to 32768k ...
[debug] resizing heap dynamically from 32768k to 65536k ...
[debug] resizing heap dynamically from 65536k to 131072k ...
[debug] resizing heap dynamically from 131072k to 262144k ...
 5000 nodes inserted
[debug] resizing heap dynamically from 262144k to 524288k ...
 1 nodes inserted
[debug] resizing heap dynamically from 524288k to 1048576k ...
 15000 nodes inserted
 2 nodes inserted
[debug] resizing heap dynamically from 1048576k to 2097152k ...
 25000 nodes inserted
 3 nodes inserted
 35000 nodes inserted
 4 nodes inserted
[debug] resizing heap dynamically from 2097152k to 4194304k ...
 45000 nodes inserted
 5 nodes inserted
 55000 nodes inserted
 6 nodes inserted
 65000 nodes inserted
 7 nodes inserted
 75000 nodes inserted
 8 nodes inserted
 85000 nodes inserted
[debug] resizing heap dynamically from 4194304k to 8388608k ...
 9 nodes inserted
 95000 nodes inserted
 10 nodes inserted
 105000 nodes inserted
 11 nodes inserted
 115000 nodes inserted
 12 nodes inserted
 125000 nodes inserted
 13 nodes inserted
 135000 nodes inserted
 14 nodes inserted
 145000 nodes inserted
 15 nodes inserted
 155000 nodes inserted
 16 nodes inserted
 165000 nodes inserted
 17 nodes inserted
 175000 nodes inserted
[debug] resizing heap dynamically from 8388608k to 16777216k ...
 18 nodes inserted
 185000 nodes inserted
 19 nodes inserted
 195000 nodes inserted
 20 nodes inserted
 205000 nodes inserted
 21 nodes inserted
 215000 nodes inserted
 22 nodes inserted
 225000 nodes inserted
 23 nodes inserted
 235000 nodes inserted
 24 nodes inserted
 245000 nodes inserted
1042.938s CPU time, 50.714s GC time (major), 250066522 mutations, 44/851838 GCs 
(major/minor)
[debug] forcing finalizers...
[debug] application terminated normally


On Feb 2, 2013, at 8:06 PM, Jim Ursetto wrote:

> (bug found -- tl;dr see end of message)
> 
> Figured it out: you're exceeding the default maximal heap size, which is 2GB. 
>  For whatever reason, Chicken doesn't terminate reliably and with an error in 
> this situation, it just tries to continue.
> 
> Simply run your program with -:d to see:
> 
> $ ./list-partials -:d
> Hash-tables - Inserting edges
> [debug] resizing heap dynamically from 1024k to 2048k ...
> [debug] resizing heap dynamically from 2048k to 4096k ...
> [debug] resizing heap dynamically from 4096k to 8192k ...
> [debug] resizing heap dynamically from 8192k to 16384k ...
> [debug] resizing heap dynamically from 16384k to 32768k ...
> [debug] resizing heap dynamically from 32768k to 65536k ...
> [debug] resizing heap dynamically from 65536k to 131072k ...
> [debug] resizing heap dynamically from 131072k to 262144k ...
> 5000 nodes inserted
> [debug] resizing heap dynamically from 262144k to 524288k ...
> 1 nodes inserted
> [debug] resizing heap dynamically from 524288k to 1048576k ...
> 15000 nodes inserted
> 2 nodes inserted
> [debug] resizing heap dynamically from 1048576k to 2097151k ...
> 25000 nodes inserted
> 3 nodes inserted
> 35000 nodes inserted
> 4 nodes inserted
> 
> Error: segmentation violation
> 
> 
> 
> The easy fix to is increase the max heap size, say to 8GB:
> 
> $ ./list-partials -:d -:hm8192000k
> [debug] application startup...
> [debug] heap resized to 1048576 bytes
> [debug] stack bottom is 0x7fff693fa4b0.
> [debug] entering toplevel toplevel...
> [debug] entering toplevel library_toplevel...
> [debug] entering toplevel build_2dversion_toplevel...
> [debug] entering toplevel eval_toplevel...
> [debug] resizing mutation-stack from 8k to 16k ...
> [debug] entering toplevel expand_toplevel...
> [debug] entering toplevel modules_toplevel...
> [debug] resizing mutation-stack from 16k to 32k ...
> [debug] entering toplevel chicken_2dsyntax_toplevel

Re: [Chicken-users] Segfault with large data-structures (bug)

[Jim Ursetto]

On Feb 2, 2013, at 8:06 PM, Jim Ursetto wrote:

> Uh oh, we've hit an actual bug now.  Although we can get nodes up to
> 85000 by increasing max heap size from 2GB to 8GB, it appears to bomb
> after the heap exceeds 4GB, maybe indicating some 32-bit sizes
> left laying around in the code.

Hmm, could it be "static C_TLS unsigned int heap_size" in runtime.c? ;)

Jim

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

Re: [Chicken-users] Segfault with large data-structures (bug)

[Jim Ursetto]

(bug found -- tl;dr see end of message)

Figured it out: you're exceeding the default maximal heap size, which is 2GB.  
For whatever reason, Chicken doesn't terminate reliably and with an error in 
this situation, it just tries to continue.

Simply run your program with -:d to see:

$ ./list-partials -:d
 Hash-tables - Inserting edges
[debug] resizing heap dynamically from 1024k to 2048k ...
[debug] resizing heap dynamically from 2048k to 4096k ...
[debug] resizing heap dynamically from 4096k to 8192k ...
[debug] resizing heap dynamically from 8192k to 16384k ...
[debug] resizing heap dynamically from 16384k to 32768k ...
[debug] resizing heap dynamically from 32768k to 65536k ...
[debug] resizing heap dynamically from 65536k to 131072k ...
[debug] resizing heap dynamically from 131072k to 262144k ...
 5000 nodes inserted
[debug] resizing heap dynamically from 262144k to 524288k ...
 1 nodes inserted
[debug] resizing heap dynamically from 524288k to 1048576k ...
 15000 nodes inserted
 2 nodes inserted
[debug] resizing heap dynamically from 1048576k to 2097151k ...
 25000 nodes inserted
 3 nodes inserted
 35000 nodes inserted
 4 nodes inserted

Error: segmentation violation



The easy fix to is increase the max heap size, say to 8GB:

$ ./list-partials -:d -:hm8192000k
[debug] application startup...
[debug] heap resized to 1048576 bytes
[debug] stack bottom is 0x7fff693fa4b0.
[debug] entering toplevel toplevel...
[debug] entering toplevel library_toplevel...
[debug] entering toplevel build_2dversion_toplevel...
[debug] entering toplevel eval_toplevel...
[debug] resizing mutation-stack from 8k to 16k ...
[debug] entering toplevel expand_toplevel...
[debug] entering toplevel modules_toplevel...
[debug] resizing mutation-stack from 16k to 32k ...
[debug] entering toplevel chicken_2dsyntax_toplevel...
[debug] entering toplevel srfi_2d69_toplevel...

 Hash-tables - Inserting edges
[debug] resizing heap dynamically from 1024k to 2048k ...
[debug] resizing heap dynamically from 2048k to 4096k ...
[debug] resizing heap dynamically from 4096k to 8192k ...
[debug] resizing heap dynamically from 8192k to 16384k ...
[debug] resizing heap dynamically from 16384k to 32768k ...
[debug] resizing heap dynamically from 32768k to 65536k ...
[debug] resizing heap dynamically from 65536k to 131072k ...
[debug] resizing heap dynamically from 131072k to 262144k ...
 5000 nodes inserted
[debug] resizing heap dynamically from 262144k to 524288k ...
 1 nodes inserted
[debug] resizing heap dynamically from 524288k to 1048576k ...
 15000 nodes inserted
 2 nodes inserted
[debug] resizing heap dynamically from 1048576k to 2097152k ...
 25000 nodes inserted
 3 nodes inserted
 35000 nodes inserted
 4 nodes inserted
[debug] resizing heap dynamically from 2097152k to 4194304k ...
 45000 nodes inserted
 5 nodes inserted
 55000 nodes inserted
 6 nodes inserted
 65000 nodes inserted
 7 nodes inserted
 75000 nodes inserted
 8 nodes inserted
 85000 nodes inserted
[debug] resizing heap dynamically from 0k to 1024k ...
[panic] out of memory - heap full while resizing - execution terminated

Uh oh, we've hit an actual bug now.  Although we can get nodes up to
85000 by increasing max heap size from 2GB to 8GB, it appears to bomb
after the heap exceeds 4GB, maybe indicating some 32-bit sizes
left laying around in the code.

Jim

On Feb 2, 2013, at 7:18 PM, Jim Ursetto wrote:

> On Feb 2, 2013, at 3:46 PM, Kristian Lein-Mathisen wrote:
> 
>> I'm getting the same result here, when I run it through csc. When I run it 
>> through csi, though, it never seems to finish - is the task that big? I had 
>> to kill it after 2-3 hours.
> 
> It's a hash table with 250,000 entries and 1,000 items per entry.  That's 
> going to be tens of gigabytes for heap (memory usage at 40,000 nodes just 
> before it dies is about 2GB on my machine).  It's 250,000 node inserts 
> (O(V)), 250 million edge inserts (O(V*E)), and 125 billion operations 
> (O(V*E^2)) to traverse the edge lists (since you are using member).  To me 
> that is pretty big.
> 
> csi doesn't crash but appears to be stuck after 40,000 nodes inserted, the 
> same place that csc crashes maybe.  It's not swap related, I had plenty of 
> memory, so something is maybe up with the hash table or GC.  I can't explain 
> why csi does not crash.
> 
> This machine is 64-bit OS X with 16GB main memory and no obvious limit to the 
> process data segment.
> 
> Probably stupid shot in the dark: what happens when the Chicken heap size 
> exceeds 4GB on a 64-bit machine?
> 
> Jim


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

Re: [Chicken-users] Segfault with large data-structures

[Jim Ursetto]

On Feb 2, 2013, at 3:46 PM, Kristian Lein-Mathisen wrote:

> I'm getting the same result here, when I run it through csc. When I run it 
> through csi, though, it never seems to finish - is the task that big? I had 
> to kill it after 2-3 hours.

It's a hash table with 250,000 entries and 1,000 items per entry.  That's going 
to be tens of gigabytes for heap (memory usage at 40,000 nodes just before it 
dies is about 2GB on my machine).  It's 250,000 node inserts (O(V)), 250 
million edge inserts (O(V*E)), and 125 billion operations (O(V*E^2)) to 
traverse the edge lists (since you are using member).  To me that is pretty big.

csi doesn't crash but appears to be stuck after 40,000 nodes inserted, the same 
place that csc crashes maybe.  It's not swap related, I had plenty of memory, 
so something is maybe up with the hash table or GC.  I can't explain why csi 
does not crash.

This machine is 64-bit OS X with 16GB main memory and no obvious limit to the 
process data segment.

Probably stupid shot in the dark: what happens when the Chicken heap size 
exceeds 4GB on a 64-bit machine?

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

Re: [Chicken-users] Segfault with large data-structures

[Jim Ursetto]

What version of chicken, and if 4.8.0 for example could you try 4.7?

On Feb 2, 2013, at 11:51, Arthur Maciel  wrote:

> Hello! I don't know if it is related to Ivan's problem, but when I compile 
> and run this code:
> 
> (use srfi-69)
> 
> (define NODES 25)
> (define EDGES 1000)
> 
> (define graph (make-hash-table))
> 
> (define (insert-edges)
>   (printf "~N Hash-tables - Inserting edges ~N")
>   (do ((n 1 (+ n 1))) ((= n NODES))
> (if (= (remainder n 5000) 0)
> (printf " ~S nodes inserted ~N" n))
> (do ((e 2 (+ e 1))) ((= e (+ 1 EDGES)))
>   (hash-table-update!/default graph
>   n
>   (lambda (edges-list)
> (if (member e edges-list)
> edges-list
> (cons e edges-list)))
>   (list e)
> 
> (time  (insert-edges))
> 
> I get this:
> 
>  $ csc list-in-hash-table-partials.scm -o list-partials.scm
>  $ ./list-partials.scm 
> 
>  Hash-tables - Inserting edges 
>  5000 nodes inserted 
>  1 nodes inserted 
>  15000 nodes inserted 
>  2 nodes inserted 
>  25000 nodes inserted 
>  3 nodes inserted 
>  35000 nodes inserted 
>  4 nodes inserted 
> Segmentation fault
> 
> 
> I tried to compile with -O2, -O -d2 and -O3. It doesn't make difference for 
> me: it always present a segfault. Any hint on how to make it work?
> 
> Thanks!
> Arthur
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] [patch] remove the initial check on directory existance

[Jim Ursetto]

I am positive this is a case where the documentation was written
to explain an implementation artifact.  That note wasn't added
until 11 months ago ... by Mario.

The current implementation returns "foo" if a file foo
(not just a directory foo) already exists.  No one is
ever going to check this return value.  It seems to me
if regular file "foo" exists it should be an error.

I don't think it's atomic any more if you ignore EEXISTS, because

1) the existing directory could be owned by the wrong person
2) it might still be a regular file
3) when used to implement dotlocking, the caller needs to know
   whether EEXISTS was returned, akin to using O_CREATE|O_EXCL.

Unfortunately as Peter suggested, I doubt we could change the
behavior to error out when the directory exists, because some
code probably relies on it.

I think we could error out on regular file existing, i.e. change
file-exists? to directory-exists? or perhaps check type
after the fact on EEXISTS.

But making it atomic would probably require a new procedure name,
which does not check for existence beforehand and does not
ignore EEXISTS.  You could still ignore EEXISTS if creating
the full path (parents? == #t).  This is then like mkdir -p.
It's how I would expect it to behave and preserves atomicity.
This could potentially go in the posix-extras egg.

Jim

On Feb 2, 2013, at 9:57 AM, Mario Domenech Goulart wrote:

> Hi,
> 
> On Sat, 2 Feb 2013 16:54:19 +0100 Peter Bex  wrote:
> 
>> On Sun, Feb 03, 2013 at 02:20:59AM +1100, richo wrote:
>>> This patch removes the internal check for directory existance in
>>> create-directory, meaning that it can be treated as atomic on platforms 
>>> where mkdir(2) is.
>> 
>> This makes it inconsistent with the documentation (which, iiuc is already
>> the case on Windows).
>> 
>> I think this patch shouldn't go through, the behavior is wrong.
>> It's probably better to make it ignore EEXIST if you want it to be
>> atomic.
> 
> Also, it's likely to break code that relies on the current
> `create-directory' behavior.
> 
> OTOH, as far as I understand, the current `create-directory'
> implementation is subject to race conditions, since the check/create
> steps are not atomic.
> 
> Maybe it should just attempt to create the directory and ignore errors
> when it cannot be created because it exists (maybe that's what Peter
> suggests -- I'm not sure).
> 
> 
> Best wishes.
> Mario
> -- 
> http://parenteses.org/mario
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Msgpack implementation for scheme (and some questions)

[Jim Ursetto]

On Jan 28, 2013, at 2:53 PM, Hugo Arregui wrote:

> 3) To read/write float/double numbers (in ieee754) i'm using
> endian-blob egg (here[4]), it's there any alternative without
> implementing the full float/double->binary logic (which seems quite
> complicated)?

Maybe I'm overlooking something, but my understanding is that all modern
machines use IEEE 754 format internally, and although endianness is
unspecified, it can be assumed it's the same as for integers except for
all but the weirdest of platforms.  Virtually all the complex logic
in endian-blob / GDB for floating point conversion is for 
extended floating point values or platforms like VAX and old
ARM processors, and could probably just be discarded.

So if you want IEEE 754 format output, can you not just cast
the floating point memory to uint8_t* (e.g. (uint8_t*)&f )
and then write out the bytes in big-endian order?

And if you don't know your system's endianness and so can't easily
use something like bswap, you should just be able to cast to a
sufficiently wide integer value and write out a byte at a time
in sequence; e.g.

 /* untested */
 double d=35.4;
 write_byte( ((*(uint64_t *)&d) >> 56) & 0xff );
 write_byte( ((*(uint64_t *)&d) >> 48) & 0xff );
 write_byte( ((*(uint64_t *)&d) >> 40) & 0xff );
 ...

The bit-twiddling of the latter example can't easily be accomplished
directly in Chicken due to lossage on integers larger than 53 bits,
but you could do byte swapping in C and byte writing from Chicken.

Jim

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

Re: [Chicken-users] Msgpack implementation for scheme (and some questions)

[Jim Ursetto]

FYI, the docs for endian-blob don't indicate the ordering of the endian blob 
after type->endian_blob.  From reading the code it's MSB and there's an 
optional "mode" arg to these procedures.  Should this be documented?  Similarly 
the optional mode argument to byte-blob->endian-blob is documented as being 
required not optional.

Jim

On Jan 28, 2013, at 6:18 PM, Ivan Raikov wrote:

> Hi Hugo,
> 
>  Thanks for your work on msgpack, it seems like an interesting project. 
> Unfortunately, machine floating point formats are complicated, so any related 
> code will be complicated as well. I don't know much about the msgpack 
> protocol, but if representing floating-point numbers as strings is an option, 
> I encourage you to look at fpio ( http://wiki.call-cc.org/eggref/4/fpio ), a 
> BSD-licensed egg for converting  floating point numbers to strings and vice 
> versa. endian-blob includes code from GDB, so it cannot be relicensed without 
> approval from the GNU project.
> 
>   Ivan
> 
> 
> 
> On Tue, Jan 29, 2013 at 5:53 AM, Hugo Arregui  wrote:
> Hi,
> 
> Recently I wrote an implementation of msgpack[1], which can be found
> here[2]. This is my first "full" project in scheme, so I would
> appreciate any feedback (please, be destructive).
> 
> A couple of points already has been mentioned:
> 
> - Macros to reduce redundancy (I'm reading about them, so I'm
> expecting to fix this soon).
> - A non technical but important thing: I'm using endian-blob egg,
> which is licensed as gpl and it's incompatible with the project
> license, which is bsd.
> 
> But, beside that, I have a few questions:
> 
> 1) To avoid the creation of very heavy structures in tests, i'm using
> a kind of mock[3], which overrides some procedures, and restores it
> later. Is this the right way to do it?.
> 
> In fact, in the "egg" branch I tried to pack the project as an egg and
> I think this "hack" is not working.
> 
> 2) To access the procedures mentioned in (1), i'm using two modules:
> "msgpack-imple" which contains the whole project and it's used for the
> tests, and "msgpack" which import "msgpack-imple" and expose the real
> interface. Again, is this the right way to do it?
> 
> 3) To read/write float/double numbers (in ieee754) i'm using
> endian-blob egg (here[4]), it's there any alternative without
> implementing the full float/double->binary logic (which seems quite
> complicated)?
> 
> Thanks,
> Hugo.
> 
> [1] http://msgpack.org/
> [2] https://github.com/hugoArregui/msgpack-scheme
> [3] 
> https://github.com/hugoArregui/msgpack-scheme/blob/master/tests/run.scm#L187
> [3] 
> https://github.com/hugoArregui/msgpack-scheme/blob/master/msgpack-imple.scm#L131
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Cannot export record methods in module

[Jim Ursetto]

I think you just need to (import scheme chicken) instead of (import chicken).

On Jan 21, 2013, at 8:09 PM, Werner Schmierdorfer wrote:

> Hi!
> 
> I try the following in chicken-4.8.0.1:
> 
> 
>   (module rectest (make-foo foo-a foo-b)
>   (import chicken)
>   (define-record foo a b))
> 
> 
> …and csi prints the following output:
> 
>   #;1> (module rectest (make-foo foo-a foo-b)
>   (import chicken)
>   (define-record foo a b))
> 
>   Warning: reference to possibly unbound identifier `foo' in:
>   Warning:foo?
> 
>   Warning: reference to possibly unbound identifier `quote' in:
>   Warning:foo?
> 
>   Error: module unresolved: rectest
> 
>   Call history:
> 
> (define84 foo-b-set! (##core#lambda (x val) 
> (##core#check (##sys#check-structure x (##core#quote foo...
> (##core#set! foo-b-set! (##core#lambda (x 
> val) (##core#check (##sys#check-structure x (##core#quote foo...
> (##core#lambda (x val) (##core#check 
> (##sys#check-structure x (##core#quote foo))) (##sys#block-set!..
> [foo-b-set!] (##core#begin (##core#check 
> (##sys#check-structure x (##core#quote foo))) (##sys#block-set! x 2 val)...
> [foo-b-set!] (##core#check 
> (##sys#check-structure x (##core#quote foo)))
> [foo-b-set!] (##sys#check-structure x 
> (##core#quote foo))
> [foo-b-set!] (##core#quote foo)
> [foo-b-set!] (##sys#block-set! x 2 val)
> (define84 foo-b (##core#lambda (x) 
> (##core#check (##sys#check-structure x (##core#quote foo))) (##sy..
> (##core#set! foo-b (##core#lambda (x) 
> (##core#check (##sys#check-structure x (##core#quote foo))) (#..
> (##core#lambda (x) (##core#check 
> (##sys#check-structure x (##core#quote foo))) (##sys#block-ref x 2)...
> [foo-b] (##core#begin (##core#check 
> (##sys#check-structure x (##core#quote foo))) (##sys#block-ref x 2))
> [foo-b] (##core#check (##sys#check-structure 
> x (##core#quote foo)))
> [foo-b] (##sys#check-structure x 
> (##core#quote foo))
> [foo-b] (##core#quote foo)
> [foo-b] (##sys#block-ref x 2) <--
> 
> 
> Is it possible (and if yes - how?) to export functions created by 
> define-record?
> 
> 
> Greetings, Werner
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

[Chicken-users] Chicken 4.8.0.1 released

[Jim Ursetto]

Hi all,

Chicken 4.8.0.1 is now available for download from the usual place:

 http://code.call-cc.org/releases/4.8.0/chicken-4.8.0.1.tar.gz

For what's new, see

 http://code.call-cc.org/releases/4.8.0/NEWS-4.8.0.1

The 4.8.0.x releases reside on the stability/4.8.0 branch in git,
which you can retrieve with:

 git clone --branch stability/4.8.0 git://code.call-cc.org/chicken-core


Jim

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

Re: [Chicken-users] Building 32-bit chicken scheme on OS X

[Jim Ursetto]

Dani,

ASSEMBLER_OPTIONS is missing:

make PLATFORM=macosx ARCH=x86 C_COMPILER_OPTIONS="-no-cpp-precomp 
-fno-strict-aliasing -fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -m32" 
ASSEMBLER_OPTIONS="-m32" LINKER_OPTIONS="-m32"

The resulting chicken gives me a bus error though and I don't know how to fix 
that.

Jim

On Jan 10, 2013, at 5:07 AM, Daniel P. Wright wrote:

> Hello,
> 
> I am trying to build chicken scheme for 32-bit on a 64-bit mac running
> Mountain Lion.  I have come across people having issues with the
> opposite case, where old versions of OS X built 32-bit and required a
> flag to build 64-bit, but not this way round.
> 
> I have taken the solution to the latter problem and reversed it, so that
> I pass ARCH="x86" to make.  The error I get is as follows:
> 
>mac:chicken-4.8.0 okubo$ make PLATFORM=macosx ARCH="x86"
>make -f ./Makefile.macosx CONFIG= all
>gcc  -c apply-hack.x86.S -o apply-hack.x86.o
>apply-hack.x86.S:35:suffix or operands invalid for `call'
>make[1]: *** [apply-hack.x86.o] Error 1
>make: *** [all] Error 2
> 
> Looking at the referenced assembly file, passing "*%eax" to call seems
> to be what's throwing it.  I don't really know what I'm doing in
> assembler, so I'm not sure whether that should be valid or not, though
> rivo238123 mentioned in #chicken that it should be in 32-bit mode.
> 
> I'm guessing there's probably a flag I'm not passing somewhere, but I'm
> not sure what it would be.  I have tried setting CPPFLAGS, LDFLAGS,
> LINKER_OPTIONS and C_COMPILER_OPTIMIZATION_OPTIONS to "-m32" (on the
> advice of rivo238123) but had no luck.
> 
> Has anybody come across this issue?  Any clues which could lead me in
> the right direction toward getting it building would be greatly
> appreciated.
> 
> Many thanks,
> 
> Dani.
> 
> PS - Please include me in replies as I am not currently subscribed to
> this list.
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] MacOSX setup-helper install error

[Jim Ursetto]

I was afraid of that, a path of that size should still have worked
with the provided parameter, and I was able to run install_name_tool
with your example path without an error.  I ran across someone
complaining about a similar issue in another project without a solution.
Installing into a shorter path is not an acceptable long-term fix IMO.

There may be something going on with 10.8 or latest XCode;
unfortunately I haven't upgraded from 10.7 yet...

On Dec 27, 2012, at 2:30 PM, .alyn.post. wrote:

> Thank you Jim,
> 
> I went ahead with #3.  Neither #1 nor #2 worked for me, but I wasn't
> as thorough as I might have been testing them.
> 
> -Alan
> 
> On Thu, Dec 27, 2012 at 01:13:20PM -0600, Jim Ursetto wrote:
>> Normally indicates the install path is too long; if so it is surprising the 
>> build
>> and install of Chicken itself even worked.
>> 
>> Try one of these fixes:
>> 
>> 1) Recompile and reinstall chicken after changing this
>>   line in Makefile.macosx:
>> 
>>   LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad -Wl,128
>> 
>>   to
>> 
>>   LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad_max_install_names
>> 
>> 2) Recompile chicken after increasing the value 128 in the same
>>   line instead, e.g.:
>> 
>>   LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad -Wl,4000 
>> 
>> 3) Install Chicken into a shorter path
>> 
>> Hopefully one of these works.
>> 
>> On Dec 27, 2012, at 12:15 PM, .alyn.post. wrote:
>> 
>>> I'm running Mac OS X 10.8.2 and have just installed the latest
>>> XCode+XCode command-line tools.  I've built chicken 4.8.0, and
>>> am trying to install the setup-helper egg.  I get the following
>>> error.  I'm not familiar with install_name_tool, though I gather
>>> it's a piece of XCode and/or some Mac OS X-specific piece of the
>>> toolchain.
>>> 
>>> Are any of you familiar enough with this platform to shed some
>>> light on what is going on?
>>> 
>>> -Alan
>>> 
>>> installing setup-helper:1.5.3 ...
>>> changing current directory to
>>> /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper
>>> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csi
>>> -bnq -setup-mode -e "(require-library setup-api)" -e "(import
>>> setup-api)" -e "(setup-error-handling)" -e
>>> "(extension-name-and-version '(\"setup-helper\" \"1.5.3\"))"
>>> /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper/setup-helper.setup
>>> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc
>>> -feature compiling-extension -setup-mode-s -O3 -d1
>>> setup-helper-mod.scm -j setup-helper-mod
>>> install_name_tool: changing install names or rpaths can't be redone
>>> for: setup-helper-mod.so (for architecture x86_64) because larger
>>> updated load commands do not fit (the program must be relinked, and
>>> you may need to use -headerpad or -headerpad_max_install_names)
>>> 
>>> Error: shell command terminated with non-zero exit status 256:
>>> install_name_tool -change libchicken.dylib
>>> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/lib/libchicken.dylib
>>> setup-helper-mod.so
>>> 
>>> Error: shell command failed with nonzero exit status 256:
>>> 
>>> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc
>>> -feature compiling-extension -setup-mode-s -O3 -d1
>>> setup-helper-mod.scm -j setup-helper-mod
>>> 
>>> 
>>> Error: shell command terminated with nonzero exit code
>>> 17920
>>> 
>>> 
>>> -- 
>>> my personal website: http://c0redump.org/
>>> 
>>> ___
>>> Chicken-users mailing list
>>> Chicken-users@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/chicken-users
>> 
> 
> -- 
> my personal website: http://c0redump.org/


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

Re: [Chicken-users] MacOSX setup-helper install error

[Jim Ursetto]

Normally indicates the install path is too long; if so it is surprising the 
build
and install of Chicken itself even worked.

Try one of these fixes:

1) Recompile and reinstall chicken after changing this
   line in Makefile.macosx:

   LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad -Wl,128

   to

   LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad_max_install_names

2) Recompile chicken after increasing the value 128 in the same
   line instead, e.g.:

   LINKER_LINK_SHARED_DLOADABLE_OPTIONS += -Wl,-headerpad -Wl,4000 

3) Install Chicken into a shorter path

Hopefully one of these works.

On Dec 27, 2012, at 12:15 PM, .alyn.post. wrote:

> I'm running Mac OS X 10.8.2 and have just installed the latest
> XCode+XCode command-line tools.  I've built chicken 4.8.0, and
> am trying to install the setup-helper egg.  I get the following
> error.  I'm not familiar with install_name_tool, though I gather
> it's a piece of XCode and/or some Mac OS X-specific piece of the
> toolchain.
> 
> Are any of you familiar enough with this platform to shed some
> light on what is going on?
> 
> -Alan
> 
> installing setup-helper:1.5.3 ...
> changing current directory to
> /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper
>  
> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csi
> -bnq -setup-mode -e "(require-library setup-api)" -e "(import
> setup-api)" -e "(setup-error-handling)" -e
> "(extension-name-and-version '(\"setup-helper\" \"1.5.3\"))"
> /var/folders/16/7q68s2js4_5d7cvdvr6zqvv8gn/T/tempd32.13162/setup-helper/setup-helper.setup
>  
> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc
> -feature compiling-extension -setup-mode-s -O3 -d1
> setup-helper-mod.scm -j setup-helper-mod
> install_name_tool: changing install names or rpaths can't be redone
> for: setup-helper-mod.so (for architecture x86_64) because larger
> updated load commands do not fit (the program must be relinked, and
>  you may need to use -headerpad or -headerpad_max_install_names)
> 
> Error: shell command terminated with non-zero exit status 256:
> install_name_tool -change libchicken.dylib
> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/lib/libchicken.dylib
> setup-helper-mod.so
> 
> Error: shell command failed with nonzero exit status 256:
> 
>  
> /Users/a/wa/call-cc.org/pkg/chicken/4.8.0/darwin/12.2.1/x86_64/gcc/4.2.1/opt/bin/csc
> -feature compiling-extension -setup-mode-s -O3 -d1
> setup-helper-mod.scm -j setup-helper-mod
> 
> 
> Error: shell command terminated with nonzero exit code
> 17920
> 
> 
> -- 
> my personal website: http://c0redump.org/
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Browsing the Chicken wiki offline

[Jim Ursetto]

On Dec 13, 2012, at 11:12 AM, Jim Ursetto wrote:

> On Dec 13, 2012, at 1:47 AM, John Magolske wrote:
> 
>> - Some intra-wiki links are absolute, for example under /wiki/menu
>> there's [[http://wiki.call-cc.org/eggs|Eggs]] which I changed to
>> [[eggs|Eggs]] so as to be able to navigate to it offline. I'm thinking
>> of writing a script to go through my local repository and convert all
>> absolute wiki.call.cc.org urls to relative. Is there a reason they
>> were input as absolute?
> 
> It might be useful to make this change to the main repository, i.e.
> sub [[http://wiki.call-cc.org/ => [[/.  Anybody see a problem with this?

I've made this change and performed some related fixups.
Let me know if this works for you.

Jim

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