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: [PATCH] Fix bug #24816: open-string-output-port extraction thunk does not truncate string port as expected by R6RS in Guile 2.1.7

[Andy Wingo]

On Wed 01 Mar 2017 22:15, Freja Nordsiek  writes:

> By the way, I tested the method you used manually on 2.0.x today and
> it fixed the discrepancy with R6RS there too. Might consider patching
> that branch too. Hopefully no one has been depending on the
> non-truncating behavior.

Would you mind sending a patch?  I would be happy to apply it :)

Cheers,

Andy

Re: [PATCH] Fix bug #24816: open-string-output-port extraction thunk does not truncate string port as expected by R6RS in Guile 2.1.7

[Freja Nordsiek]

Thanks for the tip on how to properly reply to a bugreport. I will make
sure I get that right next time.

By the way, I tested the method you used manually on 2.0.x today and it
fixed the discrepancy with R6RS there too. Might consider patching that
branch too. Hopefully no one has been depending on the non-truncating
behavior.


Freja

On Mar 1, 2017 6:55 PM, "Andy Wingo"  wrote:

> Heya Freja,
>
> On Tue 21 Feb 2017 20:36, Freja Nordsiek  writes:
>
> > Patch for bug #24816: https://debbugs.gnu.org/cgi/
> bugreport.cgi?bug=24816
>
> Apologies for not noticing this patch; I was working from the debbugs
> interface and didn't see this.  In the future you can update a bug with
> a patch by CC'ing nn...@debbugs.gnu.org, e.g. 24...@debbugs.gnu.org.
>
> Your patch is pretty much exactly what I did, too :)  One thing I did
> was require the port position to be within the bounds of the truncated
> size; was a tough call but truncate-file on a file doesn't adjust the
> position, so there's that.
>
> Thank you again for the patch and sorry for missing it.  Looking forward
> to future patches :-)
>
> Andy
>

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

[Amirouche]

Le 01/03/2017 à 20:35, Amirouche a écrit :

Le 23/02/2016 à 17:57, Arne Babenhauserheide a écrit :
That said I have an issue with registration/login
stuff anything related with setting cookies I don't find a good 
abstraction,

for it.

I keep you posted.


So I found a solution that satisfy me. Here is it:

