Re: [PATCH] Added Artanis info to new main page

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Luis Felipe López Acevedo  skribis:
>>
>>> On 2015-11-08 15:35, Dirk-Jan C. Binnema wrote:
>>
>> [...]
>>
 With the rest of the website looking so very welcoming, I could imagine
 that the gdb screenshot might look a bit scary to newcomers; perhaps
 (part of) the foo-pretty-printer[1] would be a bit easier to digest?

 https://sourceware.org/gdb/onlinedocs/gdb/Writing-a-Guile-Pretty_002dPrinter.html

 Cheers,
 Dirk.
>>>
>>> Mathieu, could you take the screenshot? Maybe with your suggestions
>>> and Dirk-jan's? I don't use GDB (I'm not there yet :P).
>>
>> Mathieu?  What’s up?  :-)
>
> I was waiting to get the screenshot done, but I have overestimated my
> motivation to look into GDB Guile pretty printing.  I think that for now
> we can use:
>
>   https://multimedialib.files.wordpress.com/2015/11/gdb-guile1.png

LGTM!  Could you add it to the web page?

> Sorry every one for my late answer.

No problem, there’s no urgency here.  :-)

Ludo’.

Re: [PATCH] Added Artanis info to new main page

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Mathieu?  What’s up?  :-)
>>
>> I was waiting to get the screenshot done, but I have overestimated my
>> motivation to look into GDB Guile pretty printing.  I think that for now
>> we can use:
>>
>>   https://multimedialib.files.wordpress.com/2015/11/gdb-guile1.png
>
> LGTM!  Could you add it to the web page?

I will do that in a batch with my other patches.

--
Mathieu Lirzin

Re: [PATCH] Added Artanis info to new main page

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Luis Felipe López Acevedo  skribis:
>>>
 On 2015-11-08 15:35, Dirk-Jan C. Binnema wrote:
>>>
>>> [...]
>>>
> With the rest of the website looking so very welcoming, I could imagine
> that the gdb screenshot might look a bit scary to newcomers; perhaps
> (part of) the foo-pretty-printer[1] would be a bit easier to digest?
>
> https://sourceware.org/gdb/onlinedocs/gdb/Writing-a-Guile-Pretty_002dPrinter.html
>
> Cheers,
> Dirk.

 Mathieu, could you take the screenshot? Maybe with your suggestions
 and Dirk-jan's? I don't use GDB (I'm not there yet :P).
>>>
>>> Mathieu?  What’s up?  :-)
>>
>> I was waiting to get the screenshot done, but I have overestimated my
>> motivation to look into GDB Guile pretty printing.  I think that for now
>> we can use:
>>
>>   https://multimedialib.files.wordpress.com/2015/11/gdb-guile1.png
>
> LGTM!  Could you add it to the web page?
>

Done in 7a2a06a1dd8dc4e6120ed5e3a6969a6dc8361a35.

Thanks,

--
Mathieu Lirzin

Announcing 8sync: an asynchronous programming language for Guile

[Christopher Allan Webber]

Hello all,

Some of you may remember the thread on this list about Guile needing an
asynchronous programming library, with a writeup from a conversation
David Thompson, Mark Weaver, guest star Andrew Engelbrecht, and I had at
LibrePlanet:

  https://lists.gnu.org/archive/html/guile-devel/2015-10/msg00015.html

Well! I've begun work on an asynchronous programming language called
"8sync" for Guile (pronounced "eight-sync", as in "eight-synchronous
communication" :))!  You can find it here:

  https://notabug.org/cwebber/8sync

A nice little logo here:

  http://dustycloud.org/gfx/goodies/8sync-protologo2.png

Hm, I need a nice website to go with that logo! :)

