<?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/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 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, 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 sperber(at)deinprogramm(dot)de or
avsm2(at)cl(dot)cam(dot)ac(dot)uk by 29 June 2012 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!  

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

    Mike Sperber (Active Group), co-chair
    Anil Madhavapeddy (University of Cambridge), co-chair
    Ashish Agarwal (New York University)
    Thomas Arts (QuviQ AB)
    Chris Houser (LonoCloud)
    Tomas Petricek (University of Cambridge)
    Heiko Seeberger (Typesafe)
    Stefan Wehr (factis research)
    Noel Welsh (untyped)

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>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 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, 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 sperber(at)deinprogramm(dot)de or
avsm2(at)cl(dot)cam(dot)ac(dot)uk by 29 June 2012 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!  

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

    Mike Sperber (Active Group), co-chair
    Anil Madhavapeddy (University of Cambridge), co-chair
    Ashish Agarwal (New York University)
    Thomas Arts (QuviQ AB)
    Chris Houser (LonoCloud)
    Tomas Petricek (University of Cambridge)
    Heiko Seeberger (Typesafe)
    Stefan Wehr (factis research)
    Noel Welsh (untyped)

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>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 intensive work on the draft R7RS, and looks forward to the public comment period on this sixth draft.

Enjoy!

For the Scheme language Steering Committee,
&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 signal; currently it doesn't take
this into account at all. POSIX has the relevant information, but we need it
to call the RTS instead of the other way around to avoid making the RTS a
client of POSIX. We could accomplish this a number of ways, including using
a counter.

Best,
Will


&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 events of a particular class.

To fix the race condition in getaddrinfo-style usage of external
events, we need a way to allocate some sort of event identifier from
Scheme, pass the identifier to C, and pass the result back to Scheme
to be put in a placeholder.


Robert Ransom
&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>

