<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.lisp.scheme.scheme48">
    <title>gmane.lisp.scheme.scheme48</title>
    <link>http://blog.gmane.org/gmane.lisp.scheme.scheme48</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2588"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2587"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2586"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2585"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2584"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2583"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2582"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2581"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2580"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2579"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2578"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2577"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2576"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2575"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2574"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2573"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2572"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2571"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2570"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2569"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2588">
    <title>Re: Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2588</link>
    <description>&lt;pre&gt;   Date: Tue, 30 Apr 2013 18:30:51 +0000
   From: Taylor R Campbell &amp;lt;campbell&amp;lt; at &amp;gt;mumble.net&amp;gt;

      Date: Tue, 30 Apr 2013 10:39:32 -0700
      From: Will Noble &amp;lt;will&amp;lt; at &amp;gt;cow9.org&amp;gt;

      However, in this case a ton of signals-related procedures in the POSIX
      module would need this treatment. I think Mike would want to use some other
      solution.

   Would they really?  I think only WAIT-FOR-CHILD-PROCESS and
   FIND-NEXT-SIGNAL rely on it.

FORK, too, I suppose, or anything that could create child processes,
so that we don't end up with zombies and nothing to reap them.


&lt;/pre&gt;</description>
    <dc:creator>Taylor R Campbell</dc:creator>
    <dc:date>2013-04-30T19:03:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2587">
    <title>Re: Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2587</link>
    <description>&lt;pre&gt;   Date: Tue, 30 Apr 2013 10:08:02 -0700
   From: Will Noble &amp;lt;will&amp;lt; at &amp;gt;cow9.org&amp;gt;

   Of course, it would be great if we don't get any unneeded reinitializers (or
   code to reload unneeded share objects) in images. 

The dynamic externals reloading mechanism currently doesn't use
reinitializers because it has to run before lots of them.  What if
each reinitializer had a list of those reinitializers that it depends
on, so that anything relying on dynamic externals would have to list
the dynamic externals renitializer?  If nothing depends on dynamic
externals then the dynamic externals reinitializer could be GC'd and
wouldn't have to run.


&lt;/pre&gt;</description>
    <dc:creator>Taylor R Campbell</dc:creator>
    <dc:date>2013-04-30T18:32:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2586">
    <title>Re: Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2586</link>
    <description>&lt;pre&gt;   Date: Tue, 30 Apr 2013 10:39:32 -0700
   From: Will Noble &amp;lt;will&amp;lt; at &amp;gt;cow9.org&amp;gt;

   However, in this case a ton of signals-related procedures in the POSIX
   module would need this treatment. I think Mike would want to use some other
   solution.

Would they really?  I think only WAIT-FOR-CHILD-PROCESS and
FIND-NEXT-SIGNAL rely on it.


&lt;/pre&gt;</description>
    <dc:creator>Taylor R Campbell</dc:creator>
    <dc:date>2013-04-30T18:30:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2585">
    <title>Re: Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2585</link>
    <description>&lt;pre&gt;
Thanks for the quick reply. No-op is a good trick to remember. I was just
thinking that if I did

(define (wait-for-child-process pid)
  signals-reinitializer
  ...)

the variable reference might get removed.

However, in this case a ton of signals-related procedures in the POSIX
module would need this treatment. I think Mike would want to use some other
solution.

Best,
Will


&lt;/pre&gt;</description>
    <dc:creator>Will Noble</dc:creator>
    <dc:date>2013-04-30T17:39:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2584">
    <title>Re: Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2584</link>
    <description>&lt;pre&gt;
What I meant was that by changing the mechanism of reinitializers, we could
forget about the transitive closure of the resumer procedure and simply
include every reinitializer. I can think of a couple of reasons for doing
things this way.

For one thing, we already reload dynamically loaded libraries when resuming
from a resumer procedure-type dumped image. In this case, posix.so has
already polluted the image without the benefit of having signals work,
because of the missing reinitializer.

Second, the signal handler reinitializer doesn't do anything heavy. It only
arranges for the system to pick up on signals. To receive those signals the
user has to use the provided functions. Otherwise they would observe not
observe any effects.