It makes significant use of delimited continuations.  You can do things
like this:

  (define (my-number-talker)
(format #t
  "Oh boy, looks like we got back ~a!\n"
  (%sync (%run (+ 1 2 3 (complicated-number-code 38))

... and the complicated-number-code will launch asynchronously, but wake
back up the appropriate function appropriately.  You can also set timed
events, read and write to ports asynchronously, and etc.  It has a nice
non-blocking loop, and personally I've found it to be a delight to use.

(Also should I be calling that thing (%sync) or (8sync)?  The jury is
out, so in the meanwhile, it's an alias!)

Anyway, there's a lot to be done... I'm not at a 0.1 release quite yet,
but am rapidly approaching it.

If you're interested in giving it a whirl, there's an IRC bot that ships
with it already in the demos/ directory.  Oh yeah, did I mention that
this makes use of the cooperative REPL system in Guile?  This means you
can *live hack your asynchronous code*.  Pretty cool!  (As such, we've
got a little guest in #guile right now named "syncbot"...)

More to come soon, including documentation, web programming examples, an
actor model implementation layered on top, and more functional
programming utilities, including maybe an Elm-like time traveling
debugger.  (There's currently some mutation under the hood, but all of
it can be refactored to be purely functional... with the exception of a
parameter that's used to find the current agenda.  Even that though,
I'll be writing code so you can schedule explicitly to the agenda
shortly if you really are upset by that one impurity.  Sure makes doing
%sync / 8sync calls nice though...)

Anyway, I'm having a ton of fun with this project.  Give it a
try... maybe you will too!

 - Chris

Re: Announcing 8sync: an asynchronous programming language for Guile

[Christopher Allan Webber]

Christopher Allan Webber writes:

> ... and the complicated-number-code will launch asynchronously, but wake
> back up the appropriate function appropriately.  You can also set timed
> events, read and write to ports asynchronously, and etc.  It has a nice
> non-blocking loop, and personally I've found it to be a delight to use.

There's one potential long-term caveat to this (maybe?), which is that
the way this achieves nice asynchronous communication is by working hand
in hand with guile's (select) statement, which seems to only work for
socket type ports and file type ports I think?  Mark Weaver said he'd
think if there were other options.  I've briefly scanned the relevant C
code but I'm not really sure if there's any way we can expose a more
flexible system or not.

Anyway, socket and file ports cover quite a lot of async stuff, so
that's a great step already!

 - Chris

Re: Reading data from a file descriptor

[Andreas Rottmann]

 writes:

> On Fri, Nov 13, 2015 at 10:51:58AM -0500, Mark H Weaver wrote:
>> Jan Synáček  writes:
>> 
>> > On Sun, Nov 8, 2015 at 12:49 AM, Andreas Rottmann 
>> > wrote:
>> >
>> > Also note that if there's no requirement to actually implement
>> > this in
>> > C, there's `fdes->inport' and `fdes->outport' on the Scheme level,
>> > so
>> > something like the following would be analogous to the C example
>> > code
>> > posted:
>> > 
>> > (import (ice-9 binary-ports))
>> > 
>> > (define (process-fd fd)
>> > (let ((port (fdes->inport fd)))
>> > (display "read: ")
>> > (display (get-bytevector-n port 100))
>> > (display "\n")))
>> > 
>> > (process-fd (acquire-valid-fd))
>> > 
>> >
>> > This is something very similar that I ended up with. Just instead of
>> > get-byte-vector, I used read-string!/partial.
>> 
>> I would advise against using 'read-string!/partial' or any of the
>> procedures in (ice-9 rw).  This is a vestigial module from Guile 1.8
>> when strings were arrays of bytes, which they no longer are.  We should
>> probably mark them as deprecated.
>> 
>> For one thing, when we switch to using UTF-8 as the internal string
>> encoding, it will not be possible to keep 'read-string!/partial'
>> efficient.  It will necessarily have to do an encoding conversion.
>> 
>> In Guile 2+, I would advise using byte vectors when working with binary
>> data.  Portions of these can be converted to strings with a given
>> encoding if desired.  I might be able to give better advice if I knew
>> more about what you are doing here.
>
> Mark,
>
> what Jan is after (and what I'd like to have too) is something
> akin to Unix read(2) with O_NONBLOCK: provide a buffer, request
> (up to) N bytes from the file (descriptor) and get an answer
> (with possibly less bytes).
>
> I tried that a while ago and was surprised that I had to resort
> to (character) strings, with all the downsides you mention. Something
> like that for byte vectors would be awesome. Either it exists (and
> neither Jan nor me have succeeded in finding it) or it doesn't.
>
The procedure with the closest semantics is R6RS
`get-bytevector-some`. While the R6RS says it will block if no data is
available, a quick look at Guile source code seems to indicate that it
probably works with non-blocking I/O -- I'd say it should return EOF if
called on a non-readable, non-blocking port, and otherwise not block,
and return the data available. This is all just from a quick
inspection, without running any actual code.

Regards, Rotty
-- 
Andreas Rottmann --