(define (pair->set-cookie item)
  `(Set-Cookie . ,(string-append (symbol->string (car item))
 "="
 (cadr item

(define (sxml->set-cookies sxml)
  (match sxml
((('doctype doctype)
  ('html ('@ . options) . rest))
  (map pair->set-cookie options))
 (_ '(

(define (sxml->response sxml)
  (let ((set-cookies (sxml->set-cookies sxml)))
(values `((content-type . (text/html)) ,@set-cookies)
  (lambda (port)
(sxml->html sxml port)

;;; handler

(define (handler request body)
  (sxml->response `((doctype "html")
(html
 (body "echo")

(format #t "Héllo! Go to http://localhost:8080\n;)
  (run-server handler))


amz3

Re: GNU Guile 2.1.7 released (beta)

[Arne Babenhauserheide]

Andy Wingo  writes:

> On Fri 24 Feb 2017 18:46, Arne Babenhauserheide  writes:
>
>> The main strategical question I see for that is: Does anything make it
>> harder to complete or improve the lilypond transition to Guile 2?
>>
>> Is there something which would need to be done before 2.2 which could
>> make it easier for lilypond developers?
>
> I don't know of any concrete points here.  2.2 is not dissimilar to 2.0.
> If you someone like to try to determine exactly what specific bits of
> Guile 2.2 impact Lilypond (and indeed any big application using the C
> interface), that would be welcome :)  I guess I'd start with NEWS to see
> what's up.

I’ll have to write up my test setup for lilypond, too …

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [PATCH] Fix bug #24816: open-string-output-port extraction thunk does not truncate string port as expected by R6RS in Guile 2.1.7

[Andy Wingo]

Heya Freja,

On Tue 21 Feb 2017 20:36, Freja Nordsiek  writes:

> Patch for bug #24816: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24816

Apologies for not noticing this patch; I was working from the debbugs
interface and didn't see this.  In the future you can update a bug with
a patch by CC'ing nn...@debbugs.gnu.org, e.g. 24...@debbugs.gnu.org.

Your patch is pretty much exactly what I did, too :)  One thing I did
was require the port position to be within the bounds of the truncated
size; was a tough call but truncate-file on a file doesn't adjust the
position, so there's that.

Thank you again for the patch and sorry for missing it.  Looking forward
to future patches :-)

Andy

Re: Guile 1.8 development

[Andy Wingo]

On Wed 01 Mar 2017 13:14, Thien-Thi Nguyen  writes:

> Which git branch is best for continued Guile 1.8 development?
> I know most people have no interest in 1.8, that's fine, just
> kindly humor this slow janitor w/ a normative answer, thanks.
>
> (I guess ‘branch_release-1-8’, but maybe someone knows better.)

Yep, branch_release-1-8.

Happy hacking,

Andy

Re: bug#24887: procedure-sources not working

[Jean Louis]

On Wed, Mar 01, 2017 at 03:09:06PM +0100, Andy Wingo wrote:
> On Sat 05 Nov 2016 23:01, Jean Louis  writes:
> 
> > Sadly, the procedure-source is not working. This would be very useful
> > for programming.
> >
> > Jean
> >
> > scheme@(guile-user) [50]> (define (dosomething text) (write text))
> > scheme@(guile-user) [50]> (dosomething "Hello")
> > "Hello"scheme@(guile-user) [50]> (procedure-source dosomething )
> > $93 = #f
> > scheme@(guile-user) [50]> 
> 
> Sadly I think I am going to WONTFIX this one :/
> 
> The reason is complicated.  First of all, a procedure's source only
> makes sense within an environment: in a module and in a lexical
> context, and you're not guaranteed to be able to reconstruct either of
> those.  Also a procedure's source is expressed in some dialect via
> macros; what should the source be for even this simple example?  Should
> it be:

Thank you. I am not an advanced user of Guile. And that
procedure-source, I can compare to (SYMBOL-PLIST 'FUNCTION) in Lisp,
as I am also using CLISP.

If I have a function defined, such as RED, then I can see the source
of the function in CLISP:

(symbol-plist 'red)
(SYSTEM::DEFINITION ((DEFUN RED (FILE) (ED FILE) (LOAD FILE)) . #(NIL NIL NIL 
NIL ((DECLARATION OPTIMIZE DECLARATION SYSTEM::DOC
 (SYSTEM::FILE ((SYSTEM::DEFUN/DEFMACRO
 #P"/home/data1/protected/.clisprc.lisp" 53 53

And I was simply expecting the PROCEDURE-SOURCE in Guile to behave in
similar fashion.

>From documentation:

-- Scheme Procedure: procedure-source proc
 -- C Function: scm_procedure_source (proc)
 Return the source of the procedure PROC.  Returns ‘#f’ if the
 source code is not available.

So that is what I am expecting according to documentation. As I am not
developer of Guile, rather user and student, I cannot go into details,
if it should be there or not.

It is simply there and is not functioning, so it is expected to
function. Or you propose the removal, I don't mind.

Jean Louis

Re: bug#24887: procedure-sources not working

[Andy Wingo]

On Sat 05 Nov 2016 23:01, Jean Louis  writes:

> Sadly, the procedure-source is not working. This would be very useful
> for programming.
>
> Jean
>
> scheme@(guile-user) [50]> (define (dosomething text) (write text))
> scheme@(guile-user) [50]> (dosomething "Hello")
> "Hello"scheme@(guile-user) [50]> (procedure-source dosomething )
> $93 = #f
> scheme@(guile-user) [50]> 

Sadly I think I am going to WONTFIX this one :/

The reason is complicated.  First of all, a procedure's source only
makes sense within an environment: in a module and in a lexical
context, and you're not guaranteed to be able to reconstruct either of
those.  Also a procedure's source is expressed in some dialect via
macros; what should the source be for even this simple example?  Should
it be:

  (define (dosomething text) (write text))

or

  (lambda (text) (write text))

And if we can't get it right (i.e., don't even know what the right
answer is) for even this simple case, how can we get it right for
something that uses macros or is defined by a macro?  What use is it,
really?  Better to just be able to link back to the source location at
which it was defined (we can do that) or to disassemble what it does (we
can do that too).

It's possible to imagine environments where you can edit the procedure's
source and continue directly, but that's not Guile -- we compile away
extraneous information that maybe you might would need if you edit a
procedure's source (e.g. you introduce a reference to a variable bound
in some outer scope that wasn't referenced before).

All that said, it's possible to attach arbitrary properties to source.
So consider:

  (define-syntax-rule (define-with-source (proc . args) body ...)
(define (proc . args)
  ;; this is how you attach arbitrary literals as procedure
  ;; properties efficiently, inside source
  #((source . (lambda args body ...)))
  body ...))

  (define-with-source (my-proc a b) (list a b))

  (procedure-property my-proc 'source)
  => (lambda (a b) (list a b))

Indeed because procedure-source just looks for the 'source property on
my-proc, you can do:

  (procedure-source my-proc)
  => (lambda (a b) (list a b))

Hope this helps.  Not sure if we should bless a "define-with-source" in
Guile; thoughts?  Is it even useful at all?

Andy

Guile 1.8 development

[Thien-Thi Nguyen]

Which git branch is best for continued Guile 1.8 development?
I know most people have no interest in 1.8, that's fine, just
kindly humor this slow janitor w/ a normative answer, thanks.

(I guess ‘branch_release-1-8’, but maybe someone knows better.)

-- 
Thien-Thi Nguyen ---
 (defun responsep (query)
   (pcase (context query)
 (`(technical ,ml) (correctp ml))
 ...))  748E A0E8 1CB8 A748 9BFA
--- 6CE4 6703 2224 4C80 7502



signature.asc
Description: PGP signature