Re: FOSDEM 2019
On 2019-02-06 22:03, Ricardo Wurmus wrote: > This takes care of compiling the files and placing them where they > should go. The upstream picture language repository does not use > Autotools. This is really nice! Thanks for the heads up. When/if my guile-wikidata is mature enough I could easily add it using this without bothering about autotools. :) So the user has the choice: either install manually via git clone or via guix package. -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: FOSDEM 2019
Ricardo Wurmus writes:
> Alex Sassmannshausen writes:
>
>> Hi Amirouche
>>
>> Amirouche Boubekki writes:
>>
>>> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen
>>> a écrit :
>>>
>>> > - Janneke mentioned the new guile build system in guix for simpler
>>> >guile packages and I think that's pretty great. Likewise there was
>>> >some mention of some sort of you-don't-have-to-use-autotools build
>>> >system and I don't remember what it's name was. (BTW, I continue to
>>> >believe that "Guix is and should be Guile's package mangager".)
>>>
>>> I was unaware that we had a guile build system in Guix.
>>>
>>> What is it?
>>
>> I may be misunderstanding — so feel free to clarify!
>>
>> The build system in Guix would be a value that can be declared in the
>> `build-system' field of package definitions. It's basically what tells
>> Guix what steps need to be performed to build and install an
>> application.
>>
>> Guile libraries and applications currently need to use the GNU Build
>> System, or the trivial build system, with some additional steps that
>> need to be added by the packager.
>>
>> If we had a build system, we could simply stick the `guile-build-system'
>> value in the `build-system' field.
>
> This exists. I use it for the picture language, for example. Here’s
> the Guix definition:
>
> --8<---cut here---start->8---
> (define-public guile-picture-language
> (let ((commit "1531116036d1b5e0d2482ff2c8d77ad21f1d2bef")
> (revision "1"))
> (package
> (name "guile-picture-language")
> (version (git-version "0" revision commit))
> (source (origin
> (method git-fetch)
> (uri (git-reference
> (url
> "https://git.elephly.net/software/guile-picture-language.git;)
> (commit commit)))
> (sha256
> (base32
> "04salmqf5x84vb3qkkxx47b64jyl290zsf3ik81l9hg6fwvvlmq3"
> (build-system guile-build-system)
> (inputs
>`(("guile" ,guile-2.2)))
> (home-page
> "https://git.elephly.net/software/guile-picture-language.git;)
> (synopsis "Picture language for Guile")
> (description
>"This package provides a simple SVG-based picture language for Guile.
> The picture values can directly be displayed in Geiser.")
> (license license:lgpl3+
> --8<---cut here---end--->8---
>
> This takes care of compiling the files and placing them where they
> should go. The upstream picture language repository does not use
> Autotools.
This is very exciting to see — sorry for the misinformation I spread.
Thanks for pointing it out.
Cheers,
Alex
Re: FOSDEM 2019
Alex Sassmannshausen writes:
> Hi Amirouche
>
> Amirouche Boubekki writes:
>
>> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen
>> a écrit :
>>
>> > - Janneke mentioned the new guile build system in guix for simpler
>> >guile packages and I think that's pretty great. Likewise there was
>> >some mention of some sort of you-don't-have-to-use-autotools build
>> >system and I don't remember what it's name was. (BTW, I continue to
>> >believe that "Guix is and should be Guile's package mangager".)
>>
>> I was unaware that we had a guile build system in Guix.
>>
>> What is it?
>
> I may be misunderstanding — so feel free to clarify!
>
> The build system in Guix would be a value that can be declared in the
> `build-system' field of package definitions. It's basically what tells
> Guix what steps need to be performed to build and install an
> application.
>
> Guile libraries and applications currently need to use the GNU Build
> System, or the trivial build system, with some additional steps that
> need to be added by the packager.
>
> If we had a build system, we could simply stick the `guile-build-system'
> value in the `build-system' field.
This exists. I use it for the picture language, for example. Here’s
the Guix definition:
--8<---cut here---start->8---
(define-public guile-picture-language
(let ((commit "1531116036d1b5e0d2482ff2c8d77ad21f1d2bef")
(revision "1"))
(package
(name "guile-picture-language")
(version (git-version "0" revision commit))
(source (origin
(method git-fetch)
(uri (git-reference
(url
"https://git.elephly.net/software/guile-picture-language.git;)
(commit commit)))
(sha256
(base32
"04salmqf5x84vb3qkkxx47b64jyl290zsf3ik81l9hg6fwvvlmq3"
(build-system guile-build-system)
(inputs
`(("guile" ,guile-2.2)))
(home-page "https://git.elephly.net/software/guile-picture-language.git;)
(synopsis "Picture language for Guile")
(description
"This package provides a simple SVG-based picture language for Guile.
The picture values can directly be displayed in Geiser.")
(license license:lgpl3+
--8<---cut here---end--->8---
This takes care of compiling the files and placing them where they
should go. The upstream picture language repository does not use
Autotools.
--
Ricardo
Re: FOSDEM 2019
Amirouche Boubekki writes: > Talking about tools and build systems, what do you think of https://waf.io/? I used to use it, and it is what brought me back to autotools. It is a nice tool in itself, but once I strayed from the happy path, I realized that autotools wins. Same for setuptools/pip, scons, and cmake. That and make distcheck. Anything which does not give me an equivalent of make distcheck isn’t good enough, because I need a way to have self-contained checking of stuff I release. That’s also something I learned over the years. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: FOSDEM 2019
Hello all, Le mer. 6 févr. 2019 à 18:47, Ludovic Courtès a écrit : > Nala Ginrut skribis: > > > Does it mean someone is working on writing Racket specific dialect > > front-end on Guile? I appreciate! > > Nope! Actually Chris Webber raised the issue of collaboration between > Racket and Guile in their talk, which is why we’re discussing it. > > But Guile is still Guile and there’s also lots of Guile hacking waiting > for us. > I actually meant to work on the racket front-end. Skimmed through their reference API and nothing stands out. I known that I don't know. Perfection is in the detail. Thad said some particular topic attracted my attention: - Phases and compilation guarantees [1] - Continuations Frames and Mark [2] - Custodians [3] [1] https://docs.racket-lang.org/reference/eval-model.html#%28part._module-eval-model%29 [2] https://docs.racket-lang.org/reference/eval-model.html#%28part._mark-model%29 [3] https://docs.racket-lang.org/reference/eval-model.html#%28part._custodian-model%29 TIL it is possible for me to create a front-end in guile. There is various example in guile tree. But again perfection is the detail. Also, I would like to point out that there are already racket things available in GNU Guile: - for-loops https://bitbucket.org/bjoli/guile-for-loops - syntax-parse https://gitlab.com/guile-syntax-parse/guile-syntax-parse Last but not least guile fibers https://github.com/wingo/fibers which rather unique in scheme universe at least. I was interested in this racket-on-guile because it seems difficult, also there was potential to make a contribution that is useful, and learn a few things about Guile inner working. At the end of the day it's not because we can run racket programs that GNU Guile will suddenly become the place to be. I don't say it is a useless project, working code is always great. But it is not enough. See for instance, PyPy has pratically catched up CPython and has better performance, it still not mainstream. Enough said ;-) I will look at r7rs branch [a] and pdf report [b] [a] http://git.savannah.gnu.org/cgit/guile.git/log/?h=r7rs-wip [b] https://small.r7rs.org/attachment/r7rs.pdf
Re: FOSDEM 2019
Hi Amirouche Amirouche Boubekki writes: > Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen > a écrit : > > > - Janneke mentioned the new guile build system in guix for simpler > >guile packages and I think that's pretty great. Likewise there was > >some mention of some sort of you-don't-have-to-use-autotools build > >system and I don't remember what it's name was. (BTW, I continue to > >believe that "Guix is and should be Guile's package mangager".) > > I was unaware that we had a guile build system in Guix. > > What is it? I may be misunderstanding — so feel free to clarify! The build system in Guix would be a value that can be declared in the `build-system' field of package definitions. It's basically what tells Guix what steps need to be performed to build and install an application. Guile libraries and applications currently need to use the GNU Build System, or the trivial build system, with some additional steps that need to be added by the packager. If we had a build system, we could simply stick the `guile-build-system' value in the `build-system' field. > In the past I was the one who argued strongly for the build system and > for the no-autotools approach — I believe in the context of outreachy. > Unfortunately I was unable to make that part a reality. > > Even so, I have been developing a solution that is part of this > discussion in the form of Guile Hall, which is a project manager for > Guile with strong integration with Guix & Autotools. > > guile hall can be found here https://gitlab.com/a-sassmannshausen/guile-hall Thank you for adding that link. I forgot to add that! > As you can see, I have a horse in this race. I would be very interested > in collaborating with others who feel strongly about this part of the > Guile/Guix user journey — either on improvements to Hall, Guix or on > other tooling. > > Talking about tools and build systems, what do you think of https://waf.io/? I have heard about it before, but to be honest I haven't engaged with it. For me, my engagement with build systems is a necessary evil. I want to do the right thing, but really I want to engage with them as little as possible. Hackers much more knowledgeable and experienced than I have persuasively argued for the benefits of the Autotools infrastructure, which also is the "blessed" GNU system. This is why I decided to have Hall build Autotools infrastructure. Sorry, this answer might not have been what you are looking for, but the truth is I don't even know enough about build systems to be able to evaluate their merits. There has been talk in the past about Autotools replacements or Guile build systems etc. but in the meantime I wanted to get something out there, in a rather unlisp-y fashion perhaps, that is worse than better (https://www.dreamsongs.com/WorseIsBetter.html). Best wishes, Alex
Re: FOSDEM 2019
Le mer. 6 févr. 2019 à 16:22, Amirouche Boubekki < amirouche.boube...@gmail.com> a écrit : > > > Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen < > alex.sassmannshau...@gmail.com> a écrit : > >> > - Janneke mentioned the new guile build system in guix for simpler >> >guile packages and I think that's pretty great. Likewise there was >> >some mention of some sort of you-don't-have-to-use-autotools build >> >system and I don't remember what it's name was. (BTW, I continue to >> >believe that "Guix is and should be Guile's package mangager".) >> >> I was unaware that we had a guile build system in Guix. > > > What is it? > I could look it up, sorry for the noise. ref: https://www.gnu.org/software/guix/manual/en/guix.html#index-guile_002dbuild_002dsystem
Re: FOSDEM 2019
Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen < alex.sassmannshau...@gmail.com> a écrit : > > - Janneke mentioned the new guile build system in guix for simpler > >guile packages and I think that's pretty great. Likewise there was > >some mention of some sort of you-don't-have-to-use-autotools build > >system and I don't remember what it's name was. (BTW, I continue to > >believe that "Guix is and should be Guile's package mangager".) > > I was unaware that we had a guile build system in Guix. What is it? > In the past I was the one who argued strongly for the build system and > for the no-autotools approach — I believe in the context of outreachy. > Unfortunately I was unable to make that part a reality. > > Even so, I have been developing a solution that is part of this > discussion in the form of Guile Hall, which is a project manager for > Guile with strong integration with Guix & Autotools. > guile hall can be found here https://gitlab.com/a-sassmannshausen/guile-hall > As you can see, I have a horse in this race. I would be very interested > in collaborating with others who feel strongly about this part of the > Guile/Guix user journey — either on improvements to Hall, Guix or on > other tooling. > Talking about tools and build systems, what do you think of https://waf.io/?
Re: FOSDEM 2019
Christopher Lemmer Webber writes: > Arne Babenhauserheide writes: > >> 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 :-) >> >> [...] >> >> 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). > > I regret that I didn't convey the right energy at the end of my talk. > I actually think Guile is in a better space than it's ever been as far > as I've been looking at it and I see an amazing future ahead for it. > > [...] > > - I do think it's true that Guile doesn't have as good of a story as >Racket in terms of getting people new to lispy languages in the door. >But! We actually had a really nice discussion about how to maybe do >the right thing to improve things for Guile. Part of that >conversation was "Oh hey, what if we took Spacemacs as inspiration? >What if we had an emacs distribution that came that was preconfigured >for people familiar with classic IDEs and which is set up and easy to >use Guile with?" This would also allow those users to "grow into" >Emacs as an editor. (I've jokingly called the idea GuileJr in the >past but it badly needs a less diminuitive name. ;)) I think this is a really valuable next step in improving our approachability for sure. I'm very interested in this, and might start looking at this next. > - Janneke mentioned the new guile build system in guix for simpler >guile packages and I think that's pretty great. Likewise there was >some mention of some sort of you-don't-have-to-use-autotools build >system and I don't remember what it's name was. (BTW, I continue to >believe that "Guix is and should be Guile's package mangager".) I was unaware that we had a guile build system in Guix. My understanding is that the Guile experience in Guix is still a bit janky — we need to wrap binaries manually; dependencies alas must be propagated… In the past I was the one who argued strongly for the build system and for the no-autotools approach — I believe in the context of outreachy. Unfortunately I was unable to make that part a reality. Even so, I have been developing a solution that is part of this discussion in the form of Guile Hall, which is a project manager for Guile with strong integration with Guix & Autotools. I will be pushing out a new release after some bug fixes with the help of Cato and Ricardo. At that point I'm fairly happy with the usability of the project. I could imagine an Emacs interface for Hall, in a similar vein to the Guix interface, which both combined could provide a ton of the functionality that our "Spacemacs" might provide. As an aside, Hall circumvents the jankiness of Guile in Guix & Autotools by being able to generate elaborate Guix recipes and basic autotools infrastructure. As you can see, I have a horse in this race. I would be very interested in collaborating with others who feel strongly about this part of the Guile/Guix user journey — either on improvements to Hall, Guix or on other tooling. Best wishes, Alex
Re: FOSDEM 2019
Nala Ginrut skribis: > Does it mean someone is working on writing Racket specific dialect > front-end on Guile? I appreciate! Nope! Actually Chris Webber raised the issue of collaboration between Racket and Guile in their talk, which is why we’re discussing it. But Guile is still Guile and there’s also lots of Guile hacking waiting for us. :-) Ludo’.
Re: FOSDEM 2019
Arne Babenhauserheide writes: > 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. Oops, I misquoted Arne as Janneke in my last email... my bad. :)
Re: FOSDEM 2019
Arne Babenhauserheide writes: > 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). I regret that I didn't convey the right energy at the end of my talk. I actually think Guile is in a better space than it's ever been as far as I've been looking at it and I see an amazing future ahead for it. I do stand by that there are a bunch of cases where catching up to Racket appears hard, but one thing we didn't catch on camera unfortunately is the great conversation we had in the cafeteria on Sunday about Guile and Racket and where their strenths are and how to learn from and collaborate with each other more. So allow me to provide an addendum to my talk, based on the conversations we had: - Guile and Racket may sometimes have some different domains where they're excelling, and that's okay and good - I do think it's true that Guile doesn't have as good of a story as Racket in terms of getting people new to lispy languages in the door. But! We actually had a really nice discussion about how to maybe do the right thing to improve things for Guile. Part of that conversation was "Oh hey, what if we took Spacemacs as inspiration? What if we had an emacs distribution that came that was preconfigured for people familiar with classic IDEs and which is set up and easy to use Guile with?" This would also allow those users to "grow into" Emacs as an editor. (I've jokingly called the idea GuileJr in the past but it badly needs a less diminuitive name. ;)) - Wingo put forward that Mes and Guix are examples of projects that are already pushing Guile's community in the right direction. And it's clear that Guile is growing a lot. - Janneke mentioned the new guile build system in guix for simpler guile packages and I think that's pretty great. Likewise there was some mention of some sort of you-don't-have-to-use-autotools build system and I don't remember what it's name was. (BTW, I continue to believe that "Guix is and should be Guile's package mangager".) There's a lot of reason for optimism. I'm sorry if I applied too much "stop energy", that's not what I meant to do. If you watched or will watch my talk, rather than consider it a "Guile is over, Racket is the future" type talk, I'd prefer it to be interpreted as "here are some experiences from an external community that might help us think how Guile could improve itself and think about where its most useful role is". But BTW, I do agree with Janneke's interpretation of my talk about "shiny matters". Plenty of sources of glossy finishes we can apply to our work, so that too is an opportunity for improvement to excite newcomers more than anything else. - Chris
Re: FOSDEM 2019
Hi Le mar. 5 févr. 2019 à 18:17, Ludovic Courtès a écrit : > Hi, > > Amirouche Boubekki skribis: > > > What does it mean in practice? What are the tasks that must dealt with? > > Like I wrote, an immediate task is to write a Racket importer for Guix¹ > and to actually package things. > > Next, we could ensure the subset of these packages that use #r6rs can > also be used as Guile packages. However Chris noted that there are few > of them; most use #lang racket. > > Thus, the next idea is to have #lang racket in Guile, which is quite a > bit of work but probably doable. Challenge accepted :) And the converse: #lang guile in > Racket. > > There are probably other things that could be done, or variants on this > theme. > > Is that clearer? > > Thanks, > Ludo’. > > ¹ > https://gnu.org/software/guix/manual/en/html_node/Invoking-guix-import.html >
Re: FOSDEM 2019
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
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
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
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
Le lun. 4 févr. 2019 à 15:52, Ludovic Courtès a écrit : > Hello Mikael! > > Mikael Djurfeldt skribis: > > > It was a great experience and joy for me to meet some of you at FOSDEM > > 2019. Thank you all! > > Seconded, that was awesome! Meeting Guilers, both newcomers and > old-timers :-), was just great! > > > Everyone who works with Guile knows that it's crap and look with envy at > > projects like Chez and Racket, right? > [...] a couple of other people talked about this yesterday at FOSDEM, and we > agree that we must work on increasing the bandwidth with Racketeers. > What does it mean in practice? What are the tasks that must dealt with?
Re: FOSDEM 2019
Thanks for filming. It was great to follow and see you titans in action. -- Matt On 2/3/19 1:34 PM, Mikael Djurfeldt wrote: It was a great experience and joy for me to meet some of you at FOSDEM 2019. Thank you all!
Re: FOSDEM 2019
Ludovic Courtès writes: Hello! > Mikael Djurfeldt skribis: > >> It was a great experience and joy for me to meet some of you at FOSDEM >> 2019. Thank you all! > > Seconded, that was awesome! Meeting Guilers, both newcomers and > old-timers :-), was just great! Thirded :-), that was so amazing, thank you all! janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: FOSDEM 2019
Hello Mikael! Mikael Djurfeldt skribis: > It was a great experience and joy for me to meet some of you at FOSDEM > 2019. Thank you all! Seconded, that was awesome! Meeting Guilers, both newcomers and old-timers :-), was just great! > Everyone who works with Guile knows that it's crap and look with envy at > projects like Chez and Racket, right? Actually, while there are many things I like about Racket (Typed Racket, DrRacket, and the wealth of available libraries come to mind), I’m also very happy with Guile and everything that’s been going on around it lately! Things like Gash/Geesh, nyacc, MesCC (we have a C compiler in Guile!), libfive, Haunt, Mumi (which runs at <https://issues.guix.info>), the picture language, the many bindings that came into existence over the last couple of years (parted, newt, GIR, Git, etc.), and of course Guix… I think we can all be very happy with how our community and software has been growing! There are many Scheme implementations out there, but few can pride themselves on having seen this much activity lately. I also consider it a strength that Guile is very much connected to the practical GNU/Linux environment and not insulated like so many programming language implementations. The amazing work Andy has been putting into Guile to keep improving it is another reason to be excited about Guile, this year maybe more than ever. I do wish more of us were joining Andy on that journey, but maybe 2019 is the year to make it happen! So… I’m just super excited about Guile, and I bet I’m not the only one. Chris Webber, Andy, Janneke, myself, and a couple of other people talked about this yesterday at FOSDEM, and we agree that we must work on increasing the bandwidth with Racketeers. As it turns out, Chris in the right position to do that: we almost tricked him into writing a Racket package importer for Guix and perhaps, who knows, toying with the idea of #lang guile in Racket. :-) Happy hacking, Guilers! Ludo’.
Re: FOSDEM 2019
Le dim. 3 févr. 2019 à 22:36, Mikael Djurfeldt a écrit : > It was a great experience and joy for me to meet some of you at FOSDEM > 2019. Thank you all! > > Now a piece of advice. > > Everyone who works with Guile knows that it's crap and look with envy at > projects like Chez and Racket, right? Jim Blandy thinks that GNU should use > Python as its scripting language. Chris Webber (probably rightly) thinks > "look how much you can accomplish with Racket so quickly". > > I've been there also. I have to confess that I have now and again regarded > Guile as crap since perhaps 1995 and there has been multiple occasions > where I have thought that basing the community effort on some other scheme > would make much more sense, and I have also always looked with envy on Chez > and mzscheme/Racket. > > Yet, it is *amazing* to me how much progress Guile has made since I left. > I, for example, *love* the new language and compiler infrastructure. > > But note now that Racket looks with envy on Chez and intends to base > Racket on Chez while Andy Wingo thinks that he can beat Chez performance. > > My advice is this: > > Idiots go around thinking that their own code is the best thing around. > Sensible people have a natural, and actually productive, tendency to be > critical about their own work. That is all good, unless it hurts the sense > of meaning and joy in your work. > > Remember now first that we are all irrational creatures. We maybe *think* > sometimes that we are rational, because what we think looks rational in our > view. The problem is that the view is usually very limited, with, for > example, a limited set of presumptions. > > For example: Guile is a piece of software, right? Wrong! It is a plant, > growing over time. Now, if we look over the fence into the other garden, > the plants there look much greener. But what will determine the ultimate > fate is not only the shape of it in the present moment, but also the genes > it carries, the quality of the soil, the amount of sunlight and the skills > of its gard[i]ners. We could have quit before we got GOOPS, or before we > got the native threading, or before the compiler tower, without which there > would be no chance to beat Chez. > > If you look at one combination of some Guile features: > > * easy embedding in applications > * support for multiple languages > * the compiler tower > * OO system with polymorphic dispatch and metaobject protocol > * nice, friendly and open community > > I think it is pretty strong and impressive, and I wouldn't like to live > without it. It's especially important to look at Guile as a good breeding > ground for new amazing work. > > That said, we should steal and collaborate all we can! > > All the best, > Mikael > Very well said. I am waiting an official announcement of the ROADMAP for GNU Guile 3 before giving my point of view.
Re: FOSDEM 2019
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
Re: FOSDEM 2019
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 pretty strong and impressive, and I wouldn't like to live > without it. It's especially important to look at Guile as a good breeding > ground for new amazing work. > > That said, we should steal and collaborate all we can! +1! Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
FOSDEM 2019
It was a great experience and joy for me to meet some of you at FOSDEM 2019. Thank you all! Now a piece of advice. Everyone who works with Guile knows that it's crap and look with envy at projects like Chez and Racket, right? Jim Blandy thinks that GNU should use Python as its scripting language. Chris Webber (probably rightly) thinks "look how much you can accomplish with Racket so quickly". I've been there also. I have to confess that I have now and again regarded Guile as crap since perhaps 1995 and there has been multiple occasions where I have thought that basing the community effort on some other scheme would make much more sense, and I have also always looked with envy on Chez and mzscheme/Racket. Yet, it is *amazing* to me how much progress Guile has made since I left. I, for example, *love* the new language and compiler infrastructure. But note now that Racket looks with envy on Chez and intends to base Racket on Chez while Andy Wingo thinks that he can beat Chez performance. My advice is this: Idiots go around thinking that their own code is the best thing around. Sensible people have a natural, and actually productive, tendency to be critical about their own work. That is all good, unless it hurts the sense of meaning and joy in your work. Remember now first that we are all irrational creatures. We maybe *think* sometimes that we are rational, because what we think looks rational in our view. The problem is that the view is usually very limited, with, for example, a limited set of presumptions. For example: Guile is a piece of software, right? Wrong! It is a plant, growing over time. Now, if we look over the fence into the other garden, the plants there look much greener. But what will determine the ultimate fate is not only the shape of it in the present moment, but also the genes it carries, the quality of the soil, the amount of sunlight and the skills of its gard[i]ners. We could have quit before we got GOOPS, or before we got the native threading, or before the compiler tower, without which there would be no chance to beat Chez. If you look at one combination of some Guile features: * easy embedding in applications * support for multiple languages * the compiler tower * OO system with polymorphic dispatch and metaobject protocol * nice, friendly and open community I think it is pretty strong and impressive, and I wouldn't like to live without it. It's especially important to look at Guile as a good breeding ground for new amazing work. That said, we should steal and collaborate all we can! All the best, Mikael
Re: FOSDEM 2019 (ACTION: please register or mail)
On Sun, 21 Oct 2018 18:42:48 -0400 Leo Famulari wrote: > On Fri, Aug 24, 2018 at 11:23:43AM +0200, Pjotr Prins wrote: > > If you intend to come and/or want to speak please add your name and > > proposed title to the new page at > > > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 > > > > Alternatively, reply here or mail me privately so we can keep a > > tally. > > I will be there! > > Please add my name to the list :) I don't have an account on > LibrePlanet. Hi Leo, nice to hear. as 2018 is already over, I suppose it was in your interest I added you to the 2019 list: https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#Attendees :-) Björn pgp55ElX9u2UR.pgp Description: OpenPGP digital signature
Re: FOSDEM 2019 (ACTION: please register or mail)
On Mon, Oct 22, 2018 at 05:34:49AM +0200, Björn Höfling wrote: > as 2018 is already over, I suppose it was in your interest I added you > to the 2019 list: > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2019#Attendees Haha, yes, I would like to be on the list for 2019. And for 2018, too, but that may be out of your control ;) signature.asc Description: PGP signature
Re: FOSDEM 2019 (ACTION: please register or mail)
On Fri, Aug 24, 2018 at 11:42:48AM +0200, Ricardo Wurmus wrote: > > Pjotr Prins writes: > > > Who wants to come to a separate 2 day GNU Guix event? > > > > That is the Thursday Jan 31st and/or Friday Feb 1st right before > > FOSDEM. I.e., 4 days of hacker nirvana. > > I plan to be there for the 2 days of Guix and the 2 FOSDEM days. > > Please also let us know (privately, if you prefer) if your attendance > would be dependent on having on-site childcare. > I'm trying to convince my wife she should come for FOSDEM, not sure how likely it's going to be. Without checking with the wife, I should be good for at least one day of GUIX hacking. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: FOSDEM 2019
Heya, Christopher Lemmer Webber skribis: > I added a talk topic: "A Guiler's Year of Racket". I think there's a > lot we could learn from our fellow friends in Racket-land, and I'd like > to share some of that! I’d be very interested in listening to it! Ludo’.
Re: FOSDEM 2019 - dev-room proposal
On 08/27/2018 10:27 AM, Pjotr Prins wrote: . Manolis and I want to submit a plan for 'Minimalistic Languages - for big ideas' dev-room. Good examples that fit the room are - mes and reproducible builds - Guile and Guix - Guile JIT - Lua JIT - Lua for scriptable projects (example?) Anyone anything to add to this list? More ideas is better. Cow?
FOSDEM 2019 - dev-room proposal
Copy from the Guix mailing list. - Forwarded message from Pjotr Prins - Date: Mon, 27 Aug 2018 11:23:19 +0200 From: Pjotr Prins To: guix-de...@gnu.org Subject: FOSDEM 2019 - dev-room proposal User-Agent: NeoMutt/20170113 (1.7.2) * Minimalistic Languages Every year FOSDEM allows for dev-rooms that need to appeal to a wider audience and do not overlap with other dev-rooms. Programming languages are popular and some of the large languages get their own, such as Python and Rust. See the devrooms section on https://archive.fosdem.org/2018/schedule/ Manolis and I want to submit a plan for 'Minimalistic Languages - for big ideas' dev-room. Good examples that fit the room are - mes and reproducible builds - Guile and Guix - Guile JIT - Lua JIT - Lua for scriptable projects (example?) Anyone anything to add to this list? More ideas is better. Other languages that could fit are Forth, Smalltalk, Tcl, Rebol. Provided they have a big idea. Note that JVM languages and languages that compile to Javascript do not fit the room. They probably have their own dev-rooms anyway. Haskell and other Lisps may fit too (if they don't get their own room). We think with enough good projects our dev-room will be of interest. Pj & Manolis - End forwarded message -
Scheme @ FOSDEM 2019
Hello all, I would like to get the ball rolling about a SCHEME event in Europe at FOSDEM in 2019 Please add your talk ideas in that page http://community.schemewiki.org/?FOSDEM2019 Best regards, Amirouche
Re: FOSDEM 2019
Manolis Ragkousis writes: > Hello everyone, > > It's that time of the year again we need to start organizing about > FOSDEM. We have a deadline for the 20th of September[1] to apply for a > devroom. We also need to start looking for a place for this year's > fringe event! > > I created a libreplanet page[2] to start writing possible talk ideas in > case we get a devroom. Thanks for everyone is doing organizing, especially Manolis for kicking this off! I added a talk topic: "A Guiler's Year of Racket". I think there's a lot we could learn from our fellow friends in Racket-land, and I'd like to share some of that!
Re: FOSDEM 2019 (ACTION: please register or mail)
Pjotr Prins writes: > Who wants to come to a separate 2 day GNU Guix event? > > That is the Thursday Jan 31st and/or Friday Feb 1st right before > FOSDEM. I.e., 4 days of hacker nirvana. I plan to be there for the 2 days of Guix and the 2 FOSDEM days. Please also let us know (privately, if you prefer) if your attendance would be dependent on having on-site childcare. -- Ricardo
Re: FOSDEM 2019 (ACTION: please register or mail)
On 8/24/18 11:23 AM, Pjotr Prins wrote: > Who wants to come to a separate 2 day GNU Guix event? > > That is the Thursday Jan 31st and/or Friday Feb 1st right before > FOSDEM. I.e., 4 days of hacker nirvana. > > FOSDEM is really great. Look at last year's schedule for Saturday > > https://archive.fosdem.org/2018/schedule/day/saturday/ > > Last year we had a 1 day event with about 25 people before FOSDEM. > See > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 > > If you intend to come and/or want to speak please add your name and > proposed title to the new page at > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 The new link is apparently: https://libreplanet.org/wiki/Group:Guix/FOSDEM2019
Re: FOSDEM 2019 (ACTION: please register or mail)
I'm in. On Fri, 24 Aug 2018, 11:23 Pjotr Prins, wrote: > Who wants to come to a separate 2 day GNU Guix event? > > That is the Thursday Jan 31st and/or Friday Feb 1st right before > FOSDEM. I.e., 4 days of hacker nirvana. > > FOSDEM is really great. Look at last year's schedule for Saturday > > https://archive.fosdem.org/2018/schedule/day/saturday/ > > Last year we had a 1 day event with about 25 people before FOSDEM. > See > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 > > If you intend to come and/or want to speak please add your name and > proposed title to the new page at > > https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 > > Alternatively, reply here or mail me privately so we can keep a tally. > > Please do so because we need to find a venue again on a first come > first go basis if we run out of seats. > > Pj. > > On Tue, Aug 21, 2018 at 04:33:53PM +0300, Manolis Ragkousis wrote: > > Hello everyone, > > > > It's that time of the year again we need to start organizing about > > FOSDEM. We have a deadline for the 20th of September[1] to apply for a > > devroom. We also need to start looking for a place for this year's > > fringe event! >
Re: FOSDEM 2019 (ACTION: please register or mail)
Who wants to come to a separate 2 day GNU Guix event? That is the Thursday Jan 31st and/or Friday Feb 1st right before FOSDEM. I.e., 4 days of hacker nirvana. FOSDEM is really great. Look at last year's schedule for Saturday https://archive.fosdem.org/2018/schedule/day/saturday/ Last year we had a 1 day event with about 25 people before FOSDEM. See https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 If you intend to come and/or want to speak please add your name and proposed title to the new page at https://libreplanet.org/wiki/Group:Guix/FOSDEM2018 Alternatively, reply here or mail me privately so we can keep a tally. Please do so because we need to find a venue again on a first come first go basis if we run out of seats. Pj. On Tue, Aug 21, 2018 at 04:33:53PM +0300, Manolis Ragkousis wrote: > Hello everyone, > > It's that time of the year again we need to start organizing about > FOSDEM. We have a deadline for the 20th of September[1] to apply for a > devroom. We also need to start looking for a place for this year's > fringe event!
Re: FOSDEM 2019
On Tue, Aug 21, 2018 at 04:33:53PM +0300, Manolis Ragkousis wrote: > Hello everyone, > > It's that time of the year again we need to start organizing about > FOSDEM. We have a deadline for the 20th of September[1] to apply for a > devroom. We also need to start looking for a place for this year's > fringe event! Hi. In your list, you mention "encouraging newbies" and "encouraging diversity". In that category, I could do a talk on my experiments in writing interactive fiction in Scheme. Interactive fiction tools like Twine have been a first step for many young programmers, and tools like Twine have been adopted by many young LGBT authors. If we could make the syntax simple and obvious enough, maybe an interactive fiction tool in Guile could be useful. But the technical challenge of making a simple tool has been surprisingly complicated in interesting ways. I went ahead and threw that up on the libreplanet wiki for now Regards, Mike Gran
Re: FOSDEM 2019
On Tue 21 Aug 2018 19:57, Ricardo Wurmus writes: > If we base our application on this proposal I think we should make these > changes: > > - mention the work on adding JIT Yes definitely! This will be Guile 3, so we can call it "Just-in-time code generation for Scheme: Speed for free in Guile 3" or something. I'd be happy to give this talk. Andy
Re: FOSDEM 2019
> I created a libreplanet page[2] to start writing possible talk ideas in > case we get a devroom. > > We also need to write a proposal for our devroom application. The last > year's proposal should be a good start. (attached) We should also talk > with the Lua people in case we can share a devroom with them. > > Start sending ideas people!! This FOSDEM is going to be awesome! Under the topic of encouraging newbies (and tangentially in the topic of increasing diversity), I could do a talk about my experiments in writing interactive fiction in Guile. I have had a goal of making something as simple to use as the Twine interactive fiction engine. I posted that on the wiki for now. -Mike Gran
Re: FOSDEM 2019
Hi Manolis, > We also need to write a proposal for our devroom application. The last > year's proposal should be a good start. (attached) Thanks for getting the ball rolling! If we base our application on this proposal I think we should make these changes: - mention the work on adding JIT - mention “Chickadee” instead of “Sly” (Chickadee is a general purpose game development toolkit that sees continued development, whereas Sly is specifically for game development with functional reactive programming) - change “AO” to “libfive Studio” (the project has been renamed) - add “R” to the list of languages for which Guix has great support - “Guile make replacement”? Is this an actual thing? - use HTTPS for http://bootstrappable.org Obviously, the list of topics would need to change (that depends on the proposals for talks) and references to “last year” would need to be updated. We should also figure out if there are enough people in the extended Guile universe who would be willing to give a talk. If we don’t have enough topics we might want to share the room with other communities that have some links to us (e.g. other Lispy languages, or “small” languages, etc). -- Ricardo
FOSDEM 2019
Hello everyone, It's that time of the year again we need to start organizing about FOSDEM. We have a deadline for the 20th of September[1] to apply for a devroom. We also need to start looking for a place for this year's fringe event! I created a libreplanet page[2] to start writing possible talk ideas in case we get a devroom. We also need to write a proposal for our devroom application. The last year's proposal should be a good start. (attached) We should also talk with the Lua people in case we can share a devroom with them. Start sending ideas people!! This FOSDEM is going to be awesome! Thank you, Manolis [1] https://fosdem.org/2019/news/2018-08-10-call-for-participation/ [2] https://libreplanet.org/wiki/Group:Guix/FOSDEM2019 * Devroom name: GNU Guile — the official extension language for the GNU Project * Devroom description: The [[https://www.gnu.org/software/guile/][GNU Guile]] programming language is dynamically typed and multi-paradigm. Guile allows for functional approaches, object-oriented programming using GOOPs (a CLOS-like object system), logic programming, and system scripting. Guile is suited for meta-programming and has a powerful macro-system which allows users to change the language on the fly. Guile features a growing set of bindings and libraries for libssh, git, json, sdl, opengl, cairo, gtk, redis, SQL, etc. GNU Guile is the preferred extension system for the GNU Project which features an implementation of the Scheme programming language, a dialect of Lisp with a mature community. GNU Guile is continually improved where recent milestones were a new compiler infrastructure, a virtual machine implementation, a switch to the Boehm-Demers-Weiser garbage collector and many improvements to the Guile Scheme language itself. Major performance improvements were demonstrated at FOSDEM with a new optimizing compiler which is now part of the recent 2.2 release. Other recent additions are a "sandbox" facility that can run code from untrusted users and improved support for immutable data. The use of GNU Guile is growing. Amongst the current applications written in Guile, there are AO, a new 3D CAD engine; Skribilo, Artanis and Haunt, (web) templating engines; Sly, a gaming engine; and (of course) GNU Guix, a functional software deployment manager for the GNU Project which also underpins GuixSD a new functional GNU/Linux Distribution. GNU Guix is a rapidly growing project that distinguishes itself by creating 100% reproducible software installations generated by a hackable system. GNU Guix is an important driver for GNU Guile development because the massive project puts large demands on GNU Guile. In the last year GNU Guix has grown 40% from approx. 200K to 280K lines of source code whereof an amazing 260K lines are written in GNU Guile! GNU Guix has great support for developers, including the GNU Emacs eco-system and GNU Guile (of course), but also for Java, Clojure, Perl, Ruby, Python, Haskell, GO, D, Erlang, and Elixir. Interesting spin-offs of Guix are a Guile make replacement, virtualization of development environments, the Shepherd and a new approach to system service integration; and the bootstrappable.org effort with Mes and Nyacc, a project for creating bootstrapped build systems from source only (also presented at FOSDEM last year) which tries to revert the current trend of bootstrapping build systems with binaries. Bootstrapping from source is crucial to free software distribution. Other noteworthy GNU Guile applications include GNU Lilypond, GnuCash, and GNU Mcron a cron-compatible task scheduler. More GNU Guile projects can be found at https://en.wikipedia.org/wiki/GNU_Guile and https://www.gnu.org/software/guile/libraries/. The devroom will provide at least the following content with a focus on software development: - An introduction to GNU Guile - Guile Next: Latest developments in GNU Guile - Concurrent programming with Fibers and 8sync - Compiler implementation in Guile - Web frameworks with GNU Guile - Shepherd the systemd replacement - GNU Guix + Latest GNU Guix developments + Tooling for development environments + Whole-system deployment, and distributed deployment - Guile and network programming + Dealing with concurrency in networking applications + Application performance - The Guile community + Freedom can be expressed in multiple ways + Encouraging and mentoring newbies; encourage diversity + Tutorials and documentation A complete list of currently considered talks can be found at https://libreplanet.org/wiki/Group:Guix/TalkProposals. The purpose of the dev room is to present latest developments in Guile itself, to share exciting news about, and demo applications using Guile, to provide a space to meet with fellow hackers and enthusiasts, and to grow the Guile community. * Related URLs - GNU Project: http://www.gnu.org - GNU Guile: https://www.gnu.org/software/guile/ - GNU Guile libs:
