Re: New logo and website design proposal

[Amirouche Boubekki]

Le 2015-09-17 16:59, Luis Felipe López Acevedo a écrit :

On 2015-09-16 03:19, Alex Sassmannshausen wrote:

Beautiful!

Like Chris, I love the demographically agnostic, yet incredibly 
inviting

drawings.  I also love the overall crisp and modern feel to the whole
site including the proposed new logos.

Fantastic :-)


+1, I really like the design, I find it well done and welcoming except 
the

following...



I also read on IRC that someone said the drawings were childish.



Some one corrected me. What I mean is that it doesn't look **serious** 
enough
in the sens that the drawings would fit way better a tutorial about 
Guile that targets
children. And I think, it's better to save those drawings that and come 
with other

illustrations/photos that are more explicit about each topic.

There should be a better place between "corporate/megacorp", "chilren 
friendly", "academics"
and "startup" designs. Maybe if the toons had a gnu/friendly 
monster/robot
face instead of human faces it will look less "primary school". Like I 
said

the drawing, I'm wondering whether it's for the correct audience.

Some comments on other webites:

- python.org, djangoproject.com, and rust-lang.org look to too 
impersonnal/dull


- ruby-lang is simple and impersonnal but I think the logo makes it work 
great


- kivy.org is really well made

- http://elm-lang.org/ nice, not too dull

Really the design is really well made, no problem with that, I just want 
to be sure
that we won't disappoint the main audience and attract a lot of newsbies 
which i think

we are not ready for.

If I can vote, I will +0.

I other comments, I think that:

- The header menu should use the same ordering as the guix header menu

- It should have bulllet points (!) something like 
https://www.rust-lang.org/

  This kind of standard a lot of people do that in their README

- It should have a code snippet

Last but not least, the website is focusing on explaining that Guile is 
an
**extension** language. I don't use it as such and neither do many 
other,

"it a general programming language with appealing embedding features".

Most people looking for language look for a language to program their 
car/house,
website, make REST apis, build games, script their system and some to 
extend their
software to provide multiple extension language  with the same API. This 
is a really
massive feature of Guile and a deserve a full block, but other aspects 
of the Guile must

appear in the page. I think it is bad rep to call it "script" language.

I think it's written nowhere that it's a scheme language following srfi 
and RNRS specifications.
Honestly it was an another argument for me to start using Guile, instead 
of Racket.




I understand. But I hope that the "Applications using guile" section
will erase any wrong impressions that some people may get after seeing
the illustrations.



This design IMO target better young people, I am not sure that's the 
image

Guile wants to show at first glance.


Hope this helps,


Amirouche




P. S.: Nala Ginrut, I put your two cents in my pocket, thanks :)




Luis Felipe López Acevedo writes:


Hello list,

As part of the Guile project I imagine, I'd like to propose these 
visual

modifications for the logo and the website.

Logo
https://multimedialib.files.wordpress.com/2015/09/guile-logo-proposal-2015-06-16.png

Website mockup (some rough sketches here)
https://multimedialib.files.wordpress.com/2015/09/website-mockup-2015-09-15.png

My intention with this proposal is, hopefully, to modernize the image 
of

the project a bit and make it more attractive to potential users.


Your comments are very welcomed,


--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: Alternative logo proposal

[Amirouche Boubekki]

Le 2015-09-18 00:11, Mathieu Lirzin a écrit :

Thorsten Wilms  writes:


Hi!

I wasn't subscribed before, but got aware of Luis's mockups via
IRC. While I think there's a lot just done right on the website
mockup, I see issues with the logo proposal.

The G in parens concept is fine, but the weighting could be
better. Even then, a G that is all round on the outside is hard to
make harmonious ... and to keep at a far distances from Google's new
G. Then in the lockup, where one paren has to step in the background,
the concept falls apart, to my eyes.

So here's my (first?) proposal, still inspired by Luis's work:
http://i.imgur.com/oKyEvkr.png


Thanks for proposing an alternative.  I rather prefer Luis' logo which 
I

find perfectly harmonious.


+1

Also, this G looks like Google G one too :)

Re: Asynchronous event loop brainstorm at FSF 30

[Amirouche Boubekki]

Héllo,

Please excuse my layman question in advance.

I find the idea awesome to work on asynchronous framework for Guile.

Le 2015-10-04 00:29, Christopher Allan Webber a écrit :

So David Thompson, Mark Weaver, Andrew Engelbrecht and I sat down to
talk over how we might go about an asynchronous event loop in Guile 
that

might be fairly extensible.  Here are some of what we discussed, in
bullet points:

 - General idea is to do something coroutine based.


IUC coroutine takes advantage of the ability to pause the execution of 
given procedure A to run a blocking operation B and execute some other 
procedure C while the blocking operation B is running. At some point, 
when the blocking operation B is finished, and C is finished, A restarts 
where it left.



 - 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)

 - If you really need to maximize your multiple cores, you can do
   multiple processes with message passing anyway


Does it mean that there will be one event loop per thread per process ?



 - So what we really need is a nice API for how to do coroutines, write
   asynchronous code, and work with some event loop with a scheduler




 - Probably a good way to start on this would be to use libuv (or is it
   libev?) and prototype this.  It's not clear if that's a good long
   term approach (eg, I think it doesn't work on the HURD for those who
   care about that, and Guix certainly does)


In asyncio the event loop can be swapped the default event loop is pure 
python. You mean that the first version will use libuv (libuv is the 
nodejs eventloop, formely based on libev).




 - Binary/custom ports could be a nice means of abstraction for this

So, that's our thoughts, maybe someone or one of us or maybe even *you*
will be inspired to start from here?



I don't want to make promises (pun on punpose) but I find this proposal 
really interesting.

Re: New logo and website design proposal

[Amirouche Boubekki]

Le 2015-10-10 00:24, Luis Felipe López Acevedo a écrit :

On 2015-09-23 11:18, Luis Felipe López Acevedo wrote:


With the feedback so far, I'm planning to make a revision of the
mockup this weekend to include the suggested changes.



Hi,

I just finished an implementation of the new website. You can grab a
copy of the built site from here:

  
https://bitbucket.org/sirgazil/dnd/downloads/guile-website-20151009.tar.gz


To try it out:

   $ cd path/to/guile-website-mmdd
   $ python3 -m http.server# couldn't find a equivalent in 
Guile


Then visit the website at .



Le 2015-10-10 00:24, Luis Felipe López Acevedo a écrit :

On 2015-09-23 11:18, Luis Felipe López Acevedo wrote:


With the feedback so far, I'm planning to make a revision of the
mockup this weekend to include the suggested changes.



Hi,

I just finished an implementation of the new website. You can grab a
copy of the built site from here:

  
https://bitbucket.org/sirgazil/dnd/downloads/guile-website-20151009.tar.gz




It looks good! Maybe because I'm getting use to it ;)

More seriously, it always looked good. It doesn't look 'unsophisticated'
(what I called previously 'childish') at all over multiple pages. The
scheme wizards are well represented.

And it definitely makes Guile more welcoming.

I happy that everybody agree that this is the way forward for Guile 
community. I'm also happy to see more people interested in accessibility

and more people acknowledging "worse is better/more accessible".


Thanks everybody!


The source files are available in this provisional repository:

https://bitbucket.org/sirgazil/guile-website

All pages of the current website are migrated to the new style, except
for the following:

* News . I'm currently
linking to Savannah to display all news.
* Community . Should
we add a Community page and link to the main menu? Or do we use the
About page to list the contact info listed in the current Community
page?
* Cool Ideas . Could
these be added to Savannah task tracker instead?
* Graphics  I don't know
what to do with this one yet.

Some other things to do:

* Fetch news from Savannah for the latest news in the home page.
* Update illustration to remove reference to Lua.

This is an overview of the website source directory structure:

guile-website
├── README
└── website
├── apps <- This is how a website is extended:
Blog, PMS, Gallery, etc.
├── static   <- Name-spaced assets for the website 
apps.

├── resources.scm<- A list of all the resources of the
website to be built (HTML, RSS, etc.)
└── utils.scm<- Common variables, URL helpers, etc.

I didn't add the code I'm using for building/testing the website
because it's hideous, and you may want to write your own code for
building anyways (à la GuixSD).

I'm willing to change any silly things you see in the code, so don't
hesitate to ask :)


--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: New logo and website design proposal

[Amirouche Boubekki]

Le 2015-10-12 20:15, Luis Felipe López Acevedo a écrit :

On 2015-10-12 08:26, l...@gnu.org wrote:

Aleix Conchillo Flaqué  skribis:

I have a suggestion: would it be possible to show only one code 
sample in
the Code examples section? The code sample would periodically switch 
to a
new one smoothly and also the user should be able to jump from sample 
to
sample by clicking some arrows. Something like racket-lang (but much 
nicer
with your design!). Also, it would save some space. The code could be 
on
the left and the explanation on the right side with the title on top 
of the

explanation.


I agree that it would be nice, if possible.

OTOH the current web site has the advantage of being JavaScript-free.

WDYT, Felipe?



I'm fine with Aleix suggestion. And it can be done so that the
examples are shown in a descent way without the effects for people who
don't use JavaScript. But I'd pass on the implementation because I
don't like much using JavaScript :)


I can do it, if nobody shims in... When I am finished with the tutorial.

Any comment is welcome.

First I tried to follow hylang tutorial [0], but I found it too short. I 
really like clojure koans [1], but there is not guilescript. I did not 
do much research, in particular there might be interesting stuff to use 
in "how to design programs" [2].


So I settled on 4 parts tutorial split into sections, but not deeper, 
where the first paragraph introduce a concept and the second paragraph 
apply the concept in the general context of guilers doing a hackfest. I 
did not talk about macros, I will think about a way to spread the 
different macros in all the parts.


Here is the plan:

# Learn Scheme Guile

## Getting started [3]

The main illustration is a breakfast box.

- call procedure
- define a variable
- how to create list
- how to create pairs
- how to create scheme dictionary aka. assoc
- how to define a procedure
- how to to create new list with initial list and a procedure using map

## Foward [4]

This continue with breakfast box and explain records with a mini todo 
list app.


- how to define a more complex procedure
- how to define variable inside procedures
- a short hand to make recursive procedures ie. named `let`
- how to define mutable datastructures ie. records

## Beyond [not written yet]

I don't know yet which example to use.

- goops
- values/receive
- apply
- compose

## Reference

A summary of all the syntax and procedure of the tutorial. This should 
be similar to hylang tutorial.



[0] 
http://docs.hylang.org/en/latest/tutorial.html#basic-intro-to-lisp-for-pythonistas

[1] http://clojurescriptkoans.com/#equality/2
[2] http://www.htdp.org/
[3] http://hypermove.net/learn-scheme-guile-basics.html
[4] http://hypermove.net/learn-scheme-guile-forward.html

Re: Gambda Logo

[Amirouche Boubekki]

Le 2015-10-13 11:37, Thorsten Wilms a écrit :

Hi!

Here's another and final logo proposal in 4 variations (attached).

It's all about the symbol, I simply picked the color and font from the
website demo, just for a first shot at a lockup.


To be honest, i like them. Keeping the lambda is interesting.

Re: Ideas for a Guile tutorial to go with the new site

[Amirouche Boubekki]

Le 2015-10-18 20:44, Luis Felipe López Acevedo a écrit :

On 2015-10-18 10:41, Christopher Allan Webber wrote:

Hello!

So I've been thinking a bit about what a friendly "intro" tutorial 
would
look like that could fit with the direction the site is heading.  I 
came

up with some ideas I wanted to capture before I totally lost them.

I think we can keep with the kids playing with robot toys idea and
stretch that a bit.  Here's a brief outline:


 - Intro
 - Getting up and running
   (picture of one of those robots with a wind-up-toy-key on its 
back?)

   + How to start guile from the command line, add readline support
   + Editor setup, simple

 Details how to write some scheme with any editor, maybe makes a
 free software editor recommendation of something simple that's 
not

 too hard to get going with Scheme.  Would GEdit work?

 Shows how to write a file and then import it at the REPL,
 then reload it as you add things.

 Teaches the basic idea of writing code in a file + playing at the 
REPL.


   + Editor setup, advanced: Emacs + Geiser

 Explains that this is the advanced, but recommended version.
 It takes some time to get started with if you are not already an
 emacs user, but you may want to come back to it later.  Explains
 how to set things up.

 - First steps

   Much like The Little Schemer uses food as variable names, I think
   it's a good idea to stick with abstract fun concepts.  Here, I 
think
   it would be great to continue along with the "Guile is a 
playground,

   come play!" idea by using toys as variable names, and defining
   procedures that evoke nostalgia for older programmers and sound
   playful for younger ones.

   Some ideas:
 + could use building lists as putting toys in and out of a toy
   chest

   (define toy-chest '(robot teddy-bear doll-with-comb 
toy-soldier))


 + could have a simple-bake-oven set of procedures that takes
   arguments like flavor and dessert-type:

 #> (define (simple-bake-oven flavor dessert-type)
  (format #f "Yum!  You made a tasty ~a flavored ~a!"
  flavor dessert-type))
 #> (simple-bake-oven "banana" "cake")
 $20 = "Yum!  You made a tasty banana flavored cake!"

   and then we can increase the advanced features a bit:

 #> (define* (fancy-bake-oven flavor dessert-type
 #:optional topping)
  (if topping
  (format #f "Yum!  You made a tasty ~a flavored ~a
covered in ~a!"
  flavor dessert-type topping)
  (format #f "Yum!  You made a tasty ~a flavored ~a!"
  flavor dessert-type)))
 #> (fancy-bake-oven "mint" "ice cream" "chocolate fudge")
 $21 = "Yum!  You made a tasty mint flavored ice cream covered
in chocolate fudge!"

   Yes... the fancy bake oven version is so fancy it can even bake
   ice cream! ;)

 + Introduce modules as extensions for our robots.

I'm sure there are other things!  But I think a tutorial in this style
might be fun, and would fit the site well.  And the desire for a good
tutorial has been expressed many times.

What do others think?


Absolutely. This is in line with my thoughts about the intro tutorial.


To the contrary I think it's not a good idea to start upfront the 
tutorial with which editor should be used is a good way to loose half of 
the readers, because they will feel more uncomfortable and not up to the 
task. To be useful emacs requires one 'Getting Started' tutorial in 
itself. Or anykind of setup for that matter. The tutorial should go as 
quickly as possible to the matter and start with coding.


I started a tutorial at http://hypermove.net/. I don't introduce 
readline until the user knows what the REPL is. Part 1 is all done in 
REPL. I subtly introduce emacs as a good choice for an editor in part 2 
which is done in an editor. But doesn't enforce it.


I don't think my tutorial is perfect, far away that idea is. I'll 
rewrite the tutorial to avoid any allusion to the Earth Software System 
and instead use The Little Lost Robot as storyline.


The "Getting up and running" section looks like a good part to start 
materializing the tutorial.


I sent a previous mail to the ML describing my work. Again feel free to 
comment.

Re: Reading data from a file descriptor

[Amirouche Boubekki]

