Re: Non-blocking web server

[Nala Ginrut]

Hi Ryan!
For the single-threaded non-blocking server in Guile, you have to make sure
at least 3 steps:
1. set socket to non-blocking
2. enable suspended ports to prepare delimited-continuation powered
coroutine
3. designed your own scheduler

Even in the single thread, you can handle requests concurrently because of
the coroutine based on delimited-continuation.

Of course you may enhance it with thread pool.


Best regards.


On Mon, Mar 25, 2024 at 4:04 AM Ryan Raymond  wrote:

> Hello, all.
> I was able to build a non-blocking web-server using network sockets.
> However, the existing guile web/server.scm implementation is
> single-threaded and therefore blocking, which is sub-optimal for some
> use-cases.
>
> I suggest we slightly modify the server logic to have an optional
> #:blocking? [bool] parameter which would enable behavior in line with the
> following excerpt from my own code. Obviously some changes would be made to
> methodology and code style, but you get the picture.
>
> (define (listen sock)
>   (let* (
> (client-connection (accept sock))
> (client-details (cdr client-connection))
> (client (car client-connection)))
> (begin-thread
>   (sigaction SIGPIPE SIG_IGN)
>   (handle client)
>   (close client))
> ))
>
> This shouldn't cause any backwards-compatibility issues since it's
> optional, but the specifics of web/server.scm might cause problems.
> Let me know what you think!
> Ryan
>

Re: Make the pkgconfig file of Guile relocatable.

[Nala Ginrut]

hi Zihao!

I think the substitution is OK.
But if you want to package for Guix, you need to go Guix way.
Guix package has made a similar approach, for example, you may check "guix
edit artanis" to see how it substitutes the dir for Artanis.

Best regards.



On Mon, Feb 28, 2022 at 12:27 AM Zhu Zihao  wrote:

>
> Currently, the guile-3.0.pc.in in 'meta' use the variable substitution
> directly.
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> bindir=@bindir@
> libdir=@libdir@
> includedir=@includedir@
> datarootdir=@datarootdir@
> datadir=@datadir@
> pkgdatadir=@datadir@/guile
> pkgincludedir=@includedir@/guile
>
> sitedir=@sitedir@
> extensiondir=@libdir@/guile/@GUILE_EFFECTIVE_VERSION@/extensions
> siteccachedir=@libdir@/guile/@GUILE_EFFECTIVE_VERSION@/site-ccache
> libguileinterface=@LIBGUILE_INTERFACE@
>
> sitedir, siteccachedir and extensiondir will be subsituted to the full
> path of the install path of Guile.
>
> But sometimes I want to install guile module in different
> prefix(e.g. NixOS, Guix, flatpak). I have to adjust these variable
> manually.
>
> My idea is change the definition of sitedir, siteccachedir, extensiondir
> use the variable substition of pkg-config instead of autotools.
>
> For example
>
> sitedir=${datadir}/guile/site/@GUILE_EFFECTIVE_VERSION@
> siteccachedir=${libdir}/guile/@GUILE_EFFECTIVE_VERSION@/extensions
>
> 
>
> So I can use
>
> pkg-config guile-3.0 --define-variable=libdir=$MY_PREFIX
> --variable=siteccachedir
>
> to get the correct install directory.
>
> Thoughts?
> --
> Retrieve my PGP public key:
>
>   gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F
>
> Zihao
>

Re: Implementing ES6 on top of Guile

[Nala Ginrut]

Sorry, "it's mostly ES6".

On Tue, Jul 6, 2021, 15:48 Nala Ginrut  wrote:

> Hi Ayush!
> I have some experiences to write language frontend on Guile.
> Here are posts and project you can take a look, they could be helpful to
> you.
>
>
> https://nalaginrut.com/archives/2016/09/05/a-preview-of-guile-lua-%28rebirth%29%2c-and-some-opinions-
>
> https://gitlab.com/NalaGinrut/guile-lua-rebirth
>
> https://nalaginrut.com/archives/2014/04/15/simple%2c-but-not-so-simple
>
> I actually have a very preliminary project to implement ES10, however, I
> never have time to finish it since I started my own company.
>
> ES10 has small fixes compared with ES6, so it's mostly ES10. Anyway,
> JavaScript is a big language to implement.
>
> I'm still interested in JavaScript frontend. I can answer questions as I
> can if you really want to make your hands dirty.
>
> Best regards.
>
>
> On Mon, Jul 5, 2021, 21:48 Ayush Jha  wrote:
>
>> The issue:
>>
>> I found an implementation of ECMAScript on Guile in the docs, and I was
>> wondering if anyone is working on improving it/building an alternative.
>>
>> I would love to get started on it. What is the status of the ECMAScript
>> implementation project as of now?
>>
>>
>> My Background:
>>
>> I am very new to the Guile project. I have written scripts in Guile and
>> have dabbled in the source code, but over all - I am fairly new to the
>> project.
>>
>>
>>
>>
>> --
>> Regards,
>> Ayush Jha
>>
>>
>>

Re: Implementing ES6 on top of Guile

[Nala Ginrut]

Hi Ayush!
I have some experiences to write language frontend on Guile.
Here are posts and project you can take a look, they could be helpful to
you.

https://nalaginrut.com/archives/2016/09/05/a-preview-of-guile-lua-%28rebirth%29%2c-and-some-opinions-

https://gitlab.com/NalaGinrut/guile-lua-rebirth

https://nalaginrut.com/archives/2014/04/15/simple%2c-but-not-so-simple

I actually have a very preliminary project to implement ES10, however, I
never have time to finish it since I started my own company.

ES10 has small fixes compared with ES6, so it's mostly ES10. Anyway,
JavaScript is a big language to implement.

I'm still interested in JavaScript frontend. I can answer questions as I
can if you really want to make your hands dirty.

Best regards.


On Mon, Jul 5, 2021, 21:48 Ayush Jha  wrote:

> The issue:
>
> I found an implementation of ECMAScript on Guile in the docs, and I was
> wondering if anyone is working on improving it/building an alternative.
>
> I would love to get started on it. What is the status of the ECMAScript
> implementation project as of now?
>
>
> My Background:
>
> I am very new to the Guile project. I have written scripts in Guile and
> have dabbled in the source code, but over all - I am fairly new to the
> project.
>
>
>
>
> --
> Regards,
> Ayush Jha
>
>
>

Re: Python-on-guile

[Nala Ginrut]

Nice to know it!
I still don't have time to polish my guile-lua-rebirth. Anyway, it's really
good news to see the transpiler has a good performance on Guile.!

Best regards.


On Fri, Apr 23, 2021 at 11:01 PM Mikael Djurfeldt 
wrote:

> Hi,
>
> Yesterday, Andy committed new code to the compiler, some of which
> concerned skipping some arity checking.
>
> Also, Stefan meanwhile committed something called "reworked object system"
> to his python-on-guile.
>
> Sorry for coming with unspecific information (don't have time to track
> down the details) but I noticed that my benchmark script written in Python,
> and which computes the 20:th Ramanujan number, now runs 60% faster than
> before these changes.
>
> This means that python-on-guile running on guile3 master executes python
> code only 2.6 times slower than the CPython python3 interpreter itself. :-)
>
> Have a nice weekend all,
> Mikael
>
>

Re: The r6rs record-type in pattern matching of Guile-3.0

[Nala Ginrut]

To whom may care this issue.
According to the discussion in IRC, here's the memo for the issue, in case
anybody encounter the same issue again:

The record is not nested inherited anymore, this would be the permanent
change.
The good thing is better performance to access record-type, the bad thing
is the incompatibility.
If anyone use pattern-matching for parsing parent of a record-type, then
it'll break.

There are probably two workarounds to keep your current code if you use
pattern-matching for parsing parent.
1. Copy and maintain the old record code:
 (rnrs records procedural) and (rnrs records syntactic) from
73d0a3bccb3c2b79d7f0e3aaca88a84f3a5c3f43

2. The r6rs record-type is powerful so that you may customize it by
redefine its constructor to always put its parent to the first field.
So that pattern-matching can correctly parse the parent in its assumed
first field.

>From 3.0, you can't bind the parent of record type in the same matching
case, the parent (super class) would be is-A relationship,
not the previous has-A relationship, so that the parent (super class) is
not nested in the record-type anymore. The inherited fields
are the parts of the record-type (subclass) from now on, which would be
faster for access, obviously.

Best regards.


On Tue, Aug 25, 2020 at 4:16 AM Nala Ginrut  wrote:

> Hi folks!
> I found the r6rs record pattern matching has different results compared to
> Guile-2.
> Here is the example code:
>
>
> -code--
> ,use (rnrs)
> ,use (ice-9 match)
>
> (define-record-type aaa (fields a))
> (define-record-type bbb (parent aaa) (fields b))
> (define r (make-bbb 1 2))
>
> (match r
>   (($ bbb ($ aaa _ a) b) (list a b))
>   (else "no"))
> ;; ==> "no"  in Guile-3
> ;; ===> (1 2) in Guile-2
>
> (match r
>   (($ bbb a b) (list a b))
>   (else "no"))
> ==> (1 2)  in Guile-3
> ==> ( 2) in Guile-2
>
> end--
>
> In Guile-2, we have to specify the parent record-type for binding the
> fields of the parent, but it seems not in Guile-3.0.
> I know Guile-3 had tweaked record-type to unify the low-level
> implementation.
>
> My question: Is this the new expected activity? Do we have to tweak all
> record type matching since Guile-3 ?
> Or maybe it's just a bug?
>
> Best regards.
>
>

The r6rs record-type in pattern matching of Guile-3.0

[Nala Ginrut]

Hi folks!
I found the r6rs record pattern matching has different results compared to
Guile-2.
Here is the example code:

-code--
,use (rnrs)
,use (ice-9 match)

(define-record-type aaa (fields a))
(define-record-type bbb (parent aaa) (fields b))
(define r (make-bbb 1 2))

(match r
  (($ bbb ($ aaa _ a) b) (list a b))
  (else "no"))
;; ==> "no"  in Guile-3
;; ===> (1 2) in Guile-2

(match r
  (($ bbb a b) (list a b))
  (else "no"))
==> (1 2)  in Guile-3
==> ( 2) in Guile-2
end--

In Guile-2, we have to specify the parent record-type for binding the
fields of the parent, but it seems not in Guile-3.0.
I know Guile-3 had tweaked record-type to unify the low-level
implementation.

My question: Is this the new expected activity? Do we have to tweak all
record type matching since Guile-3 ?
Or maybe it's just a bug?

Best regards.

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

@Andy Wingo 
It's my mistake to call an incompatible constructor after I updated the
interfaces. I think Guile-3 made more strict checking because this mistake
wasn't caught before 2.9.

Now folks may use docker to try Artanis on Guile-3

docker pull registry.gitlab.com/nalaginrut/artanis:latest

Best regards.



On Sun, Jan 19, 2020 at 3:43 AM Nala Ginrut  wrote:

