<?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://permalink.gmane.org/gmane.lisp.scheme.scheme48">
    <title>gmane.lisp.scheme.scheme48</title>
    <link>http://permalink.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/2519"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2518"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2517"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2516"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2515"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2513"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2512"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2511"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2508"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2505"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2503"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2502"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2498"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2496"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2495"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2494"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2491"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2490"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2489"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2487"/>
      </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/2519">
    <title>Re: string-hash</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2519</link>
    <description>&lt;pre&gt;
Jonathan Rees &amp;lt;jar&amp;lt; at &amp;gt;mumble.net&amp;gt; writes:


Marcus Crestani fixed this in 2008.  I just need to make a release with
the fix in it.

&lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2012-05-17T13:37:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2518">
    <title>string-hash</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2518</link>
    <description>&lt;pre&gt;http://www.cse.yorku.ca/~oz/hash.html

vm/data/struct.scm has

(define (vm-string-hash s)
  (let ((n (vm-string-length s)))
    (do ((i 0 (+ i 1))
         (h 0 (+ h (char-&amp;gt;ascii (vm-string-ref s i)))))
        ((&amp;gt;= i n) h))))

also other places in the source (but not srfi-13)

I'm not complaining, just thought this might want to go on the to-do-someday list.

Interesting coincidence, this page was the top google hit for "string hash", and its author was the first person to get ahold of scheme48 (beyond Richard and me)

Jonathan

&lt;/pre&gt;</description>
    <dc:creator>Jonathan Rees</dc:creator>
    <dc:date>2012-05-16T18:29:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2517">
    <title>CFP: Commercial Users of Functional Programming 2012</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2517</link>
    <description>&lt;pre&gt;
   COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING 2012
      CUFP 2012
                       http://cufp.org/conference
CALL FOR PRESENTATIONS
 Copenhagen, Denmark
      Sep 13-15
      Co-located with ICFP 2012
 Sponsored by SIGPLAN
    Talk Proposal Submission Deadline 29 June 2012

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're looking for two kinds of talks:

Experience reports are typically 25 minutes long, and aim to inform
participants about how functional programming plays out in &lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2012-05-14T18:18:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2516">
    <title>Commercial Users of Functional Programming 2012: Call for Presentations</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2516</link>
    <description>&lt;pre&gt;
   COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING 2012
      CUFP 2012
                       http://cufp.org/conference
CALL FOR PRESENTATIONS
 Copenhagen, Denmark
      Sep 13-15
      Co-located with ICFP 2012
 Sponsored by SIGPLAN
    Talk Proposal Submission Deadline 29 June 2012

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're looking for two kinds of talks:

Experience reports are typically 25 minutes long, and aim to inform
participants about how functional programming plays out in &lt;/pre&gt;</description>
    <dc:creator>Michael Sperber</dc:creator>
    <dc:date>2012-02-21T18:57:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2515">
    <title>[Scheme Steering Committee announcements] R7RS public comment period</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2515</link>
    <description>&lt;pre&gt;This message is being posted to various lists to inform members of the Scheme community on the development of R7RS.

I am pleased to announce that the sixth draft version of R7RS ("small" language) has been completed by working group 1 and is now available at the following URL:

 http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs-draft-6.pdf

A copy will also be posted on schemers.org .

Other documents produced by working group 1, including previous drafts and progress reports are available at the following URL:

 http://www.scheme-reports.org/2012/working-group-1.html

The editors of working groups 1 and 2, in consultation with the Scheme language steering committee, have provided a mechanism for comment and discussion.  For details, including instructions on how to submit a formal comment, please see this document:

 http://www.scheme-reports.org/2012/process1.html

The comment period is now open and will continue until June 30, 2012.

The steering committee thanks the editors for their intensi&lt;/pre&gt;</description>
    <dc:creator>Marc Feeley</dc:creator>
    <dc:date>2012-02-17T06:44:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2513">
    <title>Re: new package in sunterlib : SPAN</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2513</link>
    <description>&lt;pre&gt;At Mon, 23 Jan 2012 06:55:15 +0900,
erana Owl wrote:


You do realise that the 'P' in CPAN stands for Perl? And that Perl is
the name of another programming language? Wouldn't it make more sense
to call your thing CSAN?

Richard
&lt;/pre&gt;</description>
    <dc:creator>Richard Lewis</dc:creator>
    <dc:date>2012-01-26T07:14:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2512">
    <title>Re: new package in sunterlib : encryption</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2512</link>
    <description>&lt;pre&gt;   Date: Mon, 23 Jan 2012 06:51:36 +0900
   From: erana Owl &amp;lt;0wl256&amp;lt; at &amp;gt;gmail.com&amp;gt;

   I've ported blowfish encryption to sunterlib. It's in the git repo.

