Guile 2.1.8 on 9 March / 2.2.0 on 16 March

[Andy Wingo]

Hi,

An update on Guile 2.2 status.  As I mentioned in a previous mail, I
think the master branch is good to go.  I spent some time over the last
week going over bugs; I have looked at all bugs in our database (!),
fixed a number of them (check https://debbugs.gnu.org/rrd/guile.html!),
and I think from those bugs I have no release blockers.  I am a little
behind on guile-devel still but hope to catch up shortly; that's my only
remaining backlog.

I have forward-ported all appropriate patches from 2.0 except the
reproducible-build patches.  I am hoping Ludovic will take that up :)
So we are caught up there as well.

There are still the release blocker discussions ongoing: foreign
objects, macro-introduced toplevel identifiers, and GOOPS incompatible
changes.

I think though that we are looking pretty good for a final 2.1.8
prerelease on 9 March (in 1 week).  Then we can let people build it, fix
any build errors, try it out on various platforms or whatever, and get
out a 2.2.0 on 16 March.

I would point people to hydra tarballs to test but it seems we broke
Hydra with the dist-lzip patch :)  I reverted that patch on both
branches and hopefully we have new disted tarballs for checking in a few
hours.

Finally for the release we should consider publicity -- what do we do?
Anything special?  Volunteers are welcome here.  The NEWS is quite
verbose, so condensing it into a set of 5-10 big-ticket items could be
useful; dunno.

Maybe we can use this as an opportunity to get people to try Guix
actually -- if we cut a 2.2.0 tarball a day before and get it into Guix
and get guile-next built, perhaps we could offer a binary installation
option for people on GNU machines (via Guix).  Dunno; thoughts here are
welcome.

OK, that's all from me.  Happy hacking :)

Andy

Re: The status of JIT compiler of Guile

[Andy Wingo]

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 took a look at the diff; somehow I thought previously that it was all
in C.  Now I see that you have a (language trace) and I am intrigued :)
I need to look at this more.

It is especially amazing to see that the C component is only three
thousand lines or so.  Very cool :)

On Thu 02 Mar 2017 08:49, Nala Ginrut  writes:

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

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

Andy

Re: guile-pg 0.47 bug report

[Thien-Thi Nguyen]

() Greg Troxel 
() Sun, 07 Jun 2015 07:29:29 -0400

   I just updated pkgsrc to 0.47.  Three nits:

 You say to send bugs to ./configure --help, but that
 doesn't show up in the installed package anywhere.

Thanks for the bug report.  I have installed this fix:


 Tests failed (entirely) due to running out of shm segments.
 I have regular pgsql running, and I think the tests used to
 work.  So I wonder if there is some newly expanded
 maxconnections in the test driver.

Not that i know (i confess until this post, i was not even aware
of ‘maxconnections’).  How do you know shm segments starvation
was the culprit?  Does "make check VERBOSE=1 DEBUG=1" reveal any
clues?

 There's a libpostgres.la symlink in $prefix/lib/guile-pg
 that wasn't there in 0.46, not mentioned in NEWS.  It seems
 like it is extra and unnecessary.

Hmmm.  Investigating...

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

Re: GNU Guile 2.1.7 released (beta)

[Thien-Thi Nguyen]

() Andy Wingo 
() Wed, 01 Mar 2017 18:36:20 +0100

   [paredit-fu]
   FWIW :)

Cool.  I'll add this to the manual.  Any suggestions where?

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

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

[Chaos Eternal]

赞(+1)

On Thu, Mar 2, 2017 at 3:49 PM Nala Ginrut  wrote:

> 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: GNU Guile 2.1.7 released (beta)

[David Pirotte]

Hi Daniel,
Andy,

