FOSDEM 2019

FOSDEM 2019

[Manolis Ragkousis]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

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


[-- Attachment #2: fosdem-proposal.txt --]
[-- Type: text/plain, Size: 5943 bytes --]

* 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: https://www.gnu.org/software/guile/libraries/
  - GNU Guix: http://www.gnu.org/software/guix
  - MES and bootstrappable: https://gitlab.com/janneke/mes and
http://bootstrappable.org

* Why should FOSDEM accept this proposal?

GNU Guile is a core component of the successful and long running GNU
project, and today the fresh Lisp language is being discovered by a
new generation of programmers.  In 2016 we had our first half day
Guile devroom at FOSDEM and it was a great success: the devroom was
full for every talk!  In 2017 we were lucky to get a full day which
was also full all day. FOSDEM gives a great impulse by getting
developers together and projects like MES started there.  Both years,
together with the LUA devroom we overlapped a session where we
discussed the future of small languages (we are interested in sharing
the devroom with LUA again if we can not have a full day).

This would be the second opportunity for GNU Guile related projects
world-wide to meet at FOSDEM.  Similar to last year, we will invite
speakers from other projects that are loosely coupled to the Guile
environment (e.g. projects that use Guile purely as an extension
language, such as gdb and Lilypond).

In short, having this devroom will allow us to dig deeper into the
details of language design and reproducible software in particular,
whilst giving back to the free software community as a whole.

* Devroom organisers

  - Ludovic Courtès (ludo@gnu.org) - GNU Guile project leader
  - Ricardo Wurmus (ricardo.wurmus@mdc-berlin.de)
  - Pjotr Prins (pjotr.public445@thebird.nl)
  - Alex Sassmannshausen (alex.sassmannshausen@gmail.com)
  - Tobias Geerinckx-Rice <me@tobias.gr>
  - Manolis Ragkousis <manolis837@gmail.com>

Re: FOSDEM 2019

[Ricardo Wurmus]

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

Re: FOSDEM 2019

[Mike Gran]

> 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

[Andy Wingo]

On Tue 21 Aug 2018 19:57, Ricardo Wurmus <rekado@elephly.net> 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

[Mike Gran]

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

[Christopher Lemmer Webber]

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

[Ludovic Courtès]

Heya,

Christopher Lemmer Webber <cwebber@dustycloud.org> 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’.

FOSDEM 2019

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3169 bytes --]

Re: FOSDEM 2019

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]


Mikael Djurfeldt <mikael@djurfeldt.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

Re: FOSDEM 2019

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 5510 bytes --]

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 <arne_bab@web.de> 于 2019年2月4日周一 07:14写道：

>
> Mikael Djurfeldt <mikael@djurfeldt.com> 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
>

[-- Attachment #2: Type: text/html, Size: 6588 bytes --]

Re: FOSDEM 2019

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]

Le dim. 3 févr. 2019 à 22:36, Mikael Djurfeldt <mikael@djurfeldt.com> 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.

[-- Attachment #2: Type: text/html, Size: 3743 bytes --]

Re: FOSDEM 2019

[Ludovic Courtès]

Hello Mikael!

Mikael Djurfeldt <mikael@djurfeldt.com> 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

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> Mikael Djurfeldt <mikael@djurfeldt.com> 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 <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: FOSDEM 2019

[Matt Wette]

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

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

Le lun. 4 févr. 2019 à 15:52, Ludovic Courtès <ludo@gnu.org> a écrit :

> Hello Mikael!
>
> Mikael Djurfeldt <mikael@djurfeldt.com> 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?

[-- Attachment #2: Type: text/html, Size: 1441 bytes --]

Re: FOSDEM 2019

[Ludovic Courtès]

Hi,

Amirouche Boubekki <amirouche.boubekki@gmail.com> 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

[Christopher Lemmer Webber]

Arne Babenhauserheide writes:

> Mikael Djurfeldt <mikael@djurfeldt.com> 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

[Christopher Lemmer Webber]

Arne Babenhauserheide writes:

> Mikael Djurfeldt <mikael@djurfeldt.com> 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

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

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

Ludovic Courtès <ludo@gnu.org> 于 2019年2月6日周三 00:59写道：

> Hi,
>
> Amirouche Boubekki <amirouche.boubekki@gmail.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 1538 bytes --]

Re: FOSDEM 2019

[Matt Wette]

On 2/5/19 8:58 AM, Ludovic Courtès wrote:
> Hi,
>
> Amirouche Boubekki <amirouche.boubekki@gmail.com> 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]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

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

Matt Wette <matt.wette@gmail.com> 于 2019年2月6日周三 08:38写道：

>
>
> On 2/5/19 8:58 AM, Ludovic Courtès wrote:
> > Hi,
> >
> > Amirouche Boubekki <amirouche.boubekki@gmail.com> 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
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2142 bytes --]

Re: FOSDEM 2019

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

Hi

Le mar. 5 févr. 2019 à 18:17, Ludovic Courtès <ludo@gnu.org> a écrit :

> Hi,
>
> Amirouche Boubekki <amirouche.boubekki@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 1659 bytes --]

Re: FOSDEM 2019

[Ludovic Courtès]

Nala Ginrut <nalaginrut@gmail.com> 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

[Alex Sassmannshausen]

Christopher Lemmer Webber writes:

> Arne Babenhauserheide writes:
>
>> Mikael Djurfeldt <mikael@djurfeldt.com> 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

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <
alex.sassmannshausen@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/?

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

Re: FOSDEM 2019

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

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

>
>
> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <
> alex.sassmannshausen@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

[-- Attachment #2: Type: text/html, Size: 1752 bytes --]

Re: FOSDEM 2019

[Alex Sassmannshausen]

Hi Amirouche

Amirouche Boubekki writes:

> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <alex.sassmannshausen@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 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

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

Hello all,

Le mer. 6 févr. 2019 à 18:47, Ludovic Courtès <ludo@gnu.org> a écrit :

> Nala Ginrut <nalaginrut@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 4017 bytes --]

Re: FOSDEM 2019

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]


Amirouche Boubekki <amirouche.boubekki@gmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

Re: FOSDEM 2019

[Ricardo Wurmus]

Alex Sassmannshausen <alex.sassmannshausen@gmail.com> writes:

> Hi Amirouche
>
> Amirouche Boubekki writes:
>
>> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <alex.sassmannshausen@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 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

[Alex Sassmannshausen]

Ricardo Wurmus writes:

> Alex Sassmannshausen <alex.sassmannshausen@gmail.com> writes:
>
>> Hi Amirouche
>>
>> Amirouche Boubekki writes:
>>
>>> Le mer. 6 févr. 2019 à 14:47, Alex Sassmannshausen <alex.sassmannshausen@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 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

[swedebugia]

[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]