What is the intended application?

It is a rare application of crypto that requires as its sole crypto
primitive a block cipher, and the implementation of crypto primitives
is a task fraught with dangers such as timing side channels that need
to be addressed carefully either with strongly worded caveats or with
detailed security analyses.


&lt;/pre&gt;</description>
    <dc:creator>Taylor R Campbell</dc:creator>
    <dc:date>2012-01-22T22:02:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2511">
    <title>new package in sunterlib : xanadu</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2511</link>
    <description>&lt;pre&gt;Hi,

xanadu is a scheme Xanadu using XML scheming and trees for filesystem xml
features.
I't is in development and in the git repo.

Enjoy,
Johan
&lt;/pre&gt;</description>
    <dc:creator>erana Owl</dc:creator>
    <dc:date>2012-01-22T21:57:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2508">
    <title>new package in sunterlib : schemedoc</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2508</link>
    <description>&lt;pre&gt;Hi,

I've put a scheme coded perldoc .pod reader in sunterlib. It's in the git
repo.

There's preliminary .sod and scriblle features coming up.

Enjoy,
Johan
&lt;/pre&gt;</description>
    <dc:creator>erana Owl</dc:creator>
    <dc:date>2012-01-22T21:53:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2505">
    <title>Re: scheme48 with X11 support</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2505</link>
    <description>&lt;pre&gt;RH&amp;gt; As a topical reminder of previous X11 related work in or for scsh:
RH&amp;gt;   * scx - Xlib bindings;

And here is a port of scx to Scheme 48:

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

&lt;/pre&gt;</description>
    <dc:creator>Marcus Crestani</dc:creator>
    <dc:date>2012-01-17T06:29:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2503">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2503</link>
    <description>&lt;pre&gt;
I misunderstood your issue with the counter and ended up explaining why we
couldn't double-count, which is incredibly obvious. I hope you were not
offended ;). On the other point, it doesn't look to me like a thread queue
with a thread in it waiting for a signal could be garbage-collected...


...although I don't understand how this prevents it. The mechanism I see is
the signal mapper (from OS signal number to list of thread queues, for all
known signals). It strongly references every non-empty thread queue. So a
way to know if any thread is waiting for a signal without keeping a counter
is to iterate over the mapper looking for a non-empty queue.

(Also evidently I was talking about a different usage of weak pointers in
signal.scm than the one you referred to, so basically my entire post
explained the wrong things. Sorry!)

I don't think we really have a disagreement here. To summarize my
recommendation, I like the narrow solution where the deadlock detection code
checks if any thread is waiting on an OS &lt;/pre&gt;</description>
    <dc:creator>Will Noble</dc:creator>
    <dc:date>2012-01-14T22:55:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2502">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2502</link>
    <description>&lt;pre&gt;