> I think this is the minimum for .guile:
> 
> (import (system repl common) (ice-9 format))
> (repl-default-option-set! 'print (lambda (repl val) (format #t "~200@y" val)))
> 
> That doesn't seem so bad. For the current repl you can do:
> 
> (repl-option-set! (car (fluid-ref *repl-stack*)) 'print (lambda (repl val) 
> (format
> #t "~200@y" val)))

Veeery complicated :)

Howe about this:

(set! %repl-printer truncated-print)
(set! %truncated-print-max-chars 72)

In the repl

,repl-printer truncated-print
,truncated-print-max-chars 72

Once set, the above would be used by error and raised exception 'printers', per
default imo, otherwise we could also have:

(set! %error-printer truncated-print)

In the repl

,error-printer truncated-print

Regards,
David


pgpt0HQz0IcBH.pgp
Description: OpenPGP digital signature

problem with gdb , scm_set_automatic_finalization_enabled

[carl hansen]

> gdb
gdb: relocation error: gdb: symbol scm_set_automatic_finalization_enabled,
version GUILE_2.0 not defined in file libguile-2.0.so.22 with link time
reference

I can't run gdb which I just compiled, looks like guile problem, what's it
all mean?

Re: problem with gdb , scm_set_automatic_finalization_enabled

[carl hansen]

nevermind, I figured it out, old library in library path

ignore this message

On Thu, Mar 2, 2017 at 7:29 PM, carl hansen 
wrote:

> > gdb
> gdb: relocation error: gdb: symbol scm_set_automatic_finalization_enabled,
> version GUILE_2.0 not defined in file libguile-2.0.so.22 with link time
> reference
>
> I can't run gdb which I just compiled, looks like guile problem, what's it
> all mean?
>

Re: How to make GNU Guile more successful

[Nala Ginrut]

I think we have to elaborate the question clearer.

1. How to make guile-scheme more successful?
I think this is similar to ask "how to make scheme more successful".
This is the big question to the whole scheme community.

2. How to make guile platform more successful?
I this case, let me ask a question, if we have guile-python3
(compatible with most of Python3 features), and provide more
convenient FFI helper function to help bind more libraries in short
time, is it possible to attract more people from Python land? Given
we'll have good JIT compiler in the future.


On Thu, Mar 2, 2017 at 3:25 AM, Amirouche  wrote:
>
>
> Le 21/02/2017 à 20:25, Arne Babenhauserheide a écrit :
>>
>> Amirouche  writes:

 If someone had a realistic plan of building something like that, I
 might be able to contribute. I am not going to tackle it alone.
>>>
>>> What's the status of guildhall, does it work? where are the latest
>>> changes?
>>
>> What we need is someone who regularly puts the package folder onto a
>> static webserver
>
>
> What does it mean?
>
>> (starnge that I did not think of just using a repo
>> instead of implementing a full web interface with access rights and
>> such).
>
>
> The issue I have with the web repository (I assume you meant git repo),
> is that it requires for the maintainer of the repository to push a button,
> accept new packages (at the very least). Which would mean that I offer
> some kind of guarantees over the content of the software that you
> download. Which maybe right now I can assume, but if there is as much
> as patch in the repo as there is in guix I will need help...
>
>
>>
>> Guildhall works with guile-2.0, and there are no changes (though I have
>> a local version in which `guild hall` outputs the default installation
>> locations).
>>
>> However I get an error with guile 2.1.5:
>>
>> $ make
>> ./env /home/arne/.local/bin//guile-tools compile -Wunbound-variable
>> -Warity-mismatch -Wformat -o "guildhall/cli/config.go"
>> "guildhall/cli/config.scm"
>> Backtrace:
>> In ice-9/boot-9.scm:
>>2860:10 19 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
>>2799:17 18 (resolve-interface (guildhall config) #:select _ #:hide …)
>>2724:10 17 (_ (guildhall config) _ _ #:ensure _)
>>3000:16 16 (try-module-autoload _ _)
>> 2336:4 15 (save-module-excursion #)
>>3020:22 14 (_)
>> In unknown file:
>>13 (primitive-load-path "guildhall/config" #)
>> In guildhall/config.scm:
>>   25:0 12 (_)
>> In ice-9/boot-9.scm:
>>2799:17 11 (resolve-interface (guildhall destination fhs) #:select …)
>>2724:10 10 (_ (guildhall destination fhs) _ _ #:ensure _)
>>3000:16  9 (try-module-autoload _ _)
>> 2336:4  8 (save-module-excursion #)
>>3020:22  7 (_)
>> In unknown file:
>> 6 (primitive-load-path "guildhall/destination/fhs" #)
>> In guildhall/destination/fhs.scm:
>>  152:0  5 (_)
>> In guildhall/ext/inc/irregex-r6rs.scm:
>>1505:17  4 (sre->irregex _ . _)
>>2448:15  3 (sre->nfa _ 0)
>>2391:29  2 (lp ((* any) (: "." ($ (+ (~ numeric) 1 0 0)
>>2301:52  1 (lp ("." ($ (+ (~ numeric 1 0 _)
>> In ice-9/boot-9.scm:
>> 762:26  0 (dispatch-exception _ _ _)
>>
>> Best wishes,
>> Arne
>
>
>