thread-sleep! on bigloo3.6a FreeBSD 8.2-RELEASE

Hello,

The documentation says the following about thread-sleep! for posix threads:

     thread-sleep! timeout ; SRFI-18 function

    The  current thread  sleeps for  a  certain period.  It is  suspended and  the
    scheduler is free to  select a new thread to be resumed.  If there is only one
    thread started in the scheduler, the  same thread will be resumed. The time of
    timeout is used to determine the time the thread must sleep.

    Here are the possible types for timeout.

        * date: the thread sleeps at least until the date timeout.
        * real: the thread sleeps at least timeout seconds.
        * fixum, elong, llong: the thread sleeps at least timeout milli-seconds.

I have attached a small test file sleep-test.scm [1] that compiles fine with 

    bigloo3.6a -q -afile .afile -O5 -unsafe sleep-test.scm -o sleep-test

When run with "./sleep-test 1000" the program produces the following output:

    date1: Fri Feb  3 10:33:21 2012
    date2: Fri Feb  3 10:33:22 2012
    seconds slept: 1

The reason why the program runs fine is the function

    (define (sleep! ms)

silent exit when writing to lost connection

Assume that in the following situation, the server closes the SSL 
connection during the sleep of 30 seconds. 

(define (main main)
  (let* ((s (make-ssl-client-socket "example.com" 9000 protocol: 'sslv3))
         (from-srv (socket-input s))
         (to-srv (socket-output s)))
    (print "sleeping")
    (sleep 30000000)
    (print "printing")
    (fprint to-srv (list->string (map! (lambda (x) #\a) (make-list 100000))))
    (print "done")))

If the string written to 'to-srv' is long enough (100000 
characters is enough), then the program will simply exit with 
return code 141 without any error message (without printing 
"done").

I think, instead an exception should be raised. Otherwise, it's 
very hard to track down.

This happens with 3.7a and the latest alpha of 3.8a (27 Jan).

SRFI-18 compliance: mutex-lock!, mutex-unlock!

Hello,

the documentation [1] for mutexes with  3.8a (and 3.6a, too) describes the two
SRFI-18 procedures with the following signatures:

    (mutex-lock! mutex [timeout [thread]])
    (mutex-unlock! mutex)

The implementation in runtime/Llib/thread.scm has these signatures:

    (inline mutex-lock!::obj ::mutex #!optional (timeout::long 0))
    (inline mutex-unlock!::obj ::mutex)

The SRFI-18 document [2] instead describes the procedures having the following
signatures:

    (mutex-lock! mutex [timeout [thread]])
    (mutex-unlock! mutex [condition-variable [timeout]])

Additionally,  the signature for THREAD-JOIN! differs too:

    (thread-join! THREAD [TIMEOUT]) ; bigloo implementation and documentation
    (thread-join! thread [timeout [timeout-val]]) ; SRFI-18 documentation

Just wanted to let you know. Sorry for the noise.

Regards,
Johannes

[1]: http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-18.html#Mutexes

segfault with filter

The following program segfaults on 3.7a:

(define (main args) 
  (filter 
    (lambda (x) (< x 512))
    (map (lambda (x) (random 1024)) (make-list 220000))))

I cannot see why. It runs fine on shorter lists, below 200000.

Attached is also the C code, in case it helps.

Can anything be done about it?

Is there a public source code repository (Mercurial, Git, ...), 
from where I could try a newer version?

Thank you!

/*===========================================================================*/
/*   (segfault-1.scm)                                                        */
/*   Bigloo (3.7a)                                                           */
/*   Inria -- Sophia Antipolis (c)       Tue Sep 27 08:33:22 CEST 2011       */
/*===========================================================================*/
/* COMPILATION: (bigloo -g -cg segfault-1.scm)*/
/* GC selection */
#define THE_GC BOEHM_GC

/* debug mode */
#define BIGLOO_DEBUG 1

Installer for MinGW build of bigloo3.8a-alpha27Jan12

Hello,

For those interested, I have uploaded an installer for the MinGW build of bigloo3.8a-alpah27Jan12 to http://jwd.sandjsite.net/projects/mingw-bigloo.

Best Regards,
Joseph Donaldson

Problem compiling bigloo3.7a-2: Cannot open heap file "alsa.heap"

Hi all,

just tried to build bigloo3.7a-2, the latest release of 3.7 I've found 
at ftp://ftp-sop.inria.fr/indes/fp/Bigloo/:

./configure
make

Got the following problem:

/home/wowa/build/bigloo3.7a-2/bin/bigloo -O3 -fcfa-arithmetic -q 
-lib-dir /home/wowa/build/bigloo3.7a-2/lib/3.7a -I Llib -lib-dir 
/home/wowa/build/bigloo3.7a-2/lib/3.7a -unsafe -safee -srfi flac -copt 
"" -copt -fPIC -copt "-IClib" Llib/flac_alsadec.scm -o 
objs/flac_alsadec.o -c
*** ERROR:restore-additional-heap:
Cannot open heap file "alsa.heap" -- 
(/home/wowa/build/bigloo3.7a-2/lib/3.7a . /usr/local/lib/bigloo/3.7a)
make[5]: *** [objs/flac_alsadec.o] Ошибка 1

Regards,
Vladimir

TFP12

customization o warning/location

Hi all.

Is there an easy way to customize bigloo's warning/location
which the compiler seems to use for displaying warnings?
For example, to change the output format to some sexp format or xml format.

This would allow also for easily removing false warnings from bigloo's
output during compilation so that one can see the real ones 
One such use case:
I have several applications were bigloo's mostly clever type analysis
issues thousands of false warnings for one frequently used function so
that it's really hard to see the correct warning(s).

If no such customization mechanism exists, a compiler option like
-raw-warnings will be a minimal start; for the example in the manual
(p. 168), this should output something like this:

(bigloo-warning "foo.scm" 154 "foo:" "argument not a pair -- " 4)

Greetings
Sven

ICFP 2012 Call for papers

=====================================================================

 ICFP 2012: International Conference on Functional Programming

 Copenhagen, Denmark, September 9 - 15, 2012

 http://www.icfpconference.org/icfp2012

=====================================================================

Important Dates
~~~~~~~~~~~~~~~

 Submissions due:  Monday Mar 12, 2012 14:00 UTC
 Author response:  Monday May 07, 2012 14:00 UTC - May 9 14:00 UTC
    Notification:  Monday May 28, 2012
  Final copy due:  Monday Jul 02, 2012

Scope
~~~~~

ICFP 2012 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 and distribution; modules; components
 and composition; metaprogramming; interoperability; type systems;
 relations to imperative, object-oriented, or logic programming

* Implementation: abstract machines; virtual machines; interpretation;
 compilation; compile-time and run-time optimization; 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 and Domain-Specific Languages: 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 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 March 12 2012, 14:00 UTC, submit a full paper of at most 12 pages
 (6 pages for an Experience Report), including bibliography and
 figures.

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

* Authors have the option to attach supplementary material to a submission,
 on the understanding that reviewers may choose not to look at it.

* Each submission must adhere to SIGPLAN's republication policy, as
 explained on the web at
 http://www.acm.org/sigplan/republicationpolicy.htm

* 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 on the
conference web site.

Proceedings will be published by ACM Press.  Authors of accepted
submissions are expected to transfer the copyright to the
ACM.  Presentations will be videotaped and released online if the
presenter consents.

Formatting: Submissions must be in PDF format printable in black and
white on US Letter sized paper and interpretable by Ghostscript.  If
this requirement is a hardship, make contact with the program chair at
least one week before the deadline.  Papers must adhere to the standard
ACM 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: http://www.acm.org/sigs/sigplan/authorInformation.htm

Submission: Submissions will be accepted only online via the ICFP
website. 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 48-hour period, starting at 14:00
UTC on Monday May 7th 2012, to read reviews and respond to them.

Special Journal Issue: There will be a special issue of the Journal of
Functional Programming with papers from ICFP 2012.  The program
committee will invite the authors of select accepted papers to submit
a journal version to this issue.

Conference Chair:
 Peter Thiemann, University of Freiburg

Program Chair:
 Robby Findler, Northwestern University

Program Committee:
 Andreas Rossberg, Google
 Andrew Tolmach, Portland State University
 Brigitte Pientka, McGill University
 Colin Runciman, University of York
 Eijiro Sumii, Tohoku University
 Jan Midtgaard, Aarhus University
 John Hughes, Chalmers University of Technology and Quviq AB
 Lars Birkedal, IT University of Copenhagen
 Manuel Fähndrich, Microsoft Research
 Mariangiola Dezani-Ciancaglini, University of Turin
 Matthias Blume, Google
 R. Kent Dybvig, Cisco and Indiana University
 Sam Tobin-Hochstadt, Northeastern University
 Satnam Singh, Google Research
 Simon Marlow, Microsoft Research
 Zena M. Ariola, University of Oregon

short howto: C interface

Suppose I have a file with compilable C code, say sum.c:

int sum(int x, int y) { return x + y; }

I would like to use this function from inside a Bigloo program. 
I know that library functions can be made accessible via 'extern' 
and 'macro', like so: (extern (macro random01::double () "drand48"))
After that, I can call (random01), which works great for me.

How can I get a function called 'sum' oder 'sum-c' inside a 
Bigloo program, which will call the above function written in C? 
Could you please give me a short howto (declarations, compiler 
options, etc.)?

It can't be too difficult, I just don't see it right now.

Thank you!

Building on Mac OS X Lion