???  A thread which is waiting for a signal is sleeping.  In any case,
I don't see how this is relevant to whether we can use a counter
(which will break deadlock detection permanently if one of the signal
system's thread queues is ever GCed while a thread is blocked on it)
to determine whether any threads are waiting for an OS signal.


Signal queues are weakly held too.  Fortunately, the
(signal-queue-signals queue) call in find-next-signal keeps a
reference to the signal queue around when a thread is blocked on the
queue, so we would get away with the counter optimization (but only by
a lucky accident).


Robert Ransom


&lt;/pre&gt;</description>
    <dc:creator>Robert Ransom</dc:creator>
    <dc:date>2012-01-14T12:43:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2498">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2498</link>
    <description>&lt;pre&gt;
See attached.


Robert Ransom
&lt;/pre&gt;</description>
    <dc:creator>Robert Ransom</dc:creator>
    <dc:date>2012-01-11T08:46:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2496">
    <title>Fwd: Re: scheme-fb license change</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2496</link>
    <description>&lt;pre&gt;
In case you aren't aware of it, the community went through a big effort
to get scheme48 and most of the other copyrighted code unified under an
open source license many years ago (modified BSD). I don't know how much
is preserved in public archives, but I'm pointing you to the history so
you can be aware of it when you make your decisions.

&lt;/pre&gt;</description>
    <dc:creator>Anthony Carrico</dc:creator>
    <dc:date>2012-01-11T08:03:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2495">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2495</link>
    <description>&lt;pre&gt;

I've found some bugs in this branch; I'll send a revised branch soon.


Robert Ransom


&lt;/pre&gt;</description>
    <dc:creator>Robert Ransom</dc:creator>
    <dc:date>2012-01-11T06:37:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2494">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2494</link>
    <description>&lt;pre&gt;
Yes. A sleeping thread can't wait for a signal so a counter works just as
well as looking at the thread queue. It's less optimization than
convenience. With the approach I outlined in the previous message you might
equally well register the actual thread queues with the RTS and have
ROOT-WAIT go through them to see if a thread somewhere is waiting for a
signal, but a counter does the same thing.

Regarding the weak pointer usage in signal.scm: those map signal numbers to
signal representations. If, say, you have a signal 5 in the system, the
mapping returns the existing object when asked for signal 5. However, if
everyone else loses their reference to that object, you don't want the
abstract concept of "5" to keep it around forever without being
garbage-collected. It's not something that would break the counter shortcut.

Best,
Will


&lt;/pre&gt;</description>
    <dc:creator>Will Noble</dc:creator>
    <dc:date>2012-01-11T02:54:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2491">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2491</link>
    <description>&lt;pre&gt;

The external-events system is broken, both as used by getaddrinfo and
when used with long-lived UIDs.

When a UID is allocated from C for an event, then passed to a Scheme
thread which waits for that UID once, there is a race condition -- if
C signals an event with that UID before Scheme starts waiting for it,
the event will be dropped on the floor, and the Scheme thread will not
be awakened unless and until some other event is allocated the same
UID and is signaled.

When a long-lived UID is allocated for a class of events, and a Scheme
thread waits for that UID repeatedly, there is a different race
condition -- if C signals that UID between the time that Scheme checks
for events previously queued from C and the time that it waits for a
new event, the event signal will be dropped on the floor.

See my event-waiters branch (attached and pushed to hg-git) for a
synchronization primitive which can be used to fix the latter race
condition, provided that the event-waiter is created before C starts
signaling ev&lt;/pre&gt;</description>
    <dc:creator>Robert Ransom</dc:creator>
    <dc:date>2012-01-10T10:08:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2490">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2490</link>
    <description>&lt;pre&gt;

Would a counter be sufficient for this?  I see some use of weak
pointers in scheme/posix/signal.scm, so I really have no idea whether
we could safely use that optimization (i.e. look at a counter instead
of the thread queues themselves), even if we didn't need a more
general solution.


Robert Ransom


&lt;/pre&gt;</description>
    <dc:creator>Robert Ransom</dc:creator>
    <dc:date>2012-01-10T10:11:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2489">
    <title>Re: Changeset 0306c5a64775</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2489</link>
    <description>&lt;pre&gt;
process-id placeholders are separate from signal queues, and their
deadlock-detection issues need to be fixed separately.  (We can't just
use the fix for deadlock detection when threads are waiting on signal
queues to handle the case of process-id placeholders, because
something needs to listen for SIGCHLD all the time, even when no
threads are currently waiting on process-id placeholders.)


It makes sense to keep that mechanism separate from the
external-events package.  See my (revised)
wait-for-child-process-deadlock-fix branch (attached, and pushed using
hg-git to https://git.torproject.org/user/rransom/scheme48.git) for
that.


Robert Ransom
&lt;/pre&gt;</description>
    <dc:creator>Robert Ransom</dc:creator>
    <dc:date>2012-01-10T09:53:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2487">
    <title>Re: tmail - scheme mail demon</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2487</link>
    <description>&lt;pre&gt;Version 0.2.4 released

version 0.2.4 Changes
------------------------------

- tdaemon.scm script which can be run in scsh to (run-daemon-child
staterecord)
- "rc" alike tforks.scm, tserver.scm tclient.scm which contain tell-client
and ask-server methods.
- tforks.scm contains record and daemon to be spawned by e.g. init or
daemontools
and uses fork-and-forget with 10 commands per session.
- old/ code directory
- daemon state record (port, host, etc. in a scsh record)
- telnetable daemon

For tarballs see http://soft.vub.ac.be/~jceuppen/scheme/
tmail-0.2.X files.

Cya,
Johan

2012/1/9 erana Owl &amp;lt;0wl256&amp;lt; at &amp;gt;gmail.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>erana Owl</dc:creator>
    <dc:date>2012-01-09T14:21:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2486">
    <title>tmail - scheme mail demon</title>
    <link>http://permalink.gmane.org/gmane.lisp.scheme.scheme48/2486</link>
    <description>&lt;pre&gt;Hi all,

I'm working on a scsh/s48 mailer demon. The code now has a response system
and a socket listener etc.
See http://soft.vub.ac.be/~jceuppen/scheme/tmail-0.2.tar.gz

Cya,

Johan
&lt;/pre&gt;</description>
    <dc:creator>erana Owl</dc:creator>
    <dc:date>2012-01-08T23:12:04</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>

