Re: Asynchronous event loop brainstorm at FSF 30

[Mikael Djurfeldt]

Yes.

I'm sure both you and Mark can judge this better than can, currently.

I just didn't think Guile was that thread-unsafe.  I imagined you
would have to use mutexes around some I/O and common datastructures,
and that that would be about it, but I'm probably wrong...

Best regards,
Mikael

On Wed, Nov 18, 2015 at 3:16 PM, Christopher Allan Webber
 wrote:
> Mikael Djurfeldt writes:
>
>> Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" <
>> cweb...@dustycloud.org>:
>>>  - This would be like asyncio or node.js, asynchronous but *not* OS
>>>thread based (it's too much work to make much of Guile fit around
>>>that for now)
>>
>> Why is this (too much work for threads)?
>
> Threads bring a lot of risky problems.  I really don't want to deal with
> that much locking.  A lot of Guile's code isn't thread-safe... if we
> wanted to go to the "oh yeah super safe with threads!" direction,
> it might require something like Clojure's software transactional
> memory.  I talked to Mark Weaver about this; it's very expensive to do,
> super hard to implement (I don't think we have any guile devs
> interested), and makes things slower whenever you *aren't* using
> threads.
>
> The asyncio / node.js style of things can solve IO bound problems.  As
> for CPU bound, we can use message passing between threads or processes.
>
> It's beneficial to focus on message passing for CPU bound issues anyway,
> because this means that our code will be able to span across machines,
> if said messages are serializable.
>
> Does that make sense?
>  - Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Mikael Djurfeldt]

Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" <
cweb...@dustycloud.org>:
>  - This would be like asyncio or node.js, asynchronous but *not* OS
>thread based (it's too much work to make much of Guile fit around
>that for now)

Why is this (too much work for threads)?

Re: Asynchronous event loop brainstorm at FSF 30

[Chris Vine]

On Tue, 17 Nov 2015 11:46:24 -0600
Christopher Allan Webber  wrote:
[snip]
> This sounds very interesting... is the source available?  Could you
> point to it?
> 
> Thanks!
>  - Chris

No it's not.  I'll email you something.

Chris

Re: (list-head lst k) with k longer than (length lst)

[Jan Synáček]