> Just a report, the same compiling error existing in Guile-3.0.0.
>
> Best regards.
>
>
> On Tue, Jan 14, 2020 at 4:49 PM Nala Ginrut  wrote:
>
>> Hi Wingo!
>> Here're update:
>> 1. 2.9.9 didn't fix this issue
>>
>> 2. I imported r6rs record-type in (artanis utils), and this module was
>> imported in almost every artanis modules.
>> I do use r6rs specific record API to introspect the internal things for
>> debugging in Artanis.
>> And I imported r6rs define-record-type in server-context.scm
>> I guess there're some name conflicting.
>>
>>
>>
>> On Sat, Jan 11, 2020 at 6:33 PM Andy Wingo  wrote:
>>
>>> On Wed 08 Jan 2020 15:22, Nala Ginrut  writes:
>>>
>>> > In unknown file:
>>> >4 (primitive-load-path "artanis/server/server-context" #<…>)
>>> > In ice-9/eval.scm:
>>> >626:19  3 (_ #)
>>> > 155:9  2 (_ #)
>>> > In ice-9/boot-9.scm:
>>> >   1153:19  1 (_ _ _ _ _ _ _)
>>> >   1655:16  0 (raise-exception _ #:continuable? _)
>>> >
>>> > ice-9/boot-9.scm:1655:16: In procedure raise-exception:
>>> > Wrong number of arguments to #>> ice-9/boot-9.scm:1153:19 (a b c d e f)>
>>> >
>>> 
>>> >
>>> > Any hint that I can figure out whait's incompatible?
>>>
>>> Gosh we need to improve this info.  Anyway the procedure at
>>> boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
>>> Apparently somewhere in (artanis server server-context) is calling it
>>> with the wrong number of arguments.  What do you use for records?  Do
>>> you have your own abstraction or do you use R6RS records or something?
>>> Perhaps something in artanis relied on the way that R6RS records used to
>>> implement single inheritance, as a chain of objects instead of a flat
>>> record.  Or perhaps the adaptations to R6RS records in Guile introduced
>>> a bug.  I am interested to know the answer :)
>>>
>>> Andy
>>>
>>

Strange activity in Guile-3.0.0 record-type

[Nala Ginrut]

Here's a simple test:

---mm.scm---
(define-module (mm)
  #:use-module ((rnrs) #:select (define-record-type)))

(define-record-type aaa)
(define-record-type bbb)
--end

When I import (mm) module, there's a warning:
---
mm.scm:6:0: warning: shadows previous definition of
`dummy-1a78708d3c9406a3' at mm.scm:4:0
---

It seems aaa was overwritten by bbb.

Comments?

Best regards.

Re: Announcing the first stable release of guile-for-loops

[Nala Ginrut]

+1

On Fri, Jan 24, 2020, 20:13 Stefan Israelsson Tampe 
wrote:

>
>
> -- Forwarded message -
> From: Stefan Israelsson Tampe 
> Date: Fri, Jan 24, 2020 at 12:42 PM
> Subject: Re: Announcing the first stable release of guile-for-loops
> To: Linus Björnstam 
>
>
> Would be cool to have those implemented in guile, that would make my
> guile-syntax-parse a bit leaner
>
> Regards
> Stefan
>
> On Thu, Jan 23, 2020 at 3:03 PM Linus Björnstam <
> linus.bjorns...@veryfast.biz> wrote:
>
>> Hiya everybody!
>>
>> I have spent some time implementing efficient for loops for guile, and
>> they are baked and ready to go. I have worked the last weeks at
>> implementing generalized support for non-tail-recursive loops and am happy
>> to announce for/foldr. It is a generic right fold, with support for
>> delaying it's arguments as either thunks or promises.
>>
>> The syntax is more or less the same as racket's loops, and they are
>> generally compatible. The code generated is for almost all cases as fast as
>> hand-rolled code. They are all expressed as left or right folds, and are as
>> such (apart from for/list, but read about that in the documentation) free
>> of mutation. They are all converted to named lets.
>>
>> Some examples:
>>
>> (for/list ((a (in-range 1 6)))
>>   (* a a)) ;; => (1 4 9 16 25)
>>
>> (for*/list ((a (in-string "ab")) (b (in-range 1 3)))
>>   (list a b))
>> ;; => ((#\a 1) (#\a 2) (#\b 1) (#\b 2))
>>
>> There are many more looping constructs, among others:
>> for/sum, for/vector, for/or, for/and, for/first, for/last and a
>> side-effecting simple for.
>>
>> Here is a sieve of erathostenes:
>>
>> (define (erathostenes n)
>>   (define vec (make-vector n #t))
>>   (for/list ([i (in-range 2 n)] #:when (vector-ref vec i))
>> (for ([j (in-range/incr (* 2 i) n i)])
>>   (vector-set! vec j #f))
>> i))
>>
>> The code and documentation is available here:
>> https://hg.sr.ht/~bjoli/guile-for-loops
>>
>> A web-friendly documentation can be found here:
>> https://man.sr.ht/%7Ebjoli/for-loops-docs/for-loops.md
>>
>> The thing I had been waiting for is right fold. That allows us to write
>> loops like guile's map: non-tail recursive:
>> (for/foldr ((identity '())) ((a (in-list '(1 2 3
>>   (cons (* a a) identity))
>>
>> becomes equivalent to:
>>
>> (let loop ((random-identifier '(1 2 3)))
>>   (if (null? random-identifier)
>>   '()
>>   (let ((a (car random-identifier)))
>> (cons (* a a) (loop (cdr random-identifier))
>>
>> Happy hacking
>> Linus Björnstam
>>
>>

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

Just a report, the same compiling error existing in Guile-3.0.0.

Best regards.


On Tue, Jan 14, 2020 at 4:49 PM Nala Ginrut  wrote:

> Hi Wingo!
> Here're update:
> 1. 2.9.9 didn't fix this issue
>
> 2. I imported r6rs record-type in (artanis utils), and this module was
> imported in almost every artanis modules.
> I do use r6rs specific record API to introspect the internal things for
> debugging in Artanis.
> And I imported r6rs define-record-type in server-context.scm
> I guess there're some name conflicting.
>
>
>
> On Sat, Jan 11, 2020 at 6:33 PM Andy Wingo  wrote:
>
>> On Wed 08 Jan 2020 15:22, Nala Ginrut  writes:
>>
>> > In unknown file:
>> >4 (primitive-load-path "artanis/server/server-context" #<…>)
>> > In ice-9/eval.scm:
>> >626:19  3 (_ #)
>> > 155:9  2 (_ #)
>> > In ice-9/boot-9.scm:
>> >   1153:19  1 (_ _ _ _ _ _ _)
>> >   1655:16  0 (raise-exception _ #:continuable? _)
>> >
>> > ice-9/boot-9.scm:1655:16: In procedure raise-exception:
>> > Wrong number of arguments to #> ice-9/boot-9.scm:1153:19 (a b c d e f)>
>> >
>> 
>> >
>> > Any hint that I can figure out whait's incompatible?
>>
>> Gosh we need to improve this info.  Anyway the procedure at
>> boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
>> Apparently somewhere in (artanis server server-context) is calling it
>> with the wrong number of arguments.  What do you use for records?  Do
>> you have your own abstraction or do you use R6RS records or something?
>> Perhaps something in artanis relied on the way that R6RS records used to
>> implement single inheritance, as a chain of objects instead of a flat
>> record.  Or perhaps the adaptations to R6RS records in Guile introduced
>> a bug.  I am interested to know the answer :)
>>
>> Andy
>>
>

Re: Logo baseline

[Nala Ginrut]

On Sat, Jan 18, 2020 at 10:14 PM Ludovic Courtès  wrote:

> Hello Guilers!
>

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.
>
>
That's true, "GNU extension language" is just part of its features right
now.
And the "extension language" can't define Guile anymore, because Guile is a
productive implementation of Scheme programming language,
a web development language, a system level scripting language, and a
platform to support several different dynamic languages.



> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
>
>   GNU, fast, fun, functional
>
>
Although functional is just one of facinating features of Guile Scheme,
it's still a good selling point to introduce it to other people.



> What’s about you?  What’s Guile to you?  :-)
>
>
Guile is a modern Scheme implementation that can solve real problems in the
industry. There's a joke that Scheme is the only language that the number
of implementations
are more than the users. But I would say, Guile can help people to solve
real program in product level.
And as some people here may know, I've been always a big fan to treat Guile
as a platform for various language transpilers.
I don't know what's the proper slogan now, to me, Guile is more like a
hacking engine rather than a language.

Best regards.

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

Hi Wingo!
Here're update:
1. 2.9.9 didn't fix this issue

2. I imported r6rs record-type in (artanis utils), and this module was
imported in almost every artanis modules.
I do use r6rs specific record API to introspect the internal things for
debugging in Artanis.
And I imported r6rs define-record-type in server-context.scm
I guess there're some name conflicting.



On Sat, Jan 11, 2020 at 6:33 PM Andy Wingo  wrote:

> On Wed 08 Jan 2020 15:22, Nala Ginrut  writes:
>
> > In unknown file:
> >4 (primitive-load-path "artanis/server/server-context" #<…>)
> > In ice-9/eval.scm:
> >626:19  3 (_ #)
> > 155:9  2 (_ #)
> > In ice-9/boot-9.scm:
> >   1153:19  1 (_ _ _ _ _ _ _)
> >   1655:16  0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1655:16: In procedure raise-exception:
> > Wrong number of arguments to # ice-9/boot-9.scm:1153:19 (a b c d e f)>
> >
> 
> >
> > Any hint that I can figure out whait's incompatible?
>
> Gosh we need to improve this info.  Anyway the procedure at
> boot-9.scm:1153:19 is a record constructor, for a record with 6 fields.
> Apparently somewhere in (artanis server server-context) is calling it
> with the wrong number of arguments.  What do you use for records?  Do
> you have your own abstraction or do you use R6RS records or something?
> Perhaps something in artanis relied on the way that R6RS records used to
> implement single inheritance, as a chain of objects instead of a flat
> record.  Or perhaps the adaptations to R6RS records in Guile introduced
> a bug.  I am interested to know the answer :)
>
> Andy
>

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

When I was trying to compile Artanis with Guile-2.9.8, it throw error like
this:
---
WARNING: (artanis utils): imported module (rnrs) overrides core binding
`record-accessor'
Backtrace:
In ice-9/psyntax.scm:
   285:10 19 (parse _ (("placeholder" placeholder)) (()) _ c (eval) …)
In ice-9/eval.scm:
   293:34 18 (_ #)
In ice-9/boot-9.scm:
   3366:4 17 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
  3379:24 16 (_)
   222:29 15 (map1 (((artanis utils)) ((artanis config)) ((# #)) # …))
   222:29 14 (map1 (((artanis config)) ((artanis irregex)) ((# …)) …))
   222:29 13 (map1 (((artanis irregex)) ((artanis server #)) ((…)) …))
   222:17 12 (map1 (((artanis server server-context)) ((artanis …)) …))
  3283:17 11 (resolve-interface (artanis server server-context) # _ # …)
In ice-9/threads.scm:
390:8 10 (_ _)
In ice-9/boot-9.scm:
  3209:13  9 (_)
In ice-9/threads.scm:
390:8  8 (_ _)
In ice-9/boot-9.scm:
  3493:20  7 (_)
   2792:4  6 (save-module-excursion #)
  3513:26  5 (_)
In unknown file:
   4 (primitive-load-path "artanis/server/server-context" #<…>)
In ice-9/eval.scm:
   626:19  3 (_ #)
155:9  2 (_ #)
In ice-9/boot-9.scm:
  1153:19  1 (_ _ _ _ _ _ _)
  1655:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1655:16: In procedure raise-exception:
Wrong number of arguments to #


Any hint that I can figure out whait's incompatible?

Thanks!



On Wed, Jan 8, 2020 at 5:43 AM Andy Wingo  wrote:

> On Tue 07 Jan 2020 21:00, Stefan Israelsson Tampe 
> writes:
>
> > Bump!
> >
> > Great, but loading an extension like:
> >
> > (catch #t
> >   (lambda ()
> > (throw #t)
> > (load-extension "libguile-persist" "persist_init") (pk 1))
> >   (lambda x
> > (let ((file
> >(%search-load-path "src/.libs/libguile-persist.so")))
> >   (if
> >file
> >(catch #t
> >  (lambda ()
> >(load-extension file "persist_init"))
> >  (lambda x
> >(warn
> > "libguile-persist is not loadable!")))
> >(warn
> > "libguile-persist is not present, did you forget to make
> it?")
> >
> > And then have  line like
> >
> > (pk 5 serialize-vm-ra)
> >
> > Loading this module prints
> > (5 #f)
> >
> > Worked in releases before.
>
> Surely this test case can be shortened?  All the load-extension bits
> appear to not be necessary, right?
>
> Andy
>
>

Re: SHA256 performance with Guile 2.2 vs. Guile 3.0

[Nala Ginrut]

Congrats!
I just replaced Weinholt's hmac implementation with NSS binding for product
consideration, but nice to know this great result! And thanks to Weinholt's
work, Artanis had been relying on it for many years.

Best regards.


On Sat, Jan 4, 2020, 18:36 Göran Weinholt  wrote:

> Ludovic Courtès  writes:
>
> > Ludovic Courtès  skribis:
> >
> >> ludo@ribbon ~/src/guix$ ./pre-inst-env guix environment --pure
> --ad-hoc guile-next guile3.0-hashing -- guile ~/tmp/sha256.scm
> >>
> >> ;;; (hash
> "b33576331465a60b003573541bf3b1c205936a16c407bc69f8419a527bf5c988")
> >> clock utime stime cutime cstime gctime
> >> 65.17 89.75  0.45   0.00   0.00  35.63
> >
> > The patch below gives us:
> >
> > ludo@ribbon /tmp/hashing$ guile --r6rs -L .. ~/tmp/sha256.scm
> >
> > ;;; (hash
> "b33576331465a60b003573541bf3b1c205936a16c407bc69f8419a527bf5c988")
> > clock utime stime cutime cstime gctime
> > 59.31 80.65  0.39   0.00   0.00  30.73
> >
> > It’s a disappointingly small improvement.  The reason is that (hashing
> > fixnums) adds another layer of opacity, where it ends up doing
> > essentially:
> >
> >   (define fx32xor fxxor)
> >   …
> >
> > Thus, no inlining, and no easy trick to solve that.  :-/
>
> I've pushed a Guile-specific version of (hashing fixnums) that inlines
> the generic arithmetic procedures. This and some other small changes
> improved the runtime:
>
>clock utime stime cutime cstime gctime
>  before:
> 2.2.6  31.06 32.61  0.03   0.00   0.00   1.38
> 2.9.8  15.55 16.23  0.01   0.00   0.00   1.19
>  after:
> 2.2.6   2.95  3.01  0.00   0.00   0.00   0.10
> 2.9.8   1.98  1.99  0.00   0.00   0.00   0.08
>
> That's about 100 times slower than sha256sum from coreutils. You might
> get some more performance out of it by unrolling the loop in
> sha-256-transform!.
>
> Regards,
>
> --
> Göran Weinholt   | https://weinholt.se/
> Debian developer | 73 de SA6CJK
>
>

Re: GNU Guile 2.9.8 Released [beta]

[Nala Ginrut]

When I was trying to compile Artanis, the configure threw an error:

checking for Guile version >= 3.0... configure: error: Guile 3.0 required,
but 2.9.8 found


Here's what I put in configure.ac:
GUILE_PKG(2.2 2.3 2.9 3.0)

My question is "what's the correct config here"?

Best regards.



On Thu, Jan 2, 2020 at 9:37 PM Andy Wingo  wrote:

> We are pleased to announce GNU Guile release 2.9.8.  This is the eighth
> and possibly final pre-release of what will eventually become the 3.0
> release series.
>
> Compared to the current stable series (2.2.x), the future Guile 3.0 adds
> support for just-in-time native code generation, speeding up all Guile
> programs.  See the NEWS extract at the end of the mail for full details.
>
> Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a bug in
> libguile that caused writes to unmapped memory in some circumstances.
> This problem manifested itself as a failure of Guile to compile itself
> on some systems, notably Ubuntu 18.04 on x86-64.  It also fixes a couple
> warnings related to SRFI-35.
>
> The current plan is to make a 3.0.0 final release on 17 January 2020.
> We may need another prerelease in the interim.  It's a good time to test
> the prereleases to make sure they work on your platform.  Please send
> any build reports (success or failure) to guile-devel@gnu.org, along
> with platform details.  You can file a bug by sending mail to
> bug-gu...@gnu.org.
>
> The Guile web page is located at http://gnu.org/software/guile/, and
> among other things, it contains a copy of the Guile manual and pointers
> to more resources.
>
> Guile is an implementation of the Scheme programming language, with
> support for many SRFIs, packaged for use in a wide variety of
> environments.  In addition to implementing the R5RS Scheme standard,
> Guile includes a module system, full access to POSIX system calls,
> networking support, multiple threads, dynamic linking, a foreign
> function call interface, and powerful string processing.
>
> Guile can run interactively, as a script interpreter, and as a Scheme
> compiler to VM bytecode.  It is also packaged as a library so that
> applications can easily incorporate a complete Scheme interpreter/VM.
> An application can use Guile as an extension language, a clean and
> powerful configuration language, or as multi-purpose "glue" to connect
> primitives provided by the application.  It is easy to call Scheme code
> From C code and vice versa.  Applications can add new functions, data
> types, control structures, and even syntax to Guile, to create a
> domain-specific language tailored to the task at hand.
>
> Guile 2.9.8 can be installed in parallel with Guile 2.2.x; see
>
> http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html
> .
>
> A more detailed NEWS summary follows these details on how to get the
> Guile sources.
>
> Here are the compressed sources:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.lz   (10MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz   (12MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz   (21MB)
>
> Here are the GPG detached signatures[*]:
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.lz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz.sig
>
> Use a mirror for higher download bandwidth:
>   http://www.gnu.org/order/ftp.html
>
> Here are the SHA256 checksums:
>
>   3ce11e9dca0f475fa944729d99f33c379fe8962e729bd21a99470249624c71d7
> guile-2.9.8.tar.lz
>   4a8cf663b8bfd435168935c74a8ec434328ffad16230322c64f0ac567dda2c26
> guile-2.9.8.tar.xz
>   31c3d458ff9342db130e27c8d82d2a33912da92845e5ee431b6a125971a823d2
> guile-2.9.8.tar.gz
>
> [*] 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-2.9.8.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
> 4FD4D288D445934E0A14F9A5A8803732E4436885
>
> and rerun the 'gpg --verify' command.
>
> This release was bootstrapped with the following tools:
>   Autoconf 2.69
>   Automake 1.16.1
>   Libtool 2.4.6
>   Gnulib v0.1-1157-gb03f418
>   Makeinfo 6.5
>
> An extract from NEWS follows.
>
>
> Changes in alpha 2.9.8 (since alpha 2.9.7):
>
> * Bug fixes
>
> ** Fix bug in which abort_to_prompt used an invalid stack pointer
>
> This bug manifested itself as a bootstrap compile error on some systems,
> notably Ubuntu 18.04 on x86-64, and was due to failing to recalculate a
> local variable after a possible stack relocation.
>
> ** SRFI-35 does a #:re-export-and-replace on `'
> ** SRFI-35 avoids compiler warnings for multiply-defined condition types
>
>
> Changes in alpha 2.9.x (since the stable 2.2 series):
>
> 

Re: draft 3.0 release schedule

[Nala Ginrut]

Finally!

On Thu, Dec 12, 2019, 05:27 Andy Wingo  wrote:

> Hi,
>
> I've been trying to put out releases on an every-other-Friday schedule.
> Due to holidays I will probably bump this next one (2.9.7) up to this
> Friday.  Current plan would then be to do 2.9.8 on 3 January 2020, and
> then if all goes well 3.0.0 on 17 January 2020.
>
> Cheers,
>
> Andy
>
>

Re: landed r7rs support

[Nala Ginrut]

On Tue, Nov 19, 2019, 03:34 Amirouche Boubekki 
wrote;

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

+1
In the past decade, we've gotten some experiences about compiler frontend
around the Guile community. However, Guile is so powerful that we can also
add backend in a elegant way. It's better to mention it explicitly, and
it's deserved to have more information jn the manual.

Best regards.

Re: guile 3 update, halloween edition

[Nala Ginrut]

Hi Andy! Thanks for all the work!

On Thu, Oct 31, 2019 at 4:55 AM Andy Wingo  wrote:

> Hey folks!
>
> I wanted to send out an update on Guile 3.  Do take a look at
> https://git.savannah.gnu.org/cgit/guile.git/tree/NEWS to see where we've
> come; basically the JIT is done, and we're ready to release soonish.
>

Guile powered by JIT was confirmed to increase at least 20% performance for
Artanis.
And this is a rough result of the early-bird version of Guile-2.9. I
haven't tried the latest.
I'm looking forward to an official release of Guile-3 so that I can manage
to support the version detection correctly. It was 2.9 but should detect as
3.0, IIRC.



> But!  Now we have bootstrapping problems; how to get the implementation
> in boot-9?  Exceptions in SRFI-35, R6RS, R7RS, and Racket are these
> hierarchical things: they form a DAG of subtypes.  But core records in
> Guile aren't subtypeable, so what to do?
>

Are you talking about Guile specific record-type?
Personally, I've gradually reduced my usage of Guile records. I think R6RS
records are better for me.
I didn't know the Guile bootstrapping requires Guile specific record-type.
So I don't know better advice.


> There will be bijections
> between a Guile's "throw" arguments and structured exceptions, mostly
> inspired with what Julian did in the R6RS layer already.
>

That's cool!


> Thoughts welcome!  Also: should these structured error objects be named
> exceptions or conditions?  SRFI-35, R6RS, and R7RS say "conditions", but
> racket and my heart say "exceptions"; wdyt?
>

I never say "condition" to describe an exception. I always say "exception".
Most other languages use "exception" too. The term "condition" sounds like
conditional branching.

Best regards.

Re: Contributions to “Guile Studio”

[Nala Ginrut]

I just want to say thank you to all the contributors!
I'm trying to do some efforts to make Guile more friendly to newbies,
guile-studio seems a good thing to help them to get a start.

Best regards.


On Tue, Oct 29, 2019 at 2:40 AM Ricardo Wurmus  wrote:

>
> Hi Mark,
>
> I’m glad you consider this to be useful!
>
> >> Guile Studio is not supposed to be yet another pre-configured Emacs; its
> >> goal is just to provide a comfortable environment that works best for
> >> playing with Guile.  I’d like to have less surprising window management,
> >> but I don’t know of any clear, simple and obvious solution.  I just
> >> don’t want windows to pop up and seemingly replace others, and I want
> >> the management of how windows are arranged to be done manually and via
> >> simple buttons.  Any ideas about how to achieve this?
> >
> > I wonder if the Emacs community would be a good place to ask.
> > What do you think?
>
> I should do that; it’s just that I’m not really sure of what exactly I
> want here.  There are countless solutions (like setting windows to be
> dedicated, for example), but each of them comes with potential
> drawbacks.  I would need to know what “less surprising” really means to
> me (and inexperienced users), so that I can evaluate the drawbacks and
> constrain the set of solutions.
>
> Perhaps the new tabs feature that is now available in the latest
> unreleased version of Emacs might be of interest here.
>
> --
> Ricardo
>
>
>

Re: conflicts in the gnu project now affect guile

[Nala Ginrut]

On Sun, Oct 20, 2019 at 11:10 AM Mark H Weaver  wrote:

> It might create more divisions between us, at a time when we should be
> focused on healing our wounds and coming together as a community.  I'd
> be glad to discuss it later.
>
>
+1
I agree that let's keep friendly just like before, after all, at least in
Guile community, there're no essential conflicts among us.
Some words or proposals may be still meaningful, but maybe delay them after
we healed our wounds by these misunderstandings.
Thank you all!

Best regards.



>   Thanks,
> Mark
>
>

Re: conflicts in the gnu project now affect guile

[Nala Ginrut]

hi Andy, I think Mark has explained something, I hope you can rethink about
it calmly. It seems a misunderstanding.

A decade ago I came to Guile community, and I've learned many things from
the people here. Andy, Mark, and Ludo are the people I really respect.
However, someday if they start to blame each other, what can I do now?
No one can keep a very good relationship after so many years of
cooperation. Obviously, in a cooperation relationship, there're always
compromises and misunderstandings.

I think I can understand why many people dislike RMS. When I become a GNU
maintainer and start the first conversation, I realized RMS is not so easy
to talk.
IIRC, when I first time to contact RMS with mails, at least the first 20
private emails are quarrels. ;-)
However, I still find a way to work with him, because I think his paranoia
is the essential factor to push free software so far.

So if anyone dislikes RMS because of that, I fully understand you and I
don't think you have to endure. You may find your way out.
But I don't think the moral concerns and personal life should affect a
technical community. We're different people from different cultures.
Please let me remind that LGBT was considered immoral previously. Let's be
more diversity.

I gradually realized that people blame RMS recently is not because of his
misinterpreted comments, it's trivial, just an excuse. I think some people
just can't endure RMS, that's the essential reason. I don't know, I'm not
sure any new leader of GNU was elected, whether she/he will be still blamed
like this, after all, no one is perfect.

To my understanding, Guile is very important for GNU operating system. And
we've helped to push it so far till today. Are we doing it wrong?
If Guile quit GNU, then what's its position? IMHO, Guile is on a very good
track these years. If Guile quit GNU, is it competitive enough to other
Scheme implementation?

I'm the kind of pragmatism people. I hope you can think about it carefully.
After all, the decision includes all our efforts for many years.

But anyway, any of you will not lose my respect. Because I don't think
anyone is wrong here, you just try to insist on your faith kindly.

Best regards.



On Fri, Oct 18, 2019 at 9:08 AM Mark H Weaver  wrote:

> Hello all,
>
> I just realized that I made a mistake, and my mistake has caused people
> to strongly condemn RMS for something that he did not actually do.
>
> RMS has not yet appointed me as a co-maintainer.  To my knowledge, the
> only thing he has done so far is to *ask* me if I wanted to be appointed
> co-maintainer.  I answered "yes", but I've not yet received any further
> messages from him on this topic.  I also note that I'm not listed as a
> maintainer in the official list of maintainers.
>
> I misinterpreted RMS's question as an offer, and that was my mistake.
> The fault is mine, and mine alone.  RMS should not be blamed for it.
>
>Mark
>
>
> Andy Wingo  wrote:
> > Still, it was with surprise that I woke up this morning to a request
> > from Mark to re-join the Guile project on Savannah, saying that RMS had
> > appointed Mark to become co-maintainer, and that Mark assented -- "given
> > recent events".
> >
> > Now, Richard has no idea about Guile or how it works either technically
> > or socially, and has not consulted with me as Guile maintainer, nor to
> > my knowledge did he consult with Ludovic.
>
> "Thompson, David"  wrote:
> > But now that I know that the truth is that RMS, as chief nuisance, put
> > Mark back into this role without the consent of either active Guile
> > co-maintainer, and without even telling them, I am extremely
> > disappointed and I do not approve.
>
> Christopher Lemmer Webber  wrote:
> > I'm extremely saddened to see RMS pull this move.  It seriously
> > undermines faith for maintainers of GNU projects that ther is any
> > semblance of fair governance, and that the rug can't be pulled out from
> > under their feet at any time.
>
>

Re: Maintainership changes: many thanks to Mark!

[Nala Ginrut]

Hi Mark!
Many thanks for all your contributions!
I'm going to say that I've learned too many things from you, and you helped
me to carve my skills.
Do you remember once I said I owe you a beer? ;-)

Best regards.


On Wed, Sep 11, 2019 at 3:57 PM Andy Wingo  wrote:

> Hi all,
>
> After many years working on Guile and more than 5 years in a
> maintainer role, Mark Weaver has decided to step down.  Taking over
> from him and remaining as Guile co-maintainers are Ludovic Courtès and
> Andy Wingo.
>
> On behalf of myself and Ludovic and no doubt all Guile users and
> developers: a heartfelt thanks, Mark, for all of your years of
> service, and see you around the Guile community!
>
> Happy hacking,
>
> Andy and Ludovic
>
>

Re: Support Websocket status code

[Nala Ginrut]

hi Mark!
Yes you're right, the status code should be encoded in close-frame, not
HTTP response.
Sorry for the wrong patch. ;-)

Best regards.


On Wed, Aug 7, 2019 at 2:52 PM Mark H Weaver  wrote:

> Hi,
>
> Nala Ginrut  writes:
>
> > Hi folks!
> > The current response builder will reject status code less than 600:
> > ---code-
> >  ((not (and (non-negative-integer? code) (< code 600)))
> >   (bad-response "Bad code: ~a" code))
> > ---
> >
> > However, Websocket specific status code is larger than 1000.
>
> Section 4.2.2 paragraph 5 of RFC 6455 (the WebSocket RFC) makes it clear
> that the HTTP response should conform to RFC 2616, which specifies that
> the status code is a 3-digit integer less than 600.
>
> If I understand correctly, the larger status codes defined in section
> 7.4.1 of RFC 6455 are never used in HTTP response headers.  Rather, they
> are optionally used in WebSocket Close control frames to indicate the
> reason for closure.  See section 7.1.6 for more on that.
>
> The WebSocket protocol is quite distinct from the HTTP protocol.
> Although HTTP is used initially, after the server returns the HTTP
> response with status "101 Switching Protocols", a completely different
> protocol is used henceforth.
>
> So, I don't see anything in the RFCs to justify using the larger status
> codes in HTTP response status line.  Am I misunderstanding something?
>
>Mark
>

Re: Support Websocket status code

[Nala Ginrut]

Here is a patch to add necessary status code, and avoid checking failure
when building response.
Based on branch stable-2.2

Thanks!


On Fri, Jul 26, 2019 at 2:06 PM Nala Ginrut  wrote:

> Hi folks!
> The current response builder will reject status code less than 600:
> ---code-
>  ((not (and (non-negative-integer? code) (< code 600)))
>   (bad-response "Bad code: ~a" code))
> ---
>
> However, Websocket specific status code is larger than 1000.
> This breaks Artanis Websocket handler to return 500, so that the client
> has no way to detect the actual problem.
>
> Is there any plan to support it?
> Or maybe someone is just waiting for a patch? ;-)
>
> Best regards.
>
>
From 757bf959e364485f105a977c3f971b9252dfb4db Mon Sep 17 00:00:00 2001
From: Nala Ginrut 
Date: Mon, 29 Jul 2019 14:55:37 +0800
Subject: [PATCH] Add Websocket status code

---
 module/web/response.scm | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/module/web/response.scm b/module/web/response.scm
index 06e1c6dc1..77a856a48 100644
--- a/module/web/response.scm
+++ b/module/web/response.scm
@@ -118,7 +118,7 @@ the headers are each run through their respective validators."
   (non-negative-integer? (car version))
   (non-negative-integer? (cdr version
 (bad-response "Bad version: ~a" version))
-   ((not (and (non-negative-integer? code) (< code 600)))
+   ((not (and (non-negative-integer? code) (<= code 1015)))
 (bad-response "Bad code: ~a" code))
((and reason-phrase (not (string? reason-phrase)))
 (bad-response "Bad reason phrase" reason-phrase))
@@ -167,7 +167,20 @@ the headers are each run through their respective validators."
 (502 . "Bad Gateway")
 (503 . "Service Unavailable")
 (504 . "Gateway Timeout")
-(505 . "HTTP Version Not Supported")))
+(505 . "HTTP Version Not Supported")
+(1000 . "Normal Closure")
+(1001 . "Going Away")
+(1002 . "Protocol error")
+(1003 . "Unsupported Data")
+(1004 . "Reserved")
+(1005 . "No status received")
+(1006 . "Abnormal Closure")
+(1007 . "Invalid frame payload data")
+(1008 . "Policy Violation")
+(1009 . "Message Too Big")
+(1010 . "Mandatory Ext.")
+(1011 . "Internet Server Error")
+(1015 . "TLS handshake")))
 
 (define (code->reason-phrase code)
   (or (assv-ref *reason-phrases* code)
-- 
2.20.1

Support Websocket status code

[Nala Ginrut]

Hi folks!
The current response builder will reject status code less than 600:
---code-
 ((not (and (non-negative-integer? code) (< code 600)))
  (bad-response "Bad code: ~a" code))
---

However, Websocket specific status code is larger than 1000.
This breaks Artanis Websocket handler to return 500, so that the client has
no way to detect the actual problem.

Is there any plan to support it?
Or maybe someone is just waiting for a patch? ;-)

Best regards.

Re: python-on-guile

[Nala Ginrut]

Thanks for the work! I appreciate it!

On Sat, Jun 15, 2019 at 3:05 AM Stefan Israelsson Tampe
 wrote:
>
> python on guile has reached quite far and now compiles a lot of the standard 
> python code base. The speed has not been of importance. Rather to get good 
> coopertion between guile scheme and python programs.
>
> But it also define a scheme interface to the python functionalites and i'm 
> now trying to compile some documentation of this inteface. You can find docs 
> at http://www.c-lambda.se/python-on-guile.
>
> source code is at,
> https://gitlab.com/python-on-guile/python-on-guile/
>
> This is a work in progress.
>
> Happy hacking!!

Re: Releasing 2.2.5?

[Nala Ginrut]

I'm looking forward to it!

On Thu, Jun 6, 2019 at 4:51 PM Ludovic Courtès  wrote:
>
> Hello comrades!
>
> What would you think of releasing ‘stable-2.2’ as 2.2.5?
>
> It’s great if you can do it, Mark, but otherwise I can do it.
>
> Thanks,
> Ludo’.
>

Re: compilation pragmas?

[Nala Ginrut]

Hi Massimiliano!
Could you show some code to elaborate on your idea? It's too vague to
understand by a pure text description.

Thanks!

On Wed, May 29, 2019 at 8:43 PM Massimiliano Gubinelli
 wrote:
>
> Hello,
>  I noticed that the Tree IL compiler uses an ad-hoc code to check if some 
> symbol is dynamically defined by GOOPS, intercepting calls to the 
> toplevel-define! function which introduces just a new definition in the 
> current module. In TeXmacs we need some similar dynamics definition mechanism 
> and I get a lot of compiler warnings since the Tree IL analyser does not 
> recognise my definitions. Of course I have the option to redefine  
> toplevel-define! like GOOPS does, but I’m worried of possible name clashes. 
> Another possibility would be to introduce some “compiler pragma” support in 
> the Tree IL compiler so that it can have annotations which can then be 
> ignored when producing more lower lever code. In this way one could make the 
> mechanism of suppressing particular warnings (e.g. possibly undefined 
> symbols) independent of hacks specific only to certain libraries and provide 
> more orthogonal features. Does it sounds reasonable? I could try to hack it 
> down but I would like to discuss first possible design issues, I’m new to 
> guile compiler.
>
> Best regards,
> Massimiliano Gubinelli
>
>

Re: [PATCH] Add current-suspendable-io-status parameter

[Nala Ginrut]

Hi Mark!
I need some time to think about all the situations in front of us.
And here's a quick reply to one of your questions:


On Thu, May 16, 2019 at 8:59 AM Mark H Weaver  wrote:

> What about when we write something more structured, such as writing a
> large S-expression using 'write', or serializing XML from SXML.  In
> those cases, it's even more obvious that we have no idea how many bytes,
> nor how many characters will be written until we're finished.  Both of
> these operations result in a large number of small write operations, and
> clearly, status information for each of those small write operations is
> not useful.

At least in Artanis server-core (Ragnarok), every blocking I/O
operation from users
(the downstream developer of Artanis) will be scheduled by
delimited-continuations
with suspendable-port. I've made a lot of works to make sure users
don't have to care about
any blocking I/O jobs by themselves, this would be a great selling
point of both Artanis and Guile.

So even if they're trying to load/write very small bytes, the task
continuation will be scheduled by
suspendable-port, and it can not be changed because Guile manages all
asynchronous I/O.

Although this looks unnecessary for small bytes, we can make a fair
scheduler to smooth the situation.
That's why we still need to care for the small bytes I/O.

Re: [PATCH] Add current-suspendable-io-status parameter

[Nala Ginrut]

Similar, but in Guile, you don't have to care about if it's blocking and
schedule it by yourself, while you have to care about it explicitly in C.

 于 2019年5月15日周三 20:10写道：

> On Wed, May 15, 2019 at 07:25:37PM +0800, Nala Ginrut wrote:
> > hi Tomas!
> > For Guile, if you enabled suspendable-port, you may schedule the
> > blocking task captured by delimited continuation.
> > And use I/O multiplex mechanism (say, select or epoll) for monitoring
> > the file descriptor (or port).
>
> So basically it's like C -- you call read() or write() when select/epoll
> tells you that this socket wants to play with you. Thanks!
>
> Thanks to Chris qnd you
>
> Cheers
> -- tomás
>

Re: [PATCH] Add current-suspendable-io-status parameter

[Nala Ginrut]

hi Tomas!
For Guile, if you enabled suspendable-port, you may schedule the
blocking task captured by delimited continuation.
And use I/O multiplex mechanism (say, select or epoll) for monitoring
the file descriptor (or port).
If there's no available byte at all, then you would never be mentioned
by I/O multiplexer.
That is to say, you can do other works before it mentions you some time.

On Wed, May 15, 2019 at 6:09 PM  wrote:
>
> On Mon, May 13, 2019 at 06:54:38PM +0800, Nala Ginrut wrote:
> > Hi folks!
> > Here's a patch to add current-suspendable-io-status:
> > Its result is a pair: (finished-bytes . rest-bytes)
>
> Sorry for this possibly dumb question, but... is there a way
> to be non-blocking even if there are no readable/writable
> bytes at all? Or would one have to do multi-threading (and
> let the single threads [1] block) for that?
>
> Thanks
>
> [1] not necessarily "operating system" threads
>
> -- tomás

Re: [PATCH] Add current-suspendable-io-status parameter

[Nala Ginrut]

hi Mark!
I think your approach works for the cases which use put-bytevector* directly.
Are you assuming the server-core only handles suspendable-port with
put-bytevector in http-read or http-write?
If so, then your approach is not enough.
When the users enabled suspendable-port, every I/O operation would be
non-blocking, and be managed by overridden I/O methods rebind by
suspendable-port .
That is to say, every I/O operation should have the ability to return
the current I/O status for the scheduler. That's why I put it in
read-bytes and write-bytes.

If we add a new put-bytevector* function, and if it is the only
function which returns current I/O status, then we can't tell the
scheduler the progress when users are trying to
access database for a bigger data, or access a file on the disk, or
any other potential I/O operation registered in HTTP handler by users.
I think it's better to patch read-bytes and write-bytes for any I/O
operations, otherwise, we have to patch all the overridden functions
in suspendable-ports to make sure all
I/O operations are handled correctly by suspendable-port.

Hope I understand your idea correctly.

Best regards.

On Wed, May 15, 2019 at 4:23 AM Mark H Weaver  wrote:
>
> Hi Nala,
>
> Nala Ginrut  writes:
>
> > On Tue, May 14, 2019 at 7:01 AM Mark H Weaver  wrote:
> >> I guess what you want is the ability to see incremental reports on the
> >> progress of your large I/O operations.  Is that right?  If we are going
> >> to add an API for this, it needs to be reliable, and always give reports
> >> in terms of the high-level requests that the user gave.
> >
> > Yes, that's exactly what I want. We need to get the progress of I/O
> > operation when it's blocking
> > so that we can compute a fair priority for the tasks.
> >
> >> My preferred approach would be something like this: we could add a
> >> 'put-bytevector-some' I/O primitive which writes some bytes from a
> >> bytevector, blocking only as needed to write at least one byte.  It
> >> would return the number of bytes written.  This can be used to implement
> >> an efficient variant of 'put-bytevector' that gives you access to the
> >> real-time progress information.
> >
> > I'm not sure if put-bytevector-some does the work, I'll list my concerns:
> >
> > 1. All I/O will be managed by Guile when we enabled suspendable-port.
> > That is to say, from the users side, users never know their I/O
> > operations are blocking or not. It's transparent to users.
> > Guile will guarantee the I/O operations to be finished by managing all
> > the blocking I/O mechanisms.
> > Users can only interact with the task with read or write waiter, which
> > are registered by users themselves.
> > In this scenario, users are out of control of I/O operations. And they
> > have no way to get the progress of I/O, since there's
> > no way to pass this status to the waiter function except for
> > parameters in my patch.
> >
> > 2. suspendable-port module has already provided a bunch of overridden
> > bytevector-* functions.
> > However, they're hidden from users. I think it's good since the
> > purpose of suspendable-port is to abstract all these details from
> > users. Users only consider the read-waiter and write-waiter for scheduling.
> > If we provide the low-level bytevector functions to users to let them
> > do the non-blocking I/O by themselves, just like most C framework
> > does. Then Guile suspendable-port will lose a critical feature,
> > although users can still implement asynchronous non-blocking I/O by
> > themselves with a non-managed approach. Say, do the I/O, check result
> > by themselves, and do the scheduling.
> > Personally, I'm fine with this way, since I'm familiar with both ways.
> > But managed I/O of suspendable-port is a good selling point for many
> > inexperienced server-side developers, they can use it in Scheme just
> > like IOCP or AIO.
> >
> > Of course, I may misunderstand your mind.
> > Could you elaborate more about your approach?
>
> Here's what I had in mind.  I'm not suggesting that you use asynchronous
> non-blocking I/O.  'put-bytevector-some' would be like 'put-bytevector'
> except that it can write less than you asked it to.  Ideally it would
> block only as needed to write at least one byte.  It would be analogous
> to POSIX write(2).
>
> Here's an untested draft implementation of 'put-bytevector*' which sets
> the parameter 'current-io-status' to provide the information you wanted,
> except that here the information will reliably refer to your own buffer.
> The primitive it is built on 'put-bytevector-some' does not yet exist,
> but we 

Re: [PATCH] Add current-suspendable-io-status parameter

[Nala Ginrut]

Hi Mark!
Thanks for so patient reply!


On Tue, May 14, 2019 at 7:01 AM Mark H Weaver  wrote:
> I guess what you want is the ability to see incremental reports on the
> progress of your large I/O operations.  Is that right?  If we are going
> to add an API for this, it needs to be reliable, and always give reports
> in terms of the high-level requests that the user gave.

Yes, that's exactly what I want. We need to get the progress of I/O
operation when it's blocking
so that we can compute a fair priority for the tasks.

> My preferred approach would be something like this: we could add a
> 'put-bytevector-some' I/O primitive which writes some bytes from a
> bytevector, blocking only as needed to write at least one byte.  It
> would return the number of bytes written.  This can be used to implement
> an efficient variant of 'put-bytevector' that gives you access to the
> real-time progress information.

I'm not sure if put-bytevector-some does the work, I'll list my concerns:

1. All I/O will be managed by Guile when we enabled suspendable-port.
That is to say, from the users side, users never know their I/O
operations are blocking or not. It's transparent to users.
Guile will guarantee the I/O operations to be finished by managing all
the blocking I/O mechanisms.
Users can only interact with the task with read or write waiter, which
are registered by users themselves.
In this scenario, users are out of control of I/O operations. And they
have no way to get the progress of I/O, since there's
no way to pass this status to the waiter function except for
parameters in my patch.

2. suspendable-port module has already provided a bunch of overridden
bytevector-* functions.
However, they're hidden from users. I think it's good since the
purpose of suspendable-port is to abstract all these details from
users. Users only consider the read-waiter and write-waiter for scheduling.
If we provide the low-level bytevector functions to users to let them
do the non-blocking I/O by themselves, just like most C framework
does. Then Guile suspendable-port will lose a critical feature,
although users can still implement asynchronous non-blocking I/O by
themselves with a non-managed approach. Say, do the I/O, check result
by themselves, and do the scheduling.
Personally, I'm fine with this way, since I'm familiar with both ways.
But managed I/O of suspendable-port is a good selling point for many
inexperienced server-side developers, they can use it in Scheme just
like IOCP or AIO.

Of course, I may misunderstand your mind.
Could you elaborate more about your approach?

Best regards.

Re: [PATCH] Add current-suspendable-io-status parameter

[Nala Ginrut]

BTW, the patch is based on the latest stable-2.2 branch.

On Mon, May 13, 2019 at 6:54 PM Nala Ginrut  wrote:
>
> Hi folks!
> Here's a patch to add current-suspendable-io-status:
> Its result is a pair: (finished-bytes . rest-bytes)
>
> This is useful for designing a proper scheduler algorithm for
> suspendable I/O operations.
> For example, the server-core based on delimited-continuation can
> compute a priority based on this status to decide how to schedule the
> suspended task.
>
> Comments are welcome.
>
> Best regards.

[PATCH] Add current-suspendable-io-status parameter

[Nala Ginrut]

Hi folks!
Here's a patch to add current-suspendable-io-status:
Its result is a pair: (finished-bytes . rest-bytes)

This is useful for designing a proper scheduler algorithm for
suspendable I/O operations.
For example, the server-core based on delimited-continuation can
compute a priority based on this status to decide how to schedule the
suspended task.

Comments are welcome.

Best regards.
From 59c2584a1eda94c19fbef07bb8bfa36da3c0ce1c Mon Sep 17 00:00:00 2001
From: Nala Ginrut 
Date: Mon, 13 May 2019 18:45:54 +0800
Subject: [PATCH] Add current-suspendable-io-status

When suspendable-port is blocking, the IO waiter function can get the status
of the current IO operation.
(current-suspendable-io-status) returns a pair: (finished-bytes . rest-bytes)
---
 module/ice-9/suspendable-ports.scm | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/module/ice-9/suspendable-ports.scm b/module/ice-9/suspendable-ports.scm
index a366c8b9c..33d307a2c 100644
--- a/module/ice-9/suspendable-ports.scm
+++ b/module/ice-9/suspendable-ports.scm
@@ -54,6 +54,7 @@
   #:use-module (ice-9 match)
   #:export (current-read-waiter
 current-write-waiter
+current-suspendable-io-status
 
 install-suspendable-ports!
 uninstall-suspendable-ports!))
@@ -63,6 +64,7 @@
 
 (define current-read-waiter  (make-parameter default-read-waiter))
 (define current-write-waiter (make-parameter default-write-waiter))
+(define current-suspendable-io-status (make-parameter (cons 0 0)))
 
 (define (wait-for-readable port) ((current-read-waiter) port))
 (define (wait-for-writable port) ((current-write-waiter) port))
@@ -75,7 +77,8 @@
(error "bad return from port read function" read))
  read))
(else
-(wait-for-readable port)
+(parameterize ((current-suspendable-io-status (cons start count)))
+  (wait-for-readable port))
 (read-bytes port dst start count
 
 (define (write-bytes port src start count)
@@ -87,7 +90,8 @@
  (when (< written count)
(write-bytes port src (+ start written) (- count written)
(else
-(wait-for-writable port)
+(parameterize ((current-suspendable-io-status (cons start count)))
+  (wait-for-writable port))
 (write-bytes port src start count
 
 (define (flush-input port)
-- 
2.20.1

Re: Code coverage is broken

[Nala Ginrut]

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

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

[Nala Ginrut]

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.

Code coverage is broken

[Nala Ginrut]

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: FOSDEM 2019

[Nala Ginrut]

This patche provide #lang tag like Racket does. If so then it's reasonable
and doable. Thanks for that! :-)

Matt Wette  于 2019年2月6日周三 08:38写道：

>
>
> On 2/5/19 8:58 AM, Ludovic Courtès wrote:
> > 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.  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
> >
> >
> I assume that means a  language/racket/spec.scm file.
>
> A patch to 2.2.4 for maping #lang foo" in a file to
> langauge/foo/spec.scm is in
>
> https://github.com/mwette/guile-contrib/blob/master/patch-2.2.4/load.patch
>
>
>
>

Re: FOSDEM 2019

[Nala Ginrut]

Does it mean someone is working on writing Racket specific dialect
front-end on Guile? I appreciate!

Ludovic Courtès  于 2019年2月6日周三 00:59写道：

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

[Nala Ginrut]

Thanks for all the words folks!

I confess the thoughts about "Guile is crap" is reasonable for some people,
especially when you compare Guile to Chez and Racket. We can't ignore the
quality of Chez and Racket.
People always have choices, some would choose performance, some choose
rapid development, some choose popularity. I choose to grow up with Guile.
Of course, I can choose to grow up with anything, but I choose Guile, and
I've learnt many things. When I came to Guile community 10 years ago, I
know nothing, I just want to start to learn. And many people here helped me
a lot, I mean, on many things about programming, not only the knowledge of
Guile. It's my great appreciation to this community, so that I keep
contributing to Guile. And I don't believe Guile is crap when there is such
a community around it.

Back to the reality.
We use Python in product, alghouth GIL fucked us a lot on performance.
Alright, we endure it, who doesn't nowadays? In 2019, DevOps department
told me many problems about Python, yes, it's in a critical year to upgrade
to Python3. We can upgrade our code, but there're lot of dependencies
choose to stay at Python2 at present, maybe they will change later, but we
are going to deliver soon. We can't wait.
All these issues are ignored by developers, because they just enjoy the
convenience from Python, they care less about deployment. DevOps people are
not happy. BTW, Guix may help on this issue, but it's still not mature
enough, I'm expecting use it someday with full of hope.
Fortunately Guile saved us, and we replace Python with Guile as scripting
language. Guile's FFI is easy to use compared to CPython, so that we can do
it rapidly without any pain. The machine learning part has to stay with
Python, but the situation is much better, although we have to introduce
complex IPC architecture. If someday we can use Guile for machine learning,
then it's perfect.

Someone once asked me how to hire Scheme people. Well, the answer is easy,
we don't do that. We hire Python people, C++ people, then train them with
SICP. They become usable Scheme developer within a month. Scheme is easy to
learn with so many classical books, and we take this benefit.

It seems Scheme wins here, but why not Chez or Racket? (I mention these 2
because they are mentioned in this thread)
I was planning to use Chez in the product, and I even prepared all things
to start. But I really need keywords which is not in RnRS. I've asked this
in Chez community, and to someone here may know this issue on GitHub, it's
strongly rejected by the author. I'm not here to complain or blame anyone,
everyone has choices. So Racket and Guile are left in my arsenal.
It's really hard to make a choice between them. Racket is good, and I have
several developers graduated from universities like Waterloo which teaches
Racket so that we can take it easily.

Finally we choose Guile because I have GNU Artanis for Restful WebAPI. It's
functionalities are rich so that we can save some time. No mention we may
have Lua or Python3 (4 maybe) on Guile later. My guile-lua-rebirth is
ready, but it's no hurry. Thanks for Guile's compiler tower, so that we may
add new languages and reuse existing Guile modules in other languages on
Guile.

Guile 2.9.0 with JIT is a surprise to me that it accelerates amazingly.
I've been learning how to implement high performance optimizing compiler
with CPS according to Andy Wingo's work. It's interesting. I'd like to make
a similar thing for embedded system. Good luck to me, if I made it finally,
I can use Scheme everywhere in our product.

Dear folks, with all these things above, do you still think Guile is crap?



Arne Babenhauserheide  于 2019年2月4日周一 07:14写道：

>
> Mikael Djurfeldt  writes:
>
> > It was a great experience and joy for me to meet some of you at FOSDEM
> > 2019. Thank you all!
>
> Thank you, too!
>
> > 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?
>
> I’ll ignore for a moment that this is a rhethoric method and answer
> directly: No, I don’t think that Guile is crap. It is actually really
> good, and while there are missing parts, I enjoy working in Guile more
> than I enjoy working in Python. Even when I use parentheses :-)
>
> The talk by Christopher Webber basically described the importance of
> shiny — all the bits other people already polished. A similar argument
> cuts for using Python, and even Java.
>
> This does not make it invalid: Chris is right that shiny is important;
> but it is not all-important, especially not in the long run. And
> different from many other projects, Guile takes the long run seriously.
>
> And seeing my scripts finish within 60ms is impressive. It’s not yet
> perl-level startup-time, but it already beats Python (by a narrow margin).
>
> > That is all good, unless it hurts the sense of meaning and joy in your
> > work.
>
> Thank you for these words!
>
> > I think it is 

Re: moving to gitlab?

[Nala Ginrut]

First, I hope Guile can use gitlab.
However, IIRC, RMS has some comments on this, the hosting service must be
free, and it shouldn't allow to fork, but branch-based. This is reasonable
to protect project, but RMS speaks as a skilled hacker, I have to say it's
very good policy in a professional engineers team to be branch-based.
But nowadays, people hope FOSS project be easier to contribute, fork is
easier for them.
I accept patches on Gitlab for GNU Artanis.

BTW, that's the main reason I write GNU Artanis, since I'd like to provide
a new Savannah to provide modern services and abey FSF ethic. Although it's
in a very slow stepping toward to final target...

Greg Troxel  于 2019年1月23日周三 09:32写道：

> Aleix Conchillo Flaqué  writes:
>
> > Any chance or interest in moving to gitlab? My apologies if this has
> > been discussed already. Not that I ever contribute anything directly
> > to Guile (2 patches in 6 years?), but it feels like it would be an
> > improvement in terms of communication, sending patches, etc. May be it
> > would even encourage more developers to contribute? Sending patches
> > over a mailing list shouldn't be a thing anymore. Again, my apologies.
>
> I can't speak for the coalition, but generally there is a notion that
> FSF projects are hosted on infrastructure operated by a charitable
> non-profit that has the advancement of Free Software as the goal.
>
> Also, history shows that the place people move to because of concerns
> about $PREVIOSU_PLACE will follow suit eventually...
>
> If your point is that the self-hosted infrastructure should have some
> way for random poeple to provide in-tool changes, that sounds sensible.
>
>

Re: GTK3 bindings status

[Nala Ginrut]

Hi Mike! I'm just here to say, thanks for the work!

Mike Gran  于 2018年11月12日周一 07:52写道：

> Hi-
>
> After a few weeks hacking, I have actually got a library that parses
> GObject-Introspection *.typelib files to create Guile bindings, and I
> have added just enough machinery to get GTK's famous Example 1 to run.
>
> Theirs
>   https://developer.gnome.org/gtk3/stable/gtk-getting-started.html
> Mine
>   https://github.com/spk121/guile-gi/blob/master/test/example-1.scm
>
> The library code is an awful mess, so I wouldn't bother trying to
> build it or use it, yet, but, it was a milestone I though I might
> report.
>
> The cool part of that example is that I'm using a lambda as a GObject
> button "clicked" signal callback, which ended up requiring quite a bit
> of infrastructure and FFI.
>
> So a few weeks ago there was a bit of discussion about the best way to
> accomplish a GTK3 binding for Guile.  I got a lot of great advice,
> but, I decided to choose a low-level approach to it, mostly in C, for
> now, which I believe is necessary to smooth the edges between
> GTK's API and Scheme.  Also, I decided to skip GOOPS for a more direct
> approach, which may or may not be a terrible idea.
>
> Regards,
> Mike
>
>

Re: 2018 Scheme and Functional Programming Workshop CfP

[Nala Ginrut]

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
>
> * Experience Reports, with a limit to 14 pages. Each accepted report
> will be presented by its authors in a 25 minute slot including Q
>
> * 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
>
> 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 

What's the alternative of scm_new_port_table_entry?

[Nala Ginrut]

I found there're many issues after scm_new_port_table_entry was
removed recently:


commit 9417fdb80fb5db4f657c9a329faaa61162ab996b
Author: Ludovic Courtès 
Date:   Fri Feb 16 14:26:56 2018 +0100

doc: Fix typo about SRFI-4 syntax.

Reported by Matt Wette .
...skipping...
  (scm_new_port_table_entry): Remove; not useful.
---

This breaks me when I'm trying to compile something required it.
And this change seems prevent people compile GDB with guile support:
https://github.com/crosstool-ng/crosstool-ng/issues/718


So what's the alternative of scm_new_port_table_entry to use ?

Best regards.

Re: Question: link to wrong library

[Nala Ginrut]

Or run it with LD_LIBRARY_PATH

2018年1月22日 19:36，"Chaos Eternal" <eternalch...@shlug.org>写道：

>  gcc  -pthread -I.  -Wl,-rpath -lguile-2.2  -lgc test.c
>
> On Mon, Jan 22, 2018 at 7:30 PM 陶青云 <qingyun@tophant.com> wrote:
>
>> some result
>>
>> ```
>> ~/code/guile-2.2
>> $ LDFLAGS=-Wl,-rpath LD_LIBRARY_PATH=./libguile/.libs gcc  -pthread -I.
>> -lguile-2.2  -lgc test.c
>> ~/code/guile-2.2
>> $ ldd ./a.out
>> linux-vdso.so.1 (0x7ffc441a)
>> libguile-2.2.so.1 => /usr/lib/libguile-2.2.so.1 (0x7f3cfb519000)
>> libgc.so.1 => /usr/lib/libgc.so.1 (0x7f3cfb2af000)
>> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f3cfb091000)
>> libc.so.6 => /usr/lib/libc.so.6 (0x7f3cfacd9000)
>> libffi.so.6 => /usr/lib/libffi.so.6 (0x7f3cfaad)
>> libunistring.so.2 => /usr/lib/libunistring.so.2 (0x7f3cfa75f000)
>> libgmp.so.10 => /usr/lib/libgmp.so.10 (0x7f3cfa4cc000)
>> libltdl.so.7 => /usr/lib/libltdl.so.7 (0x7f3cfa2c2000)
>> libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x7f3cfa08a000)
>> libm.so.6 => /usr/lib/libm.so.6 (0x7f3cf9d3e000)
>> /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
>> (0x7f3cfba49000)
>> libdl.so.2 => /usr/lib/libdl.so.2 (0x7f3cf9b3a000)
>> libatomic_ops.so.1 => /usr/lib/libatomic_ops.so.1 (0x7f3cf9937000)
>> ```
>>
>>
>> -- Original --
>> *From: * "Chaos Eternal"<eternalch...@shlug.org>;
>> *Date: * Mon, Jan 22, 2018 12:58 PM
>> *To: * "Nala Ginrut"<nalagin...@gmail.com>;
>> *Cc: * "陶青云"<qingyun@tophant.com>; "guile-devel"<guile-devel@gnu.org>;
>>
>> *Subject: * Re: Question: link to wrong library
>>
>>
>> or try this
>> LDFLAGS=-Wl,-rpath
>>
>> On Mon, Jan 22, 2018, 09:08 Nala Ginrut <nalagin...@gmail.com> wrote:
>>
>>> I think you may need LD_LIBRARY_PATH
>>>
>>> 2018年1月21日 23:46，"陶青云" <qingyun@tophant.com>写道：
>>>
>>>> Hi. I'm new to guile.  I compiled it from source without `make
>>>> install`.
>>>>
>>>> I write a simple C file and use the flowing command to compile it.
>>>> `gcc -pthread -I. -L ./libguile/.libs -lguile-2.2  -lgc test.c`
>>>> it successed. but the a.out is always link to my system guile library.
>>>>$ ldd ./a.out
>>>> linux-vdso.so.1 (0x7fffc259b000)
>>>> libguile-2.2.so.1 => /usr/lib/libguile-2.2.so.1 (0x7fa90f9fe000)
>>>> libgc.so.1 => /usr/lib/libgc.so.1 (0x7fa90f794000)
>>>>
>>>>
>>>> even I do the flowing:
>>>> $ cp libguile/.libs/libguile-2.2.so.1.3.0  libguile/.libs/
>>>> libguile-2.5.so
>>>>
>>>> $ gcc -pthread -I. -L ./libguile/.libs -lguile-2.5  -lgc test.c  # it
>>>> successed
>>>>
>>>> $ ldd ./a.out
>>>> linux-vdso.so.1 (0x7ffd283e)
>>>> libguile-2.2.so.1 => /usr/lib/libguile-2.2.so.1 (0x7f83c71cc000)
>>>> libgc.so.1 => /usr/lib/libgc.so.1 (0x7f83c6f62000)
>>>>
>>>>
>>>> Could someone give me some tips.  Thanks.
>>>>
>>>

Re: Question: link to wrong library

[Nala Ginrut]

I think you may need LD_LIBRARY_PATH

2018年1月21日 23:46，"陶青云" 写道：

> Hi. I'm new to guile.  I compiled it from source without `make install`.
>
> I write a simple C file and use the flowing command to compile it.
> `gcc -pthread -I. -L ./libguile/.libs -lguile-2.2  -lgc test.c`
> it successed. but the a.out is always link to my system guile library.
>$ ldd ./a.out
> linux-vdso.so.1 (0x7fffc259b000)
> libguile-2.2.so.1 => /usr/lib/libguile-2.2.so.1 (0x7fa90f9fe000)
> libgc.so.1 => /usr/lib/libgc.so.1 (0x7fa90f794000)
>
>
> even I do the flowing:
> $ cp libguile/.libs/libguile-2.2.so.1.3.0  libguile/.libs/libguile-2.5.so
>
> $ gcc -pthread -I. -L ./libguile/.libs -lguile-2.5  -lgc test.c  # it
> successed
>
> $ ldd ./a.out
> linux-vdso.so.1 (0x7ffd283e)
> libguile-2.2.so.1 => /usr/lib/libguile-2.2.so.1 (0x7f83c71cc000)
> libgc.so.1 => /usr/lib/libgc.so.1 (0x7f83c6f62000)
>
>
> Could someone give me some tips.  Thanks.
>

Re: Rename GNU fdisk to GUILE diskutils

[Nala Ginrut]

Personally, I don't think adding guile prefix to a package name is the way
to advocating Guile, unless it's Guile specific program and used by Guile
only.
GNU Artanis is written in pure Guile scheme, but the name doesn't imply any
guile stuff. If people like it, then they will like the power of Guile. But
if they know little about Guile, they may afraid of using it when they see
Guile-webframework as the name.
It's not so easy to let people accept a new language. So I think it's
better to avoid such implication.


2017年12月15日 06:15，"Richard Stallman" 写道：

> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> The program's name is and will remain GNU fdisk.
>
> We're talking about the name of the _package_
> that will contain this program and others.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
> Skype: No way! See https://stallman.org/skype.html.
>
>
>

Re: Error while detecting Guile-3.0

[Nala Ginrut]

I formatted a patch here in case anyone need it before 3.0 release.


On Mon, Oct 23, 2017 at 3:42 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
> Sorry, this line:
> ---
> (define guile-module "guile-2.2")
> ---
>
> On Mon, Oct 23, 2017 at 3:40 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
>> And this line should be changed to "guile-3.0" in meta/guile-config.in
>>
>> ---
>> (define guile-module "guile-3.0")
>> ---
>>
>> Best regards.
>>
>>
>> On Mon, Oct 23, 2017 at 3:36 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
>>> Now I think it's because GUILE-VERSION:
>>> -
>>> GUILE_MAJOR_VERSION=2
>>> GUILE_MINOR_VERSION=3
>>> GUILE_MICRO_VERSION=0
>>> -
>>>
>>> After I changed it to:
>>> 
>>> GUILE_MAJOR_VERSION=3
>>> GUILE_MINOR_VERSION=0
>>> GUILE_MICRO_VERSION=0
>>> ----
>>>
>>> The problem gone.
>>>
>>> I think it's better to fix it in master branch, or people may find
>>> it's confusing sometimes.
>>>
>>> Best regards.
>>>
>>>
>>>
>>> On Mon, Oct 23, 2017 at 3:19 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
>>>> hi folks!
>>>> I'm trying to use Guile-3.0 for a project, but it complains when configure:
>>>> -
>>>> checking for Guile version >= 3.0... configure: error: Guile 3.0
>>>> required, but 2.3.0 found
>>>> -
>>>>
>>>> The related lines in configure.ac is here:
>>>> =
>>>>  GUILE_PKG(2.2 3.0)
>>>>  GUILE_PROGS
>>>> =
>>>>
>>>> Why it's 2.3.0? Is it a bug?
>>>>
>>>> Best regards.
From 62c51c72610aa4fd077bbc66bd1acee5167952e4 Mon Sep 17 00:00:00 2001
From: Nala Ginrut <nalagin...@gmail.com>
Date: Mon, 23 Oct 2017 15:44:44 +0800
Subject: [PATCH] fixed version string to 3.0

---
 GUILE-VERSION| 4 ++--
 meta/guile-config.in | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/GUILE-VERSION b/GUILE-VERSION
index a44c254fb..0db8a3b45 100644
--- a/GUILE-VERSION
+++ b/GUILE-VERSION
@@ -1,8 +1,8 @@
 # -*-shell-script-*-
 
 # Note: `GUILE_VERSION' is defined in `configure.ac' using `git-version-gen'.
-GUILE_MAJOR_VERSION=2
-GUILE_MINOR_VERSION=3
+GUILE_MAJOR_VERSION=3
+GUILE_MINOR_VERSION=0
 GUILE_MICRO_VERSION=0
 
 GUILE_EFFECTIVE_VERSION=3.0
diff --git a/meta/guile-config.in b/meta/guile-config.in
index b3e4c3d94..5236476c4 100755
--- a/meta/guile-config.in
+++ b/meta/guile-config.in
@@ -77,7 +77,7 @@ exec "@installed_guile@" -e main -s $0 "$@"
 (dle "  " p " --help  - show usage info (this message)")
 (dle "  " p " --help SUBCOMMAND - show help for SUBCOMMAND")))
 
-(define guile-module "guile-2.2")
+(define guile-module "guile-3.0")
 
 (define (pkg-config . args)
   (let* ((real-args (cons %pkg-config-program args))
-- 
2.11.0

Re: Error while detecting Guile-3.0

[Nala Ginrut]

Sorry, this line:
---
(define guile-module "guile-2.2")
---

On Mon, Oct 23, 2017 at 3:40 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
> And this line should be changed to "guile-3.0" in meta/guile-config.in
>
> ---
> (define guile-module "guile-3.0")
> ---
>
> Best regards.
>
>
> On Mon, Oct 23, 2017 at 3:36 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
>> Now I think it's because GUILE-VERSION:
>> -
>> GUILE_MAJOR_VERSION=2
>> GUILE_MINOR_VERSION=3
>> GUILE_MICRO_VERSION=0
>> -
>>
>> After I changed it to:
>> 
>> GUILE_MAJOR_VERSION=3
>> GUILE_MINOR_VERSION=0
>> GUILE_MICRO_VERSION=0
>> 
>>
>> The problem gone.
>>
>> I think it's better to fix it in master branch, or people may find
>> it's confusing sometimes.
>>
>> Best regards.
>>
>>
>>
>> On Mon, Oct 23, 2017 at 3:19 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
>>> hi folks!
>>> I'm trying to use Guile-3.0 for a project, but it complains when configure:
>>> -
>>> checking for Guile version >= 3.0... configure: error: Guile 3.0
>>> required, but 2.3.0 found
>>> -
>>>
>>> The related lines in configure.ac is here:
>>> =
>>>  GUILE_PKG(2.2 3.0)
>>>  GUILE_PROGS
>>> =
>>>
>>> Why it's 2.3.0? Is it a bug?
>>>
>>> Best regards.

Re: Error while detecting Guile-3.0

[Nala Ginrut]

And this line should be changed to "guile-3.0" in meta/guile-config.in

---
(define guile-module "guile-3.0")
---

Best regards.


On Mon, Oct 23, 2017 at 3:36 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
> Now I think it's because GUILE-VERSION:
> -
> GUILE_MAJOR_VERSION=2
> GUILE_MINOR_VERSION=3
> GUILE_MICRO_VERSION=0
> -
>
> After I changed it to:
> 
> GUILE_MAJOR_VERSION=3
> GUILE_MINOR_VERSION=0
> GUILE_MICRO_VERSION=0
> 
>
> The problem gone.
>
> I think it's better to fix it in master branch, or people may find
> it's confusing sometimes.
>
> Best regards.
>
>
>
> On Mon, Oct 23, 2017 at 3:19 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
>> hi folks!
>> I'm trying to use Guile-3.0 for a project, but it complains when configure:
>> -
>> checking for Guile version >= 3.0... configure: error: Guile 3.0
>> required, but 2.3.0 found
>> -
>>
>> The related lines in configure.ac is here:
>> =
>>  GUILE_PKG(2.2 3.0)
>>  GUILE_PROGS
>> =
>>
>> Why it's 2.3.0? Is it a bug?
>>
>> Best regards.

Re: Error while detecting Guile-3.0

[Nala Ginrut]

Now I think it's because GUILE-VERSION:
-
GUILE_MAJOR_VERSION=2
GUILE_MINOR_VERSION=3
GUILE_MICRO_VERSION=0
-

After I changed it to:

GUILE_MAJOR_VERSION=3
GUILE_MINOR_VERSION=0
GUILE_MICRO_VERSION=0


The problem gone.

I think it's better to fix it in master branch, or people may find
it's confusing sometimes.

Best regards.



On Mon, Oct 23, 2017 at 3:19 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
> hi folks!
> I'm trying to use Guile-3.0 for a project, but it complains when configure:
> -
> checking for Guile version >= 3.0... configure: error: Guile 3.0
> required, but 2.3.0 found
> -
>
> The related lines in configure.ac is here:
> =
>  GUILE_PKG(2.2 3.0)
>  GUILE_PROGS
> =
>
> Why it's 2.3.0? Is it a bug?
>
> Best regards.

Error while detecting Guile-3.0

[Nala Ginrut]

hi folks!
I'm trying to use Guile-3.0 for a project, but it complains when configure:
-
checking for Guile version >= 3.0... configure: error: Guile 3.0
required, but 2.3.0 found
-

The related lines in configure.ac is here:
=
 GUILE_PKG(2.2 3.0)
 GUILE_PROGS
=

Why it's 2.3.0? Is it a bug?

Best regards.

Re: Wisp as shipped language in Guile?

[Nala Ginrut]

Well yes, it looks good if we have it. And I could let users of Artanis
write HTML template like Ruby slim.
http://slim-lang.com/

2017年9月19日 下午10:10，"Christopher Allan Webber" 写道：

> Matt Wette writes:
>
> >> On Sep 17, 2017, at 4:22 PM, Arne Babenhauserheide 
> wrote:
> >>
> >>
> >> Matt Wette  writes:
> >>> Looks promising, especailly if the footprint is small.
> >>> Can someone post the sample guix specification?
> >>> I could not access from the gnunet log.
> >>
> >> Do you mean the wisp package for Guix?
> >
> > No, I meant the guix package spec for package foo written in wisp.
> >
> > define-public foo
> >package
> >   name "guile-wisp"
> >   source : origin
> >  ...
>
> https://dustycloud.org/blog/wisp-lisp-alternative/
>
>

Re: Wisp as shipped language in Guile?

[Nala Ginrut]

Hi Arne!
Personally, I'd like to see many languages on Guile. But I prefer  maintain
mine, guile-lua-rebirth and a new shell language(undone) as an external
package.
GNU official project reviews contributions too strictly, it's good for the
quality and free software ethics, but too difficult for new contributors as
a compromise.
I will be happy to see if wisp accepted to be in Guile core. But if not,
it's not a big deal IMO, especially when we have Guix now.
What do you think?

Best regards


2017年8月11日 下午5:11，"Arne Babenhauserheide" 写道：

> Hi,
>
> Any word on this? We have ecmascript, we have elisp, we have brainfuck,
> why not wisp — which is finished and stable and does not require any
> non-sexp-scheme code in Guile?
>
> Best wishes,
> Arne
>
> Arne Babenhauserheide  writes:
>
> > Hi Mark,
> >
> > Mark H Weaver  writes:
> >
> >>> Essentially this is about making wisp as language part of the
> >>> "batteries" of Guile.
> >>
> >> About 4.5 years ago, I went out on a limb and added SRFI-105 (curly
> >> infix expressions) to core Guile.  Even now, I'm of the opinion that
> >> judicious use of curly infix could be beneficial for readability, but as
> >> far as I can tell, there's been essentially no uptake.  If I'm wrong
> >> about that, please let me know.
> >
> > I’ve been using SRFI-105 quite a bit — not only in Wisp. It helped me in
> > reducing the reservations colleagues of mine had against Scheme
> > (prefix-comparisons and prefix-math look odd to many people).
> >
> >> Anyway, regardless of my personal opinion, I think we need to be careful
> >> not to add things to Guile that will go unused and merely contribute to
> >> its increasing bloat.
> >
> > Given that language/wisp (as I have it here) is less than half the size
> > of language/elisp or language/ecmascript, and will require much less
> > maintenance (it is in final form and will automatically benefit from all
> > improvements to Scheme proper — different from both elisp and ecmascript
> > which need to follow a moving target to keep their utility) and that it
> > is less than twice the size of language/brainfuck, I think calling Wisp
> > part of bloat isn’t right.
> >
> >> I think the relevant question is: are a
> >> non-trivial number of people likely to use this?  For starters, do you
> >> know anyone writing non-trivial amounts of Wisp code other than
> >> yourself?  You might expect that to change if we added it to core Guile,
> >> but that didn't seem to happen with SRFI-105.
> >
> > This depends on what you consider non-trivial.
> >
> > Two weeks ago CalGuixSD said in IRC he’d written the system definition
> > for Guix in Wisp. However he had to give up on that, because it would
> > have required to install Wisp while he did not have Guix
> > yet. (https://gnunet.org/bot/log/guix/2017-05-03).
> >
> > This is actually what prompted me to write here again: In this usecase
> > it acts to facilitate entry into Scheme, because using the language for
> > setup is an obvious case where people get put off by the parens at
> > first. And different from other notations, going from Wisp to regular
> > Scheme is trivial: automatic conversion even keeps the comments.
> >
> > Using Wisp as system language is among the things people can only do
> > when they always have Wisp with Guile — when it’s part of its batteries
> > (along with brainfuck, javascript and elisp).
> >
> >
> > Aside from being a good starter, there are domains where I see Wisp as a
> > different quality of readability, for example when it comes to text-rich
> > formats (I think you know the talk from FOSDEM:
> > https://fosdem.org/2017/schedule/event/naturalscriptwritingguile/ ).
> >
> >
> > Finally I see that Wisp is the one project of mine which generates the
> > most interest (as estimated by people reading its site — easily twice as
> > many as those who have read my Freenet articles (since 2010!) — and from
> > people asking how to use it), so I would like to make Wisp easier for
> > people to use. It seems that Wisp draws people.
> >
> >
> >> So, unless Wisp is being used by more people than I suspect, my personal
> >> take on this is that we should not incorporate Wisp into Guile at this
> >> time.
> >>
> >> On the other hand, if there are sane changes that we can make to Guile
> >> that would facilitate adding support for languages like Wisp and
> >> SRFI-110 to Guile via external libraries, I would absolutely be in favor
> >> of working toward that goal.
> >
> > The main missing piece I see right now would be the option for
> > language//spec.scm to automatically add suffixes to
> > %load-extensions when switching to a language and removing them when
> > switching back (along with a solution for ..go).
> >
> > Or providing a mapping from extension to language.
> >
> > One of these would also be needed for *.el(elisp) and *.js(ecmascript).
> >
> > However this will not allow using Wisp in the REPL on Guile
> > 

Re: ffi-help: handling types

[Nala Ginrut]

Good job!


2017年6月28日 上午10:26，"Matt Wette" 写道：

> Hi All,
>
> I am working on a ffi-helper: a program that will read in a C dot-h file
> and generate a Guile dot-scm file which defines a module to provide hooks
> into the associated C library.  A little status on type handling:
>
> For nominal C types I am trying to stick to the (system foreign) type
> system.  For aggregate types I am using scheme-bytestructures (
> https://github.com/TaylanUB/scheme-bytestructures).  However, I am
> currently putting a guile struct wrapper on top of bytestructure
> descriptors in order to provide a more user-friendly interface (IMO).
>
> In the demo I have created a (cairo cairo-svg) ffi-module which gets
> converted to a guile module via
> $ guild compile-ffi cairo/cairo-svg.ffi
>
> Then I start guile and do this:
>
> scheme@(guile-user)> (use-modules (cairo cairo-svg))
> scheme@(guile-user)> (use-modules (ffi-help))
> scheme@(guile-user)> (use-modules (system foreign))
>
> scheme@(guile-user)> (define srf (cairo_svg_surface_create
> (string->pointer "abc.svg") 200.0 200.0))
> scheme@(guile-user)> srf
> $2 = 
>
> @(guile-user)> (define cr (cairo_create srf))
> scheme@(guile-user)> cr
> $1 = 
>
> scheme@(guile-user)> (define mx (make-cairo_matrix_t))
> scheme@(guile-user)> mx
> $3 = #
>
> scheme@(guile-user)> (pointer-to mx)
> $4 = 
>
> scheme@(guile-user)> (cairo_get_font_matrix cr (pointer-to mx))
> scheme@(guile-user)>
>
> Matt
>
>
>

Re: [ Porting Guile on Android 4.4 ]

[Nala Ginrut]

I'm not familiar with this porting work, so can't help more. But it's great
if I could use Guile on my phone!
Thanks for the work!

2017年6月16日 下午11:48，"Robert Dazi" 写道：

> Hello,
> I tried to port Guile 2.2.1 on Android 4.4. As you might know, Android is
> not GNU/Linux and many functions (and even types such as localeconv) are
> missing or not acting as expected (either because the Linux headers have
> been ripped off or because Bionic lacks those features).
> That means the libraries needed some rewriting, and Guile too. Here some
> issues :
>- the 'configure' script generated by autoconf uses the PREFIX variable
> to find libltdl, whereas it is better to ask the user for that path.
>- Bionic doesn't implement well locales (and won't), setlocale is an
> empty function returning NULL
>- Because the encoding format is unknown, init_random raises an error,
> but init_random is called before init_throw so since the static variable
> for throwing is set to an unknown state (on my device it is set to 0), it
> leads to a segfault. (By the way, setting LC_ALL to UTF-8 fixes the
> encoding issue if init_throw called before init_random).
>
> Eventually, I've got a (seemingly working) rpl by commenting out the
> 'setlocale' line within top-repl.scm.
>
> Thanksfully,
>

Re: Efficiency of `map`

[Nala Ginrut]

Hi Mark!
Do you have any advice to optimize it without disable GC temperaly? Or the
only way is to change a better GC?

2017年6月10日 12:28，"Mark H Weaver" 写道：

> Stefan Monnier  writes:
>
> >>   (define (map f l)
> >> (if (pair? l)
> >> (cons (f (car l))
> >>   (map f (cdr l)))
> >> '()))
> >>
> >> whereas we used to have to write code like this in order to support long
> >> lists without overflowing the stack:
> >>
> >>   (define (map f l)
> >> (let loop ((l l) (out '()))
> >>   (if (pair? l)
> >>   (loop (cdr l) (cons (f (car l)) out))
> >>   (reverse out
> >
> > Ignoring stack usage, is the first version faster or slower than the
> second?
> > [ Or is the speed difference negligible?  ]
>
> I don't have time to perform proper benchmarks, but some admittedly
> inadequate measurements on my Thinkpad X200 suggest that the first
> version is about 1.5% faster, mainly because it makes a lot less work
> for the GC.  See below for details of what I did.
>
> > How 'bout using a side-effecting `reverse!` (like Lisp's nreverse)?
>
> We can't do that, because in the presence of first-class continuations
> where the 'f' passed to map may return more than once, using mutation to
> build the result list will change the result for some programs.  Both
> modern scheme standards (R6RS and R7RS) explicitly specify that "If
> multiple returns occur from map, the values returned by earlier returns
> are not mutated".
>
>   Mark
>
>
> mhw@jojen ~$ guile
> GNU Guile 2.2.2
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (define (map1 f l) (if (pair? l) (cons (f (car l))
> (map f (cdr l))) '()))
> scheme@(guile-user)> (define (map2 f l) (let loop ((l l) (out '())) (if
> (pair? l) (loop (cdr l) (cons (f (car l)) out)) (reverse out
> scheme@(guile-user)> (define var #f)
> scheme@(guile-user)> (define test-list (iota 10))
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1
> ;; 13.121194s real time, 14.072380s run time.  2.346036s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1
> ;; 13.006867s real time, 13.940452s run time.  2.263353s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1
> ;; 13.079656s real time, 13.946879s run time.  2.197271s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1
> ;; 13.029591s real time, 15.312230s run time.  5.601020s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1
> ;; 13.041985s real time, 15.306287s run time.  5.581253s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1
> ;; 12.003391s real time, 13.421369s run time.  3.662504s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1
> ;; 11.993404s real time, 13.367805s run time.  3.496328s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1
> ;; 11.964659s real time, 13.362942s run time.  3.544227s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1
> ;; 12.619559s real time, 13.153612s run time.  1.471917s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1
> ;; 12.600161s real time, 13.136094s run time.  1.476574s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1
> ;; 12.584059s real time, 13.142257s run time.  1.478289s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1
> ;; 12.626346s real time, 13.146946s run time.  1.466499s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1
> ;; 12.009064s real time, 13.361389s run time.  3.690290s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1
> ;; 11.970217s real time, 13.317716s run time.  3.352065s spent in GC.
> scheme@(guile-user)>
>
> Here are the 4 best times for each procedure:
>
> map1:
> ;; 12.619559s real 

Re: Is the backtrace broken in 2.2.2?

[Nala Ginrut]

I'm trying to form a simplified test case, please wait a moment.


2017年5月13日 06:21，"Mark H Weaver" <m...@netris.org>写道：

> Nala Ginrut <nalagin...@gmail.com> writes:
>
> > On Wed, May 3, 2017 at 3:45 AM, Andy Wingo <wi...@pobox.com> wrote:
> >> On Mon 01 May 2017 06:45, Nala Ginrut <nalagin...@gmail.com> writes:
> >>
> >>> Hi all!
> >>> I'm using the latest Guile from git repo.
> >>> It seems something is wrong to print message of backtrace.
> >>>
> >>> ---cut
> >>> Exception thrown while printing backtrace:
> >>> ERROR: In procedure vector-ref: Value out of range: 156
> >>> end--
> >>>
> >>> Any thoughts?
> >>
> >> Always or just sometimes?  Needs a test case :)
> >>
> >> Note that there was this, in the past:
> >> 4dcc97288dc2c43ea9f2e61fdb1357cec3936fc9.  But that was fixed.
>
> > It always appears. Maybe relate to call-with-prompt?
>
> Can you provide a small self-contained test case to demonstrate the
> problem, so that we can reproduce it on our systems?
>
>   Mark
>

Re: Is the backtrace broken in 2.2.2?

[Nala Ginrut]

It always appears. Maybe relate to call-with-prompt?

On Wed, May 3, 2017 at 3:45 AM, Andy Wingo <wi...@pobox.com> wrote:
> On Mon 01 May 2017 06:45, Nala Ginrut <nalagin...@gmail.com> writes:
>
>> Hi all!
>> I'm using the latest Guile from git repo.
>> It seems something is wrong to print message of backtrace.
>>
>> ---cut
>> Exception thrown while printing backtrace:
>> ERROR: In procedure vector-ref: Value out of range: 156
>> end--
>>
>> Any thoughts?
>
> Always or just sometimes?  Needs a test case :)
>
> Note that there was this, in the past:
> 4dcc97288dc2c43ea9f2e61fdb1357cec3936fc9.  But that was fixed.
>
> Andy

Is the backtrace broken in 2.2.2?

[Nala Ginrut]

Hi all!
I'm using the latest Guile from git repo.
It seems something is wrong to print message of backtrace.

---cut
Exception thrown while printing backtrace:
ERROR: In procedure vector-ref: Value out of range: 156
end--

Any thoughts?

Best regards.

Re: RFC: (ice-9 sandbox)

[Nala Ginrut]

Hmm...I didn't think about this security issue. And even if we may do some
verification in IR(say, CPS or lower level), it's insufficient to avoid
security issue, since front-end implementation may use cross module
function to mimic primitives for other languages.
Now I think maybe front-end writer has to write their own sandbox with
(ice-9 sandbox) if any necessary. :-)

Best regards.


2017年4月17日 16:07，"Andy Wingo" <wi...@pobox.com>写道：

> On Sat 15 Apr 2017 19:23, Nala Ginrut <nalagin...@gmail.com> writes:
>
> > Could you please add #:from keyword to evil-in-sand box to indicate
> > the language front-end? Don't forget there's multi-lang plan. :-)
>
> In theory yes, but I don't know how to make safe sandboxes in other
> languages.  ice-9 sandbox relies on the Scheme characteristic that the
> only capabilities granted to a program are those that are in scope.
> Other languages often have ambient capabilities -- like Bash for example
> where there's no way to not provide the pipe ("|") operator.  I think
> adding other languages should be an exercise for the reader :)
>
> Andy
>

Re: RFC: (ice-9 sandbox)

[Nala Ginrut]

Hi Andy!
It's pretty cool!
Could you please add #:from keyword to evil-in-sand box to indicate the
language front-end? Don't forget there's multi-lang plan. :-)

Best regards.

Andy Wingo 于2017年3月31日周五 17:28写道：

> Hi,
>
> Attached is a module that can evaluate an expression within a sandbox.
> If the evaluation takes too long or allocates too much, it will be
> cancelled.  The evaluation will take place with respect to a module with
> a "safe" set of imports.  Those imports include most of the bindings
> available in a default Guile environment.  See the file below for full
> details and a number of caveats.
>
> Any thoughts?  I would like something like this for a web service that
> has to evaluate untrusted code.
>
> Andy
>
>

Re: GNU Guile 2.2.0 released

[Nala Ginrut]

Congrats!
6 years, well I never realized it. At that time I was a newbie in Scheme land...

Best regards.


On Thu, Mar 16, 2017 at 6:16 PM, Andy Wingo  wrote:
> We are delighted to announce GNU Guile release 2.2.0, the first of a
> new stable release series.
>
> More than 6 years in the making, Guile 2.2 includes a new optimizing
> compiler and high-performance register virtual machine.  Compared to
> the old 2.0 series, real-world programs often show a speedup of 30% or
> more with Guile 2.2.
>
> Besides the compiler upgrade, Guile 2.2 removes limitations on user
> programs by lowering memory usage, speeding up the "eval" interpreter,
> providing better support for multi-core programming, and last but not
> least, removing any fixed limit on recursive function calls.
>
> Not only does Guile 2.2 run fast, it also supports the creation of
> user-space concurrency facilities that multiplex millions of
> concurrent lightweight "fibers".  See
> https://www.gnu.org/software/guile/news/gnu-guile-220-released.html
> for pointers to promising experiments.
>
> If you are migrating from earlier versions of Guile, be sure to read
> the NEWS below for exhaustive information on user-visible changes
> relative to the previous stable series.  Installation instructions
> follow the NEWS.  As a bonus, this release includes a binary release
> built with Guix that you can untar onto any x86_64 GNU/Linux system
> and test out Guile for yourself; details at the end of this mail.
>
>  *  *  *
>
> Guile is an implementation of the Scheme programming language.
>
> The Guile web page is located at https://gnu.org/software/guile/, and
> among other things, it contains a copy of the Guile manual and pointers
> to more resources.
>
> Guile can run interactively, as a script interpreter, and as a Scheme
> compiler to VM bytecode.  It is also packaged as a library so that
> applications can easily incorporate a complete Scheme interpreter/VM.
> An application can use Guile as an extension language, a clean and
> powerful configuration language, or as multi-purpose "glue" to connect
> primitives provided by the application.  It is easy to call Scheme code
> From C code and vice versa.  Applications can add new functions, data
> types, control structures, and even syntax to Guile, to create a
> domain-specific language tailored to the task at hand.
>
> Guile implements many common Scheme standards, including R5RS, R6RS, and
> a number of SRFIs.  In addition, Guile includes its own module system,
> full access to POSIX system calls, networking support, multiple threads,
> dynamic linking, a foreign function call interface, and powerful string
> processing.
>
> Guile 2.2.0 can be installed in parallel with Guile 2.0.x; see
> https://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html.
>
> Changes in 2.2.0 (changes since the 2.0.x stable release series):
>
> * Notable changes
>
> ** Speed
>
> The biggest change in Guile 2.2 is a complete rewrite of its virtual
> machine and compiler internals.  The result is faster startup time,
> better memory usage, and faster execution of user code.  See the
> "Performance improvements" section below for more details.
>
> ** Better thread-safety
>
> This new release series takes the ABI-break opportunity to fix some
> interfaces that were difficult to use correctly from multiple threads.
> Notably, weak hash tables and ports are now transparently thread-safe.
> See "Scheduling" in the manual, for updated documentation on threads and
> communications primitives.
>
> ** Better space-safety
>
> It used to be the case that, when calling a Scheme procedure, the
> procedure and arguments were always preserved against garbage
> collection.  This is no longer the case; Guile is free to collect the
> procedure and arguments if they become unreachable, or to re-use their
> slots for other local variables.  Guile still offers good-quality
> backtraces by determining the procedure being called from the
> instruction pointer instead of from the value in slot 0 of an
> application frame, and by using a live variable map that allows the
> debugger to know which locals are live at all points in a frame.
>
> ** Off-main-thread finalization
>
> Following Guile 2.0.6's change to invoke finalizers via asyncs, Guile
> 2.2 takes the additional step of invoking finalizers from a dedicated
> finalizer thread, if threads are enabled.  This avoids concurrency
> issues between finalizers and application code, and also speeds up
> finalization.  If your application's finalizers are not robust to the
> presence of threads, see "Foreign Objects" in the manual for information
> on how to disable automatic finalization and instead run finalizers
> manually.
>
> ** Better locale support in Guile scripts
>
> When Guile is invoked directly, either from the command line or via a
> hash-bang line (e.g. "#!/usr/bin/guile"), it now installs the current
> locale via a call to 

Re: The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

This version has fixed file missing during compilation.


On Tue, Mar 14, 2017 at 10:35 AM, Nala Ginrut <nalagin...@gmail.com> wrote:
> Rebased to the latest, folks may download the tarball directly
> https://github.com/NalaGinrut/guile-tjit/releases/tag/tjit-2.1.8.975-1f6fc-rebase
>
>
> On Mon, Mar 6, 2017 at 7:19 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
>> I've rebased the latest master (2.1.7.1040-0f7db-dirty) and fixed to work.
>> The result become more interesting with the naive case mentioned in my
>> earlier mail:
>> Chez: 15s
>> Guile-JIT: 12s
>>
>> Alright, we still need to face some problems.
>>
>> In Atsuro's original design, there're two files should be included
>> with Scheme's "include" function  in the compiling time. IMO this is
>> not a good way, since it'll assume the building path is the same with
>> source path. Then it complains jit-code-t.scm and
>> compat-x86_64-linux.scm are missing. I've fixed this issue in Makefile
>> to make a soft link. In the long term I think it's better to change
>> its design to use modules.
>>
>> And we don't have to generate jit-code-t.scm every time we compile.
>> This file is generated by gen-code-t.scm according to GNU-lightning
>> header file. Next step, I will move it to script directory and we may
>> generate it with guild. It's a standalone script actually.
>>
>> To be continued.

Re: The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

Rebased to the latest, folks may download the tarball directly
https://github.com/NalaGinrut/guile-tjit/releases/tag/tjit-2.1.8.975-1f6fc-rebase


On Mon, Mar 6, 2017 at 7:19 PM, Nala Ginrut <nalagin...@gmail.com> wrote:
> I've rebased the latest master (2.1.7.1040-0f7db-dirty) and fixed to work.
> The result become more interesting with the naive case mentioned in my
> earlier mail:
> Chez: 15s
> Guile-JIT: 12s
>
> Alright, we still need to face some problems.
>
> In Atsuro's original design, there're two files should be included
> with Scheme's "include" function  in the compiling time. IMO this is
> not a good way, since it'll assume the building path is the same with
> source path. Then it complains jit-code-t.scm and
> compat-x86_64-linux.scm are missing. I've fixed this issue in Makefile
> to make a soft link. In the long term I think it's better to change
> its design to use modules.
>
> And we don't have to generate jit-code-t.scm every time we compile.
> This file is generated by gen-code-t.scm according to GNU-lightning
> header file. Next step, I will move it to script directory and we may
> generate it with guild. It's a standalone script actually.
>
> To be continued.

Re: The status of JIT compiler of Guile

[Nala Ginrut]

Hi Andy!
Sorry for late replay, it seems I've filtered your mail to another TAG
in my mailbox.


On Thu, Mar 2, 2017 at 4:31 PM, Andy Wingo  wrote:
> Heya Nala :-)
>
> And hello Atsuro!  I don't think I have had the chance of expressing to
> you how impressive your work is.  Awesome stuff!!!
>
> What do you all think is the way forward for this work?  Is it something
> that you see being integrated eventually into Guile git?  Is it a
> project that should be maintained separately?  If the latter, what
> interfaces do you need from Guile?

I'm not going to fork Guile and maintain it separately.
What I concern is if the current design is suitable to integrate
directly. And the origianl
repo can't be compiled in my machine. So I'm trying to rebase with the
latest master and
research Atsuro's paper. The point is that after ICFP meeting, no one
have tried it successfully.
Then I choose to fix it to work.

I've discussed with @Ludo, I think it's better to integrate it as a
plugin, and could be maintained separately.
It is possible to have some hooks in Guile VM to enable certain
optimizing, but I don't think we have it now, right?

it's just my idea. It's possible to integrate it directly, since it's
working with the latest Guile smoothly.
But there maybe some trivial issues need to be tweaked.

Another pointer I have to mention is that I'm not sure if the tracing
JIT concerned delimited-continuation capturing properly.
This is one of the questions on the meeting, and Atsuro said he has no
idea about that issue. That's another reason I prefer
to do some research before any conclusion or patches.

What do you think?
Are you can't wait to integrate it at once? Or make more flexible
things in Guile VM to hold pluginable optimizing sutffs?
For me, it's fine, after all, I use it everyday now. ;-P


> I think this test is a bignum/allocation test, not a compiler test.
> Still, good to see some results.

Yes it is, I just want to show something. Unfortunately, I'm not good
at benchmark. ;-)

> Andy

Re: The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

I've rebased the latest master (2.1.7.1040-0f7db-dirty) and fixed to work.
The result become more interesting with the naive case mentioned in my
earlier mail:
Chez: 15s
Guile-JIT: 12s

Alright, we still need to face some problems.

In Atsuro's original design, there're two files should be included
with Scheme's "include" function  in the compiling time. IMO this is
not a good way, since it'll assume the building path is the same with
source path. Then it complains jit-code-t.scm and
compat-x86_64-linux.scm are missing. I've fixed this issue in Makefile
to make a soft link. In the long term I think it's better to change
its design to use modules.

And we don't have to generate jit-code-t.scm every time we compile.
This file is generated by gen-code-t.scm according to GNU-lightning
header file. Next step, I will move it to script directory and we may
generate it with guild. It's a standalone script actually.

To be continued.

The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

Hi folks!
It's been a long time for me to be inactive here. ;-)

I saw there's thread to discuss Guile benchmark, I think it's better
to mention the JIT compiler of Guile. It exists and real, and of
course, very fast.

Thanks Atsuro Hoshino, who is the author of Guile JIT compiler.  We've
met on ICFP2016 in Nara. And I'm great impressed by this work. I'm
enjoying the contribution very much, especially when yesterday I made
it work successfully!

I think Atsuro is very busy these months, so that he has no time to
take a look on my patches. After waited half a year, I decide to take
the responsibility to maintain this project. I have to mention that
JIT compiler is not in Guile upstream repo at present, it's maintained
on GitHub.

I've forked the repo and patched it to make it work, and rebased it to
our latest master branch (2.1.7.980-f5904-dirty). Now it works on the
latest Guile code base. I'lI keep on maintaining it before Atsuro come
back to take it.
My plan is to keep it updating with the latest Guile master branch,
and try to fix problems, respond the issues, finally, when it becomes
mature, I'll send patches-set to Guile upstream.
Please come back soon, we need you, Atsuro ;-)

Here's my repo, reports and patches are welcome, I prefer maintain it
on GitHub, this will be easier for most of folks:
==
https://github.com/NalaGinrut/guile-tjit
==
Please follow nala-tjit branch which is maintaining by me.

To build it , you need gnu-lightning, and you should add
--enable-lightning when configure:
==
./configure --enable-lightning
==

To run it with JIT, please add --tjit option:
=
guile --tjit
=

The JIT is still experimental, so please report if you encounter any
problem, I'll try to help to fix it, and I'm here to invite
contributors to help this significant project. Atsuro's paper is here:
===
http://scheme2016.snow-fort.org/static/scheme16-paper3.pdf
===

About the performance, I tried a poor test:
code
 (define (fib n)
   (define (iter a b c)
 (cond ((= c 0) b)
   (#t (iter (+ a b) a (- c 1)
   (iter 1 0 n))

 (define a (fib 100))
=end

It's not a fair test, and I'm a bad benchmarker, but it shows
interesting result on my machine:
Chez: 15s
guile-master: 28s
guile-jit: 15s

Now you know it's different, huh?
Come to get involved please, try it on your code, and report
something, find bugs as possible. And let's pray it could be fixed
automatically. ;-P

Best regards.

Re: Guile security vulnerability w/ listening on localhost + port (with fix)

[Nala Ginrut]

On Tue, 2016-10-11 at 09:01 -0500, Christopher Allan Webber wrote:
> The Guile team has just pushed out a new commit on the Guile stable-2.0
> branch addressing a security issue for Guile.  There will be a release
> shortly as well.  The commit is
> 08c021916dbd3a235a9f9cc33df4c418c0724e03, or for web viewing purposes:
> 
>   http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0=08c021916
> dbd3a235a9f9cc33df4c418c0724e03
> 
> Due to the nature of this bug, Guile applications themselves in general
> aren't vulnerable, but Guile developers are.  Arbitrary scheme code may
> be used to attack your system in this scenario.
> 
> There is also a lesson here that applies beyond Guile: the presumption
> that "localhost" is only accessible by local users can't be guaranteed
> by modern operating system environments.  If you are looking to provide
> local-execution-only, we recommend using unix domain sockets or named
> pipes.  Don't rely on localhost plus some port.
> 


Indeed, I've considered to do so in Artanis too.
But maybe we should provide both just like what php-fpm does? And let users
choose which one to use, localhost:port or unix socket.

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

[Nala Ginrut]

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 author Atsuro 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
> 

Re: GNU Guile 2.1.4 released [beta]

[Nala Ginrut]

Nice work!
Thanks for working on it!
I think maybe we can expect 2.2 released end of this year, right? ;-)

Best regards.

On Wed, 2016-09-14 at 13:41 +0200, Andy Wingo wrote:
> We are pleased to announce GNU Guile release 2.1.4.
> 
> Guile 2.1.4 is the fourth pre-release in what will eventually become the
> 2.2 release series.  We encourage you to test this release and provide
> feedback to guile-devel@gnu.org.
> 
> This release adds an atomic reference facility and fixes many small
> bugs.  See the full NEWS below, for details.
> 
> The Guile web page is located at http://gnu.org/software/guile/, and
> among other things, it contains a copy of the Guile manual and pointers
> to more resources.
> 
> Guile is an implementation of the Scheme programming language, with
> support for many SRFIs, packaged for use in a wide variety of
> environments.  In addition to implementing the R5RS Scheme standard,
> Guile includes a module system, full access to POSIX system calls,
> networking support, multiple threads, dynamic linking, a foreign
> function call interface, and powerful string processing.
> 
> Guile can run interactively, as a script interpreter, and as a Scheme
> compiler to VM bytecode.  It is also packaged as a library so that
> applications can easily incorporate a complete Scheme interpreter/VM.
> An application can use Guile as an extension language, a clean and
> powerful configuration language, or as multi-purpose "glue" to connect
> primitives provided by the application.  It is easy to call Scheme code
> From C code and vice versa.  Applications can add new functions, data
> types, control structures, and even syntax to Guile, to create a
> domain-specific language tailored to the task at hand.
> 
> Guile 2.1.4 can be installed in parallel with Guile 2.0.x; see
> http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html
> .
> 
> A more detailed NEWS summary follows these details on how to get the
> Guile sources.
> 
> Here are the compressed sources:
>   http://alpha.gnu.org/gnu/guile/guile-2.1.4.tar.gz   (17MB)
>   http://alpha.gnu.org/gnu/guile/guile-2.1.4.tar.xz   (10MB)
> 
> Here are the GPG detached signatures[*]:
>   http://alpha.gnu.org/gnu/guile/guile-2.1.4.tar.gz.sig
>   http://alpha.gnu.org/gnu/guile/guile-2.1.4.tar.xz.sig
> 
> Use a mirror for higher download bandwidth:
>   http://www.gnu.org/order/ftp.html
> 
> Here are the SHA256 checksums:
> 
>   04dd7b9ea58644b5631e74c212678db6498f945c5dd8f3900c01409c054ad7c3  guile-
> 2.1.4.tar.gz
>   326440e5041892ea8f99828178385f6066f936353d3a91404b88986f91f713f1  guile-
> 2.1.4.tar.xz
> 
> [*] 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-2.1.4.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
> FF478FB264DE32EC296725A3DDC0F5358812F8F2
> 
> and rerun the 'gpg --verify' command.
> 
> This release was bootstrapped with the following tools:
>   Autoconf 2.69
>   Automake 1.15
>   Libtool 2.4.6
>   Gnulib v0.1-800-g68b6ade
>   Makeinfo 6.1
> 
> 
> Changes in 2.1.4 (changes since the 2.1.3 alpha release):
> 
> * Notable changes
> ** C99 required
> 
> Following Emacs, you must use a C99-capable compiler when building
> Guile.  In the future we also expect require C99 to use Guile's C
> interface, at least for `stdint' support.
> 
> * New interfaces
> ** Implement R6RS custom binary input/output ports
> 
> See "Custom Ports" in the manual.
> 
> ** Implement R6RS output-buffer-mode
> ** Implement R6RS bytevector->string, string->bytevector
> 
> See "R6RS Transcoders" in the manual.
> 
> ** Thread-safe atomic boxes (references)
> 
> See "Atomics" in the manual.
> 
> ** File descriptor finalizers
> 
> See "Ports and File Descriptors" in the manual.
> 
> * Performance improvements
> ** Added unboxing support for `logxor'
> ** Better integer unboxing
> 
> * Incompatible changes
> ** Statically scoped module duplicate handlers
> 
> It used to be that if a module did not specify a #:duplicates handler,
> when a name was first referenced in that module and multiple imported
> modules provide that name, the value of the
> `default-duplicate-binding-handlers' parameter would be used to resolve
> the duplicate bindings.  We have changed so that instead a module
> defaults to the set of handlers described in the manual.  If the module
> specifies #:duplicates, of course we use that.  The
> `default-duplicate-binding-handlers' parameter now simply accesses the
> handlers of the current module, instead of some global value.
> 
> * Bug fixes
> ** Better MinGW support
> 
> `system*' is now supported on MinGW targets.
> 
> ** Avoid flushing buffers on ftell
> 
> Fixes regression relative to Guile 2.0.
> 
> ** HTTP library does not require 

Re: A request to take charge of guile-zmq

[Nala Ginrut]

For historical reasons, Artanis keeps github repo for a mirror. And it's
indicated in the project name. The mirror was on gitorious, which is
unavailable for pushing now.

I use mailing-list for maintaining it. But few people use it.

John Darrington <j...@gnu.org>于2016年9月13日周二 02:10写道：

> Please don't use github for GNU programs (or parts thereof).  For ethical
> reasons
> github is unacceptable for us.
>
> See https://www.gnu.org/software/repo-criteria-evaluation.html  for a
> list of what
> we can and cannot use.
>
> J'
>
>
> On Mon, Sep 12, 2016 at 11:02:58PM +0800, Nala Ginrut wrote:
> > I plan to use guile-zmq in my work. Also, guile-zmq may play an
> important role
> > in Artanis.??
> >
> > Thanks Wingo for all previous work. If you don't mind, I would like to
> take
> > charge of guile-zmq for improving and maintaining.
> >
> > Here's the new repo:
> >
> > https://github.com/NalaGinrut/guile-zmq
> >
> >
> > Contributions welcome!
> > Thanks!
>

A request to take charge of guile-zmq

[Nala Ginrut]

I plan to use guile-zmq in my work. Also, guile-zmq may play an important role
in Artanis. 

Thanks Wingo for all previous work. If you don't mind, I would like to take
charge of guile-zmq for improving and maintaining.

Here's the new repo:

https://github.com/NalaGinrut/guile-zmq


Contributions welcome!
Thanks!

Re: [PATCH 02/25] Define structure

[Nala Ginrut]

Hi Dmitry! Thanks for working on it!


On Mon, 2016-07-18 at 18:17 +0300, kact...@gnu.org wrote:
> From: Dmitry Bogatov 
> 
> +(define-module (system foreign declarative)
> +  #:export (make-foreign-type)
> +  #:export (define-foreign-type))
> +(use-modules (srfi srfi-9))

You don't have to write #:export several times, one just enough
#:export (make-foreign-type define-foreign-type)

Re: [PATCH] gnu: Add emacs-clojure-mode

[Nala Ginrut]

This patch seems for Guix?

On Wed, 2016-05-18 at 15:56 +0200, Catonano wrote:
> 

Re: anyone define port types?

[Nala Ginrut]

On Mon, 2016-03-28 at 21:04 +0200, Andy Wingo wrote:
> Hi!
> 
> I am working on improving our port implementation to take advantage of
> the opportunity to break ABI in 2.2.  I am wondering how much I can
> break C API as well -- there are some changes that would allow better
> user-space threading
> (e.g. http://thread.gmane.org/gmane.lisp.guile.devel/14158/focus=15463
> or Chris Webber's 8sync).  But those changes would require some
> incompatible changes to the C API related to port internals.  This API
> is pretty much only used when implementing port types.  So, I would like
> to collect a list of people that implement their own ports :) I know
> Guile-GNOME does it for GNOME-VFS, though GNOME-VFS is super-old at this
> point...  Anyway.  Looking forward to your links :)


Fortunately, I haven't do the work for the port, but it's likely to
customize the soft port in the future. If so, I would choose to stick to
2.1+

Best regards.

Re: [FEATURE REQUEST] Add a hook to print warning message prefix string

[Nala Ginrut]

On Fri, 2016-03-18 at 13:10 +, Wette, Matthew R (3441) wrote:
> What about a command line option to eliminate the message all together.
> 

That means each time the users want to use REPL to test Lua code, they
have to add an option to run Guile. IMO it's not the best solution. ;-)
But many thank for response!

Best regards.

[FEATURE REQUEST] Add a hook to print warning message prefix string

[Nala Ginrut]

Hi folks!
I'm hacking guile-lua-rebirth these days. It's expected to release a
workable version this year. Besides, I can use Artanis from
guile-lua-rebirth smoothly. So we may never call Artanis a Scheme
framework then. ;-)

Well, here's my problem.
When we call a function in Lua and it's needed to be compiled, there'll
be warning message start with ";;;" which is the comment syntax of
Scheme.
But it seems our Lua compiler doesn't like it:

===log=
;;; note: source file ./language/lua/stdlib/io.scm
;;;   newer than
compiled 
/home/nalaginrut/.cache/guile/ccache/2.2-LE-8-3.7/home/nalaginrut/Project/guile-lua-rebirth/language/lua/stdlib/io.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling ./language/lua/stdlib/io.scm
;;; WARNING: compilation of ./language/lua/stdlib/io.scm failed:
;;; ERROR: Syntax error:
;;; ./language/lua/stdlib/io.scm:1:1: Syntax error: unexpected token :
in form semi-colon
===end==

This problem won't cause any error, and Lua works fine. It's just ugly
and scare someone.

So my suggestion is that we add a helper function to customize the
warning message prefix string to make sure it's compatible for the
specific language frontend.

This feature is useful for our multi-lang plan in the future.

Say, for Lua, like this:

(set-warning-prefix! "---")
==start
--- note: source file ./language/lua/stdlib/io.scm
---   newer than
compiled 
/home/nalaginrut/.cache/guile/ccache/2.2-LE-8-3.7/home/nalaginrut/Project/guile-lua-rebirth/language/lua/stdlib/io.scm.go
--- note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
---   or pass the --no-auto-compile argument to disable.
--- compiling ./language/lua/stdlib/io.scm
===end=

What do you think?

Re: What is needed in guildhall to include it in Guile?

[Nala Ginrut]

IMO, at least we need a convenient way to add new packages.
Of course we may send mail to an official maintainer, but it's not good
experience because folks do the work part time, most of the time they
are busy.

I may anticipate the packages amount for Guile would be increasing if we
done it properly. 

And I believe we need a critical feature for "guild list-packages" to
show the actual module path, say, if I installed "rbtree" module, I
don't know how should I load it. I've tried (use-modules (rbtree)) and
(use-modules (rbtree rbtree)) but failed. It's better to show it's
module path in the information.

It's unreasonable to force users to download and read the src.

I think this feature could be put either "list-packages" or "show"
command.

Best regards.


On Mon, 2016-02-22 at 16:08 +0100, Arne Babenhauserheide wrote:
> Hi,
> 
> In january there was a thread here about Guildhall with the notion
> 
> > I encourage you to hack on Guildhall to make it more usable for your
> > needs.
> 
> I finished my PhD last month, so I have some freed-up time — and I would
> like to use some of it to hack on Guildhall and make it ready for
> inclusion in Guile.
> 
> However there’s one stumbling block: I don’t see what’s actually missing
> from it. So I want to be bold and request something:
> 
> 
> Please tell me what’s missing in Guildhall, so I can implement it.
> 
> 
> Best wishes,
> Arne
> 
> [1]: https://lists.gnu.org/archive/html/guile-devel/2016-01/msg00010.html
> 
> PS: I write now, because I just stumbled over a situation again, where
> I’d have loved to just have guildhall at hand by default. I wanted
> to test uptop.scm which needs guile-ssh, so I just wanted to quickly
> get guile-ssh and run the script. Yes, guix can do that. But the
> guix daemons weren’t running.
> 

Re: I wrote fluid advection code: How to make this more elegant?

[Nala Ginrut]

The math formula may take advantage of sweet expression which is
contained in the current Guile reader, IIRC.
One may give it a try?

On Sat, 2016-01-23 at 13:42 +0100, Taylan Ulrich Bayırlı/Kammer wrote:
> Arne Babenhauserheide  writes:
> 
> > Hi,
> >
> > I just recreated a fluid advection exercise in Guile Scheme and I’m not
> > quite happy with its readability. Can you help me improve it?
> >
> > My main gripe is that the math does not look instantly accessible.
> >
> > The original version was in Python:
> >
> > psi[i] - c1*(psi[i+1] - psi[i-1]) + c2*(psi[i+1] - 2.0*psi[i] + 
> > psi[i-1])
> >
> > My port to Scheme looks like this:
> >
> > (let ((newvalue (+ (- (psir i)
> >   (* c1 (- (psir (+ i 1)) (psir (- i 1)
> >(* c2 (+ (- (psir (+ i 1)) (* 2 (psir i)))
> > (psir (- i 1)))
> >   (array-set! psinew newvalue i))
> 
> Guile supports SRFI-105, so that could be:
> 
> {{psi[i] - {c1 * {psi[{i + 1}] - psi[{i - 1}]}}} + {c2 * {{psi[{i + 1}] - 
> {2 * psi[i]}} + psi[{i - 1}]}}}
> 
> which is less readable than the Python version because there's no
> first-hand support for operator precedence so we {} group all binary
> operations, plus we need to use {} within [], plus we must separate
> operators with whitespace, but maybe it's acceptable.
> 
> You can put "#!curly-infix" at the start of your Scheme file to enable
> SRFI-105 syntax.
> 
> Note that all those 'psi[x]' expressions will expand to
> 
> ($bracket-apply$ psi x)
> 
> and you can implement a macro of that name to turn that into whatever is
> suitable at compile-time.  (If performance is not an issue, SRFI-123
> provides a run-time polymorphic procedure for $bracket-access$.)
> 
> With a smart definition of $bracket-apply$, you could also cut down
> those psi[{i + 1}] to psi[i + 1].  The latter will expand to
> 
> ($bracket-apply$ psi i + 1)
> 
> which could be accommodated for in a special-purpose definition of
> $bracket-apply$ such as:
> 
> (syntax-rules ()
>   ((_ obj index)
>(obj index))
>   ((_ obj x operator y)
>(obj (operator x y
> 
> That would *not* support e.g. psi[i + j - 1], which would instead need
> to be written e.g. psi[{i + j} - 1], i.e. we only save one pair of {},
> but maybe that's good enough.
> 
> By the way, e.g. {x - y + z} will turn into ($nfx$ x - y + z), and maybe
> there's a definition for $nfx$ out in the wild (or you can create one)
> that does operator precedence.  (That could then also be used in
> $bracket-apply$.)  So optimally, the whole thing could become:
> 
> {psi[i] - c1 * {psi[i + 1] - psi[i - 1]} + c2 * {psi[i + 1] - 2 * psi[i] 
> + psi[i - 1]}}
> 
> Taylan
> 

[ANN] GNU Artanis-0.1.1(Beta) released!

[Nala Ginrut]

<#secure method=pgpmime mode=sign>

I'm pleased to announce GNU Artanis-0.1.1(Beta)

NEWS

Changes in 0.1.1
* Notable changes
  Added debug-mode, which can reload modules/specified files on the fly.
  Added inotify support.
  Fixed several bugs.
  Updated manual.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.1.tar.gz   (472KB)
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.1.tar.bz2   (388KB)

Here are the GPG detached signatures[*]:
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.1.tar.gz.sig
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.1.tar.bz2.sig

Use a mirror for higher download bandwidth:
  http://www.gnu.org/order/ftp.html

Here are the MD5 and SHA1 checksums:

3fd4cb515f757f6b62c1074ab0d38293  artanis-0.1.1.tar.gz
101d6ee9c2c2354e4a401dafdac36ac0  artanis-0.1.1.tar.bz2
c04dfeb2f6045bd1228ba6aafe76406a4599  artanis-0.1.1.tar.gz
93e047b1fae3111b892535d5d1f746342d95da4e  artanis-0.1.1.tar.bz2

[*] 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 artanis-0.1.1.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 EE78E925

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69.120-5dcda-dirty
  Guile 2.0.11.162-133ec


-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

Fingerprint 77F8 7D5B B425 E505 535E  C365 9182 7E28 EE78 E925




signature.asc
Description: This is a digitally signed message part

[ANN] GNU Artanis-0.1.0 released [beta]

[Nala Ginrut]

<#secure method=pgpmime mode=sign>

I'm pleased to announce artanis-0.1.0 here. 
GNU Artanis is a monolithic web application framework(WAF) written in
Guile Scheme. 
http://web-artanis.com 
It is designed to support the development of dynamic websites, web 
applications, web services and web resources. Artanis provides several 
tools for web development: MVC, database access, templating frameworks, 
session management, URL-remapping for RESTful, page caching, and so on. 
GNU Artanis is under GPLv3+ & LGPLv3+ (dual licenses). 
GNU Artanis is also the official project of SZDIY community. It's used 
to build server side of SZDIY common service. It is offered to GNU 
project to make free software better. 
http://szdiy.org 

Here are the compressed sources:
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.0.tar.gz   (468KB)
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.0.tar.bz2   (384KB)

Here are the GPG detached signatures[*]:
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.0.tar.gz.sig
  http://alpha.gnu.org/gnu/artanis//artanis-0.1.0.tar.bz2.sig

Use a mirror for higher download bandwidth:
  http://www.gnu.org/order/ftp.html

Here are the MD5 and SHA1 checksums:

fe4652be30fd040f04940f09e1fea926  artanis-0.1.0.tar.gz
0ac17cdda340aa468cb9aa30956dcca2  artanis-0.1.0.tar.bz2
9a684c3a5e72785e9f1e8e3d48ca51c7f5aa7f5e  artanis-0.1.0.tar.gz
45a360337d3156856dd67222093efe220f4728d7  artanis-0.1.0.tar.bz2

[*] 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 artanis-0.1.0.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 EE78E925

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69.120-5dcda-dirty
  Guile 2.0.11.162-133ec

NEWS

Changes in 0.1.0
* Notable changes
  MVC support.
  Migration support.
  Optimized uploading for speed.
  Command line tools.
  Fixed many bugs.
  Add several test cases.

-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

Fingerprint 77F8 7D5B B425 E505 535E  C365 9182 7E28 EE78 E925




signature.asc
Description: This is a digitally signed message part

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

[Nala Ginrut]

On Wed, 2015-11-04 at 22:27 +0100, Mathieu Lirzin wrote:
> Also you have removed “Ragnarok”.  if it is related to this change can
> you explain it in the commit log otherwise please do a separate patch.
> 

Now that Luis has updated to add Artanis to libraries, I think I don't
have to send the patch twice. ;-)
Anyway, I could explain it here. Ragnarok as a generic server is
obsolete now, it'll be replaced by Artanis as a monolithic framework
with a strong server core (this will happen in v0.2+).

Ragnarok is pthread based server in OOP way. After I've played FP for
years, I found I dislike OOP gradually. And I dislike pthread more.
Artanis has almost all the features in Ragnarok. Actually, the brand new
server-core in Artanis named after "Ragnarok". I think the meaning is
clear enough for folks. ;-)


> On a more general topic, IIUC Artanis is not an “application” but a
> library so maybe it is not a good idea to include it in (index-page)
> since it uses the term “applications using Guile“ (The same problem will
> apply to Sly I guess).  WDYT?

Yes, it should be put to Libraries. And I suggest add a entry of
Libraries below Applications, since it's not so easy to find "libraries"
link.

Best regards.

[PATCH] Added Artanis info to new main page

[Nala Ginrut]

Hi folks!
Our new main site really rock, right?

I believe that we may add more to "Applications using Guile".
Here's mine, the entry of GNU Artanis.

Attached the patch.

Happy hacking!

>From e6b323352382898b570e81c9f43b970c3facb1a3 Mon Sep 17 00:00:00 2001
From: Nala Ginrut <nalagin...@gmail.com>
Date: Thu, 5 Nov 2015 02:42:49 +0800
Subject: [PATCH] Added GNU Artanis info

* website/apps/base/index-page.scm
* website/apps/base/libraries-page.scm
---
 website/apps/base/index-page.scm |9 -
 website/apps/base/libraries-page.scm |   10 +-
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/website/apps/base/index-page.scm b/website/apps/base/index-page.scm
index 712a7ac..68d3a76 100644
--- a/website/apps/base/index-page.scm
+++ b/website/apps/base/index-page.scm
@@ -231,7 +231,14 @@
 	 (img (@ (src ,(static-url "base/img/apps-thumbnails/sly.png"))
 		 (alt "")))
 	 (h3 "Sly")
-	 (p "2D/3D game engine")))
+	 (p "2D/3D game engine"))
+	(a
+	 (@ (class "app-example")
+		(href "http://web-artanis.com;))
+	 (img (@ (src ,(static-url "http://web-artanis.com/img/logo.png;))
+		 (alt "")))
+	 (h3 "GNU Artanis")
+	 (p "Web Application Framework")))
 	   (section
 	(@ (id "news") (class "free-flow-box"))
 	(h2 "News")
diff --git a/website/apps/base/libraries-page.scm b/website/apps/base/libraries-page.scm
index 3485888..5389cbc 100644
--- a/website/apps/base/libraries-page.scm
+++ b/website/apps/base/libraries-page.scm
@@ -197,12 +197,12 @@
 	 (p (b "License: ") "GPL"))
 	(section
 	 (@ (class "lib"))
-	 (h3 (a (@ (href "http://gitorious.org/glow/ragnarok/;))
-		"Ragnarok"))
+	 (h3 (a (@ (href "http://web-artanis.com/;))
+		"GNU Artanis"))
 	 (p (span (@ (class "guile-version-tag")) "Guile 2.0"))
-	 (p "A server for HTTP and other Internet protocols, with support "
-	"for templates, CGI, and more.")
-	 (p (b "License: ") "LGPL 3 or later"))
+	 (p "GNU Artanis is a web application framework(WAF) written in Guile Scheme."
+	"for templates, MVC, Relational Mapping and more.")
+	 (p (b "License: ") "GPLv3+ and LGPLv3+"))
 	(h2 (@ (id "tools")) "Tools")
 	(p "These projects are tools for or implemented with Guile. Mostly, "
 	   "these are the types of things that automate documentation or "
-- 
1.7.10.4

Re: New logo and website design proposal

[Nala Ginrut]

On Fri, 2015-10-09 at 17:24 -0500, Luis Felipe López Acevedo wrote:
> 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 .


You may try Artanis for this:
=
guile -c "(use-modules (artanis artanis))(init-server)(run)"
=

http://www.gnu.org/software/artanis/manual/manual.html#sec-4-2

Re: Asynchronous event loop brainstorm at FSF 30

[Nala Ginrut]

Hi Christopher!
I'm one of guys who's interested in this topic, say, async IO in Guile.

On Sat, 2015-10-03 at 17:29 -0500, Christopher Allan Webber wrote:
>  - 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)

Personally, I would like to avoid callback way for asyncio which is the
way in node.js. And I believe we have chances to avoid it in Guile.

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

I've learned roughly about how Erlang deals with multicore problem (I
don't know if Erlang has better solution since 2008). I'm not going to
discuss about the design here, but I have to mention that a proper
general coroutine interface in Guile core should provide a flexible way
to let users do there scheduling policy with multicores. Maybe it's too
idealism, but it's no harm to list it before the coding work.

>  - Initially, this would probably providing a general API for
>coroutines.  Mark thinks delimited continuations would not be as
>efficient as he'd like, but we think it's okay because we could
>provide a nice abstraction where maybe something nicer could be
>swapped out later, so delimited continuations could at least be a
>starting point.

Yes the current delimited-continuations is not so efficient. I think it
has to be optimized in the future. But I'm still standing on optimistic
side of delimited-continuation based asyncio design. Yes, I know it's
faster (in single core) if we use libev/libuv, which keeps fewer
information/states for each request compared to continuations. But I
don't see it's the best solution for scalability taking advantage of
distributed system.

Maybe I'm a little out of topic, a general async event loop is
unnecessary to be salable.

>  - 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
> 
>  - On top of this, "fancier" high level systems like an actor model or
>something like Sly's functional reactive programming system could be
>done.

Yes, it's better than playing raw continuations, which is hard to handle
and debug. ;-)

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

Anyway, it's no harm to add an implementation based on libuv/libev, but
I think it's improper to be put in Guile core. Or we'll introduce third
party lib as the prerequisites.
Unfortunately, there's no epoll in GNU/Hurd although it is believed not
so hard to be added based on current `select' in Glibc (different from
Linux, these stuffs are in userland on Hurd). I have discussed it with
Hurd folks, but we still have no coding work for it yet.

Again, it's no harm to add it as a lib, folks need efficient asyncio,
always.

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

Years ago, Mark Weave has told me (actually it's a kindly warning) that
we have to handle the ports properly for nonblock asyncio. It could be
more complex if one uses DB in her/his program. It's better if we could
have better abstraction for these ports. But I still have no idea about
it.


Any more comments? I think it's better to discuss it more, and list
more potential issues to be noticed。There're always big problems when you
want to design general interface.

Re: New logo and website design proposal

[Nala Ginrut]

Really cool！my two cents
On 2015-09-15 16:05, David Pirotte wrote:

> Hi Luis,
>
> Cool work, many thanks!
>
> I'll read carefully and if I feel like I should, I'll provide some
> more [personal]
> feedback, but as an overall and quick look, it really is nice.
>
>
Glad you like it, David, thanks :)

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.
>>
>
> This is definitely going to impact potential users, I think, thanks
> for doing this!
>
> Do you have the site source code somewhere we could look at it and maybe
> patch?
>
>
No code yet, the mock-up is an SVG drawing. I'm waiting for feedback on the
general design first before implementing anything.

Thanks for the feedback, David :)


-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

Anyone can explain the fields of vm_cont?

[Nala Ginrut]

I found that there's no any comments for the fields of struct vm_cont in
vm.h. Is there anyone kind enough to point me out?

 struct scm_vm_cont {
   SCM *sp;
   SCM *fp;
   scm_t_uint8 *ra, *mvra;
   scm_t_ptrdiff stack_size;
   SCM *stack_base;
   scm_t_ptrdiff reloc;
   scm_t_uint32 flags;
 };

I want to know the meaning of each fields, thanks!

PS: please don't reply me "it's unnecessary to know it for using Guile",
I want to know it anyway. ;-P

Best regards.
 

Re: Attempt to create an inline assembler for Guile

[Nala Ginrut]

nice work!
I may take look at it closely.
And I would recommend you use FFI if you just want to get pagesize, it's
easier than writing bunch of C code:
=code
(use-modules (system foreign))
(define ffi (dynamic-link))
(define sysconf
  (pointer-procedure int
  (dynamic-func sysconf ffi)
  (list int)))

(sysconf 30) ; 30 stands for _SC_PAGESIZE
== 4096
==end===

Happy hacking!

On Wed, 2015-06-24 at 21:41 +0200, Sjoerd van Leent wrote:
 Hi All,
 
 In line with my will to create an assembler, I started first by being able
 to execute something in memory, using the memory-mapper strategy. I am
 aware not all platforms use the same mechanism, but this is a starting
 point.
 
 At a later point, an inline assembler can be used by a (more abstract) JIT
 engine
 
 I put my repository here:
 
 https://github.com/santidhammo/guile-assembler
 
 Met vriendelijke groet,
 Sjoerd

Re: Guile Assembler

[Nala Ginrut]

On Tue, 2015-06-23 at 11:12 +0200, to...@tuxteam.de wrote:
 What does number/base do? Does it change the read syntax of numbers?
 

I think it defines a function (number/base base) first, then use it as
argument of the outer function...

http://docs.racket-lang.org/reference/define.html


 -- t

Re: Guile Assembler

[Nala Ginrut]

On Tue, 2015-06-23 at 11:27 +0200, to...@tuxteam.de wrote:
 Hm. Where's the difference to Guile's define? And why do you have double
 parentheses in your example?
 
 Still a bit lost.

hmm...do you read the pasted code in the repo? ;-)

Anyway, it's not standard Scheme grammar, so that's why I mention it.

 Regards
 -- t

Re: Guile Assembler

[Nala Ginrut]

hi Panicz!

On Mon, 2015-06-22 at 22:49 +0200, Panicz Maciej Godek wrote:
 My repo is available here:
 
 https://bitbucket.org/panicz/envy/src

Thanks for the hint!
There's tiny problem IMO, (define ((number/base base) (l ...)) is not
supported in Guile, but I do see something similar in Racket, say:
==code==
(define ((number/base base) l) l)
===end==

Anyway, I'm interested in this topic too. ;-)

 (the project uses an extension module from another project that is not
 contained in the repo, but can be easily obtained from
 https://bitbucket.org/panicz/slayer/src)
 
 Regards,
 M.

Re: Handling HTTP Upgrade requests

[Nala Ginrut]

On Tue, 2015-03-10 at 21:59 +0100, Andy Wingo wrote:
 On Thu 26 Feb 2015 08:51, Nala Ginrut nalagin...@gmail.com writes:
 
  3. I have to mention that the current inner server is not non-block and
  weak for slow-header-DDOS.
 
 Indeed.  I think the right solution is cothreads.  What do you think?
 

Yes, it's my answer too.  ;-)

For more clearly, NIO + cooperative threads. If it's BIO, then it works
fine with normal/good requests, but halts with the intended tricky
formatted bad requests.

Sometimes it could halt long time when you upload bigger file. That's
what current Artanis suffering from. But could be solved easily with
Nginx reverse-proxy. Anyway, this issue is not only about NIO, there're
large room for optimizing though.



  PS: To those who care, unfortunately, Guile has no epoll/kqueue yet,
  that's one of the reasons why I want to write new server core for
  Artanis. ;-)
 
 The wip-ethreads branch has something like this.  Perhaps that could
 serve for inspiration :)

Yes, it's good start for me. Years ago, Mark once gave me a warn that a
good non-blocking design may need to change something in Guile-core,
especially ports. But it's not an easy work to make the whole Guile
support non-blocking in short time. Dunno if it's still true for current
Guile.

My plan is to provide restricted non-blocking I/O cautiously.
Of course, I'm optimistic to expect Guile support better non-blocking
from long term perspective. ;-)

Re: Handling HTTP Upgrade requests

[Nala Ginrut]

Hi David!

IMHO, there's no HTTP header anymore once you've done handshake
successfully, but sending frame defined by WebSocket.

For this case, once handshake is successful, I think you have to spawn a
new server instance (or use callbacks, depends on your server
architecture design) rather than using Guile inner HTTP server to manage
this socket. Or it'll be cracked while parsing HTTP header as you
pasted.

One of the possible way is to build a WebSocket gateway to dispatch the
connections to each server instance (or callbacks) and managing
handshake for each connection.


Anyway, to support WebSocket, one have to customize the server core. The
Guile inner server is dedicated to be the HTTP one, IIRC. That's why I
stopped development of websocket module in Artanis, since I have to
write its new async server core first. ;-)


On Sat, 2015-02-21 at 18:00 -0500, David Thompson wrote:
 I've been tinkering with adding WebSockets[0] support to Guile's HTTP
 arsenal.  The first blocking issue I've come across is that an HTTP
 server must be able to detect the Upgrade header[1] and change
 protocols.  In my case, once a client thread accepts a WebSocket
 connection, it should speak the WebSocket protocol, not HTTP.
 
 Here's an example of a backtrace that you'd see after a successful
 WebSocket handshake, when the client tries to actually make use of the
 socket:
 
 In ice-9/boot-9.scm:
171:12  3 (with-throw-handler #t #procedure 1720560 at web/... #)
 In web/server/http.scm:
126:17  2 (#procedure 1720560 at web/server/http.scm:125:15 ())
 In web/request.scm:
204:31  1 (read-request #closed: file 0 ())
 In ice-9/boot-9.scm:
106:20  0 (#procedure 10ce380 at ice-9/boot-9.scm:97:6 (thr... ...)
 ERROR: Bad request: Bad Request-Line: \x81\x86B\x93�Q
 
 Does anyone have an idea about how to approach this problem?
 
 Thanks in advance!
 
 [0] http://www.websocket.org/
 [1] http://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header
 

[master branch] Strange problem while fetching symbol from certain module

[Nala Ginrut]

Hi folks!
I'm using master branch(2.1) for a while, since it's faster than
guile-2.0. But I encountered a problem after repo updated.

-begin-
scheme@(guile-user) (@ (rnrs) bytevector?)
ERROR: In procedure #procedure 185b520 ():
ERROR: In procedure private-lookup: No variable bound to bytevector? in
module (guile)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1] ,bt
   0 (#procedure 185b520 ())
-end---


Any hint for that?

Thanks!

Re: [patch] Location header is a URI-reference

[Nala Ginrut]

Thanks for working on it!
I haven't looked into this patch, but I hope it taking care of empty
string properly, since URL reference allows it.


Best regards.


On Wed, Oct 15, 2014 at 5:54 PM, Andy Wingo wi...@pobox.com wrote:
 Following RFC 7231, the HTTP Location: header is a URI-reference, not a
 URI.  This patch updates Guile's web modules appropriately, fixes a case
 in which URI fragments were parsed incorrectly, and makes public
 interfaces for creating URI references.

 Thoughts?  This is also in wip-uri-reference.

 Andy



 --
 http://wingolog.org/

Re: Verifying Toolchain Semantics

[Nala Ginrut]

On Mon, Oct 6, 2014 at 12:24 AM, Ian Grant ian.a.n.gr...@googlemail.com
wrote:

 On Sun, Oct 5, 2014 at 11:15 AM, Nala Ginrut nalagin...@gmail.com wrote:
 
  Alright, I changed a system and try it again with evince successfully.
  Anyway, I did't find any maths or special symbols in it, so it could be
  published on your blog as plain text. But you may insist on the opinion
 of
  PDF.

 There is another reason why I use PDF. It's much nicer to read. I love
 Garamond. Did you see the Jobs movie? Do you remember what he said
 about Garamond?


Well, I'm a naive font fan so I may understand you. I usually use my fav
font on page according to the design with HTML5/CSS stuff.
Forget about it, it's far from the topic.



 What we really need to do is find out what software Mark was using to
 pdf-png. If it segfaults then there is a good chance that that bug
 can be turned into a working exploit. Because all binaries distributed
 by the binary-distributors are identical, attackers can analyse the
 file and work out how to turn a bad pointer dereference into an
 exploitable PDF attack vector which executes binary code contained
 in the PDF.


Agreed. But I think the PDF is more complicated than TXT. One of my fav
ezine, Phrack is plain txt, and it's cool.
So my suggestion is to provide both TXT and PDF if the article is important.

Anyway, the font is a big issue for whom loves it, so I don't involve such
argue. ;-)

Re: Verifying Toolchain Semantics

[Nala Ginrut]

On Sun, Oct 5, 2014 at 10:14 PM, Ian Grant ian.a.n.gr...@googlemail.com
wrote:

 On Sun, Oct 5, 2014 at 1:39 AM, Nala Ginrut nalagin...@gmail.com wrote:
 
  The real problem here, is the provided PDF can't be opened normally.
 That's
  bad, for your idea. It's your mistake, not others.

 Then tell me the name, the sha512sum of the file, the URL from which
 you downloaded it and the size of the file as reported by your
 filesystem. Also tell me the exact error, and the program (including
 the version number) and if possible the file location of the error.


Alright, I changed a system and try it again with evince successfully.
Anyway, I did't find any maths or special symbols in it, so it could be
published on your blog as plain text. But you may insist on the opinion of
PDF.
It's not your mistake but mine. ;-)

Thanks
 Ian