Of course, it would be great if we don't get any unneeded reinitializers (or
code to reload unneeded share objects) in images. I think for that we would
need to have procedures refer to their containing packages, and have
packages refer to package-specific reinitializers.

Best,
Will


&lt;/pre&gt;</description>
    <dc:creator>Will Noble</dc:creator>
    <dc:date>2013-04-30T17:08:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2583">
    <title>Re: Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2583</link>
    <description>&lt;pre&gt;
Will Noble &amp;lt;will&amp;lt; at &amp;gt;cow9.org&amp;gt; writes:


Hmmm.  It seems the problem is not so much the mechanism but that there
is no path from `date' to the reinitializer for the signal handlers.
Otherwise, it'd be likely that reinitializers would pollute images
dumped with a resumer procedure.  Having said that, I'll have to think a
bit more about how to create such a path.

&lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2013-04-30T13:40:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2582">
    <title>Re: Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2582</link>
    <description>&lt;pre&gt;   Date: Mon, 29 Apr 2013 07:10:14 -0700
   From: Will Noble &amp;lt;will&amp;lt; at &amp;gt;cow9.org&amp;gt;

   It seems to me that we should be able to expect reinitializers to run. I'm
   not sure what the best solution here is. We could use a separate
   second-stage initialization thunk list to implement reinitializers, instead
   of the current method (relying on record resumers). Or maybe there is a
   natural way of ensuring that reinitializers are always reachable. If we find
   an acceptable solution I'd be happy to code it up.

If you want to guarantee that the reinitializer has been included in
the image in some code you want to run, you can pass it to the NO-OP
procedure (from the BIG-UTIL structure, if I recall correctly) in that
code.  E.g., you might do this at the start of WAIT-FOR-CHILD-PROCESS:

(define (wait-for-child-process pid)
  (no-op sigchld-reinitializer)
  ...mess with pid...)


&lt;/pre&gt;</description>
    <dc:creator>Taylor R Campbell</dc:creator>
    <dc:date>2013-04-29T14:42:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2581">
    <title>Reinitializer failing to run</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2581</link>
    <description>&lt;pre&gt;Hi all,

I'm having a problem with reinitializers. The macro DEFINE-REINITIALIZER
defines a record variable, which might or might not be reachable from a
resumer function. When it is not, the reinitialization routine doesn't make
it into the saved heap image.

Take this example:
    (cond ((fork) =&amp;gt; wait-for-child-process)
          (else (exec "date"))))
; no values returned
Writing good.image
Writing bad.image

Resuming good.image and calling DATE works as expected, but running the VM
with bad.image hangs it because the reinitializer from the posix-process
module that installs signal handlers doesn't run, causing the system to
ignore SIGCHLD signals.

Using ADD-INITIALIZTION-THUNK! instead of a reinitializer doesn't work
because when the thunk runs posix.so would not yet have been loaded back in.

It seems to me that we should be able to expect reinitializers to run. I'm
not sure what the best solution here is. We could use a separate
second-stage initialization thunk list to implement reinitializers, instead
of the current method (relying on record resumers). Or maybe there is a
natural way of ensuring that reinitializers are always reachable. If we find
an acceptable solution I'd be happy to code it up.

Best,
Will


&lt;/pre&gt;</description>
    <dc:creator>Will Noble</dc:creator>
    <dc:date>2013-04-29T14:10:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2580">
    <title>Commercial Users of Functional Programming 2013: Call for Presentations</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2580</link>
    <description>&lt;pre&gt;
     Workshop for
   Commercial Users of Functional Programming 2013
 Sponsored by SIGPLAN
      CUFP 2013
      Co-located with ICFP 2013
      Boston, MA, United States
      Sep 22-24
   Talk Proposal Submission Deadline: 29 June 2013

The annual CUFP workshop is a place where people can see how others
are using functional programming to solve real world problems; where
practitioners meet and collaborate; where language designers and users
can share ideas about the future of their favorite language; and where
one can learn practical techniques and approaches for putting
functional programming to work.

Giving a CUFP Talk
==================

If you have experience using functional languages in a practical
setting, we invite you to submit a proposal to give a talk at the
workshop. We are looking for both experience reports and in-depth
technical talks.

Experience reports are typically 25 minutes long (but negotiable), and
aim to inform participants about how functional programming plays out
in real-world applications, focusing especially on lessons learned and
insights gained. Experience reports don't need to be highly technical;
reflections on the commercial, management, or software engineering
aspects are, if anything, more important.

Technical talks are also 25 minutes long (also negotiable), and should
focus on teaching the audience something about a particular technique
or methodology, from the point of view of someone who has seen it play
out in practice. These talks could cover anything from techniques for
building functional concurrent applications, to managing dynamic
reconfigurations, to design recipes for using types effectively in
large-scale applications. While these talks will often be based on a
particular language, they should be accessible to a broad range of
programmers.

If you are interested in offering a talk, or nominating someone to do
so, send an e-mail to marius(at)twitter(dot)com or
sperber(at)deinprogramm(dot)de or by 29 June 2013 with a short
description of what you'd like to talk about or what you think your
nominee should give a talk about. Such descriptions should be about
one page long.

There will be a short scribes report of the presentations and
discussions but not of the details of individual talks, as the meeting
is intended to be more a discussion forum than a technical
interchange. You do not need to submit a paper, just a proposal for
your talk! Note that we will need all presenters to register for the
CUFP workshop and travel to Boston at their own expense.

Program Committee
=================

    Marius Eriksen (Twitter, Inc), co-chair
    Mike Sperber (Active Group), co-chair
    Mary Sheeran (Chalmers)
    Andres Löh (Well-Typed)
    Thomas Gazagnaire (OCamlPro)
    Steve Vinoski (Basho)
    Jorge Ortiz (Foursquare, Inc.)
    Blake Matheny (Tumblr, Inc.)
    Simon Marlow (Facebook, Inc.)

More information
================

For more information on CUFP, including videos of presentations from
previous years, take a look at the CUFP website at
http://cufp.org. Note that presenters, like other attendees, will need
to register for the event. Presentations will be video taped and
presenters will be expected to sign an ACM copyright release
form. Acceptance and rejection letters will be sent out by July 16th.

Guidance on giving a great CUFP talk
====================================

Focus on the interesting bits: Think about what will distinguish your
talk, and what will engage the audience, and focus there. There are a
number of places to look for those interesting bits.

Setting: FP is pretty well established in some areas, including formal
verification, financial processing and server-side web-services. An
unusual setting can be a source of interest. If you're deploying
FP-based mobile UIs or building servers on oil rigs, then the
challenges of that scenario are worth focusing on. Did FP help or
hinder in adapting to the setting?

Technology: The CUFP audience is hungry to learn about how FP
techniques work in practice. What design patterns have you applied,
and to what areas? Did you use functional reactive programming for
user interfaces, or DSLs for playing chess, or fault-tolerant actors
for large scale geological data processing? Teach us something about
the techniques you used, and why we should consider using them
ourselves.

Getting things done: How did you deal with large software development
in the absence of a myriad of pre-existing support that are often
expected in larger commercial environments (IDEs, coverage tools,
debuggers, profilers) and without larger, proven bodies of libraries? 
Did you hit any brick walls that required support from the community?

Don't just be a cheerleader: It's easy to write a rah-rah talk about
how well FP worked for you, but CUFP is more interesting when the
talks also spend time on what doesn't work. Even when the results were
all great, you should spend more time on the challenges along the way
than on the parts that went smoothly.


&lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2013-03-10T13:25:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2579">
    <title>Re: Map doesn't work with n lists</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2579</link>
    <description>&lt;pre&gt;
Cinolt &amp;lt;cinolt.yk&amp;lt; at &amp;gt;gmail.com&amp;gt; writes:


I don't know exactly what you're looking at, but Scheme 48, in all
versions I've had running, says something like this:

Welcome to Scheme 48 1.9 (made by sperber on 2013-02-14)
See http://s48.org/ for more information.
Please report bugs to scheme-48-bugs&amp;lt; at &amp;gt;s48.org.
Get more information at http://www.s48.org/.
Type ,? (comma question-mark) for help.
(2 4 6)

&lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2013-03-03T14:52:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2578">
    <title>Map doesn't work with n lists</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2578</link>
    <description>&lt;pre&gt;
R5RS specifies that map work with an arbitrary amount of lists, "(map proc
list1 list2 ...)" however I get an error when I try to evaluate:

(map + '(1 2 3) '(1 2 3))

assertion-violation: wrong number of arguments [tail-call]
                     (#{procedure 8517 map} '(#{procedure 110 +} (1 2 3) (1 2 3)))


&lt;/pre&gt;</description>
    <dc:creator>Cinolt</dc:creator>
    <dc:date>2013-03-02T14:24:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2577">
    <title>testing 3</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2577</link>
    <description>&lt;pre&gt;Testing mail server configuration. No action is required on your part.

Best
Jonathan


&lt;/pre&gt;</description>
    <dc:creator>Jonathan Rees</dc:creator>
    <dc:date>2013-02-25T21:20:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2576">
    <title>Re: Scheme 48 1.9 available</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2576</link>
    <description>&lt;pre&gt;This is awesome Mike, thanks for the release! 


On Friday, January 25, 2013 at 2:14 AM, Michael Sperber wrote:


I'll be looking into making a release in the next few weeks. Not having an officially packaged s48 1.9 was our biggest blocker for distribution. 

-Roderic&lt;/pre&gt;</description>
    <dc:creator>Roderic Morris</dc:creator>
    <dc:date>2013-01-27T15:28:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2575">
    <title>Re: Scheme 48 1.9 available</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2575</link>
    <description>&lt;pre&gt;
gavino_learning &amp;lt;visphatesjava&amp;lt; at &amp;gt;gmail.com&amp;gt; writes:


I believe the scsh people have already been working on the basis of of
the development code that has been released as 1.9, but don't know the
exact status.


I already ported some of it, mainly what's needed for ftpd to run.  Help
with completing the port would be appreciated:

http://www.s48.org/cgi-bin/hgwebdir.cgi/sunet/


It just means steering Scheme 48 more towards practical applications.
The next big concrete step is R6RS support.

&lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2013-01-25T07:14:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2574">
    <title>Re: Scheme 48 1.9 available</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2574</link>
    <description>&lt;pre&gt;
awesome!
will scsh follow?
sunet?

You mentioned a new direction? What will it be?


&lt;/pre&gt;</description>
    <dc:creator>gavino_learning</dc:creator>
    <dc:date>2013-01-23T20:48:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2573">
    <title>Re: Scheme 48 1.9 available</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2573</link>
    <description>&lt;pre&gt;JR&amp;gt; The name of the command ought to be:
JR&amp;gt; ,show-known-structures (or more precisely
JR&amp;gt; ,show-structures-in-config-package , which I assume is what it does).

Thanks for catching this, we are going to fix this.

&lt;/pre&gt;</description>
    <dc:creator>Marcus Crestani</dc:creator>
    <dc:date>2013-01-23T12:47:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2572">
    <title>Re: Scheme 48 1.9 available</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2572</link>
    <description>&lt;pre&gt;
Jonathan Rees &amp;lt;jar&amp;lt; at &amp;gt;mumble.net&amp;gt; writes:


It's an Eclipse plugin for Scheme 48:

http://www.s48.org/sdt/

&lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2013-01-22T19:19:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2571">
    <title>Re: Scheme 48 1.9 available</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2571</link>
    <description>&lt;pre&gt;
On Jan 22, 2013, at 12:28 PM, Michael Sperber wrote:


Probably too late to change now, but ,show-known-packages lists structures, not packages. Packages in scheme 48 are almost always anonymous - the package/structure distinction is an important part of the design. The name of the command ought to be: ,show-known-structures (or more precisely ,show-structures-in-config-package , which I assume is what it does).

(Yes, there are many commands with names of the form ,xxx-package that take structure names, but they only take structure names as an expedient, because there is usually no way to name a package.  The meaning is usually: operate on the package that underlies the designated structure.)

Sorry I missed this on my earlier review; I neglected to read the new features list. If it's too late to change the command name, perhaps its documentation can at least be corrected in some future release.

Just curious, what is SDT and why is it playing with the command processor? I found no google hits for "SDT (Marcus Crestani,
 Sebastian Rheinecker)".

Jonathan


&lt;/pre&gt;</description>
    <dc:creator>Jonathan Rees</dc:creator>
    <dc:date>2013-01-22T18:14:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2570">
    <title>Scheme 48 1.9 available</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2570</link>
    <description>&lt;pre&gt;
Version 1.9 of the Scheme 48 system is now available from the Scheme 48
home page:

http://www.s48.org/

Scheme 48 is a based on byte-code interpreter and comes with a module
system, an extensive set of libraries, an interactive command-line-based
development environment and a manual in various formats. Scheme 48 runs
on most Unix/Linux systems, as well as Windows NT, 2000, XP, and Vista,
and is fully R5RS-conformant.

The 1.9 release has been a long time in the making, and is a substantial
feature release, with help from many contributors.  See the attached
release notes for details.

This release marks a change in direction (actually two
changes) for Scheme 48:

As most regular users of the system know, the system was originally
developed by Richard Kelsey and Jonathan Rees.  I have handled the
releases of Scheme 48 since version 1.1, with the help of Martin
Gasbichler, Marcus Crestani and many other volunteers.  We have tried to
make the system more oriented towards practical uses, and thus moved
away from Richard's and Jonathan's original goals for the system.
Nevertheless, we continued to release and distribute with Richard's and
Jonathan's names featured most prominently, as the number of
contributors and the amount of contributed code steadily increased.

Richard and Jonathan requested that we made the gradual change in
direction of the project explicit, which we are trying to do starting
with this release.  The last release Richard and Jonathan handled was
0.57, and they created a 0.58 release that is a more appropriate
starting point for the subsequent releases.  This release 0.58 is also
now available from the web site.  Unfortunately, Richard, Jonathan, and
I were not able to reach an agreement on how to best handle changes made
since then, particularly on how to properly attribute contributions and
changes made to the system.  I decided to do my best to accurately
credit contributors for each single file in the system.  This involved a
lot of archeology: I'm more than happy to add credit where I dropped the
ball, and apologize for any inaccuracies I have introduced.

Also, the 1.9 release is also probably the last release handled by me
that is actually called "Scheme 48", as we are working on introducing
more major changes, among them R6RS support.  (This may take a while
yet.  I do not have much time to spend on Scheme 48 these days.)  So
future releases along this line will have a name other than "Scheme 48".

Anyway, for now, here's Scheme 48 1.9.  I appreciate the help of
numerous contributors who helped me pushing this out; the long delay,
however, is all my fault.

Enjoy!

&lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2013-01-22T17:28:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2569">
    <title>Re: Scheme 48 1.9 release candidate #1</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2569</link>
    <description>&lt;pre&gt;
On Dec 30, 2012, at 11:40 AM, Michael Sperber wrote:


Compiled and ran tests on a 2008 SUSE Linux, all ok.
Compiled (with ./configure CFLAGS="-O0") and ran tests on Lion, all ok.
Without -O0 on Lion compilation and execution were excruciatingly slow, as you reported.
Haven't tested it with my own programs yet.
Jonathan



&lt;/pre&gt;</description>
    <dc:creator>Jonathan Rees</dc:creator>
    <dc:date>2012-12-31T17:33:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2568">
    <title>Re: Scheme 48 1.9 release candidate #1</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2568</link>
    <description>&lt;pre&gt;MS&amp;gt; I'd appreciate if people could give this a whirl.  I'm especially
MS&amp;gt; interested in reports Mac OS X Mountain Lion and Windows 8.

Mountain Lion's LLVM/Clang still has the bug you've mentioned.  I work
around it by turning off the compiler's optimization ("-O0"), e.g.

  ./configure CFLAGS="-O0"

Other than that, the release candidate works fine.

&lt;/pre&gt;</description>
    <dc:creator>Marcus Crestani</dc:creator>
    <dc:date>2012-12-30T17:41:20</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.lisp.scheme.scheme48">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.scheme.scheme48</link>
  </textinput>
</rdf:RDF>