On Tue, Nov 17, 2015 at 10:27 PM, Mark H Weaver  wrote:
> Chris Vine  writes:
>
>> On Tue, 17 Nov 2015 11:53:05 +0100
>> Jan Synáček  wrote:
>>> Hello,
>>>
>>> I'm getting:
>>>
>>> scheme@(guile-user)> (list-head '(1 2 3) 5)
>>> ERROR: In procedure list-head:
>>> ERROR: In procedure list-head: Wrong type argument in position 1
>>> (expecting pair): ()
>>>
>>> This looks pretty much like a bug to me. Shouldn't list-head return
>>> the entire list when the 'k' is bigger than its length? If that is not
>>> the case, at least the error is really confusing. I'm using Guile
>>> 2.0.11.
>>
>> The error message is confusing, but I guess the behaviour of list-head
>> mirrors R5RS list-tail: instead of mandating the return of an empty
>> list, R5RS states that "It is an error if list has fewer than k
>> elements".
>
> Exactly right, but I agree that the error message is confusing.
>
> Unless otherwise specified, Scheme and Guile tend to be strict in cases
> like this.  For example, if a procedure is documented to "Copy the first
> K elements from LST", and says nothing about what happens for lists with
> fewer than K elements, you should assume that it's an error.
>
>  Mark

Thank you for the explanation.

-- 
Jan Synáček

Re: Reading data from a file descriptor

[Jan Synáček]

On Tue, Nov 17, 2015 at 1:59 PM, Chris Vine  wrote:
> On Tue, 17 Nov 2015 10:53:19 +0100
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Mon, Nov 16, 2015 at 11:54:33AM +0100, Amirouche Boubekki wrote:
>> > On 2015-11-13 21:41, Jan Synáček wrote:
>>
>> [...]
>>
>> > >I have an open fd to a unix socket and I want to read data from
>> > >it. I know that the data is going to be only strings, but I don't
>> > >know the length in advance.
>> >
>> > Do you know a delimiter? maybe it's the null char?
>> >
>> > TCP is stream oriented, it's not structured at this layer into
>> > messages or segments. You need some knowledge about the byte stream
>> > to be able to split it into different meaningful piece for the
>> > upper layer.
>>
>> I think I "got" Jan's request, because I've been in a similar
>> situation before: delimiter is not (yet) part of it. What he's
>> looking for is an interface à la read(2), meaning "gimme as much
>> as there is in the queue, up to N bytes, and tell me how much
>> you gave me". Of course, putting stuff in a byte vector would
>> be preferable; the only functions I've seen[1] which "do" that
>> interface are read-string!/partial and write-string/partial
>> operate on strings, not byte arrays, alas.
>
> guile's R6RS implementation has get-bytevector-some, which will do that
> for you, with unix-read-like behaviour.
>
> You cannot use this for UTF-8 text by trying to convert the bytevector
> with utf8->string, because you could have received a partially formed
> utf-8 character.  So for text, you should use line orientated reading,
> such as with ice-9 read-line or R6RS get-line.
>
> Chris

This seems to be exactly what I'm looking for, thank you!

-- 
Jan Synáček

Re: Asynchronous event loop brainstorm at FSF 30

[Christopher Allan Webber]

Mikael Djurfeldt writes:

> Den 4 okt 2015 02:30 skrev "Christopher Allan Webber" <
> cweb...@dustycloud.org>:
>>  - This would be like asyncio or node.js, asynchronous but *not* OS
>>thread based (it's too much work to make much of Guile fit around
>>that for now)
>
> Why is this (too much work for threads)?

Threads bring a lot of risky problems.  I really don't want to deal with
that much locking.  A lot of Guile's code isn't thread-safe... if we
wanted to go to the "oh yeah super safe with threads!" direction,
it might require something like Clojure's software transactional
memory.  I talked to Mark Weaver about this; it's very expensive to do,
super hard to implement (I don't think we have any guile devs
interested), and makes things slower whenever you *aren't* using
threads.

The asyncio / node.js style of things can solve IO bound problems.  As
for CPU bound, we can use message passing between threads or processes.

It's beneficial to focus on message passing for CPU bound issues anyway,
because this means that our code will be able to span across machines,
if said messages are serializable.

Does that make sense?
 - Chris

Re: Asynchronous event loop brainstorm at FSF 30

[Christopher Allan Webber]

Chris Vine writes:

> On Tue, 17 Nov 2015 11:46:24 -0600
> Christopher Allan Webber  wrote:
> [snip]
>> This sounds very interesting... is the source available?  Could you
>> point to it?
>> 
>> Thanks!
>>  - Chris
>
> No it's not.  I'll email you something.
>
> Chris

Thanks!  I'm reading the code you sent me.  Before I had received your
code, I had started on something yesterday... I'm happy to see we have
some similar ideas.  I might borrow some from you.

I'll be posting what I have shortly, as soon as I have enough little
demos locally to prove whether the thing I wrote makes sense or not.

 - Chris

Guile-Clutter 1.12.2 released

[David Pirotte]

Hello,

We are pleased to announce Guile-Clutter 1.12.2, the next maintenance
release for the Guile-Clutter 1.0 series.


* Guile-Clutter Homepage: 

http://www.gnu.org/software/guile-gnome/clutter


* Guile-Clutter 1.12.2 release tarball GPG signature [*]:


http://download.savannah.gnu.org/releases/grip/guile-clutter/guile-clutter-1.12.2.tar.gz

http://download.savannah.gnu.org/releases/grip/guile-clutter/guile-clutter-1.12.2.tar.gz.sig

[ Special Notes:

[-] As I'm updating Guile-Clutter's web pages for this release, I
still have a pending authorization request to upload the 
release files. So,
in the mean time, I uploaded them under Grip's dowload area, 
which explains
the download url refers to grip instead of 
guile-gnome/guile-clutter ...

[-] Downloads will redirect to your nearest mirror site.
Files on mirrors may be subject to a replication delay of up to 
24 hours.
In case of problems use

http://download-mirror.savannah.gnu.org/releases/grip/guile-clutter

* About Guile-Clutter:

Guile-Clutter is a Guile wrapper for the ultra-hip Gnome Clutter library!

Clutter is a Scene Graph based canvas working in Retained Mode. Every object on 
the
scene is usually a 2D surface inside a 3D space.

Guile-Clutter brings the power of Guile scheme to your Clutter applications!

Guile-Clutter is part of GNU Guile-Gnome.


* Changes since 1.10.0

The primary objectives, working towards this release, were (a) to remove all 
code
specific to the support of Guile versions prior to Guile 2, (b) removing all 
Guile
deprecated calls, and then (c) wrap Clutter 1.12 of course :)!

Dependencies

- Guile-Clutter now requires Guile 2.0, allows Guile 2.2
- Requires Guile-Gnome >= 2.16.3

Clutter specific

- Removing types deprecated in Clutter 1.12.
- Custom bindings added for: ClutterMatrix, ClutterRect, ClutterPoint,
  ClutterSize and ClutterMargin.
- CoglPixelFormat must become visible from guile-clutter [special 
patch].
- Fixing and/or adding special wrappers for: clutter_text_get_color,
  clutter_actor_get_background_color, clutter_image_set_data,
  clutter_actor_get_margin.
- Updating wrapset.api for Clutter 1.12.
- Call to clutter_init fixed.
- Example based upon deprecated functionality removed.
- Hello-transition.scm example fixed.

Other changes

- Pkg-config support added
- Autotool chain improvements
- Make check, make distcheck fixed
- LICENSE file added


* This release was built/tested using the following tools:

-] gcc(Debian 4.9.3-5) 4.9.3 
-] autoconf   (GNU Autoconf) 2.69 
-] automake   (GNU automake) 1.15 
-] libtool(GNU libtool) 2.4.2 
-] makeinfo   (GNU texinfo) 6.0 

-] guile-2.0  2.0.11.114-649ec
-] guile-cairogit clone - master branch
-] g-wrap-2.0-guile   1.9.15
-] guile-gnome2.16.3
-] guile-lib  0.2.2

-] glib-2.0   2.46.2
-] gobject-2.02.46.2
-] gthread-2.02.46.2
-] atk2.18.0
-] pango  1.38.1
-] pangocairo 1.38.1
-] cairo-gobject  1.14.4
-] cogl-1.0   1.12.2
-] clutter-1.01.12.2


David,
on behalf of the Guile-Clutter team.


[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

gpg --verify guile-clutter-1.12.2.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys A3057AD7

and rerun the 'gpg --verify' command.


pgpf24p0xNBgX.pgp
Description: OpenPGP digital signature

Unintentional conflict in define-immutable-type?

[Rob Browning]

This crashes in 2.0:

  (use-modules (srfi srfi-9 gnu))

  (define-immutable-record-type foo
(foo x)
foo?
(x x))

  (foo 1)

like this:

  foo.scm:10:9: In procedure #:
  foo.scm:10:9: In procedure make-struct: Wrong type argument in position 1: 
#

Changing the type name to  (or even xfoo) fixes the conflict, even
though "define-immutable-type foo" actually creates a binding for ,
not foo.

I thought there was a chance this might be unintentional.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4