Matt Welland | 10 Feb 14:06 2016

How to build from git? Errors on Ubuntu 15.10

I have chicken installed, is that recent enough for bootstrapping? I'm interested in trying feathers and the new profiling. Are there any plans to back port those features to the 4 series?

Here are the first few errors:

gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -c -Os -fomit-frame-pointer  -DC_BUILDING_LIBCHICKEN library.c -o library-static.o -I. -I./
[01m[Klibrary.c:[m[K In function ‘[01m[Ktrf_18674[m[K’:
[01m[Klibrary.c:4876:11:[m[K [01;35m[Kwarning: [m[Kimplicit declaration of function ‘[01m[KC_pick[m[K’ [-Wimplicit-function-declaration]
 C_word t2=C_pick(0);
[01;32m[K           ^[m[K
[01m[Klibrary.c:4879:1:[m[K [01;35m[Kwarning: [m[Kimplicit declaration of function ‘[01m[KC_adjust_stack[m[K’ [-Wimplicit-function-declaration]
[01;32m[K ^[m[K
[01m[Klibrary.c:[m[K At top level:
[01m[Klibrary.c:6665:25:[m[K [01;31m[Kerror: [m[Kunknown type name ‘[01m[KC_proc7[m[K’
 static void C_fcall tr7(C_proc7 k) C_regparm C_noret;
[01;32m[K                         ^[m[K
[01m[Klibrary.c:6666:35:[m[K [01;31m[Kerror: [m[Kunknown type name ‘[01m[KC_proc7[m[K’
 C_regparm static void C_fcall tr7(C_proc7 k){
[01;32m[K                                   ^[m[K
[01m[Klibrary.c:6678:25:[m[K [01;31m[Kerror: [m[Kunknown type name ‘[01m[KC_proc6[m[K’
 static void C_fcall tr6(C_proc6 k) C_regparm C_noret;
[01;32m[K                         ^[m[K
[01m[Klibrary.c:6679:35:[m[K [01;31m[Kerror: [m[Kunknown type name ‘[01m[KC_proc6[m[K’
 C_regparm static void C_fcall tr6(C_proc6 k){
[01;32m[K                                   ^[m[K
[01m[Klibrary.c:6690:25:[m[K [01;31m[Kerror: [m[Kunknown type name ‘[01m[KC_proc5[m[K’
Chicken-users mailing list
Chicken-users <at>
Lindsey Kuper | 9 Feb 07:09 2016

ICFP 2016 Second Call for Papers

                              ICFP 2016
The 21st ACM SIGPLAN International Conference on Functional Programming
                        Second Call for Papers

Important dates

Submissions due:    Wednesday, March 16 2016, 15:00 (UTC)
                    (now open)
Author response:    Monday, 2 May, 2016, 15:00 (UTC) -
                    Thursday, 5 May, 2016, 15:00 (UTC)
Notification:       Friday, 20 May, 2016
Final copy due:     TBA
Early registration: TBA
Conference:         Monday, 19 September -
                    Wednesday, 21 September, 2016
                    (note updated conference dates)


ICFP 2016 seeks original papers on the art and science of functional
programming. Submissions are invited on all topics from principles to
practice, from foundations to features, and from abstraction to
application. The scope includes all languages that encourage
functional programming, including both purely applicative and
imperative languages, as well as languages with objects, concurrency,
or parallelism. Topics of interest include (but are not limited to):

- Language Design: concurrency, parallelism, and distribution;
  modules; components and composition; metaprogramming; type systems;
  interoperability; domain-specific languages; and relations to
  imperative, object-oriented, or logic programming.

- Implementation: abstract machines; virtual machines; interpretation;
  compilation; compile-time and run-time optimization; garbage
  collection and memory management; multi-threading; exploiting
  parallel hardware; interfaces to foreign functions, services,
  components, or low-level machine resources.

- Software-Development Techniques: algorithms and data structures;
  design patterns; specification; verification; validation; proof
  assistants; debugging; testing; tracing; profiling.

- Foundations: formal semantics; lambda calculus; rewriting; type
  theory; monads; continuations; control; state; effects; program
  verification; dependent types.

- Analysis and Transformation: control-flow; data-flow; abstract
  interpretation; partial evaluation; program calculation.

- Applications: symbolic computing; formal-methods tools; artificial
  intelligence; systems programming; distributed-systems and web
  programming; hardware design; databases; XML processing; scientific
  and numerical computing; graphical user interfaces; multimedia and
  3D graphics programming; scripting; system administration; security.

- Education: teaching introductory programming; parallel programming;
  mathematical proof; algebra.

- Functional Pearls: elegant, instructive, and fun essays on
  functional programming.

- Experience Reports: short papers that provide evidence that
  functional programming really works or describe obstacles that have
  kept it from working.

If you are concerned about the appropriateness of some topic, do not
hesitate to contact the program chair.

Abbreviated instructions for authors

- By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at
  most 12 pages (6 pages for an Experience Report), in standard
  SIGPLAN conference format, including figures but ***excluding

The deadlines will be strictly enforced and papers exceeding the page
limits will be summarily rejected.

***ICFP 2016 will employ a lightweight double-blind reviewing
process.*** To facilitate this, submitted papers must adhere to two

 1. ***author names and institutions must be omitted***, and

 2. ***references to authors' own related work should be in the third
    person*** (e.g., not "We build on our previous work ..." but
    rather "We build on the work of ...").

The purpose of this process is to help the PC and external reviewers
come to an initial judgement about the paper without bias, not to make
it impossible for them to discover the authors if they were to
try. Nothing should be done in the name of anonymity that weakens the
submission or makes the job of reviewing the paper more difficult
(e.g., important background references should not be omitted or
anonymized). In addition, authors should feel free to disseminate
their ideas or draft versions of their paper as they normally
would. For instance, authors may post drafts of their papers on the
web or give talks on their research ideas. We have put together a
document answering frequently asked questions that should address many
common concerns:
(last updated February 8, 2016).

- Authors have the option to attach supplementary material to a
  submission, on the understanding that reviewers may choose not to
  look at it. The material should be uploaded at submission time, as a
  single pdf or a tarball, not via a URL. This supplementary material
  may or may not be anonymized; if not anonymized, it will only be
  revealed to reviewers after they have submitted their review of your
  paper and learned your identity.

- Each submission must adhere to SIGPLAN's republication policy, as
  explained on the web at:

- Authors of resubmitted (but previously rejected) papers have the
  option to attach an annotated copy of the reviews of their previous
  submission(s), explaining how they have addressed these previous
  reviews in the present submission. If a reviewer identifies
  him/herself as a reviewer of this previous submission and wishes to
  see how his/her comments have been addressed, the program chair will
  communicate to this reviewer the annotated copy of his/her previous
  review. Otherwise, no reviewer will read the annotated copies of the
  previous reviews.

Overall, a submission will be evaluated according to its relevance,
correctness, significance, originality, and clarity. It should explain
its contributions in both general and technical terms, clearly
identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. The technical
content should be accessible to a broad audience. Functional Pearls
and Experience Reports are separate categories of papers that need not
report original research results and must be marked as such at the
time of submission. Detailed guidelines on both categories are given

Presentations will be videotaped and released online if the presenter
consents. The proceedings will be freely available for download from
the ACM Digital Library from at least one week before the start of the
conference until two weeks after the conference.

Formatting: Submissions must be in PDF format printable in black and
white on US Letter sized paper and interpretable by
Ghostscript. Papers must adhere to the standard SIGPLAN conference
format: two columns, nine-point font on a ten-point baseline, with
columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter
of 2pc (0.33in). A suitable document template for LaTeX is available

Submission: Submissions will be accepted at

Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.

Author response: Authors will have a 72-hour period, starting at 15:00
UTC on Monday, 2 May, 2016, to read reviews and respond to them.

ACM Author-Izer is a unique service that enables ACM authors to
generate and post links on either their home page or institutional
repository for visitors to download the definitive version of their
articles from the ACM Digital Library at no charge. Downloads through
Author-Izer links are captured in official ACM statistics, improving
the accuracy of usage and impact measurements. Consistently linking
the definitive version of ACM article should reduce user confusion
over article versioning. After your article has been published and
assigned to your ACM Author Profile page, please visit to learn how
to create your links for free downloads from the ACM DL.

AUTHORS TAKE NOTE: The official publication date is the date the
proceedings are made available in the ACM Digital Library. This date
may be up to two weeks prior to the first day of your conference. The
official publication date affects the deadline for any patent filings
related to published work.

Special categories of papers

In addition to research papers, ICFP solicits two kinds of papers that
do not require original research contributions: Functional Pearls,
which are full papers, and Experience Reports, which are limited to
six pages. Authors submitting such papers may wish to consider the
following advice.

Functional Pearls

A Functional Pearl is an elegant essay about something related to
functional programming. Examples include, but are not limited to:

- a new and thought-provoking way of looking at an old idea
- an instructive example of program calculation or proof
- a nifty presentation of an old or new data structure
- an interesting application of functional programming techniques
- a novel use or exposition of functional programming in the classroom

While pearls often demonstrate an idea through the development of a
short program, there is no requirement or expectation that they do
so. Thus, they encompass the notions of theoretical and educational

Functional Pearls are valued as highly and judged as rigorously as
ordinary papers, but using somewhat different criteria. In particular,
a pearl is not required to report original research, but, it should be
concise, instructive, and entertaining. Your pearl is likely to be
rejected if your readers get bored, if the material gets too
complicated, if too much specialized knowledge is needed, or if the
writing is inelegant. The key to writing a good pearl is polishing.

A submission you wish to have treated as a pearl must be marked as
such on the submission web page, and should contain the words
``Functional Pearl'' somewhere in its title or subtitle. These steps
will alert reviewers to use the appropriate evaluation
criteria. Pearls will be combined with ordinary papers, however, for
the purpose of computing the conference's acceptance rate.

Experience Reports

The purpose of an Experience Report is to help create a body of
published, refereed, citable evidence that functional programming
really works ? or to describe what obstacles prevent it from working.

Possible topics for an Experience Report include, but are not limited

- insights gained from real-world projects using functional

- comparison of functional programming with conventional programming
  in the context of an industrial project or a university curriculum

- project-management, business, or legal issues encountered when using
  functional programming in a real-world project

- curricular issues encountered when using functional programming in

- real-world constraints that created special challenges for an
  implementation of a functional language or for functional
  programming in general

An Experience Report is distinguished from a normal ICFP paper by its
title, by its length, and by the criteria used to evaluate it.

- Both in the proceedings and in any citations, the title of each
  accepted Experience Report must begin with the words ``Experience
  Report'' followed by a colon. The acceptance rate for Experience
  Reports will be computed and reported separately from the rate for
  ordinary papers.

- An Experience Report is at most six pages long. Each accepted
  Experience Report will be presented at the conference, but depending
  on the number of Experience Reports and regular papers accepted,
  authors of Experience reports may be asked to give shorter talks.

- Because the purpose of Experience Reports is to enable our community
  to accumulate a body of evidence about the efficacy of functional
  programming, an acceptable Experience Report need not add to the
  body of knowledge of the functional-programming community by
  presenting novel results or conclusions. It is sufficient if the
  Report states a clear thesis and provides supporting evidence. The
  thesis must be relevant to ICFP, but it need not be novel.

The program committee will accept or reject Experience Reports based
on whether they judge the evidence to be convincing. Anecdotal
evidence will be acceptable provided it is well argued and the author
explains what efforts were made to gather as much evidence as
possible. Typically, more convincing evidence is obtained from papers
which show how functional programming was used than from papers which
only say that functional programming was used. The most convincing
evidence often includes comparisons of situations before and after the
introduction or discontinuation of functional programming. Evidence
drawn from a single person's experience may be sufficient, but more
weight will be given to evidence drawn from the experience of groups
of people.

An Experience Report should be short and to the point: make a claim
about how well functional programming worked on your project and why,
and produce evidence to substantiate your claim. If functional
programming worked for you in the same ways it has worked for others,
you need only to summarize the results?the main part of your paper
should discuss how well it worked and in what context. Most readers
will not want to know all the details of your project and its
implementation, but please characterize your project and its context
well enough so that readers can judge to what degree your experience
is relevant to their own projects. Be especially careful to highlight
any unusual aspects of your project. Also keep in mind that specifics
about your project are more valuable than generalities about
functional programming; for example, it is more valuable to say that
your team delivered its software a month ahead of schedule than it is
to say that functional programming made your team more productive.

If your paper not only describes experience but also presents new
technical results, or if your experience refutes cherished beliefs of
the functional-programming community, you may be better off submitting
it as a full paper, which will be judged by the usual criteria of
novelty, originality, and relevance. If you are unsure in which
category to submit, the program chair will be happy to help you


General Co-Chairs:

Jacques Garrigue (Nagoya University)
Gabriele Keller (University of New South Wales)

Program Chair:

Eijiro Sumii (Tohoku University)

Program Committee:

Koen Claessen (Chalmers University of Technology)
Joshua Dunfield (University of British Columbia, Canada)
Matthew Fluet (Rochester Institute of Technology)
Nate Foster (Cornell University)
Dan Grossman (University of Washington, USA)
Jurriaan Hage (Utrecht University)
Roman Leshchinskiy (Standard Chartered Bank)
Keisuke Nakano (The University of Electro-Communications)
Aleksandar Nanevski (IMDEA Software Institute)
Scott Owens (University of Kent)
Sungwoo Park (Pohang University of Science and Technology)
Amr Sabry (Indiana University)
Tom Schrijvers (KU Leuven)
Olin Shivers (Northeastern University)
Walid Taha (Halmstad University)
Dimitrios Vytiniotis (Microsoft Research, Cambridge)
David Walker (Princeton University)
Nobuko Yoshida (Imperial College London, UK)

External Review Committee:

John Croisant | 7 Feb 23:53 2016

[ANN] ck-macros egg

I have created a new egg, ck-macros. If you have ever written a 
syntax-rules macro and wished that you could expand its arguments ahead 
of time, this egg may be of interest to you.

The egg includes Oleg Kiselyov's "ck" macro, plus about 80 small 
composable CK-macros written by me, most of them analogous to functions 
from R5RS, SRFI-1, and SRFI-43.

For those not aware (as I wasn't until a week ago), CK-macros are a 
style of macros which use the CK abstract machine (implemented as the 
core "ck" macro) to recursively expand the CK-macro's arguments, before 
the CK-macro itself is expanded. This gives you more control over the 
macro expansion process, allowing you to easily combine simple reusable 
macros to form more complex macros. This makes it easy to write portable 
macros that previously were only feasible using non-portable features 
like CHICKEN's low level macros.

Writing CK-macros is remarkably similar to writing Scheme functions, 
except they are computed at macro-expansion time, and you have the 
benefit of syntax-rules pattern matching and destructuring. You can even 
implement "higher-ordered macros" which take a macro as an argument. For 
example the "c-map" macro applies a macro to every item in a list, at 
macro-expansion time.

Another nice thing about CK-macros is that all of the macros currently 
in the egg are implemented using only standard R5RS features, namely 
syntax-rules and let-syntax. This means they are trivially portable to 
any R5RS implementation, unlike CHICKEN's low level macros.

For more information about CK-macros, including a tutorial about how to 
write them (it's not hard, but there are a few things you must be 
careful of), see the egg wiki page:

In the future, I plan to add non-portable CK-macros (based on CHICKEN's 
low level macros) for string manipulation and decimal math.

Many thanks to Oleg Kiselyov for creating the "ck" macro, without which 
this egg would not be possible. Thanks also to "please_help", who 
mentioned CK-macros on IRC, which led me to learn about them.

- John Croisant
Peter Sommerfeld | 2 Feb 12:11 2016

Error compiling chicken cygwin x86_64

I've compiled chicken without any problems on cygwin x86 on a 32 bit 
notebook. The same fail swith cygwin 86_64:
$ make PLATFORM=cygwin PREFIX=~/local VARDIR=~/
gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H 
-DC_ENABLE_PTABLES -c apply-hack.x86.S -o apply-hack.x86.o
apply-hack.x86.S: Assembler messages:
apply-hack.x86.S:35: Error: operand type mismatch for `call'
rules.make:184: die Regel für Ziel „apply-hack.x86.o“ scheiterte
make: *** [apply-hack.x86.o] Fehler 1
Adding ARCH=x86_64:
$ make PLATFORM=cygwin PREFIX=~/local VARDIR=~/ ARCH=x86_64
make: *** Keine Regel vorhanden, um das Ziel „apply-hack.x86_64.S“,
benötigt von „apply-hack.x86_64.o“, zu erstellen.  Schluss.

Any help appreciated


Chicken-users mailing list
Chicken-users <at>
Peter Achten | 2 Feb 10:30 2016

[TFP 2016] 1st call for papers

                     C A L L   F O R   P A P E R S

                     ======== TFP 2016 ===========

           17th Symposium on Trends in Functional Programming
                            June 8-10, 2016
                  University of Maryland, College Park
                          Near Washington, DC

The symposium on Trends in Functional Programming (TFP) is an
international forum for researchers with interests in all aspects of
functional programming, taking a broad view of current and future
trends in the area. It aspires to be a lively environment for
presenting the latest research results, and other contributions (see
below). Authors of draft papers will be invited to submit revised
papers based on the feedback receive at the symposium.  A
post-symposium refereeing process will then select a subset of these
articles for formal publication.

TFP 2016 will be the main event of a pair of functional programming
events. TFP 2016 will be accompanied by the International Workshop on
Trends in Functional Programming in Education (TFPIE), which will take
place on June 7nd.

The TFP symposium is the heir of the successful series of Scottish
Functional Programming Workshops. Previous TFP symposia were held in
    * Edinburgh (Scotland) in 2003;
    * Munich (Germany) in 2004;
    * Tallinn (Estonia) in 2005;
    * Nottingham (UK) in 2006;
    * New York (USA) in 2007;
    * Nijmegen (The Netherlands) in 2008;
    * Komarno (Slovakia) in 2009;
    * Oklahoma (USA) in 2010;
    * Madrid (Spain) in 2011;
    * St. Andrews (UK) in 2012;
    * Provo (Utah, USA) in 2013;
    * Soesterberg (The Netherlands) in 2014;
    * and Inria Sophia-Antipolis (France) in 2015.
For further general information about TFP please see the TFP homepage.

== SCOPE ==

The symposium recognizes that new trends may arise through various
routes.  As part of the Symposium's focus on trends we therefore
identify the following five article categories. High-quality articles
are solicited in any of these categories:

Research Articles: leading-edge, previously unpublished research work
Position Articles: on what new trends should or should not be
Project Articles: descriptions of recently started new projects
Evaluation Articles: what lessons can be drawn from a finished project
Overview Articles: summarizing work with respect to a trendy subject

Articles must be original and not simultaneously submitted for
publication to any other forum. They may consider any aspect of
functional programming: theoretical, implementation-oriented, or
experience-oriented.  Applications of functional programming
techniques to other languages are also within the scope of the

Topics suitable for the symposium include, but are not limited to:

      Functional programming and multicore/manycore computing
      Functional programming in the cloud
      High performance functional computing
      Extra-functional (behavioural) properties of functional programs
      Dependently typed functional programming
      Validation and verification of functional programs
      Debugging and profiling for functional languages
      Functional programming in different application areas:
        security, mobility, telecommunications applications, embedded
        systems, global computing, grids, etc.
      Interoperability with imperative programming languages
      Novel memory management techniques
      Program analysis and transformation techniques
      Empirical performance studies
      Abstract/virtual machines and compilers for functional languages
      (Embedded) domain specific languages
      New implementation strategies
      Any new emerging trend in the functional programming area

If you are in doubt on whether your article is within the scope of
TFP, please contact the TFP 2016 program chair, David Van Horn.


To reward excellent contributions, TFP awards a prize for the best paper
accepted for the formal proceedings.

TFP traditionally pays special attention to research students,
acknowledging that students are almost by definition part of new
subject trends. A student paper is one for which the authors state
that the paper is mainly the work of students, the students are listed
as first authors, and a student would present the paper. A prize for
the best student paper is awarded each year.

In both cases, it is the PC of TFP that awards the prize. In case the
best paper happens to be a student paper, that paper will then receive
both prizes.


TFP is financially supported by CyberPoint, Galois, Trail of Bits, and
the University of Maryland Computer Science Department.


Acceptance of articles for presentation at the symposium is based on a
lightweight peer review process of extended abstracts (4 to 10 pages
in length) or full papers (20 pages). The submission must clearly
indicate which category it belongs to: research, position, project,
evaluation, or overview paper. It should also indicate which authors
are research students, and whether the main author(s) are students.  A
draft paper for which ALL authors are students will receive additional
feedback by one of the PC members shortly after the symposium has
taken place.

We use EasyChair for the refereeing process. Papers must be submitted at:

Papers must be written in English, and written using the LNCS
style. For more information about formatting please consult the
Springer LNCS web site:


Submission of draft papers:     April 8, 2016
Notification:                   April 15, 2016
Registration:                   May 13, 2016
TFP Symposium:                  June 8-10, 2016
Student papers feedback:        June 14, 2016
Submission for formal review:   July 14, 2016
Notification of acceptance:     September 14, 2016
Camera ready paper:             October 14, 2016


Amal Ahmed              Northeastern University (US)
Nada Amin               École Polytechnique Fédérale de Lausanne (CH)
Kenichi Asai            Ochanomizu University (JP)
Małgorzata Biernacka    University of Wroclaw (PL)
Laura Castro            University of A Coruña (ES)
Ravi Chugh              University of Chicago (US)
Silvia Ghilezan         University of Novi Sad (SR)
Clemens Grelck          University of Amsterdam (NL)
John Hughes             Chalmers University of Technology (SE)
Suresh Jagannathan      Purdue University (US)
Pieter Koopman          Radboud University Nijmegen (NL)
Geoffrey Mainland       Drexel University (US)
Chris Martens           University of California, Santa Cruz (US)
Jay McCarthy            University of Massachusetts, Lowell (US)
Heather Miller          École Polytechnique Fédérale de Lausanne (CH)
Manuel Serrano          INRIA, Sophia-Antipolis (FR)
Scott Smith             Johns Hopkins University (US)
Éric Tanter             University of Chile (CL)
David Van Horn (Chair)  University of Maryland (US)
Niki Vazou              University of California, San Diego (US)

Chicken-users mailing list
Chicken-users <at>
Peter Sommerfeld | 28 Jan 13:31 2016

Installing on Suse Tumbleweed

Hi everyone!

I'm new to scheme/chicken and this list.

I've tried to install 4.10.1 on SUSE Tumbleweed (the rolling release of
# make PLATFORM=linux PREFIX=/usr/local

Compiling seems to succeed. At least ./csi and other programs are
starting. But all files remain in the build directory and are not passed
to /usr/local.

Did I do something wrong or do I have to do additional steps?
May be I can pass the file to the appropriate directories by hand but I
need to know the correct locations in that case.

tia, Peter
Kooda | 28 Jan 01:00 2016

CHICKEN game making-of blog post

Whow, it’s been a while since I released my tiny CHICKEN game.

I finally took the time to finish the postmortem blog post, I hope
you’ll find it interesting. :)

Here it is:

Chicken-users mailing list
Chicken-users <at>
Jörg F. Wittenberger | 26 Jan 17:59 2016

problem compiling master


I just recompiled "master" on the raspberrypi.  Took forever as
expected.  But does not work.

chicken-install complains about setup-download not avail.

How would I figure out what went wrong?

Thanks so much


Chicken-users mailing list
Chicken-users <at>
Claude Marinier | 24 Jan 21:25 2016

big prime number


Spurred by the recent excitement about a new largest prime number (1), I wanted to see how long it would take to just write the number. So I wrote a simple program and added timing to produce the following.

claude <at> hibou:~/Programming/scheme$ ./big-prime 
time to compute big prime : 1.074 seconds
time to convert it to a string : 778.617 seconds
time to write it to a file : 710.805 seconds

I compiled the program on Debian 8 64-bit with Chicken 8.10.0 and Numbers 4.3 and "-O3". The CPU is an old dual-core Pentium E2200 <at> 2.20GHz.

    Version 4.10.0 (rev b259631)
    linux-unix-clang-x86-64 [ 64bit manyargs dload ptables ]
    compiled 2015-08-04 on (Linux)

Here is the program (minus timing code).

(use numbers)
(define big-prime (- (expt 2 74207281) 1))
(define big-print-str (number->string big-prime))
(define outport (open-output-file "big-prime.txt"))
(display big-prime outport) (newline outport)
(close-output-port outport)

A colleague claims a Haskell program calculating the prime and writing it to a file ran in 17 seconds. That's 89 times faster.

Am I missing something? Is 4.10.1 faster?

Back in June, there was talk of Numbers performance. Where do we stand now? Should I try the code in GIT?

Thank you.

P.S. He may have written the number in binary. That would explain a lot. Still, am I missing something? Hum ... I should probably use cpu-time instead of current-milliseconds but (oddly) I do not know have to deal with the two returned values. :-(

Claude Marinier
Chicken-users mailing list
Chicken-users <at>
Hefferon, James S. | 23 Jan 12:29 2016

Scraping the REPL?

I am writing a document that will include figures showing
interactions with the Chicken interpreter.  In past documents of
this kind, by-hand cutting and pasting has led me to have such
illustrations be inaccurate.  So I would like those to be
produced as part of the process of compiling the document (I am
writing in LaTeX).

Basically, I'd like to feed lines to the csi and then scrape the
entire REPL off screen, so I can collect it and include it in
the doc.

In the past I have done some scraping of this kind with a Python
script using an Expect module.  But it is a clunky process, with
problems of its own.

I see from the "Confirmed deviations" page that transcripts are
not implemented.  Before I launch what is really a kludge, can I
ask if I am missing some other option?  None of the eggs 
seemed to me to do this but maybe I missed some obvious point.
Something that drops the entire interaction to a file would be ideal.

Thank you for any help.
Jörg F. Wittenberger | 22 Jan 19:42 2016

on ticket 1231

Hi all,

there is a problem I have with ticket 1231.

In short: I'd love to see the patch applied.  (Or learn about issues it

Long story: The pigeon-hole egg I recently published looks internally
somewhat like the "rewrite it using condition-variables" the source of
the mailbox egg suggests.  (Ignoring here that it allows for flow
control to avoid a fast sender bringing down the whole system by blowing
up memory consumption.)

Right now the development version (according to the measurements I've
been able to create - you know "benchmarks", they always lie) is roughly
on par on performance with the mailbox egg.  That is: WHEN using
`(mutex-lock! #f #f)`.

I hesitate to release this code, because I don't want to cause trouble.
 The released version works around the srfi-18 incompatibility at the
cost of ~20% performance loss.  Too bad to be ignored.



Chicken-users mailing list
Chicken-users <at>