Moritz Heidkamp | 29 Jan 18:51 2015

Re: [SECURITY] Fix buffer overrun in substring-index[-ci]

On 12 January 2015 17:29 CET, Moritz Heidkamp wrote:

> the substring-index[-ci] procedures of the data-structures unit are
> vulnerable to a buffer overrun attack when passed an integer greater
> than zero as the optional START argument. This issue was fixed in master
> (25db851) and chicken-5 (63d0445) via the patch discussed at

This vulnerability was assigned CVE-2014-9651.

Kind regards,
The CHICKEN team
Chicken-users mailing list
Chicken-users <at>
Alexej Magura | 29 Jan 13:23 2015

maintaining posix-extras

I can't find Jim Ursetto's email anywhere in the source for posix-extras 
or on his website, although I suppose I could check the mailing list, 
but I figured this'd be faster.  EDIT: I checked the mailing list, and 
it looks like Jim keeps his email hidden so it looks like this might be 
the only way to get in touch with him.

I'd like to start maintaining the posix-extras egg, and wanted to make 
sure this'd be fine with Jim.
Alexej Magura | 29 Jan 07:38 2015

emacs svnwiki mode

Does anybody have any custom svnwiki mode setups for Emacs?  I googled 
for a svnwiki mode but didn't find any there or in my Linux distro's repos.
Daniel Ziltener | 26 Jan 17:41 2015

Up to date Chicken packages for most Linux distributions

I created a repository on the OpenSUSE Build Service with packages for most 
distributions. For some distributions all that was needed was a little 
tweaking, for some it was a bit more, but here it is:

Have fun with it! Oh, and I'd be glad if users of other distributions than 
OpenSUSE could maybe give feedback if they really work as intended, but they 


Daniel Ziltener

Benutze Kryptographie für E-Mails; siehe
Please use cryptography for email; see
Chicken-users mailing list
Chicken-users <at>
Christian Kellermann | 26 Jan 13:59 2015

Updated CHICKEN packages for cygwin comming to you soon

Dear list,

I have been mailing back and forth with the fine cygwin folks the
last weeks. As a result we will have up-to-date CHICKEN packages
for 32 and 64 bit platforms available as soon as the uploaded files
have been verified by their machinery.

As a downside the 64 bit version does not have an apply hack available
for now since Microsoft choose another ABI for ttheir 64bit platform.
So if you really want your 64 bit CHICKEN on windows to be able to
handle all the arguments please consider contributing such an apply