On 2015-11-13 21:41, Jan Synáček wrote:

On Fri, Nov 13, 2015 at 4:51 PM, 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.

Regards,
  Mark



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.

In Python the socket.recv method returns bytestring but still you have 
to parse
to bytestring to make sure the delimiter is not in the middle of the 
string. What
I mean is that in theory you might socket.recv the end of an application 
level message

and the beginning of another using the same call.

Otherwise said, the only thing that could make sens for a (recv) 
procedure is
to return the full content of the inbound network buffer for the given 
socket

as a bytevector but it will still require work to to make things work...



 The good thing about using read-string!/partial is,
that I don't have to specify how many bytes I want to read and it does
the right thing. If you point me to a better direction, I'll be
grateful. I came up with:

(for-each (lambda (fd)
(let* ((buf (make-string 4096)))
  (read-string!/partial buf (fdes->inport fd))
  (format #t "fd[~a]: ~a" fd buf) (newline)))
  fds)


Have a look at the implementation. IMO the solution is to build a loop 
with

(read-char) [1] looking for the *end char* to stop the loop.

[1] 
https://www.gnu.org/software/guile/manual/html_node/Reading.html#index-read_002dchar

Re: Guile-Clutter 1.12.2 released

[Amirouche Boubekki]

Le 2015-11-19 05:43, David Pirotte a écrit :

Hello,

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



Thanks David and the team for making GNOME Clutter available in GNU 
Guile. I really like Clutter (and clutter but that's a story for another 
time). I find that it's the correct level of abstraction for doing 
modern applications. It has no high level widgets but provides a 
flexible API to create your own. I really like it.


Among other things it has bezier lines drawing support via cairo [1], 
bundles a few OpenGL effects like blur or "page turn" and an animations 
helpers. This might sound like toy features, but IMO those pave the 
ground for new GUI paradigms.


Soon more FUI in the wild ;)

Have a look at: http://www.nongnu.org/grip/examples.html

Thanks again!!

[1] I was under the impression that cogl support this natively but it 
seems like the  support did not land upstream yet.





* 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 

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

[Amirouche Boubekki]

Héllo,


I've done some exploration regarding this topic; I think it might of 
interest or it's very naive.


It goes like this:

``` scheme

(define (loop-run-forever)
  (while #true
(call-with-prompt 'loop
  loop-run-once
  (lambda (cc callback) (callback cc)

```

`loop-run-once` does the `do-select` thing and call scheduled task. Then 
we only need to wrap blocking calls inside `abort-to-prompt`, here an 
example with `read`:


```
(define (read/ sock)
  (abort-to-prompt 'loop (lambda (cc)
   (loop-add-reader sock (lambda () (cc (read 
sock)))

```

`loop-add-reader` is procedure that register a callback against `select` 
to restart the computation where it was left it's equivalent to 
`port-request-read` machinery.



I attached an example server, the client is vanilla imperative code. 
Also, it doesn't implement exception propagation.



I don't understand the point of %8sync macro when all blocking calls can 
be expressed directly in terms of abort-to-prompt.



HTH
(setlocale LC_ALL "")

(define sock (socket PF_INET SOCK_STREAM 0))
(connect sock AF_INET INADDR_LOOPBACK 12345)

(pk sock)
(write "héllo world" sock)
(write "you are free" sock)
(close sock)
(define-module (plain))

(use-modules (srfi srfi-9))  ;; records
(use-modules (srfi srfi-9 gnu))  ;; set-record-type-printer! and set-field

;;;
;;; plain records
;;;
;;
;; macro to quickly define records
;;
;;
;; Usage:
;;
;;   (define-record-type  seats wheels)
;;   (define smart (make-abc 2 4))
;;   (car-seats smart) ;; => 2
;;
;; Mutation is not done in place, via set-field or set-fields eg.:
;;
;; (define smart-for-4 (set-field smart (seats) 4))
;; 

(define-syntax define-record-type*
  (lambda (x)
(define (%id-name name) (string->symbol (string-drop (string-drop-right 
(symbol->string name) 1) 1)))
(define (id-name ctx name)
  (datum->syntax ctx (%id-name (syntax->datum name
(define (id-append ctx . syms)
  (datum->syntax ctx (apply symbol-append (map syntax->datum syms
(syntax-case x ()
  ((_ rname field ...)
   (and (identifier? #'rname) (and-map identifier? #'(field ...)))
   (with-syntax ((cons (id-append #'rname #'make- (id-name #'rname 
#'rname)))
 (pred (id-append #'rname (id-name #'rname #'rname) #'?))
 ((getter ...) (map (lambda (f)
  (id-append f (id-name #'rname 
#'rname) #'- f))
#'(field ...
 #'(define-record-type rname
 (cons field ...)
 pred
 (field getter)
 ...))

(export define-record-type*)
(re-export set-record-type-printer!)
(re-export set-field)
(use-modules (rnrs bytevectors))
(use-modules (ice-9 rdelim))


(define sock (socket PF_INET SOCK_STREAM 0))
(bind sock (make-socket-address AF_INET INADDR_ANY 12345))
(listen sock 128)
(define inbound (accept sock))

(define-public (string->scm string)
  (call-with-input-string string
(lambda (port)
  (read port

(define (read-message port)
  (let next ((char (read-char port))
 (out '()))
(if (eq? char #\0)
(list->string (reverse out))
(next (read-char port) (cons char out)

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

[Amirouche Boubekki]

Le 2015-12-04 03:15, Amirouche Boubekki a écrit :


```
(define (read/ sock)
  (abort-to-prompt 'loop (lambda (cc)
   (loop-add-reader sock (lambda () (cc (read
sock)))
```


This is mistake, it should be a macro, so that, I think, even if the 
callstack displays the `loop-run-forever` and `loop-run-once` jazz, it 
still appears that the error happens where the blocking/async macro 
read/ was used.

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

[Amirouche Boubekki]

Le 2015-12-04 03:47, Amirouche Boubekki a écrit :


   Le 2015-12-04 03:15, Amirouche Boubekki a écrit :

   ```
   (define (read/ sock)
 (abort-to-prompt 'loop (lambda (cc)
  (loop-add-reader sock (lambda () (cc 
(read

   sock)))
   ```



   This is a mistake, it *must* be a macro



This will only help with debugging but not catching error and
dealing with them at runtime ie. it doesn't propagate the exception
but it can be done and requires a form similar to 
propagate-%async-exceptions.


TBH the code still seems complex maybe complicated. FWIW here is
what I think right now. Be warned that everything should be taken
with a grain of salt.

* Agenda

** The canonical callback based event loop API is not visible enough

It should be obvious coming from outside Guile world what/where
is the event loop. As such, agenda doesn't seem like a good name.

** Agenda has both `schedule` and `queue`

For a proof of concept, queue/schedule is not useful to demonstrate
the purpose of eightsync as it's an optimization.

** `(current-agenda-prompt)`

No need to throw, there should always be a current agenda.

* 

Schedule should be in its own file. Also, in place of:

```
(define-record-type 
  (make-schedule-intern segments)
  schedule?
  (segments schedule-segments set-schedule-segments!))
```

I prefer:

```
(define-record-type 
  (%make-schedule segments)
  schedule?
  (segments schedule-segments-ref schedule-segments-set!))
```

Use of `*-ref` and `*-set!`.

Or better: `(define-record-type*  segments)` (actually I
think this macro should be in Guile, since it much easier to
introduce  to new devs).

** `time` procedures have equivalent in Guile

*** `tdelta` is not useful.

* ``

** `run-it`

It's sound like it's a `(loop-call-soon callback #:optional (delay 0))`
procedure.

Instead it's a `(make-run-request proc #:optional time)`.

It's never used.

I'd rather to use a `delay`, and let the devs compute the correct delay,
when they wants to run something at an absolute time to limit the
proliferation of sugar procedure in the library.

*** `(wrap e ...)` and `(wrap-apply body)`

I'm pretty sure that `wrap` can be written using `wrap-apply`. This 
looks

suspicious for several reasons.

First it looks like a delayed call, so why not use force/delay.

Also wrap-apply is never used.

I think it's not schemey to hide a lambda this way, especially 
`wrap-apply`

which breaks lexical scope.

`wrap` is used with `(make-run-request proc time)` in `run`, `run-at`
and `run-delay`, e.g.:

```
(define-syntax-rule (%run-delay body ... delay-time)
  (%run-at body ... (tdelta delay-time)))
```

Again, `run` and others are building a datastructure not registering
a callback so the naming is not good.

* `(make-port-request port #:key read write except)`

In `async.scm` I don't need to create a datastructure to subscribe to 
select events.


** `port-request` defined at L452 is never used

* %8sync

This is the main macro, here is it's definition:

```
(define-syntax-rule (%8sync async-request)
  (propagate-%async-exceptions
   (abort-to-prompt (current-agenda-prompt) async-request)))
```

I'm wondering whether (current-agenda-prompt) is useful.
I think the code will abort to the prompt of the current dynamic
context. So except if there is multiple agenda in the same thread,
it's not useful.


It's comparable to the way I define blocking procedures in async.scm

```
(define-public (read/ sock)
  (abort-to-prompt 'loop async-request
```

where `async-request` is in `async.scm`:

```
(lambda (cc) (loop-add-reader sock (lambda () (cc (read sock)
```

It's the way `async.scm` does blocking calls (and *only* blocking 
calls).
`read/` and its `async-request` is missing catch around `read` and 
something

like `propagate-%async-exceptions`.

8sync has two types of async-request:

** run-requests, which implements kind of a *coroutine* behavior.

It pause the execution of the current procedure and schedule
the provided lambda to be run soonish; This doesn't exists in
async.scm. The only thing useful this can do, is break the callstack
to allow deeper recursion.

** port-requests, which implements imperative asynchronous calls of 
blocking operations


** %8sync usage example

```
(%8sync (%run (handle-line socket ready-line username)))
```

Where %run is a macro that implements exception catch,
complementary to `propagate-%async-exceptions`.

** Last note

This doesn't look nice:

```
(define (ports->procs ports port-map)
  (lambda (initial-procs)
(fold
 (lambda (port prev)
   (cons (lambda ()
   ((hash-ref port-map port) port))
 prev))
 initial-procs
 ports)))
```

then:

```
   ((compose (ports->procs
  read-ports
  (agenda-read-port-map agen

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

[Amirouche Boubekki]

Le 2015-12-05 15:58, Christopher Allan Webber a écrit :

Amirouche Boubekki writes:


* %8sync

This is the main macro, here is it's definition:

```
(define-syntax-rule (%8sync async-request)
   (propagate-%async-exceptions
(abort-to-prompt (current-agenda-prompt) async-request)))
```

I'm wondering whether (current-agenda-prompt) is useful.
I think the code will abort to the prompt of the current dynamic
context. So except if there is multiple agenda in the same thread,
it's not useful.


You're right that this is the context in which this becomes useful.  I
might have composed agendas at some point.  I'm not sure.


It's comparable to the way I define blocking procedures in async.scm

```
(define-public (read/ sock)
   (abort-to-prompt 'loop async-request
```


Right, that means that 'loop is always for "the agenda", and there will
always be one.


where `async-request` is in `async.scm`:

```
(lambda (cc) (loop-add-reader sock (lambda () (cc (read sock)
```

It's the way `async.scm` does blocking calls (and *only* blocking
calls).  `read/` and its `async-request` is missing catch around
`read` and something like `propagate-%async-exceptions`.


8sync doesn't block though.  Its use of select means you only need to
get information once it's available.

The code you have here will block other code that is available to run
while it's waiting for code.


I wrote "blocking" code in the sens that it is a call that blocks
when the port is not ready. In this case `read` is called
when the port is ready via the lambda registered as callback
with `loop-add-reader` which is called via select only when the port is 
ready.


It's similar to 8sync code, except there is not later dispatch like
in setup-async-request. Instead it's directly registers in the handler
of call-with-prompt.

The argument of the prompt is:


(lambda (cc) (loop-add-reader sock
   (lambda ()
 (cc (read sock)


Which is called by the handle of call-with-prompt as callback:

```
(call-with-prompt 'loop
  loop-run-once
  (lambda (cc callback) (callback cc)
```

Here cc is the continuation of the prompt handler.

tldr: There is certain number of proc that call each other
  in some order for the better good :)



8sync has two types of async-request:

** run-requests, which implements kind of a *coroutine* behavior.

It pause the execution of the current procedure and schedule
the provided lambda to be run soonish; This doesn't exists in
async.scm. The only thing useful this can do, is break the callstack
to allow deeper recursion.


That's not true.  See the problems of "callback hell" people get into 
in

node.js.  8sync mitigates this.


Yes, but this must be mitigated only for calls that would block without
select.


As for the callback stack, it does get broken that's true... but that's
why 8sync gives you copies of all the stacks that were recursively
called as it walks back through its ~futures upon some exception.


This is nice.



I realize I disagreed with a lot of what you said, but a lot of the
things you challenged are intentional designs in 8sync, not accidents.

I do appreciate the feedback though, it helped me clarify some of the
design decisions in 8sync, which will be useful for docs-writing!



Thanks for taking the time to respond it helps better understand.

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

[Amirouche Boubekki]

Le 2015-12-05 15:58, Christopher Allan Webber a écrit :

Amirouche Boubekki writes:


*** `tdelta` is not useful.


tdelta is used so the the agenda knows to put it a future time from the
current execution of the agenda.



I wanted to write that it's only a shorcut:

```
(define tdelta make-time-delta)
```

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

[Amirouche Boubekki]

Le 2015-12-05 15:58, Christopher Allan Webber a écrit :

Amirouche Boubekki writes:


* Agenda

** The canonical callback based event loop API is not visible enough

It should be obvious coming from outside Guile world what/where
is the event loop. As such, agenda doesn't seem like a good name.


"Agenda" is not a unique name for this.  That's what SICP uses, that's
what Sly uses.



Ok with agenda, maybe that's a native idiom I don't get.

Still I think that the canonical event loop API should be implemented
in an obvious way. If otherwise, it should be clear why it's not done 
that

way. In my implementation I don't rely on intermediate data-structures
and it's obvious imho:

- how to run procedure in the loop asap
- how to register a callback to run when a port is ready
- how to pause a procedure until a port is ready

And afaik, it doesn't forbid functional programming. The only mutations
that happen, happen inside the loop primitives to register and run 
select

callbacks.




** Agenda has both `schedule` and `queue`

For a proof of concept, queue/schedule is not useful to demonstrate
the purpose of eightsync as it's an optimization.


It's no mere optimization.  "schedule" is future events that haven't
been queued; it's only for time-delayed events.  The queue is for 
things

that must be done immediately.


Sure it is an optimisation. Only `schedule` is needed to implemented
both "call later" and "call asap" which is "call later" with a delay of 
0.

Re: Guix as a Guile package manager

[Amirouche Boubekki]

Héllo,

On 2016-01-09 11:35, Fabio Pesari wrote:

Package managers have been immensely successful in increasing the
popularity of programming languages - think about Perl's CPAN or Ruby's
Gem. But Guile doesn't a package manager, and that in my opinion slows
down its adoption.


There is a package manager https://github.com/ijp/guildhall with a 
package

repository with automatic package publishing without review.


The Guix repos distribute a lot of useful Guile libraries (like
guile-json or guile-opengl) which can't be found on most distro
repositories and it already provides Guile APIs and package management
capabilities...


my question is, can Guix be forked into a full-blown Guile package 
manager

like gem from Ruby?


I'm not a core developer, but I don't think it makes sens to fork. Most
if not all features of guix are required by language package manager.
This includes virtualenv since guix can do them via 'guix environment'.

I think what could/should/must be done is settle on guix being the 
package
manager of Guile *and* document how to create package recipes for pure 
and
non-pure guile non autotools modules. Maybe declare guix the optional 
official

package manager something like that..


I know that an argument could be made that Guix can already be used in
this way, but there are many Scheme coders who don't need a system-wide
package manager


This is not an issue since IIRC you can install guix as a user. Not sure
what the status of this mode of operation is.

Also binary installation of guix is trivial, so it's not like something
that can forbid people using it. Having guix in other distros would be
of great help too.


and would rather use a program that can manage Guile
packages under a user root like ~/.guile and allow them to easily
distribute their packages


Again there is guildhall even if it doesn't have the polish (nice web 
ui)

of pypi or cpan, it's said to work.


(something like Python's virtualenvs would also be useful).


This is supported by guix.


Perhaps some of the Guix code can be moved to a library, so that both
the Guix and the Guile package manager binaries can reuse the same 
code.

Moving Guix' core to a library would also facilitate its inclusion in
things like PackageKit, as well as make it easier to create front-ends.

I'm not a package management expert so I'm not sure this idea is
feasible but I would really like Guile to become more
popular, and this I think would be a step in the right direction.


To repeat myself, I think we need more guidance and incentive on how to
include guile modules that are not autotools ready. For my usecase and a
lot of other modules I don't think it makes sens to have autotools if 
you
have guix. People who happen to not want to use/install guix, can 
resolve

dependencies themself and I don't see how autotools help anyway.

Somewhat related: even if I never saw a package rejected in guix, I 
think
most contributors have some expectations regarding the quality of 
packages
included in guix *main* repository. Otherwise said, I don't mind pushing 
a

alpha software or snippet on pypi, but this is not the case with guix.

So maybe, it will be nice to have a guix repository dedicated to guile
modules where the expectations will much lower and where guilers
can freely share their small and not so small contributions.

Also, this will be a visible example of how to extend guix with third 
party
package repository which is a significant asset is some commercial 
situations.


--
Amirouche ~ amz3 ~ http://www.hypermove.net

Re: Guix as a Guile package manager

[Amirouche Boubekki]

On 2016-01-09 15:06, Fabio Pesari wrote:

On 01/09/2016 02:05 PM, Amirouche Boubekki wrote:

There is a package manager https://github.com/ijp/guildhall with a
package
repository with automatic package publishing without review.


Asking users to install a separate package manager might work in some
cases (Leiningen, Composer) but it usually leads to fragmentation and
confusion (as it was the case with many Lisps, especially CLs).



That's one of the reason why I advocate for guix as package manager of 
guile.


I'm not a core developer, but I don't think it makes sens to fork. 
Most

if not all features of guix are required by language package manager.
This includes virtualenv since guix can do them via 'guix 
environment'.


I called for a fork because having Guix as both a general-purpose
package manager and a Guile-specific package manager is very confusing
and doesn't follow the UNIX philosophy.



Can you explain what a Guile specific fork of guix will bring over guix?


User should be able to upload packages but each package should be
carefully reviewed (possibly by the community itself).


This is not how pypi works for instance.


Somewhat related: even if I never saw a package rejected in guix, I
think
most contributors have some expectations regarding the quality of
packages
included in guix *main* repository. Otherwise said, I don't mind 
pushing

a
alpha software or snippet on pypi, but this is not the case with guix.

So maybe, it will be nice to have a guix repository dedicated to guile
modules where the expectations will much lower and where guilers
can freely share their small and not so small contributions.


I agree with you that users should be able to submit packages easily -
that's why I called for a fork, so that the standards for package
inclusion can be much lower (except for freedom, which is imperative)
and the Guile packages are by default separated from all other 
software.


This could also be achieved with a separate repo (like "guile-contrib"
or something along these lines) for Guix, sure, but I'd still like a
separate repo with a separate database and site, so that important
things like user ratings can be implemented independently from the 
other

Guix repos.



I just checked the documentation [1] and it's possible to have third 
party

repositories but the policy is to not fork the effort and package guile
softwares in guix.

[1] 
https://www.gnu.org/software/guix/manual/guix.html#index-GUIX_005fPACKAGE_005fPATH



Also, this will be a visible example of how to extend guix with third
party
package repository which is a significant asset is some commercial
situations.


I'm not against the idea of third party package repositories (I see no
reason why this functionality should not be implemented) but Guix 
should

focus on having every decent quality free program in its repositories,
so that people are not encouraged to use third-party repos.

I find it self-defeating that in distros like Parabola (or upstream,
Arch), fully functional and semi-popular programs like OpenArena,
pngquant and yuicompressor can only be found in the user repository 
(the

AUR), which also distribute proprietary software.

If people are encouraged to include third-party repos, freedom goes out
of the window pretty easily, so the official repositories should be as
complete as possible (I know it's easier said than done, but it should
be much easier for Guix compared to other package managers).


My question is: what must do a guix fork that guix doesn't have already?

Re: Guile Module Documentation

[Amirouche Boubekki]

Hi Alex!

Le 2016-01-10 01:02, Alex Weiss a écrit :

I've written a couple of guile modules. What is the best way to
generate documentation using the procedures docstrings?



I don't know such tool in Guile. The current pratice is to create
the documentation from scratch ie. without auto-generation.

I am very interested to work a such a tool. Using a markdown library
I wrote earlier, we might be able to create something similar to
https://github.com/dotmpe/mkdoc

I've done some exploratory work. Here is what I've got:


  ;; retrieve module by name
  (define srfi1 (resolve-module '(srfi srfi-1)))

  ;; go over public interface and print procedure name and documentation
  (module-for-each (lambda (name variable) (when (procedure? 
(variable-ref variable)) (pk name (procedure-documentation (variable-ref 
variable) srfi1)


Starting with that, one can create an html, txt or whatever of a module.

What about docdog as the name of the program? :)

HTH,

Amirouche aka amz3

Re: [ann] fibers 0.1.0

[Amirouche Boubekki]

(Resent the mail to the mailing list)

On 2016-07-04 10:34, Andy Wingo wrote:

Hi all,

I just released Fibers 0.1.0.  Fibers is an experimental facility for
Erlang-like concurrency in Guile 2.2.

As an example, here is a ping server written in Fibers:

(define (socket-loop socket store)
  (let loop ()
(match (accept socket)
  ((client . addr)
   (set-nonblocking! client)
   ;; Disable Nagle's algorithm.  We buffer ourselves.
   (setsockopt client IPPROTO_TCP TCP_NODELAY 0)
   (spawn (lambda () (client-loop client addr store)))
   (loop)

As you can see it's straightforward in style.  For each client that
comes in, we spawn a fiber to handle the client.  Here's the fiber that
handles the client:

(define (client-loop port addr store)
  (let loop ()
(let ((line (read-line port)))
  (cond
   ((eof-object? line)
(close-port port))
   (else
(put-string port line)
(put-char port #\newline)
(force-output port)
(loop))



It's ok to use several put-* procedure instead of one? For example:

```
(put-string port "abc")
```

is not better than:

```
(put-char port #\a)
(put-char port #\b)
(put-char port #\c)
```

Otherwise said is there still buffering when using non blocking sockets?

Does (web client) http-get work vanilla with fiber?


Thanks for the hard work!

Re: [PATCH 18/25] write documentation for (system foreign declarative)

[Amirouche Boubekki]

On 2016-07-18 17:17, kact...@gnu.org wrote:

From: Dmitry Bogatov 

Document '' record type and 'define-foreign-type' 
procedure.


Can you compare this 'foreign-type' library with scheme-bytestructures 
[0]. How

can both libraries help each other? Work hand in hand?

[0] https://github.com/TaylanUB/scheme-bytestructures

Tell me if I'm wrong but it looks like you have to define validate, 
encode
and decode proc for every single structure with no helpers. It seems to 
me
that it's some kind of framework for doing validation of static typed 
procedures

which also handles automatic conversion between C land and scheme land.

Honestly this is not the kind of library I would use, I seldom do input 
validation
when the client of my program is a developer. Maybe I'm wrong but IMO 
dynamic languages

help that.

Also based on my small experience of ffi, there is not much conversion 
to do between
scheme and C and what's best is to avoid any copy which is what does 
scheme-bytestructures.


WDYT?


Thanks!


--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: Experimental JIT for Guile (???!)

[Amirouche Boubekki]

On 2016-09-28 09:45, Christopher Allan Webber wrote:

Oh great to hear this extra backstory!

Atsuro, welcome to the Guile community... I'd love to see collaboration
between you and Guile core!


+1



Nala Ginrut writes:


Well, there's interesting story behind it.
Few days ago this new JIT backend named Nash was introduced in 
ICFP2016 (scheme
workshop), I and Ludo are lecturers too. When I first saw the topic, I 
looked
back to Ludo and thought "oh you guys are making a new weapon secretly 
huh?"
I thought this work must be encouraged and helped by Ludo or Wingo or 
Mark, but
finally I realized that I was wrong, the authorAtsuro Hoshino was 
hacking JIT

backend for Guile all by himself. Ludo got surprised too.
I have to say, lone hero pattern is not recommended for a community 
project, but
anyway he did it bravely and the result seems good according to the 
paper.
After the meeting, I and Ludo tried to convince him to get involved 
into our

community to get more help and feedback.

I CC him here, and it depends on him whether/when to introduce more.

I think this project is just amazing, really! Thank you Hoshino! ;-)

Best regards.

On Tue, 2016-09-27 at 12:30 -0500, Christopher Allan Webber wrote:

Earlier today, David Thompson pointed to this paper in #guix on
freenode:

 
https://github.com/8c6794b6/guile-tjit-documentation/raw/master/nash.pdf


And here seems to be the source:

 https://github.com/8c6794b6/guile-tjit

I'm not informed enough to judge this myself, but this seems like a
reasonable start-of-implementation of the ideas expressed here:

 
http://wingolog.org/archives/2015/11/03/two-paths-one-peak-a-view-from-below

-on-high-performance-language-implementations

It mentions hot loops and compiling to native code... that's about as
much as I can tell myself about it being on track.But it seems pretty
cool, especially for something shooting onto the radar seemingly out 
of

nowhere!

Anyone more informed have thoughts? :)
- Chris



--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: FOSDEM 2017 Schedule is there! Change of schedule!:wq

[Amirouche Boubekki]

On 2017-01-03 15:46, Pjotr Prins wrote:

In other good news: we have a full day instead of a half day!

  https://fosdem.org/2017/schedule/track/gnu_guile/

All talks have more time and we can still add a few talks. The final
schedule has to be ready by this Saturday.


Great news :)


So, if anyone has ideas, please shoot. Also note it is now on Sunday.


None on my side.



Pj.

On Mon, Dec 19, 2016 at 08:37:44AM +0100, Alex Sassmannshausen wrote:


Pjotr Prins writes:

> Check it out K.3.201 - looks awesome!
>
> https://fosdem.org/2017/schedule/day/saturday/

Indeed, most excellent!  Looking forward to this greatly :-)

Alex



--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: FOSDEM social dinner

[Amirouche Boubekki]

On 2017-01-09 14:37, Catonano wrote:

2017-01-06 10:46 GMT+01:00 Alex Sassmannshausen
:


Hello,

Guile has a dev room at FOSDEM this year — for a whole day! The
dev
room will be on Sunday.

Whilst organising it, we had the idea that it would be fun to have a
Guile/Guix user & dev dinner on the Saturday evening. I'm hereby
officially opening registration for that :-D

I have not chosen a restaurant yet, but it will be something that
provides a varietary of dietary options (omnivore, veggie, vegan).
If
you are interested in coming along, just drop me a line to confirm.

So — who's in for Guile social dinner on Saturday 4 February 2017
in
Brussels?

Best wishes,

Alex


It seems that  I will manage to be there, too.

So count me in !

I'm an omnivore !


Me too.

Re: FOSDEM 2017 audio/video volunteers needed

[Amirouche Boubekki]

On 2017-01-11 09:05, Ricardo Wurmus wrote:

Pjotr Prins  writes:


On Tue, Jan 10, 2017 at 04:02:32AM +, Pjotr Prins wrote:

Hi all,

FOSDEM provides live streaming of talks and archiving. We need
volunteers to man the FOSS setup that handles the camera and mike.
Ideally two people who expect to be in the room all day :). It is
mostly automated and does not require special skills.


No response. We need help! Two people can take turns over the day.
Please volunteer, it is important we capture all talks.


I could do some of it, but I’m also giving talks, so we need at least
one more person to help out.


I hope I will be up to the task; count me in.

Thread 1 "guile" received signal SIGPWR, Power fail/restart.

[Amirouche Boubekki]

I have a guile crash that I can reproduce all the time so far that says:

  Thread 1 "guile" received signal SIGPWR, Power fail/restart.

Before the crash I see things like that when running with guile with 
gdb:


  [Thread 0x7fffe3fff700 (LWP 24262) exited]
  [New Thread 0x7fffea89e700 (LWP 24265)]
  [Thread 0x7fffea89e700 (LWP 24265) exited]
  [New Thread 0x7fffe3fff700 (LWP 24266)]

Here is the core of the crash: http://hyperdev.fr/static/c3b2-core-2.gz

I use guile-2.2.3 from guix.

To reproduce the bug you need guix:

  git clone git://gnunet.org/gnunet-guile2.git

Then install gnunet:

  guix package -f guix.scm

And guile-wiredtiger:

  guix package -i guile-wiredtiger

Then compile the gnunet-guile with:

  ./bootstrap && ./configure && make

You need to run gnunet services, for that do the following:

  mkdir /tmp/gnunet/p2
  gnunet-arm -c etc/p2.conf -s

To reproduce the bug, you need to go inside prototypes/c3b2 directory
and start a guile REPL:

  cd prototypes/c3b2
  GUILE_LOAD_PATH=`pwd` ../../pre-inst-env gdb guile

In the Guile REPL type the following:

  (use-modules (wiredtiger wiredtiger) (wiredtiger feature-space) 
(wiredtiger extra))

  (define run (@@ (web) run-discovery))
  (with-env (env-open* "wt" (list *feature-space*) 
"create,log=(enabled=true)")

   (run "../../etc/p2.conf"))

Re: Thread 1 "guile" received signal SIGPWR, Power fail/restart.

[Amirouche Boubekki]

On 2018-01-20 20:32, Amirouche Boubekki wrote:
I have a guile crash that I can reproduce all the time so far that 
says:


  Thread 1 "guile" received signal SIGPWR, Power fail/restart.



I can reproduce the bug without guile-wiredtiger, here is the backtrace:

[Thread 0x7fffed9f1700 (LWP 25673) exited]
[New Thread 0x7fffed9f1700 (LWP 25677)]
[Thread 0x7fffed9f1700 (LWP 25676) exited]

Thread 1 "guile" received signal SIGPWR, Power fail/restart.
0x7762b58f in pthread_cond_wait@@GLIBC_2.3.2 ()
   from 
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libpthread.so.0

(gdb) bt
#0  0x7762b58f in pthread_cond_wait@@GLIBC_2.3.2 ()
   from 
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libpthread.so.0

#1  0x77b63b4b in block_self ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#2  0x77b64030 in scm_timed_wait_condition_variable ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#3  0x77b680c9 in vm_debug_engine ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#4  0x77b752aa in scm_call_n ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#5  0x77af98d7 in scm_primitive_eval ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#6  0x77af9933 in scm_eval ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#7  0x77b449d0 in scm_shell ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#8  0x77b104ed in invoke_main_func ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#9  0x77af2cba in c_body ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#10 0x77b71c4d in vm_regular_engine ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#11 0x77b752aa in scm_call_n ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#12 0x77b644e6 in catch ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#13 0x77af32a0 in scm_i_with_continuation_barrier ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#14 0x77af3335 in scm_c_with_continuation_barrier ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#15 0x77b6310c in with_guile ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#16 0x77858732 in GC_call_with_stack_base ()
   from 
/gnu/store/fminmbril5qr836cj4ndq3b9d4q9iazv-libgc-7.6.0/lib/libgc.so.1

#17 0x77b63498 in scm_with_guile ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#18 0x77b10682 in scm_boot_guile ()
   from 
/gnu/store/0v539yjmdqhjm1xcpvndmagkgjz5fvh2-guile-2.2.2/lib/libguile-2.2.so.1

#19 0x00400b40 in main ()

The core is at http://hyperdev.fr/static/gnunet-guile-1.gz

To reproduce follow those steps



I use guile-2.2.3 from guix.

To reproduce the bug you need guix:

  git clone git://gnunet.org/gnunet-guile2.git

Then install gnunet:

  guix package -f guix.scm

Then compile the gnunet-guile with:

  ./bootstrap && ./configure && make

You need to run gnunet services, for that do the following:

  mkdir /tmp/gnunet/p2
  gnunet-arm -c etc/p2.conf -s



Then inside the gnunet-guile2 directory, run the following command:

  ./pre-inst-env guile test-sigpwr-fail.scm

Re: Thread 1 "guile" received signal SIGPWR, Power fail/restart.

[Amirouche Boubekki]

On 2018-01-20 20:48, Amirouche Boubekki wrote:

On 2018-01-20 20:32, Amirouche Boubekki wrote:
I have a guile crash that I can reproduce all the time so far that 
says:


  Thread 1 "guile" received signal SIGPWR, Power fail/restart.



[snip]



The core is at http://hyperdev.fr/static/gnunet-guile-1.gz

To reproduce follow those steps



I use guile-2.2.3 from guix.

To reproduce the bug you need guix:

  git clone git://gnunet.org/gnunet-guile2.git

Then install gnunet:

  guix package -f guix.scm

Then compile the gnunet-guile with:

  ./bootstrap && ./configure && make

You need to run gnunet services, for that do the following:

  mkdir /tmp/gnunet/p2
  gnunet-arm -c etc/p2.conf -s



Then inside the gnunet-guile2 directory, run the following command:

  ./pre-inst-env guile test-sigpwr-fail.scm


It seems like it's easier to reproduce with gdb.

Re: Thread 1 "guile" received signal SIGPWR, Power fail/restart.

[Amirouche Boubekki]

On 2018-01-21 05:45, Mark H Weaver wrote:

Amirouche Boubekki  writes:

I have a guile crash that I can reproduce all the time so far that 
says:


  Thread 1 "guile" received signal SIGPWR, Power fail/restart.


SIGPWR is used internally by libgc.  If I recall correctly, it's done 
to

suspend all threads within their signal handlers before performing a
garbage collection.  I can't seem to reproduce this on my system at the
moment, but as I recall, when this happened in GDB I would simply type
"c" to continue.  Does that work for you?

  Mark


Indeed:

Thread 1 "guile" received signal SIGPWR, Power fail/restart.
0x7762b58f in pthread_cond_wait@@GLIBC_2.3.2 () from 
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libpthread.so.0

(gdb) c
Continuing.

Thread 1 "guile" received signal SIGXCPU, CPU time limit exceeded.
0x75f386a6 in sigsuspend () from 
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libc.so.6

(gdb) c
Continuing.
[New Thread 0x7fffed9f1700 (LWP 27311)]
[Thread 0x7fffee1f2700 (LWP 27293) exited]

Thanks Mark!

bug#15228: making open-process public [Was: Re: Using open-input-output-pipe]

[Amirouche Boubekki]

Moving the conversation to guile-devel.

Can I have feedback on the patch I sent for #15228

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15228

On 2018-01-22 16:40, Edwin Watkeys wrote:

Hi all,

Thanks for all the input. Here a simple implementation that I've come 
up

with; I'm not sure it's bullet-proof. This scenario is so common—using
open-input-output-port on a Unix filter—that I would argue that the 
rw-port

design is broken; there really should be a way to close the input and
output independently. I checked back on the mailing list to the genesis 
of

this feature, and there didn't seem to be a lot of discussion of the
design. Something that's analogous to open-process, which returns 
multiple

values, or a hypothetical (call-with-port-input-output ARGS (lambda (in
out) ...)) would seem to be better. I'm going to try out these ideas 
when I

get a bit of spare time.

(define (generate-digest str)
  (call-with-values
  (lambda () (open-process OPEN_BOTH "shasum" "-a" "256"))
(lambda (read-port write-port pid)
  (write str write-port)
  (close-port write-port)
  (let ((line (read-line read-port)))
(close-port read-port)
(car (string-split line #\space))

Regards,
Edwin

On Mon, Jan 22, 2018 at 6:00 AM, Chris Vine  
wrote:



> On 01/21/2018 12:31 PM, Edwin Watkeys wrote:
>
> > Hi all,
> >
> > I'm trying to write a procedure that processes some input through a
> > unix utility. Open-input-output-pipe returns a bidirectional pipe
> > that I can both read and write to. However, there is no way that I
> > can figure out to tell the external process that input is complete,
> > as there is no way to determine the output port of the rw-port and
> > therefore no way to close it. Closing an rw-port closes both the
> > read and write ports.
> >
> > Open-input-output-port therefore seems useful for line-based
> > external processes but not for ones that function on the entirety
> > of user input e.g. wc and sort.
> >
> > Is my analysis of the situation roughly accurate?
> >
> > Regards,
> > Edwin

If you want fine-grained control, you might want to look at some of 
the

procedures in guile-lib's (os process) module, and in particular the
'run-with-pipe' procedure, or using its 'run-concurrently+' procedure
with guile's 'pipe' (the parent can block on its read pipe once it has
completed writing to the child until the child process closes the 
other
end of the pipe upon finishing, causing the parent to get an 
eof-object

provided it has itself previously closed the write end of its read
pipe).

Otherwise if you want to stick to guile proper, you may have to do it 
by
hand.  As 'pipe' gives you an input and output port for each pipe 
which

can be independently closed, you could use two of these with the
'dup2', 'fork' and 'execl' procedures.  It's tedious though.

Chris




--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: crashes with Fibers

[Amirouche Boubekki]

On 2018-06-29 11:20, Clément Lassieur wrote:

Hi,

I'm encountering a few crashes with Fibers that happen when I call
CALL-WITH-NEW-THREAD in a Fiber.  TEST4 crashes every time.  TEST5 
never

outputs, but it doesn't crash every time.

TEST1 is exactly like TEST5 except that I replace CALL-WITH-NEW-THREAD
with SPAWN-FIBER.

Is it a mistake from me or a Guile bug?  If it is a bug, do you know if
there are workarounds?


Sorry, I did not read the code. What are you trying to achieve?




Thank you,
Clément

(use-modules (fibers channels)
 (fibers))

;; good
(define (test1)
  (run-fibers
   (lambda ()
 (spawn-fiber
  (lambda ()
(let ((channel (make-channel)))
  (spawn-fiber
   (lambda ()
 (put-message channel "hello world")))
  (format #t "~a~%" (get-message channel))
   #:drain? #t))
⊣ hello world

;; good
(define (test2)
  (let ((channel (make-channel)))
(call-with-new-thread
 (lambda ()
   (put-message channel "hello world")))
(format #t "~a~%" (get-message channel
⊣ hello world
⇒ #t

;; good
(define (test3)
  (run-fibers
   (lambda ()
 (let ((channel (make-channel)))
   (call-with-new-thread
(lambda ()
  (put-message channel "hello world")))
   (format #t "~a~%" (get-message channel
   #:drain? #t))
⊣ hello world
⇒ #t

;; bad
(define (test4)
  (run-fibers
   (lambda ()
 (spawn-fiber
  (lambda ()
(letain' guile, an opinionated choic ((channel 
(make-channel)))

  (call-with-new-thread
   (lambda ()
 (put-message channel "hello world")))
   #:drain? #t))
⊣ scheme@(guile-user)> In
/home/clement/.guix-profile/share/guile/site/2.2/fibers/internal.scm:
  402:6  1 (suspend-current-fiber _)
  In unknown file:
 0 (scm-error misc-error #f "~A" ("Attempt to suspend
fiber within continuation barrier") #f)
  ERROR: In procedure scm-error:
  Attempt to suspend fiber within continuation barrier

;; bad
(define (test5)
  (run-fibers
   (lambda ()
 (spawn-fiber
  (lambda ()
(let ((channel (make-channel)))
  (call-with-new-thread
   (lambda ()
 (put-message channel "hello world")))
  (format #t "~a~%" (get-message channel))
   #:drain? #t))
⊣ scheme@(guile-user)> In
/home/clement/.guix-profile/share/guile/site/2.2/fibers/operations.scm:
  188:5  3 (perform-operation #< wrap-fn: #f try-fn:
# block-fn: #>)
  In 
/home/clement/.guix-profile/share/guile/site/2.2/fibers/channels.scm:

  88:26  2 (try-fn)
  In 
/home/clement/.guix-profile/share/guile/site/2.2/fibers/internal.scm:

  219:6  1 (schedule-fiber! _ _)
  In unknown file:
 0 (scm-error misc-error #f "~A" ("epoll instance is 
dead") #f)

  ERROR: In procedure scm-error:
  epoll instance is dead


--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: crashes with Fibers

[Amirouche Boubekki]

On 2018-07-01 15:09, Clément Lassieur wrote:

Amirouche Boubekki  writes:


Sorry, I did not read the code. What are you trying to achieve?


Within a fiber, I need to spawn several Guile-Git clones in parallel.
Since they block the Fibers scheduler, they need to be in separate
threads.


I tried that in the past it was working, but don't remember correctly
how I did.

epoll is dead seems to indicate that there is no fiber scheduler running
from the thread your are calling put-message. This might be a design 
decision

or not. My understanding is that your code should work as intended.

Anyway, try to spawn the thread and/or create the channel before you
run fibers. I can't try that myself because of my slow connection which
takes ages to install guile-fibers.

Something like:

(define (test6)
  (let ((channel (make-channel)))
(call-with-new-thread
 (lambda ()
   (put-message channel "hello world")))
(run-fibers
 (lambda ()
   (spawn-fiber
(lambda ()
  (format #t "~a~%" (get-message channel)
#:drain? #t)))

Re: crashes with Fibers

[Amirouche Boubekki]

On 2018-07-02 00:32, Amirouche Boubekki wrote:

On 2018-07-01 15:09, Clément Lassieur wrote:

Amirouche Boubekki  writes:


Sorry, I did not read the code. What are you trying to achieve?


Within a fiber, I need to spawn several Guile-Git clones in parallel.
Since they block the Fibers scheduler, they need to be in separate
threads.


I tried that in the past it was working, but don't remember correctly
how I did.


epoll is dead seems to indicate that there is no fiber scheduler 
running
from the thread your are calling put-message. This might be a design 
decision

or not. My understanding is that your code should work as intended.


You test5 code should definitly work. Otherwise, it requires to 
pre-allocate
as many thread as you need before you know you will them. May be we can 
look
at it backward and say, that allocating a pool of threads in advance is 
more

interesting performance wise.


Anyway, try to spawn the thread and/or create the channel before you
run fibers. I can't try that myself because of my slow connection which
takes ages to install guile-fibers.

Something like:


(use-modules (fibers))
(use-modules (fibers channels))


(define (test6)
  (let ((channel (make-channel)))
(call-with-new-thread
 (lambda ()
   (put-message channel "hello world")))
(run-fibers
 (lambda ()
   (spawn-fiber
(lambda ()
  (format #t "~a~%" (get-message channel)
#:drain? #t)))


It works on my side.

Re: crashes with Fibers

[Amirouche Boubekki]

On 2018-07-02 00:41, Amirouche Boubekki wrote:

On 2018-07-02 00:32, Amirouche Boubekki wrote:

On 2018-07-01 15:09, Clément Lassieur wrote:

Amirouche Boubekki  writes:


Sorry, I did not read the code. What are you trying to achieve?


Within a fiber, I need to spawn several Guile-Git clones in parallel.
Since they block the Fibers scheduler, they need to be in separate
threads.


I tried that in the past it was working, but don't remember correctly
how I did.


epoll is dead seems to indicate that there is no fiber scheduler 
running
from the thread your are calling put-message. This might be a design 
decision

or not. My understanding is that your code should work as intended.


You test5 code should definitly work. Otherwise, it requires to 
pre-allocate
as many thread as you need before you know you will them. May be we can 
look
at it backward and say, that allocating a pool of threads in advance is 
more

interesting performance wise.


Anyway, try to spawn the thread and/or create the channel before you
run fibers. I can't try that myself because of my slow connection 
which

takes ages to install guile-fibers.

Something like:


(use-modules (fibers))
(use-modules (fibers channels))


(define (test6)
  (let ((channel (make-channel)))
(call-with-new-thread
 (lambda ()
   (put-message channel "hello world")))
(run-fibers
 (lambda ()
   (spawn-fiber
(lambda ()
  (format #t "~a~%" (get-message channel)
#:drain? #t)))


It works on my side.


FWIW, the following code doesn't crash, but apparently does nothing:

(define (test7)
  (let ((channel (make-channel)))
(run-fibers
 (lambda ()
   (spawn-fiber
(lambda ()
  (call-with-new-thread
   (lambda ()
 (put-message channel "hello world")))
  (format #t "~a~%" (get-message channel)
#:drain? #t)))

(n-for-each-par-map 16 store download (reverse (iota (max-id))))) crash

[Amirouche Boubekki]

I have a program that try to download hackernews locally.

What it does is simple, it fetch the max identifier and
http-get each json value starting with the most recent
item. I use n-for-each-par-map with 16 threads I have
8 cores.

Here is the full program:

(define-module (hn))

(use-modules (srfi srfi-1))
(use-modules (ice-9 receive))
(use-modules (ice-9 threads))
(use-modules (ice-9 iconv))
(use-modules (web client))
(use-modules (json))


(define (max-id)
  (receive (response body) (http-get 
"https://hacker-news.firebaseio.com/v0/maxitem.json";)

(string->number (bytevector->string body "utf-8"

(define (download uid)
  (catch #t
(lambda ()
  (let* ((uid (1+ uid))
 (url "https://hacker-news.firebaseio.com/v0/item/~a.json";)
 (url (format #f url uid)))
(cons uid
  (json-string->scm
   (call-with-values (lambda () (http-get url))
 (lambda (response body)
   (bytevector->string body "utf-8")))
(lambda _ '(

(define (store pair)
  (if (null? pair)
  (format #t "X\n")
  (let ((port (open-file "hn.scm" "a")))
(format #t "~a\n" (car pair))
(write (cdr pair) port)
(close port

(define (dump)
  (n-for-each-par-map 16 store download (reverse (iota (max-id)

(dump)

It also requires json module from 
https://raw.githubusercontent.com/a-guile-mind/Culturia/master/src/json.scm


How can I debug this?

--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: (n-for-each-par-map 16 store download (reverse (iota (max-id))))) crash

[Amirouche Boubekki]

Hi Mark,

Thanks for your support and time.

On 2018-07-05 20:30, Mark H Weaver wrote:

Hi,

Amirouche Boubekki  writes:


I have a program that try to download hackernews locally.

What it does is simple, it fetch the max identifier and
http-get each json value starting with the most recent
item. I use n-for-each-par-map with 16 threads I have
8 cores.

Here is the full program:


[...]


(define (store pair)
  (if (null? pair)
  (format #t "X\n")
  (let ((port (open-file "hn.scm" "a")))
(format #t "~a\n" (car pair))


These calls to (format #t ...), which write to a port that is shared by
multiple threads, should be performed while holding a mutex to prevent
concurrent writes to the same port.


Ok, but it's called by:

  (n-for-each-par-map n sproc pproc lst1 lst2)

and the manual says about SPROC that :

  The sproc calls are made serially,
  in list element order, one at a time.

In my case SPROC is 'store', so my understanding is that
it should require no lock.



I/O operations in Guile do not include built-in thread synchronization,
at least not in the fast path cases.  However, an effort was made to
avoid _crashes_ on common architectures in the event of concurrent use
of the same port.  Our hope was that the worst that would typically
happen is garbled I/O.  Perhaps we failed to realize that hope.


I saw that behavior while use fibers.


How can I debug this?


It would be helpful to see a GDB backtrace from a crash in this 
program.


I will retry without mutex and only gdb to reproduce the crash
and have a trace.


Does it help to protect the shared port with a mutex?


I ran the program with gdb and a lock, it downloads more suff,
but it's also much slower.


 Thanks,
   Mark


Thanks again!

--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

2018 Scheme and Functional Programming Workshop CfP

[Amirouche Boubekki]

I did not see this CfP going through Guile mailling list,
so here is it. Deadline is monday!


DEADLINE: 9 July 2018, (Any time in the world)
WEBSITE: https://brinckerhoff.org/scheme2018/
LOCATION: St. Louis, MO, USA (co-located with ICFP and Strange Loop)
DATE: 28 September 2018 (Friday)

The 2018 Scheme and Functional Programming Workshop is calling for 
submissions.


Full papers are due 9 July 2018.
Authors will be notified by 20 July 2018.
Camera-ready versions are due 9 September 2018.
All deadlines are (23:59 UTC-12), "Anywhere on Earth".

We invite high-quality papers about novel research results, lessons 
learned from practical experience in industrial or educational setting, 
and even new insights on old ideas. We welcome and encourage submissions 
that apply to any language that can be considered Scheme: from strict 
subsets of RnRS to other "Scheme" implementations, to Racket, to Lisp 
dialects including Clojure, Emacs Lisp, Common Lisp, to functional 
languages with continuations and/or macros (or extended to have them) 
such as Dylan, ECMAcript, Hop, Lua, Scala, Rust, etc. The elegance of 
the paper and the relevance of its topic to the interests of Schemers 
will matter more than the surface syntax of the examples used. Topics of 
interest include (but are not limited to):


   Interaction: program-development environments, debugging, testing, 
refactoring
   Implementation: interpreters, compilers, tools, garbage collectors, 
benchmarks
   Extension: macros, hygiene, domain-specific languages, reflection, 
and how such extension affects interaction.
   Expression: control, modularity, ad hoc and parametric polymorphism, 
types, aspects, ownership models, concurrency, distribution, 
parallelism, non-determinism, probabilism, and other programming 
paradigms
   Integration: build tools, deployment, interoperation with other 
languages and systems
   Formal semantics: Theory, analyses and transformations, partial 
evaluation
   Human Factors: Past, present and future history, evolution and 
sociology of the language Scheme, its standard and its dialects

   Education: approaches, experiences, curricula
   Applications: industrial uses of Scheme
   Scheme pearls: elegant, instructive uses of Scheme

Submission Information

Please submit full papers and experience reports to our Submission Page:
https://easychair.org/conferences/?conf=scheme2018

[NEW SINCE 2017!] Paper submissions must use the format acmart and its 
sub-format acmlarge. They must be in PDF, printable in black and white 
on US Letter size. Microsoft Word and LaTeX templates for this format 
are available at:


http://www.sigplan.org/Resources/Author/

This change is in line with ACM conferences (such as ICFP with which we 
are colocated) switching from their traditional two-column formats (e.g. 
sigplanconf) to the above. While a two-column format with small fonts is 
much more practical when reading printed papers, the single-column 
format with large fonts is nicer to view on a computer screen, as most 
papers are read these days.


To encourage authors to submit their best work, we offer three tracks:

* Full Papers, with a limit of 14 pages. Each accepted paper will be 
presented by its authors in a 25 minute slot including Q&A.


* Experience Reports, with a limit to 14 pages. Each accepted report 
will be presented by its authors in a 25 minute slot including Q&A.


* Lightning talks, with a limit to 192 words. Each accepted lightning 
talk will be presented by its authors in a 5 minute slot, followed by 5 
minutes of Q&A.


The size limits above exclude references and any optional appendices. 
There are no size limits on appendices, but the papers should stand 
without the need to read them, and reviewers are not required to read 
them.


Authors are encouraged to publish any code associated to their papers 
under an open source license, so that reviewers may try the code and 
verify the claims.


Proceedings will be printed as a Technical Report at the University of 
Alabama at Birmingham.


Publication of a paper at this workshop is not intended to replace 
conference or journal publication, and does not preclude re-publication 
of a more complete or finished version of the paper at some later 
conference or in a journal.


Sincerely,

John Clements, General Chair
William E. Byrd, Program Committee Chair


Program Committee:

Claire Alvis  (Sparkfund, USA)
William E. Byrd  (Program Committee Chair)  (University of Alabama at 
Birmingham, USA)
Maxime Chevalier-Boisvert  (Montreal Institute for Learning Algorithms, 
Canada)

John Clements  (General Chair) (Cal Poly, San Luis Obispo, USA)
Ronald Garcia  (University of British Columbia, Canada)
Yukiyoshi Kameyama (University of Tsukuba, Japan)
Paul A. Steckler (Northeastern University, USA)
Larisse Voufo (Google, USA)


Workshop Steering Committee:

Will Clinger, Northeastern University
Marc Feeley, Université de Montréal
Dan Friedman, Indiana University
Olin Shivers, Nort

Re: crashes with Fibers

[Amirouche Boubekki]

https://github.com/wingo/fibers/issues/21

Le mar. 17 juil. 2018 à 20:17, Clément Lassieur  a
écrit :

> Clément Lassieur  writes:
>
> > Ludovic Courtès  writes:
> >
> >> Hello Clément,
> >>
> >> Clément Lassieur  skribis:
> >>
> >>> ;; bad
> >>> (define (test4)
> >>>   (run-fibers
> >>>(lambda ()
> >>>  (spawn-fiber
> >>>   (lambda ()
> >>> (let ((channel (make-channel)))
> >>>   (call-with-new-thread
> >>>(lambda ()
> >>>  (put-message channel "hello world")))
> >>>#:drain? #t))
> >>> ⊣ scheme@(guile-user)> In
> /home/clement/.guix-profile/share/guile/site/2.2/fibers/internal.scm:
> >>>   402:6  1 (suspend-current-fiber _)
> >>>   In unknown file:
> >>>  0 (scm-error misc-error #f "~A" ("Attempt to suspend
> fiber within continuation barrier") #f)
> >>>   ERROR: In procedure scm-error:
> >>>   Attempt to suspend fiber within continuation barrier
> >>
> >> I think the problem here is that the new thread inherit the dynamic
> >> environment of the spawning thread.  Thus, ‘put-message’, called in that
> >> new thread, thinks it’s running within a Fiber, but it’s not.
> >>
> >> Because of that, ‘put-message’ tries to suspend itself, but it cannot:
> >> ‘call-with-new-thread’ is written in C, so it’s a “continuation barrier”
> >> (meaning that it’s a continuation that cannot be captured and resumed
> >> later.)
> >>
> >> So I think if you really want that, you can perhaps do something like
> >> (untested):
> >>
> >>   (call-with-new-thread
> >> (lambda ()
> >>   (parameterize ((current-fiber #f))
> >> (put-message channel "hello world"
> >
> > It works, but only with (@@ (fibers internal) current-fiber) because the
> > parameter isn't exported.
> >
> > Thank you Ludo!
>
> Hi Andy,
>
> I'm adding you to this conversation to notify you about this Fibers
> issue.  (I don't have a Github account to report the bug there.)
>
> Thanks,
> Clément
>
>

Re: 2018 Scheme and Functional Programming Workshop CfP

[Amirouche Boubekki]

Hello Nala,

I did not send my paper about zehefyu (formely known as neon)

nevermind, I did not find time to read the new microkanren code...

Le mer. 1 août 2018 à 10:43, Nala Ginrut  a écrit :

> I've sent a paper about guile-lua, hope everything is ok ;-P
> On Fri, Jul 6, 2018 at 2:46 PM Amirouche Boubekki
>  wrote:
> >
> > I did not see this CfP going through Guile mailling list,
> > so here is it. Deadline is monday!
> >
> >
> > DEADLINE: 9 July 2018, (Any time in the world)
> > WEBSITE: https://brinckerhoff.org/scheme2018/
> > LOCATION: St. Louis, MO, USA (co-located with ICFP and Strange Loop)
> > DATE: 28 September 2018 (Friday)
> >
> > The 2018 Scheme and Functional Programming Workshop is calling for
> > submissions.
> >
> > Full papers are due 9 July 2018.
> > Authors will be notified by 20 July 2018.
> > Camera-ready versions are due 9 September 2018.
> > All deadlines are (23:59 UTC-12), "Anywhere on Earth".
> >
> > We invite high-quality papers about novel research results, lessons
> > learned from practical experience in industrial or educational setting,
> > and even new insights on old ideas. We welcome and encourage submissions
> > that apply to any language that can be considered Scheme: from strict
> > subsets of RnRS to other "Scheme" implementations, to Racket, to Lisp
> > dialects including Clojure, Emacs Lisp, Common Lisp, to functional
> > languages with continuations and/or macros (or extended to have them)
> > such as Dylan, ECMAcript, Hop, Lua, Scala, Rust, etc. The elegance of
> > the paper and the relevance of its topic to the interests of Schemers
> > will matter more than the surface syntax of the examples used. Topics of
> > interest include (but are not limited to):
> >
> > Interaction: program-development environments, debugging, testing,
> > refactoring
> > Implementation: interpreters, compilers, tools, garbage collectors,
> > benchmarks
> > Extension: macros, hygiene, domain-specific languages, reflection,
> > and how such extension affects interaction.
> > Expression: control, modularity, ad hoc and parametric polymorphism,
> > types, aspects, ownership models, concurrency, distribution,
> > parallelism, non-determinism, probabilism, and other programming
> > paradigms
> > Integration: build tools, deployment, interoperation with other
> > languages and systems
> > Formal semantics: Theory, analyses and transformations, partial
> > evaluation
> > Human Factors: Past, present and future history, evolution and
> > sociology of the language Scheme, its standard and its dialects
> > Education: approaches, experiences, curricula
> > Applications: industrial uses of Scheme
> > Scheme pearls: elegant, instructive uses of Scheme
> >
> > Submission Information
> >
> > Please submit full papers and experience reports to our Submission Page:
> > https://easychair.org/conferences/?conf=scheme2018
> >
> > [NEW SINCE 2017!] Paper submissions must use the format acmart and its
> > sub-format acmlarge. They must be in PDF, printable in black and white
> > on US Letter size. Microsoft Word and LaTeX templates for this format
> > are available at:
> >
> > http://www.sigplan.org/Resources/Author/
> >
> > This change is in line with ACM conferences (such as ICFP with which we
> > are colocated) switching from their traditional two-column formats (e.g.
> > sigplanconf) to the above. While a two-column format with small fonts is
> > much more practical when reading printed papers, the single-column
> > format with large fonts is nicer to view on a computer screen, as most
> > papers are read these days.
> >
> > To encourage authors to submit their best work, we offer three tracks:
> >
> > * Full Papers, with a limit of 14 pages. Each accepted paper will be
> > presented by its authors in a 25 minute slot including Q&A.
> >
> > * Experience Reports, with a limit to 14 pages. Each accepted report
> > will be presented by its authors in a 25 minute slot including Q&A.
> >
> > * Lightning talks, with a limit to 192 words. Each accepted lightning
> > talk will be presented by its authors in a 5 minute slot, followed by 5
> > minutes of Q&A.
> >
> > The size limits above exclude references and any optional appendices.
> > There are no size limits on appendices, but the papers should stand
> > without the need to read them, and reviewers are not required to read
> > them.
> >
> > Authors are 

Re: Guile 3 update, August edition

[Amirouche Boubekki]

Le ven. 24 août 2018 à 14:19, Christopher Lemmer Webber <
cweb...@dustycloud.org> a écrit :

> Andy Wingo writes:
>
> > In this particular example, the JITted code runs about 3x faster than
> > the interpreted code.  The JIT doesn't do register allocation; not sure
> > precisely how to do that.  A future topic.  For the moment I want to
> > consolidate what we have and once it's all just magically working and
> > everybody's programs are faster, we release Guile 3.
>
> This is great news!  Very excited about Guile 3 over here!  :)
>
>
Same here! Thanks a lot for this updates. I abandonned my Chez scheme
adventures somewhat thanks to those updates!

Keep it steady and happy hacking!

Scheme @ FOSDEM 2019

[Amirouche Boubekki]

Hello all,


I would like to get the ball rolling about a SCHEME event in Europe at 
FOSDEM in 2019


Please add your talk ideas in that page 
http://community.schemewiki.org/?FOSDEM2019



Best regards,



Amirouche

Re: guile 3 update, september edition

[Amirouche Boubekki]

Le lun. 17 sept. 2018 à 10:26, Andy Wingo  a écrit :

> Hi!
>
> This is an update on progress towards Guile 3.  In our last update, we
> saw the first bits of generated code:
>
>   https://lists.gnu.org/archive/html/guile-devel/2018-08/msg5.html
>
> Since then, the JIT is now feature-complete.  It can JIT-compile *all*
> code in Guile, including delimited continuations, dynamic-wind, all
> that.  It runs automatically, in response to a function being called a
> lot.  It can also tier up from within hot loops.
>

This looks very good!

When the merge will be done, maybe it will be time to move guile-next to
master in guix? WDYT?

Keep it steady!

Re: Proposal of a better hash table implementation based on SRFI 125

[Amirouche Boubekki]

Le 2018-12-28 17:11, Jéssica Milaré a écrit :

Hello,

As I said in a previous e-mail, currently SRFI-69 is broken for weak
hash tables - and I've sent a patch to fix it. However, I think there
are many other problems with current implementation of hash tables.
There are guile standard hash tables, SRFI-69 hash tables (which is
implemented on top of standard hash tables) and also R6RS hash tables
(which is implemented on top or SRFI-69 and completely lacks support
for weak keys and/or values).

I think that should be fixed and guile should have only two kinds of
hash tables: the standard guile hash table and another extended hash
table type that will be used directly by R6RS, SRFI-125 and SRFI-69.
In my opinion, it should be based on SRFI-125, which is part of R7RS
Red Edition, but also supports some other procedures to make it
compatible with R6RS and SRFI-69, supporting weakness and immutable
hash tables.

I'm already implementing the SRFI-125 based hash tables library for
myself, so, if that is accepted, I can also make a patch for guile.



Yes please make a patch and attach it to the bug report.

Don't forget to send an announcement when you SRFI-125 implementation
is ready for testing. Is it already available anywhere?

TIA

Re: Proposal of a better hash table implementation based on SRFI 125

[Amirouche Boubekki]

I will try to look at the commits. One last niptick, can you push guile
master branch to you repository, and make a pull request against it so that
I can directly comment in the pull requests. please. It's easier to way to
see the overall changes in particular.

Le dim. 13 janv. 2019 à 23:52, Jéssica Milaré  a
écrit :

> Finally finished the libraries.
>
> SRFI-125 is implemented. I took the liberty to create a procedure
> scm_hash_n_items in 'libguile/hashtab.c' that works with both normal and
> weak hash tables, so the GENERIC-HASH-TABLES module don't need to keep
> track of the hash table size anymore.
>
> `make check` runs everything ok. I believe it's ready for testing. Any
> feedback is welcome.
>
> Regards,
> Jéssica
>
> Em sáb, 12 de jan de 2019 às 18:34, Jéssica Milaré 
> escreveu:
>
>> (It seems I mistakenly responded only to a personal e-mail, sorry,
>> responded now to everyone in the list with updates).
>>
>> So here are the news:
>>
>> I've created a module called (ice-9 generic-hash-tables), which is
>> similar to SRFI-125, and used it to implement SRFI-69, (RNRS HASHTABLES),
>> SRFI-126 and SRFI-125. Since SRFI-125 depends on SRFI-128, I've implemented
>> it as well. My public repository already has SRFI-128, I'm just finishing
>> some tests with SRFI-125 and, once they are done, I'll push it as well.
>>
>> The module (ice-9 generic-hash-tables), is quite usable and all exported
>> procedures are documented. I've created tests for it and also ported
>> standard tests from SRFI-126.
>>
>> Now, I see that 'libguile/hashtab.h' code keeps track of the number of
>> elements in hash tables, but the field is not visible from Scheme. Can that
>> be changed? Then generic hash tables wouldn't need to also keep track of
>> the number of elements (like SRFI-69 currently does) and that would
>> simplify its code.
>>
>> Besides, what about creating new versions HASHX-* procedures that accept
>> an equivalence procedure instead of an assoc procedure? Perhaps prefixed by
>> 'NEW-' or post-fixed by a '*'.
>>
>> I've also found inconsistencies between SRFI-125 and it's reference
>> implementation and standard tests. I've implemented according to the
>> specification - so, for instance, HASH-TABLE=? checks if the equivalence
>> function of both hash tables are the same and HASH-TABLE returns an
>> immutable hash table.
>>
>> Code is public and suggestions are always welcome :)
>> https://github.com/jessymilare/guile
>>
>> Regargs,
>> Jéssica
>>
>> Em dom, 30 de dez de 2018 às 15:50, Amirouche Boubekki <
>> amirou...@hypermove.net> escreveu:
>>
>>> Le 2018-12-28 17:11, Jéssica Milaré a écrit :
>>> > Hello,
>>> >
>>> > As I said in a previous e-mail, currently SRFI-69 is broken for weak
>>> > hash tables - and I've sent a patch to fix it. However, I think there
>>> > are many other problems with current implementation of hash tables.
>>> > There are guile standard hash tables, SRFI-69 hash tables (which is
>>> > implemented on top of standard hash tables) and also R6RS hash tables
>>> > (which is implemented on top or SRFI-69 and completely lacks support
>>> > for weak keys and/or values).
>>> >
>>> > I think that should be fixed and guile should have only two kinds of
>>> > hash tables: the standard guile hash table and another extended hash
>>> > table type that will be used directly by R6RS, SRFI-125 and SRFI-69.
>>> > In my opinion, it should be based on SRFI-125, which is part of R7RS
>>> > Red Edition, but also supports some other procedures to make it
>>> > compatible with R6RS and SRFI-69, supporting weakness and immutable
>>> > hash tables.
>>> >
>>> > I'm already implementing the SRFI-125 based hash tables library for
>>> > myself, so, if that is accepted, I can also make a patch for guile.
>>> >
>>>
>>> Yes please make a patch and attach it to the bug report.
>>>
>>> Don't forget to send an announcement when you SRFI-125 implementation
>>> is ready for testing. Is it already available anywhere?
>>>
>>> TIA
>>>
>>

Re: Proposal of a better hash table implementation based on SRFI 125

[Amirouche Boubekki]

Thanks!

I have done mostly a cosmetic review of your code. Here is the summary:

- There is two big procedures that I think should be split `
get-hash-functions` and `hash-table` to help readability
- I am not very fond of  generic-hash-table macros, I would rather use
apply / call-with-values, if there is an optimisation to be done it should
be done in the compiler... no?

Otherwise:

- You follow the GNU guidelines for commit message that is a good thing
(minor niptick, you should use present tense "Fix" instead of "Fixed",
"Implement" instead of "Implemented"
- The code is very readable

I don't know about whether that code requires additions to the manual since
it's R7RS and SRFI.

I cc'ed Mark Weaver.

Le jeu. 17 janv. 2019 à 22:14, Jéssica Milaré  a
écrit :

> *Note
>
> Em qui, 17 de jan de 2019 às 19:13, Jéssica Milaré 
> escreveu:
>
>> Done.
>>
>> Not that there are many commits. The first commit only fixes bug 33827 of
>> SRFI 69, and SRFI 69 is reimplemented in the third commit, which pretty
>> much erases the changes of the first commit.
>>
>> https://github.com/jessymilare/guile/pull/1
>>
>> Em qua, 16 de jan de 2019 às 22:19, Amirouche Boubekki <
>> amirouche.boube...@gmail.com> escreveu:
>>
>>> I will try to look at the commits. One last niptick, can you push guile
>>> master branch to you repository, and make a pull request against it so that
>>> I can directly comment in the pull requests. please. It's easier to way to
>>> see the overall changes in particular.
>>>
>>> Le dim. 13 janv. 2019 à 23:52, Jéssica Milaré  a
>>> écrit :
>>>
>>>> Finally finished the libraries.
>>>>
>>>> SRFI-125 is implemented. I took the liberty to create a procedure
>>>> scm_hash_n_items in 'libguile/hashtab.c' that works with both normal and
>>>> weak hash tables, so the GENERIC-HASH-TABLES module don't need to keep
>>>> track of the hash table size anymore.
>>>>
>>>> `make check` runs everything ok. I believe it's ready for testing. Any
>>>> feedback is welcome.
>>>>
>>>> Regards,
>>>> Jéssica
>>>>
>>>> Em sáb, 12 de jan de 2019 às 18:34, Jéssica Milaré <
>>>> jessymil...@gmail.com> escreveu:
>>>>
>>>>> (It seems I mistakenly responded only to a personal e-mail, sorry,
>>>>> responded now to everyone in the list with updates).
>>>>>
>>>>> So here are the news:
>>>>>
>>>>> I've created a module called (ice-9 generic-hash-tables), which is
>>>>> similar to SRFI-125, and used it to implement SRFI-69, (RNRS HASHTABLES),
>>>>> SRFI-126 and SRFI-125. Since SRFI-125 depends on SRFI-128, I've 
>>>>> implemented
>>>>> it as well. My public repository already has SRFI-128, I'm just finishing
>>>>> some tests with SRFI-125 and, once they are done, I'll push it as well.
>>>>>
>>>>> The module (ice-9 generic-hash-tables), is quite usable and all
>>>>> exported procedures are documented. I've created tests for it and also
>>>>> ported standard tests from SRFI-126.
>>>>>
>>>>> Now, I see that 'libguile/hashtab.h' code keeps track of the number of
>>>>> elements in hash tables, but the field is not visible from Scheme. Can 
>>>>> that
>>>>> be changed? Then generic hash tables wouldn't need to also keep track of
>>>>> the number of elements (like SRFI-69 currently does) and that would
>>>>> simplify its code.
>>>>>
>>>>> Besides, what about creating new versions HASHX-* procedures that
>>>>> accept an equivalence procedure instead of an assoc procedure? Perhaps
>>>>> prefixed by 'NEW-' or post-fixed by a '*'.
>>>>>
>>>>> I've also found inconsistencies between SRFI-125 and it's reference
>>>>> implementation and standard tests. I've implemented according to the
>>>>> specification - so, for instance, HASH-TABLE=? checks if the equivalence
>>>>> function of both hash tables are the same and HASH-TABLE returns an
>>>>> immutable hash table.
>>>>>
>>>>> Code is public and suggestions are always welcome :)
>>>>> https://github.com/jessymilare/guile
>>>>>
>>>>> Regargs,
>>>&

Re: Proposal of a better hash table implementation based on SRFI 125

[Amirouche Boubekki]

Thanks for the feedback!

Also, if you are interested in r7rs in guile you might be interested in
`r7rs-wip` branch of guile


Le dim. 20 janv. 2019 à 14:50, Jéssica Milaré  a
écrit :

>
>
> Em dom, 20 de jan de 2019 às 10:58, Amirouche Boubekki <
> amirouche.boube...@gmail.com> escreveu:
>
>> Thanks!
>>
>> I have done mostly a cosmetic review of your code. Here is the summary:
>>
>
> Your comments are very good, I'll do most of the suggested changes.
>
>
>> - There is two big procedures that I think should be split `
>> get-hash-functions` and `hash-table` to help readability
>> - I am not very fond of  generic-hash-table macros, I would rather use
>> apply / call-with-values, if there is an optimisation to be done it should
>> be done in the compiler... no?
>>
>
> These macros were copied from old SRFI-69 code. Regarding to
> optimizations, I don't ask myself if something *should be* done by the
> compiler, but if it *actually is* done by the compiler. Otherwise, we'll
> end in a discussion involving a "sufficiently smart compiler", not a real
> compiler.
>
> Otherwise:
>>
>> - You follow the GNU guidelines for commit message that is a good thing
>> (minor niptick, you should use present tense "Fix" instead of "Fixed",
>> "Implement" instead of "Implemented"
>> - The code is very readable
>>
>> I don't know about whether that code requires additions to the manual
>> since it's R7RS and SRFI.
>>
>> I cc'ed Mark Weaver.
>>
>> Le jeu. 17 janv. 2019 à 22:14, Jéssica Milaré  a
>> écrit :
>>
>>> *Note
>>>
>>> Em qui, 17 de jan de 2019 às 19:13, Jéssica Milaré <
>>> jessymil...@gmail.com> escreveu:
>>>
>>>> Done.
>>>>
>>>> Not that there are many commits. The first commit only fixes bug 33827
>>>> of SRFI 69, and SRFI 69 is reimplemented in the third commit, which pretty
>>>> much erases the changes of the first commit.
>>>>
>>>> https://github.com/jessymilare/guile/pull/1
>>>>
>>>> Em qua, 16 de jan de 2019 às 22:19, Amirouche Boubekki <
>>>> amirouche.boube...@gmail.com> escreveu:
>>>>
>>>>> I will try to look at the commits. One last niptick, can you push
>>>>> guile master branch to you repository, and make a pull request against it
>>>>> so that I can directly comment in the pull requests. please. It's easier 
>>>>> to
>>>>> way to see the overall changes in particular.
>>>>>
>>>>> Le dim. 13 janv. 2019 à 23:52, Jéssica Milaré 
>>>>> a écrit :
>>>>>
>>>>>> Finally finished the libraries.
>>>>>>
>>>>>> SRFI-125 is implemented. I took the liberty to create a procedure
>>>>>> scm_hash_n_items in 'libguile/hashtab.c' that works with both normal and
>>>>>> weak hash tables, so the GENERIC-HASH-TABLES module don't need to keep
>>>>>> track of the hash table size anymore.
>>>>>>
>>>>>> `make check` runs everything ok. I believe it's ready for testing.
>>>>>> Any feedback is welcome.
>>>>>>
>>>>>> Regards,
>>>>>> Jéssica
>>>>>>
>>>>>> Em sáb, 12 de jan de 2019 às 18:34, Jéssica Milaré <
>>>>>> jessymil...@gmail.com> escreveu:
>>>>>>
>>>>>>> (It seems I mistakenly responded only to a personal e-mail, sorry,
>>>>>>> responded now to everyone in the list with updates).
>>>>>>>
>>>>>>> So here are the news:
>>>>>>>
>>>>>>> I've created a module called (ice-9 generic-hash-tables), which is
>>>>>>> similar to SRFI-125, and used it to implement SRFI-69, (RNRS 
>>>>>>> HASHTABLES),
>>>>>>> SRFI-126 and SRFI-125. Since SRFI-125 depends on SRFI-128, I've 
>>>>>>> implemented
>>>>>>> it as well. My public repository already has SRFI-128, I'm just 
>>>>>>> finishing
>>>>>>> some tests with SRFI-125 and, once they are done, I'll push it as well.
>>>>>>>
>>>>>>> The module (ice-9 generic-hash-tables), is quite usable and all
>>>>>>> exported procedures are documented. I&

Re: FOSDEM 2019

[Amirouche Boubekki]

Le dim. 3 févr. 2019 à 22:36, Mikael Djurfeldt  a
écrit :

> It was a great experience and joy for me to meet some of you at FOSDEM
> 2019. Thank you all!
>
> Now a piece of advice.
>
> Everyone who works with Guile knows that it's crap and look with envy at
> projects like Chez and Racket, right? Jim Blandy thinks that GNU should use
> Python as its scripting language. Chris Webber (probably rightly) thinks
> "look how much you can accomplish with Racket so quickly".
>
> I've been there also. I have to confess that I have now and again regarded
> Guile as crap since perhaps 1995 and there has been multiple occasions
> where I have thought that basing the community effort on some other scheme
> would make much more sense, and I have also always looked with envy on Chez
> and mzscheme/Racket.
>
> Yet, it is *amazing* to me how much progress Guile has made since I left.
> I, for example, *love* the new language and compiler infrastructure.
>
> But note now that Racket looks with envy on Chez and intends to base
> Racket on Chez while Andy Wingo thinks that he can beat Chez performance.
>
> My advice is this:
>
> Idiots go around thinking that their own code is the best thing around.
> Sensible people have a natural, and actually productive, tendency to be
> critical about their own work. That is all good, unless it hurts the sense
> of meaning and joy in your work.
>
> Remember now first that we are all irrational creatures. We maybe *think*
> sometimes that we are rational, because what we think looks rational in our
> view. The problem is that the view is usually very limited, with, for
> example, a limited set of presumptions.
>
> For example: Guile is a piece of software, right? Wrong! It is a plant,
> growing over time. Now, if we look over the fence into the other garden,
> the plants there look much greener. But what will determine the ultimate
> fate is not only the shape of it in the present moment, but also the genes
> it carries, the quality of the soil, the amount of sunlight and the skills
> of its gard[i]ners. We could have quit before we got GOOPS, or before we
> got the native threading, or before the compiler tower, without which there
> would be no chance to beat Chez.
>
> If you look at one combination of some Guile features:
>
> * easy embedding in applications
> * support for multiple languages
> * the compiler tower
> * OO system with polymorphic dispatch and metaobject protocol
> * nice, friendly and open community
>
> I think it is pretty strong and impressive, and I wouldn't like to live
> without it. It's especially important to look at Guile as a good breeding
> ground for new amazing work.
>
> That said, we should steal and collaborate all we can!
>
> All the best,
> Mikael
>

Very well said.

I am waiting an official announcement of the ROADMAP for GNU Guile 3 before
giving my point of view.

Re: FOSDEM 2019

[Amirouche Boubekki]

Le lun. 4 févr. 2019 à 15:52, Ludovic Courtès  a écrit :

> Hello Mikael!
>
> Mikael Djurfeldt  skribis:
>
> > It was a great experience and joy for me to meet some of you at FOSDEM
> > 2019. Thank you all!
>
> Seconded, that was awesome!  Meeting Guilers, both newcomers and
> old-timers :-), was just great!
>
> > Everyone who works with Guile knows that it's crap and look with envy at
> > projects like Chez and Racket, right?
>

[...]

a couple of other people talked about this yesterday at FOSDEM, and we
> agree

that we must work on increasing the bandwidth with Racketeers.
>

What does it mean in practice? What are the tasks that must dealt with?

Re: FOSDEM 2019

[Amirouche Boubekki]

Hi

Le mar. 5 févr. 2019 à 18:17, Ludovic Courtès  a écrit :

> Hi,
>
> Amirouche Boubekki  skribis:
>
> > What does it mean in practice? What are the tasks that must dealt with?
>
> Like I wrote, an immediate task is to write a Racket importer for Guix¹
> and to actually package things.
>
> Next, we could ensure the subset of these packages that use #r6rs can
> also be used as Guile packages.  However Chris noted that there are few
> of them; most use #lang racket.
>
> Thus, the next idea is to have #lang racket in Guile, which is quite a
> bit of work but probably doable.


Challenge accepted :)

And the converse: #lang guile in
> Racket.
>
> There are probably other things that could be done, or variants on this
> theme.
>
> Is that clearer?
>
> Thanks,
> Ludo’.
>
> ¹
> https://gnu.org/software/guix/manual/en/html_node/Invoking-guix-import.html
>

Re: FOSDEM 2019

[Amirouche Boubekki]

Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <
alex.sassmannshau...@gmail.com> a écrit :

> >  - Janneke mentioned the new guile build system in guix for simpler
> >guile packages and I think that's pretty great.  Likewise there was
> >some mention of some sort of you-don't-have-to-use-autotools build
> >system and I don't remember what it's name was.  (BTW, I continue to
> >believe that "Guix is and should be Guile's package mangager".)
>
> I was unaware that we had a guile build system in Guix.


What is it?


> In the past I was the one who argued strongly for the build system and
> for the no-autotools approach — I believe in the context of outreachy.
> Unfortunately I was unable to make that part a reality.
>
> Even so, I have been developing a solution that is part of this
> discussion in the form of Guile Hall, which is a project manager for
> Guile with strong integration with Guix & Autotools.
>

guile hall can be found here https://gitlab.com/a-sassmannshausen/guile-hall


> As you can see, I have a horse in this race.  I would be very interested
> in collaborating with others who feel strongly about this part of the
> Guile/Guix user journey — either on improvements to Hall, Guix or on
> other tooling.
>

Talking about tools and build systems, what do you think of https://waf.io/?

Re: FOSDEM 2019

[Amirouche Boubekki]

Le mer. 6 févr. 2019 à 16:22, Amirouche Boubekki <
amirouche.boube...@gmail.com> a écrit :

>
>
> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <
> alex.sassmannshau...@gmail.com> a écrit :
>
>> >  - Janneke mentioned the new guile build system in guix for simpler
>> >guile packages and I think that's pretty great.  Likewise there was
>> >some mention of some sort of you-don't-have-to-use-autotools build
>> >system and I don't remember what it's name was.  (BTW, I continue to
>> >believe that "Guix is and should be Guile's package mangager".)
>>
>> I was unaware that we had a guile build system in Guix.
>
>
> What is it?
>

I could look it up, sorry for the noise.

ref:
https://www.gnu.org/software/guix/manual/en/guix.html#index-guile_002dbuild_002dsystem

Re: FOSDEM 2019

[Amirouche Boubekki]

Hello all,

Le mer. 6 févr. 2019 à 18:47, Ludovic Courtès  a écrit :

> Nala Ginrut  skribis:
>
> > Does it mean someone is working on writing Racket specific dialect
> > front-end on Guile? I appreciate!
>
> Nope!  Actually Chris Webber raised the issue of collaboration between
> Racket and Guile in their talk, which is why we’re discussing it.
>
> But Guile is still Guile and there’s also lots of Guile hacking waiting
> for us.
>

I actually meant to work on the racket front-end.

Skimmed through their reference API and
nothing stands out. I known that I don't know.
Perfection is in the detail. Thad said some particular
topic attracted my attention:

- Phases and compilation guarantees [1]
- Continuations Frames and Mark [2]
- Custodians [3]

[1]
https://docs.racket-lang.org/reference/eval-model.html#%28part._module-eval-model%29
[2]
https://docs.racket-lang.org/reference/eval-model.html#%28part._mark-model%29
[3]
https://docs.racket-lang.org/reference/eval-model.html#%28part._custodian-model%29

TIL it is possible for me to create a front-end in guile.
There is various example in guile tree.
But again perfection is the detail.

Also, I would like to point out that there are already
racket things available in GNU Guile:

- for-loops https://bitbucket.org/bjoli/guile-for-loops
- syntax-parse https://gitlab.com/guile-syntax-parse/guile-syntax-parse

Last but not least guile fibers https://github.com/wingo/fibers
which rather unique in scheme universe at least.

I was interested in this racket-on-guile because it seems difficult,
also there was potential to make a contribution that is useful,
and learn a few things about Guile inner working.

At the end of the day it's not because we can run racket
programs that GNU Guile will suddenly become the place
to be. I don't say it is a useless project, working code is always
great. But it is not enough. See for instance, PyPy has pratically
catched up CPython and has better performance, it still not
mainstream.

Enough said ;-)

I will look at r7rs branch [a] and pdf report [b]

[a] http://git.savannah.gnu.org/cgit/guile.git/log/?h=r7rs-wip
[b] https://small.r7rs.org/attachment/r7rs.pdf

Re: Code coverage is broken

[Amirouche Boubekki]

code coverage work with guile-2.2

Here is the test run:

amirouche@ubujan19:~/src/scheme/guile/coverage$ guile --version
guile (GNU Guile) 2.2.4
Copyright (C) 2018 Free Software Foundation, Inc.

License LGPLv3+: GNU LGPL 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
amirouche@ubujan19:~/src/scheme/guile/coverage$ ls
Makefile  run-tests-with-coverage.scm  test.scm
amirouche@ubujan19:~/src/scheme/guile/coverage$ cat Makefile
all:
@guile --debug run-tests-with-coverage.scm test.scm
@genhtml test.scm.info | tail -n 3
amirouche@ubujan19:~/src/scheme/guile/coverage$ cat
run-tests-with-coverage.scm
(use-modules (system vm coverage)
 (system vm vm))


(define (run-test-with-coverage test)
  (call-with-values (lambda ()
  (with-code-coverage
   (lambda ()
 (load test
(lambda (data result)
  (let ((port (open-output-file (string-append test ".info"
(coverage-data->lcov data port)
(close port)

(run-test-with-coverage (cadr (program-arguments)))
amirouche@ubujan19:~/src/scheme/guile/coverage$ cat test.scm
(display "test echo\n")
amirouche@ubujan19:~/src/scheme/guile/coverage$ make
test echo
Overall coverage rate:
  lines..: 1.5% (135 of 9180 lines)
  functions..: no data found
amirouche@ubujan19:~/src/scheme/guile/coverage$

Get the code with: git clone https://github.com/a-guile-mind/coverage.git

The thing that is not implemented is getting the coverage for the "current
directory".
The percentage that genhtml gives is the overall coverage of all the code
that is loaded (I guess).

Le ven. 8 févr. 2019 à 21:41, Nala Ginrut  a écrit :

> Hi folks!
> I'm trying to add code coverage for certain program.
> However, the function callings are always unrecorded.
>
> --
> (use-modules (system vm coverage)
>  (system vm vm))
>(call-with-values
> (lambda ()
>(with-code-coverage
>  (lambda () (display "hello\n"
> (lambda (data result)
>   (let ((port (open-output-file "1.info")))
> (coverage-data->lcov data port)
> (close port
>
> ---
>
> (To someone who uses old 2.0, with-code-coverage interface has been
> changed to accept only one thunk)
>
> When I use lcov to generate coverage graph, it always complains that
> 
>  lines..: 0.0% (0 of 36447 lines)
>   functions..: no data found
>   branches...: no data found
> 
> I found the FN tag in info file is always missing.
>

> Then I found in 581a4eb82b1534970060e3cbd79b9a96d351edf9
>
> -
> +  #;
>  (for-each dump-function procs)
> -
> It seems that FN printing was skipped intended.
>
> Is it a bug?
> Anyone who has tried code coverage?
>
> Thanks!
>
>

Re: Code coverage is broken

[Amirouche Boubekki]

Sorry! My test is not good. Ignore what I posted previously.

Re: Code coverage is broken

[Amirouche Boubekki]

Le sam. 9 févr. 2019 à 14:48, Nala Ginrut  a écrit :

> I wonder if it's a bug that the FN was skipped.
>

Yes it is expected, see
http://git.savannah.gnu.org/cgit/guile.git/tree/module/system/vm/coverage.scm#n309

Here is a patch that take into account function coverage, it is rather slow.

demo: https://screenshots.firefox.com/FmuctotjXTFRSiFW/null

HTH


> On Sat, Feb 9, 2019 at 10:51 AM Nala Ginrut  wrote:
> >
> > Never mind, it's better than mine, at least there're lines records,
> > although functions calling are still missing.
> > Thanks ;-)
> >
> > On Sat, Feb 9, 2019 at 8:27 AM Amirouche Boubekki
> >  wrote:
> > >
> > > Sorry! My test is not good. Ignore what I posted previously.
>

Re: Code coverage is broken

[Amirouche Boubekki]

with the attachement this time.

Le sam. 9 févr. 2019 à 18:10, Amirouche Boubekki <
amirouche.boube...@gmail.com> a écrit :

>
>
> Le sam. 9 févr. 2019 à 14:48, Nala Ginrut  a écrit :
>
>> I wonder if it's a bug that the FN was skipped.
>>
>
> Yes it is expected, see
> http://git.savannah.gnu.org/cgit/guile.git/tree/module/system/vm/coverage.scm#n309
>
> Here is a patch that take into account function coverage, it is rather
> slow.
>
> demo: https://screenshots.firefox.com/FmuctotjXTFRSiFW/null
>
> HTH
>
>
>> On Sat, Feb 9, 2019 at 10:51 AM Nala Ginrut  wrote:
>> >
>> > Never mind, it's better than mine, at least there're lines records,
>> > although functions calling are still missing.
>> > Thanks ;-)
>> >
>> > On Sat, Feb 9, 2019 at 8:27 AM Amirouche Boubekki
>> >  wrote:
>> > >
>> > > Sorry! My test is not good. Ignore what I posted previously.
>>
>
From d32da0570d3f6aa1857331c821ca071b0eca96f2 Mon Sep 17 00:00:00 2001
From: Amirouche 
Date: Sat, 9 Feb 2019 18:08:45 +0100
Subject: [PATCH] add function coverage


diff --git a/module/system/vm/coverage.scm b/module/system/vm/coverage.scm
index 0d51e261a..f151912f7 100644
--- a/module/system/vm/coverage.scm
+++ b/module/system/vm/coverage.scm
@@ -21,6 +21,7 @@
   #:use-module (system vm frame)
   #:use-module (system vm program)
   #:use-module (system vm debug)
+  #:use-module (system xref)
   #:use-module (ice-9 format)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-9)
@@ -309,11 +310,11 @@ gathered, even if their code was not executed."
   ;; FIXME: Re-enable this code, but using for-each-elf-symbol on each source
   ;; chunk.  Use that to build a map of file -> proc-addr + line + name.  Then
   ;; use something like procedure-execution-count to get the execution count.
-  #;
+
   (define (dump-function proc)
 ;; Dump source location and basic coverage data for PROC.
 (and (or (program? proc))
- (let ((sources (program-sources* data proc)))
+ (let ((sources (program-sources proc)))
(and (pair? sources)
 (let* ((line (source:line-for-user (car sources)))
(name (or (procedure-name proc)
@@ -330,8 +331,9 @@ gathered, even if their code was not executed."
 (if (string? path)
 (begin
   (format port "SF:~A~%" path)
-  #;
-  (for-each dump-function procs)
+  (let ((procs (file-procedures file)))
+(when procs
+  (for-each dump-function procs)))
   (for-each (lambda (line+count)
   (let ((line  (car line+count))
 (count (cdr line+count)))
diff --git a/module/system/xref.scm b/module/system/xref.scm
index e335f9481..d0ac49615 100644
--- a/module/system/xref.scm
+++ b/module/system/xref.scm
@@ -26,7 +26,8 @@
 procedure-callees
 procedure-callers
 source-closures
-source-procedures))
+source-procedures
+file-procedures))
 
 ;;;
 ;;; The cross-reference database: who calls whom.
@@ -371,3 +372,11 @@ pair of the form (module-name . variable-name), "
  (false-if-exception (open-input-file file
  (file (if port (port-filename port) file)))
 (lookup-source-procedures file line *sources-db*)))
+
+(define (lookup-procedures file-table)
+  (apply append (hash-fold (lambda (key value acc) (cons value acc)) '() file-table)))
+
+(define (file-procedures file)
+  "Retrieve all procedures defined in FILE. Can return multiple times the same procedure"
+  (ensure-sources-db #f)
+  (and=> (hash-ref *sources-db* file) lookup-procedures))
-- 
2.19.1

Re: make-c-struct and pointer->string

[Amirouche Boubekki]

Eventually, I can reproduced the issue with guile-next from guix:

scheme@(guile-user) [1]> (make-c-struct (list '* '*) (list (string->pointer
"hello ") (string->pointer "there!")))
$5 = #
scheme@(guile-user) [1]> (parse-c-struct $5 (list '* '*))
$6 = (# #)
scheme@(guile-user) [1]> (map pointer->string $6)
$7 = ("hello " "there!")
scheme@(guile-user) [1]> (make-c-struct (list '* '*) (list (string->pointer
"hello") (string->pointer "there!")))
$8 = #
scheme@(guile-user) [1]> (parse-c-struct $8 (list '* '*))
$9 = (# #)
scheme@(guile-user) [1]> (map pointer->string $9)
$10 = ("hello" "there!")
scheme@(guile-user) [1]> (make-c-struct (list '* '*) (list (string->pointer
"hello") (string->pointer "there!")))
$11 = #
scheme@(guile-user) [1]> (parse-c-struct $11 (list '* '*))
$12 = (# #)
scheme@(guile-user) [1]> (map pointer->string $12)
$13 = ("?<\"?\x0e\x7f" "@?f\x01")
scheme@(guile-user) [1]>
scheme@(guile-user)>


Le mar. 26 mars 2019 à 14:19, David Pirotte  a écrit :

> Hello,
>
> guile 2.2.4.1-cdb19
>
> ,use (system foreign)
>
> ;; this fails
>
> scheme@(guile-user)> (make-c-struct (list '* '*) (list (string->pointer
> "hello ") (string->pointer "there!")))
> $16 = #
> scheme@(guile-user)> (parse-c-struct $16 (list '* '*))
> $17 = (# #)
> scheme@(guile-user)> (map pointer->string $17)
> $18 = ("?g?գU" "`!?գU")
>
> ;; but this works
>
> scheme@(guile-user)> (map pointer->string (parse-c-struct (make-c-struct
> (list '* '*) (list (string->pointer "hello ") (string->pointer "there!")))
> (list '* '*)))
> $19 = ("hello " "there!")
>
>
> David
>

Bringing back gc-live-object-stats

[Amirouche Boubekki]

Hello all,


I am stuck with a memory leak. I think *gc-live-object-stats* [0] would
help.

[0]
https://www.gnu.org/software/guile/manual/html_node/Garbage-Collection-Functions.html#index-gc_002dlive_002dobject_002dstats

Can some explain to me how to bring it back?

Thanks in advance,


Amirouche ~ amz3

Re: Bringing back gc-live-object-stats

[Amirouche Boubekki]

Thanks for your reply.

Le jeu. 16 mai 2019 à 03:41, Mark H Weaver  a écrit :

> Amirouche Boubekki  writes:
>
> > I am stuck with a memory leak. I think gc-live-object-stats [0] would
> help.
> >
> > [0]
> https://www.gnu.org/software/guile/manual/html_node/Garbage-Collection-Functions.html#index-gc_002dlive_002dobject_002dstats
> >
> > Can some explain to me how to bring it back?
>
> Personally, I suggest finding another approach to debug your leak.
>

> I don't want to spend much time on this, because I suspect it would be a
> lot of work for questionable benefit, and it's not clear whether the
> result of that work will be acceptable to either libgc or Guile.  It
> might introduce too much added complexity or overhead.
>

Then it would be preferable to remove it from the manual.

My understanding of how GC works makes unlikely there is a leak
in the Guile code except particular cases that I don't know about,
but I tested some of those. For instance, dynamic-func pointers are
collected.

Also while experimenting with the official Python bindings, I discovered
that I did not setup proper eviction configuration which leads to something
that looks like a leak. In fact, it is just that wiredtiger can not keep up
with
the batch load in the default configuration.

Anyway, Thanks!

Re: landed r7rs support

[Amirouche Boubekki]

> On Sun, Nov 17, 2019 at 3:45 PM Andy Wingo  wrote:
>>
>> Hey all :)
>>
>> Just a little heads-up that I just landed R7RS support.  Thanks to Göran
>> Weinholt for akku-scm (https://gitlab.com/akkuscm/akku-r7rs/) and
>> OKUMURA Yuki for yuni (https://github.com/okuoku/yuni), off of which
>> some of these files were based.  (These projects are public domain /
>> CC0).


Le lun. 18 nov. 2019 à 13:43, Mikael Djurfeldt  a écrit :
>
> Wonderful!
>

+1

> Then I guess the texts in sections 9.1.5

link: https://www.gnu.org/software/guile/manual/guile.html#Status

> and 9.4.7

link: 
https://www.gnu.org/software/guile/manual/guile.html#Extending-the-Compiler

In that section, maybe add a note about a web assembly backend?

> in the manual should be updated? I would have submitted a patch if I knew 
> better how to reformulate.
>
> Best regards,
> Mikael
>

-- 
Amirouche ~ https://hyper.dev

Re: Mutating public bindings of a declarative module

[Amirouche Boubekki]

Le dim. 24 nov. 2019 à 18:54, Ludovic Courtès  a écrit :
>
> Hello!
>
> It seems that if you ‘set!’ a public variable of a declarative module,
> the change is visible to all the module users, but it’s not necessarily
> visible to procedures within that module, presumably because they use an
> inlined or specialized variant of that thing.
>
> I would have imagined that public bindings are considered mutable and
> thus not subject to inlining; OTOH, that would obviously be a loss, so
> the current approach makes sense.
>
> Anyway, it complicates a use case for me.  In Guix, we “mock” bindings
> like so:
>
>   (define-syntax-rule (mock (module proc replacement) body ...)
> "Within BODY, replace the definition of PROC from MODULE with the 
> definition
>   given by REPLACEMENT."
> (let* ((m (resolve-interface 'module))
>(original (module-ref m 'proc)))
>   (dynamic-wind
> (lambda () (module-set! m 'proc replacement))
> (lambda () body ...)
> (lambda () (module-set! m 'proc original)
>
> and that allows us to write tests that temporarily modify public (or
> private!) bindings.
>
> It seems like this could be addressed by compiling selected modules with
> ‘user-modules-declarative?’ set to #false, or by avoiding the above hack
> altogether when possible, but I thought I’d share my impressions and
> listen to what people think.  :-)
>

For what it is worth, in my project I take a different approach to
mock. Some may call it inversion-of-control of something like that.
Basically, everything that must be mocked is passed as a procedure.

For instance, in babelia there is a pool of thread worker with a
fibers mainthread. There is three primitives: initialize the thread
pool, apply a thunk in a worker, and for-each-par-map. During the
tests I can not run the pool of thread worker because of the #:drain
behavior [0], I could workaround it some other way like explained in
the ticket by Wingo.

[0] https://github.com/wingo/fibers/issues/30

Anyway, the other advantage of making the thread pool configurable is
that my OKVS abstraction is not tied to it. The full-text search
abstraction dubbed fts is passed `apply` and `for-each-map` as last
two arguments in the constructor:


  (define-record-type 
(make-fts engine ustore prefix limit apply for-each-map)
fts?
(engine fts-engine)
(prefix fts-prefix)
(ustore fts-ustore)
(limit fts-limit)
(apply %fts-apply)
(for-each-map %fts-for-each-map))

Then during the tests or else, I can pass custom implementations:

  (define (for-each-map sproc pproc lst)
(for-each sproc (map pproc lst)))

  (define fts (make-fts engine
ustore
'(test-fts-prefix)
1
(lambda (thunk) (apply thunk '())) ;; fts-apply
for-each-map))

Similarly, in OKVS SRFI, see [1], to make database engine swappable, I
rely on a similar pattern that was dubbed typeclass object by SRFI-128
(comparators). In those cases, the record instance contains only
procedures.

[1] 
https://github.com/scheme-requests-for-implementation/srfi-167/blob/master/srfi/engine.sld#L1

The approach I described, that boils down to passing a wanna be mocked
procedure as argument, can work.

> Thanks,
> Ludo’.

Hope this helps.

Re: For a cheaper ‘bytevector->pointer’

[Amirouche Boubekki]

Le dim. 24 nov. 2019 à 11:53, Ludovic Courtès  a écrit :
>
> Hello!
>
> A few days ago David was explaining on #guile how ‘bytevector->pointer’
> was generating too much garbage for his use case.  An idea we came up
> with was to embed the pointer object in the bytevector.

I would be very happy to have a more performant bytevector->pointer
for my OKVS work.

>
> The patch below does that but it leads to segfaults because I’m guessing
> there’s generated bytecode somewhere that still uses the wrong offset; I
> adjusted code that emits ‘pointer-ref/immediate’, what else did I miss?
>
> Also, since we disable internal pointers, we’d need to register an
> additional displacement, and I’m not sure if this is a good idea.
>
> Thoughts?
>
> Thanks,
> Ludo’.
>


-- 
Amirouche ~ https://hyper.dev

Re: GNU Guile 2.9.7 Released [beta]

[Amirouche Boubekki]

Le ven. 13 déc. 2019 à 14:31, Andy Wingo  a écrit :
>
> We are pleased to announce GNU Guile release 2.9.7.  This is the seventh
> and hopefully next-to-last pre-release of what will eventually become
> the 3.0 release series.

I tested with nomunofu v0.2.0 (http://hyper.dev/nomunofu-v0.2.0.tar.gz)

The import process is 2% faster using Guile 2.9.7 compared to Guile 2.9.6.

The import process is between 3 and 4 times slower a similar database
written in C called 4store. The import process is 5 times slower than
Virtuoso.

Those tests were done against a test file that is much smaller than memory.

Re: GNU Guile 2.9.7 Released [beta]

[Amirouche Boubekki]

Le sam. 14 déc. 2019 à 19:03, Amirouche Boubekki
 a écrit :
>
> Le ven. 13 déc. 2019 à 14:31, Andy Wingo  a écrit :
> >
> > We are pleased to announce GNU Guile release 2.9.7.  This is the seventh
> > and hopefully next-to-last pre-release of what will eventually become
> > the 3.0 release series.
>
> I tested with nomunofu v0.2.0 (http://hyper.dev/nomunofu-v0.2.0.tar.gz)
>
> The import process is 2% faster using Guile 2.9.7 compared to Guile 2.9.6.
>
> The import process is between 3 and 4 times slower a similar database
> written in C called 4store. The import process is 5 times slower than
> Virtuoso.
>
> Those tests were done against a test file that is much smaller than memory.

I did some tests against more data around 5GB with 32GB of RAM available.

The query with a cold cache is much faster using guile:

cold cache: 0.027838s
hot cache: 0.023536s

The timings for virtuoso with the same query on first start:

cold cache: 0.744s
hot cache: 0.008s

After restarting virtuoso, I got the following timings for the same query:

first query: 0.058s
second query: 0.008s

In the case the cache is cold, the query is 27 times faster with guile
nomunofu. After restarting virtuoso, guile-nomunofu first query is two
times faster.

Disclaimer: benchmarking is a dark art, take those numbers with a grain of salt.


-- 
Amirouche ~ https://hyper.dev

Re: landed r7rs support

[Amirouche Boubekki]

Le lun. 18 nov. 2019 à 12:43, Mikael Djurfeldt  a écrit :
>
> On Sun, Nov 17, 2019 at 3:45 PM Andy Wingo  wrote:
>>
>> Hey all :)
>>
>> The library syntax for R7RS is a subset of R6RS, so to use R7RS you just
>> (import (scheme base)) and off you go.  As with R6RS also, there are
>> some small lexical incompatibilities regarding hex escapes; see "R7RS
>> Incompatibilities" in the manual.  Also there is a --r7rs command-line
>> option.

I do not think the library syntax for R7RS is a _subset_ of R6RS.  For
one, it rely
on `define-library` instead of `library`.

For anyone trying to write (and benchmark!) code across scheme implementations,
you will have some luck with -x options:

  -x EXTENSION   add EXTENSION to the front of the load extensions

You can call guile with:

  guile -x .guille.scm ...

And use .guile.scm as an extension for guile specific files.

Also, in R6RS library form, the form `import` is not defined that is
you can not do:

(library (mylib)
  (export myfunc)
  (import (scheme base)) ...)

ref: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38760

Re: Logo baseline

[Amirouche Boubekki]

Le sam. 18 janv. 2020 à 15:14, Ludovic Courtès  a écrit :
>
> Hello Guilers!
>
> The Guile logo has this “GNU extension language” baseline.  As Guile 3
> came out, this baseline felt odd to me, not quite corresponding to the
> way I see Guile.
>
> Clearly, Guile is still an extension language, with many great
> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.), and I’m sure
> libguile is here to stay.  Yet, to me, “extension language” does not
> accurately capture what Guile today allows for and what people have been
> doing with it; since 2.0, it’s more than an extension language, even
> more so with the performance afforded by Guile 3.

I agree.

>
> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
>
>   GNU, fast, fun, functional
>

I think the term functional is overloaded and somewhat misleading
because Guile is NOT ONLY functional.
I would rather see "multi-paradigm" and / or "batteries included".

> What’s about you?  What’s Guile to you?  :-)

Guile is a fast dynamic programming language.

Re: Better HTTPS support in (web client)

[Amirouche Boubekki]

Le ven. 10 janv. 2020 à 16:56, Chris Vine  a écrit :
>
> Is the new implementation usable with suspendable ports?  When I last
> looked the read-response-body procedure was not, which meant that
> http-get and http-put were not, which meant that you could not really
> use them with fibers.

Is that because of get-bytevector-all is coded in C?

Re: clutter, clutter-glx [1.12.2] generating doc, 2 errors

[Amirouche Boubekki]

2014-04-13 14:58 GMT+02:00 Chris Vine :

> On Sat, 12 Apr 2014 23:28:18 -0300
> David Pirotte  wrote:
> > Hello,
> >
> >   I'm on guile (GNU Guile) 2.0.11.2-0ece4 now
> >
> > Although I did not update the wrapset.api yet, in order to get a
> > general picture of updating a clutter  binding
>
> Provide a binding for clutter's gobject-introspection interface and you
> will carry most other gobject based libraries with you.
>

True. There is already [1] that is meant to do it, I don't know if it still
works.

I imagine it would be a significant amount of work though.
>

I'm not sure about that. There are several such "bindings" in Python using
different approach (pure/non-pure, ctypes, cffi, cython,...) and targeting
different VMs (PyPy, CPython 3.x). Even if it's not easy there is a lot of
code to learn how to do it.


[1] https://gitorious.org/guile-gir (last commit 2011)