Please let me know if you run into troubles! (And / or drop by in
#chicken and complain about it)

Thank you!



May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.
Daniel Ziltener | 26 Jan 07:15 2015

In-code documentation with Cock - how?

I found the egg manual to cock a bit unhelpful for what it states about the 
.setup-file. I'm working on a library where my .setup-file contains two 
"compile" and an "install-extension" expressions, but the manual now tells me 
I have to use "setup-shared-extension-module" and "run-cock". Do I put them in 
the setup file additionally to the already-existing content, or do they 
replace certain parts?
Is cock even "state of the art" for in-code and egg documentation?


Daniel Ziltener

Benutze Kryptographie für E-Mails; siehe
Please use cryptography for email; see
Chicken-users mailing list
Chicken-users <at>
Alexej Magura | 25 Jan 23:21 2015

malloc'd memory

If I have a function that returns a malloc'd pointer, or that needs to 
have a buffer malloc'd, is it more idiomatic to (1) malloc and free in 
the caller function (which is C's idiom, IIRC), or (2) malloc it in C 
and then just return the pointer for free'ing by Chicken once the caller 
function is done with the pointer?
Alexej Magura | 25 Jan 22:55 2015

Re: readline egg v2.0 feedback

Forgot to send my reply to the Chicken users mailing list too.

-------- Forwarded Message -------- Subject: Date: From: To:
Re: [Chicken-users] readline egg v2.0 feedback
Sun, 25 Jan 2015 14:54:09 -0700
Alexej Magura <agm2819 <at>>
Matt Welland <mattrwelland <at>>

Actually, after reviewing the source a little, it seems that #4 is already supported, although it probably isn't very well documented.  This next release may need to be 3.0 instead of 2.5 if I decide to change the interface again--I hate doing that--which may prove necessary with some of the changes I already
want to make to the history-list function for example: presently the underly C code uses a statically allocated buffer, which should be more than big enough for most cases, but I feel like it's awfully wasteful, and would be better served by dynamic memory allocation instead.

I'm not familiar with the ,X interface idiom or whatever it is, but it sounds like something worth looking into and using.

As for using sqlite, I'd be worried that it would add unnecessary overhead and read/write times to readline; moreover, readline provides no hooks, AFAICT; I'd have to write my own, and I don't see much to gain from using sqlite, sorry.  I guess you were hoping that it would make it easier to implement more advanced history features like, super easy history grepping, running the last command over again, and that sort of thing, or something like that?

One problem with Readline, which I admittedly have been avoiding, is that the documentation, is lacking, and, I think, this may contribute to the number/degree of users unaware or unsure of how to achieve a desired effect using Readline.

On 01/25/2015 02:29 PM, Matt Welland wrote:
#1 - yes, appreciated
#2 - nice, csi commands using the ,X interface would be nice. ,er - enable recording, ,dr - to disable recording or something similar.
#3 - very nice indeed.
#4 - even nicer :)

Aside: I think it'd be handy to store my csi history using my sqlite3 based "hs" command line history store tool ( If your readline library allowed writing hooks that could update/query via other calls it would be easy to bolt on hs or other such tools. Perhaps this is already easy - I haven't actually looked yet.

On Sun, Jan 25, 2015 at 1:50 PM, Alexej Magura <agm2819 <at>> wrote:
I think that a reasonable solution would be to (1) create the history file if it does not already exist, (2) allow users to explicitly disable/enable history keeping at any time, (3) simplify history file installation to include only about a line of code, (4) add an option to either wipe the history file completely, truncat it to X many lines or history transactions.

How does all that sound?

Also, it's worth noting that we're currently on version 2.4 with 2.5 on the way.

On 01/25/2015 10:21 AM, John Cowan wrote:
matt <at> scripsit:

As a daily user of csi with readline I look forward to using your
enhancements.  If it makes sense to do I would like to see the
behavior change for a new install, currently the user has to touch
the ~/.csi-history (?) file before history will be kept. I'd like it
if that became unnecessary.
That amounts to saying that every instance of csi logs everything you do.
For both space and security reasons, I think it's better if the user has
to take an affirmative action before that happens.

Chicken-users mailing list
Chicken-users <at>

Chicken-users mailing list
Chicken-users <at>
Didier Verna | 24 Jan 11:01 2015

[2nd CfP] European Lisp Symposium 2015, April 20-21, London

		 ELS'15 - 8th European Lisp Symposium
		    Goldsmiths College, London, UK

			  April 20-21, 2015

	  Sponsored by EPITA, Franz Inc. and Lispworks Ltd.

Recent news:

- Submission deadline in less than a month now!
- Programme committee has been announced (see below)
- Venue information now available on the web site

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in Lisp to participate.

The 8th European Lisp Symposium invites high quality papers about
novel research results, insights and lessons learned from practical
applications and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
- Educational approaches and perspectives
- Experience reports and case studies

We invite submissions in the following forms:

  Papers: Technical papers of up to 8 pages that describe original
    results or explain known ideas in new and elegant ways.

  Demonstrations: Abstracts of up to 2 pages for demonstrations of
    tools, libraries, and applications.

  Tutorials: Abstracts of up to 4 pages for in-depth presentations
    about topics of special interest for at least 90 minutes and up to
    180 minutes.

  The symposium will also provide slots for lightning talks, to be
  registered on-site every day.

All submissions should be formatted following the ACM SIGS guidelines
and include ACM classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see: and

Important dates:

  - 22 Feb 2015: Submission deadline
  - 15 Mar 2015: Notification of acceptance
  - 29 Mar 2015: Early registration deadline
  - 05 Apr 2015: Final papers
  - 20-21 Apr 2015: Symposium

Programme chair:
    Julian Padget, University of Bath, UK

Local chair:
    Christophe Rhodes, Goldsmiths, University of London, UK

Programme committee:
    Sacha Chua — Toronto, Canada
    Edmund Weitz — University of Applied Scicences, Hamburg, Germany
    Rainer Joswig — Hamburg, Germany
    Henry Lieberman — MIT, USA
    Matthew Flatt — University of Utah, USA
    Christian Queinnec — University Pierre et Marie Curie, Paris 6, France
    Giuseppe Attardi — University of Pisa, Italy
    Marc Feeley — University of Montreal, Canada
    Stephen Eglen — University of Cambridge, UK
    Robert Strandh — University of Bordeaux, France
    Nick Levine — RavenPack, Spain

Search Keywords:

#els2015, ELS 2015, ELS '15, European Lisp Symposium 2015,
European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium,
European Lisp Conference 2015, European Lisp Conference '15


My new Jazz CD entitled "Roots and Leaves" is out!
Check it out:

Didier Verna <didier <at>>
ELSAA, President

Chicken-users mailing list
Chicken-users <at>
Tim van der Linden | 24 Jan 07:27 2015

Homepage design proposal - part 2

Hi All

Forgive me for skipping out of the running Homepage design proposal thread with top posting a new message. I
simply want to distill the great comments I got so far (thanks everyone!) on the first rough draft of the
homepage, so we can keep all the information together.

Let me run over the major points.


1. Images of real life chickens

The image I used on the homepage is a random image of chickens (not from Alaric) but carries a creative
commons license which allows free commercial use. The only thing we need to do is to add some sort of credit
to the photographer on the site.

Yet, Alaric, if you are listening and able to shoot some pics of your chicks...?

Yaroslav pointed out that the picture is currently a bit attention demanding, so I will see to tone it down a
bit. Maybe a different (brighter?) picture might seek less attention.

2. Still much text

As some have correctly pointed out, there is still a load of text (amount did not change that much over the
original), yet I intentionally did not touch the actual content. I am in no (technical knowledgeable)
position to edit the text.

I am fully aware that the text, especially the bullet points and feature listings, is much too long. They are
not "punchy" enough, not (dare I say it) commercial enough. A powerful bullet I like (short, to the point)
is: "Very supportive community, with a wide intellectual background.". I think this should be an example
for the other points.

So I reach out to you guys to help reshape these texts into a more to-the-point and accurate form. Mario
already provided some good alternative texts.

3. Colors

Almost everyone pointed out that some texts are not very readable with the current color scheme. I agree
(sorry for that ;) ). Also, Mario, yes I tried to incorporate the colors of the logo into the site, simply
because I like both the logo and its colors. It just feels right. It's playful and yet professional.

I feel a bit uncomfortable with picking a different color scheme as I think this would fight the logo very
quickly. On the other main focus is not I could just be talking gibberish here. you also mean we could change the actual colors of the logo, Mario?

If there are any color-aware folks in the room to comment on this....please do!


1. Interactive shell

As I understand it this would be not as feasible as I first thought, and, in hindsight, for good reason
(Thanks for pointing out why everyone). So, let us assume we do not get an interactive shell...yet I do find
it important that we show some code examples right on the front page.

Maybe three or four (or more!) samples depicting typical features of CHICKEN. These samples could be
easily "flipped" through with a few navigation buttons, they would carry a clear title per sample and a few
comments inline of what this code is about. Programmers love to see beautiful code...right?

2. Map of CHICKEN around the world

Hmmm...Peter made a good remark about privacy...and apparently this has been attempted before and has
already seen its exit. No map then.

3. Latest changes

Mario was not very favorable about the "Latest changes" section on the homepage...yet this is something I
see with a lot of languages and end-user tools. To me, it shows that there is progress going on. If I see no
version numbers/release dates I tend to get suspicious. If there is a clear timeline that shows that the
project is alive, however, it boosts my confidence in giving it a try. Or does that sound too naive?

4. Eggs list

Peter mentioned a link to the eggs list...actually I did not think about that at all, but it is indeed very
important to show some major eggs right on the front page. Eggs are what can make the language more
interesting to more higher level users and to show that a lot of tooling is already available. CHICKEN is
not only a compiler for/dialect of Scheme, but an impressive tool belt as well.


1. Structure

Matt wrote a very insightful reply towards how we should approach this beast. First, Matt, don't feel
hopelessly outclassed...I wrote but two eggs which I consider to be the basics of the basics. I shamefully
haven't touched CHICKEN and wasn't present in the community for the whole 2014...

Next, the reference to the Open Dylan is very nice. They have the exact features I was looking for. Yet their
design is, regretfully, a simple Bootstrap theme.

Finally, I also agree that only reforming the homepage, only to fall back to the current design for the
remainder of the site, only adds insult to injury. I too think it is therefor important to try and get a
picture of how the site is currently structured (sitemap?) and see how we can (and if we need to)
restructure the information to be better accessible and digestible.

Moving the Download button more in sight and presenting more apparent top links to relevant parts of the
site was my feeble attempt at restructuring. Yet, again, I agree this has to be done in a more structural
way. Any ideas anyone?

2. Gathering it all

Do you all think the mailing list is the perfect spot to discuss and progress with a possible new site
overhaul? As many different topics may need to be discussed, ideas presented and alterations
may be difficult to keep everything organized with mail. Ideas?

Tim van der Linden | 23 Jan 08:24 2015

Homepage design proposal

Hi all!

In the recent light of visual changes to the wiki, I have picked up an old(er) idea to have my go at a redesign of
the homepage (landing page, front page, the-first-page, etc...).

I, for one, find our CHICKEN site charming. Yet many new folks see the homepage more as the scrolling end
credits to CHICKEN The Movie then an actual eye-catching, easy to pick-up page. Too much text, no
pleasing, eye stroking candy.

Do not understanding me wrong, I do not wish to push a Candy Crush, plastic, all bells & whistles design, yet I
hope most of you agree that something needs to be done to attract new users (rather then to scare them away)
and to try to get to information faster.

The first thing I did on this journey was to take a peek at our fellow language pages, and see what they do to
reel them in. A quick glance at other languages (like Python, Racket (!), Ruby, Erlang, ...) show the
following common features:

- See common, easy-to-understand code samples depicting typical language features
- Clear changelog timeline
- Visual weight (visual importance, not one blob of text)
- Big Download/Get Started now call-to-action

Things less commonly see, but just plain beautiful:

- The ability to run code in an interactive shell
- A map of CHICKEN across the world
- A list of real-life CHICKEN projects
- An awesome photo of chickens

For the design I thought it would be smart to give it a minimalistic approach...CHICKEN is a tiny language
after all, and we want to tout it's simplicity, right?

Before putting in to much design work, I thought I would throw it out early in the process.
So I have gone ahead and create a (very rough) design for the homepage only, using flat elements and
hopefully a better approach then currently is the case.
Mind that this is only a mock-up (nothing works!) and not all information is accurate. But it should give you
a fairly good idea of the direction I wish to take...

Also...if there are any *real* designers in the house...any help is welcomed ;)

Find it here:

All input is greatly appreciated and I hope this will spark a few ideas here and there...