Re: Newbie thoughts on Guile Hall + Guix

Re: Newbie thoughts on Guile Hall + Guix

[dsmich]

From: "Mikael Djurfeldt" 
To: "Aleix Conchillo Flaqué"
Cc: "guile-user"
Sent: Sunday February 6 2022 8:15:06AM
Subject: Re: Newbie thoughts on Guile Hall + Guix

> I also think that there is a need for something light-weight and
cross
 > platform. I think, e.g., that PyPI is one of the main reasons for
the
 > success of Python and that the lack of something in that direction
is
 > holding Guile back.

...

> So, the
 > question is if it would be possible to use aspects of Guix and
 > Hall---to
 > refactor things, perhaps akin to the peeling off that Christine is
 > talking
 > about? Maybe with some extra support for the non-Guix case such
that
 > the
 > package would work both within snd outside of Guix? Am I crazy?

Not crazy. I think this is a wonderful idea.

-Dale

Re: Newbie thoughts on Guile Hall + Guix

[Blake Shaw]

Aleix Conchillo Flaqué <aconchillo@gmail.com> writes:

> My 2 cents:
>
> - Doing something in Guile is tough. I've been trying since 2011.
>
> Why is it tough?
>
> - The manual is written by very smart people for very smart people. Not for
>   newcomers.

I've seen this sentiment expressed a few times when this topic has popped
up, and I think it can come across as assuming that the people who struggle
with it are either not very smart, new to programming, or both. For
instance, I know that someone who described a difficult experience
which shared many of the same attributes as my experience, and they are
the author of a popular programming book that is certainly not for
newcomers. Before the pandemic threatened to separate me from my
partner if I returned to school, I was doing my PhD in philosophy of
mathematics focusing on categorical logic, and I've been programming
since I was 15, almost 20 years now (but I will admit I'm no super
hacker, my work has been specifically limited to audio dsp, opengl,
opencv and stage video & lighting). And I worry that beyond possibly
scaring off folks who could possibly become very active members of the
community, this form of sentiment functions to allow us to forgo the  
difficult work of understanding what the problems are and how they can
be addressed.

> I'm excited to see what Blake comes up with, but the content will
> probably still be not-trivial. At the end of the day it's a reference manual, not
> a book to teach you how to write a new project from scratch.

I'm glad to hear it! It good to see so many people get excited about
documentation! Which certainly indicates a shared desire to see the
documentation improved. And I agree its a manual, and if anything there
is a good amount of inconsistency when the manual is itself unsure whether its
a tutorial or a manual. I think I have a very simple guideline that I'll
present that allows us to maintain most of the existing material while
allowing us to revise sections in a consistent way to make them less
tutorial-like, quicker to consult, and easier to understand, at once!
It's not magic, but I think will offer a notable improvement both "for the
working hacker", but also for the little schemers like myself. I'll be
excited to hear what you think of it. 
>
> - There are no simple and modern resources that teach what is the "Guile/Scheme"
> way. How do you even organize a project when you start? Or something like 
> https://go.dev/tour/ to teach the basics. Yes, you can read books but most people
> when they start to learn a new language they just want to try to do something
> quick. And the books that teach Scheme are not trivial/practical.

I agree, and I'm really excited to see how Jeremy Korwin's book develops
because from just a glance at it, it seems to be on the right track to
fill those shoes.

>
> - Lack of libraries. We do have libraries but the ecosystem is not big and for
> those libraries we have it's hard to get started, most don't have simple examples
> or don't have examples at all.
>
> - Assuming you find the library you need... how do you start using it? How do you
> install it? Now there's Guix, but not everyone has Guix or wants to install Guix.
> I'm on macOS currently so I can't even install Guix unfortunately.
>
> - Lack of support in editors other than Emacs (yes, geiser is great!). There's a
> project that might help there: https://gitlab.com/rgherdt/scheme-lsp-server. But
> LSP is not enough, you need a paredit equivalent, etc.
>
> - Creating a new library is (or was) not easy. guile-hall and guix help here. But
> how do newcomers even find "guile-hall"? Should guile-hall be part of Guile and
> included in the manual?
>
> - Distributing the new library you have created is (or was) not easy either.
> Also, guile-hall and guix issues here.
>
> So basically today we are kind of forcing people to learn Emacs and Guix (if you
> can even use Guix) to have a minimum decent environment.
>
> For me starting with Guile was not hard because of autotools, I already had to
> deal with that for many years. For me the hardest part was the lack of resources
> (libraries, tutorials, examples, simple books).
>
> As for myself, I've been trying to create libraries to replicate what I use at
> work (and I'm far from that) or others that I find fun. And I will try to keep
> doing that to improve Guile's ecosystem and help with anything else I can.
>
> Best,
>
> Aleix
>

I address many of your concerns in my presentation, but not all of
them, and I agree with most them. Will be interested to hear what you think!

ez,
blake

-- 
“In girum imus nocte et consumimur igni”

Re: Newbie thoughts on Guile Hall + Guix

[Blake Shaw]

Catonano <catonano@gmail.com> writes:

Hi Adriano, 


> I personally believe this is a good chunk of why Guile wasn't as successful as Python
>
> With Guile the overall experience is extremely frustrating
>
> I've been hanging around here for years, on and off, and overall I haven't done anything, in Guile

I think this type of response should be taken seriously by all of
us, and we should seek to know why this happens for some users, as I've
seen plenty of people express the same sentiment. Guile seems to be a
community that takes pride in its openness, so in order to grow it seems
we should seek to know:

    + Where do some users get stuck?
    + What kind of applications are they trying to write?

We might find that there is a lot of overlap where there is a set of
solutions for doing things, but its difficult to find out where to find
the know-how. If we are able to recognize this, we are closer to address
the issues, and it seems like something many guile users have in common
is that they want to make the community and learning experience better.

> I managed to do some widgets in clojurescript, some modest datapipes in Clojure, a game of life with some 2d graphics library in Clojure
>
> I made some things in Python
>
> In Guile ?
>
> Nothing, nisba, nada

I feel you! And there seems to be many others who have had similar experiences.

Perhaps a survey is due. Are those who are highly productive in guile
relying heavily on the FFI? What is their workflow and how does it
differ from those who are hitting walls?

>
> I can relate to the experience of feeling frustrated about how casually some things are referred to on Guile channels
>
> Last time it was about the new exceptions
>
> But I remember I asked for an example of some usage of the APIs for web serving in Guile, some years ago
>
> I was kindly offered an example by Andy Wingo nonetheless
>
> But then I could follow up, I got lost, I don't remember why exactly, but I was ashamed to keep gong n any way
>
> Something similar happened when I asked about lazyness
>
> I don't think I've ever seen a community that suffers the curse of knowledge more than the Guile community
>
> This is why I was enticed to attempt the only video in my life about how to read a file (a basic use case) with Guile
>
> And I'm mumbling to do a new series about project management and package building
>
> And about delimited continuations
>
> And, and, and....
Totally. I think many of us can relate. 
>
> That is, my hope now is that Guile can be made into something empowering, so that it will be useful to someone else in the future
>

And so that we can work on cool projects together, and grow as a
community :)

> rather than disempowering as it has always been (for me at least)
>
> I've been terribly frustrated about this in the past and I'm so refreshed to see you landing here, in Guile land

Thanks! I'm glad to be here and meet you. I'm about to attempt my first
professional project that will use Guile, and I'm a bit
nervous. Nevertheless, I'm the type of nerd that has always used obscure
academic programming systems for commercial art projects, and theres
certainly something sisyphean about it, as it means that I end up
writing a lot of C, which brings me little pleasure. But as a former
Puredata programmer, I realize that when you get in the swing of things
it usually pays off majorly, especially the aspect of being a part of a
community that is small and close-nit.

>
> One final note: while I have been emotional about this in the past, I believe I'm not being emotional now

I'd hope the Guile community can similarly refrain from taking criticism
personally, and recognize that everyone is here to contribute to
something we see as powerful, beautiful, and reflects humanity's better
attributes. Nobody is here to bring the community down... we're here to
build, and see our contributions grow like a nice garden of blooming
hacks and programs :)
>
> My remarks are not meant to disparage the Guile/Guix community, I acknowledge the generosity of this community, overall
>
> I just think that it's right and useful to raise perceived problems
Without a doubt. I think we're all here for community, free software,
and comradely discourse, not just scheme.
>
> And I think this initiative to reconsider the structure of the manual is one of the best things that happened in a very long time
I'm super glad folks have taken to it well! It's the type of subject
that can get bogged down in bikeshedding when too many long-time users
are set in their ways. So the fact that folks seem to be excited about
it, seems to indicate that won't be the case this time around.
>
> After so many years I still can't tell where to look in it when I need something
>
Let's fix that! :)

Looking forward to your feedback on my presentation.

ez,
b
-- 
“In girum imus nocte et consumimur igni”

Re: Newbie thoughts on Guile Hall + Guix

[Olivier Dion via General Guile related discussions]

On Wed, 09 Feb 2022, Blake Shaw <blake@nonconstructivism.com> wrote:

> Perhaps a survey is due.

I believe that a roadmap for the future of Guile is due.  There were
discussions last months on the mailing list for recruting a new
maintainer and perhaps making a group of hackers to develop Guile.  I
don't know if things will get concretize some days -- I believe that
many of us are busy with our works/studies -- but when it does, I will
be there to give time back to this project and community.

A survey would certainly help to find what's lacking in the development
environment for the users, and that could be the first step of this
roadmap.

-- 
Olivier Dion
Polymtl

Re: Newbie thoughts on Guile Hall + Guix

[Aleix Conchillo Flaqué]

My 2 cents:

- Doing something in Guile is tough. I've been trying since 2011.

Why is it tough?

- The manual is written by very smart people for very smart people. Not for
newcomers. I'm excited to see what Blake comes up with, but the content
will probably still be not-trivial. At the end of the day it's a reference
manual, not a book to teach you how to write a new project from scratch.

- There are no simple and modern resources that teach what is the
"Guile/Scheme" way. How do you even organize a project when you start? Or
something like https://go.dev/tour/ to teach the basics. Yes, you can read
books but most people when they start to learn a new language they just
want to try to do something quick. And the books that teach Scheme are not
trivial/practical.

- Lack of libraries. We do have libraries but the ecosystem is not big and
for those libraries we have it's hard to get started, most don't have
simple examples or don't have examples at all.

- Assuming you find the library you need... how do you start using it? How
do you install it? Now there's Guix, but not everyone has Guix or wants to
install Guix. I'm on macOS currently so I can't even install Guix
unfortunately.

- Lack of support in editors other than Emacs (yes, geiser is great!).
There's a project that might help there:
https://gitlab.com/rgherdt/scheme-lsp-server. But LSP is not enough, you
need a paredit equivalent, etc.

- Creating a new library is (or was) not easy. guile-hall and guix help
here. But how do newcomers even find "guile-hall"? Should guile-hall be
part of Guile and included in the manual?

- Distributing the new library you have created is (or was) not easy
either. Also, guile-hall and guix issues here.

So basically today we are kind of forcing people to learn Emacs and Guix
(if you can even use Guix) to have a minimum decent environment.

For me starting with Guile was not hard because of autotools, I already had
to deal with that for many years. For me the hardest part was the lack of
resources (libraries, tutorials, examples, simple books).

As for myself, I've been trying to create libraries to replicate what I use
at work (and I'm far from that) or others that I find fun. And I will try
to keep doing that to improve Guile's ecosystem and help with anything else
I can.

Best,

Aleix

Re: Newbie thoughts on Guile Hall + Guix

[Maxime Devos]

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

Aleix Conchillo Flaqué schreef op wo 09-02-2022 om 12:05 [-0800]:
> - Assuming you find the library you need... how do you start using it? How
> do you install it? Now there's Guix, but not everyone has Guix or wants to
> install Guix. I'm on macOS currently so I can't even install Guix
> unfortunately.

About finding and installing libraries:

Nix and ‘homebrew’ support Mac (MacOS? macOS? OS-X? no idea what the
‘proper’ spelling is).  I don't know if Nix and homebrew have much
Guile stuff though ...

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Newbie thoughts on Guile Hall + Guix

[Aleix Conchillo Flaqué]

On Wed, Feb 9, 2022 at 12:28 PM Maxime Devos <maximedevos@telenet.be> wrote:

> Aleix Conchillo Flaqué schreef op wo 09-02-2022 om 12:05 [-0800]:
> > - Assuming you find the library you need... how do you start using it?
> How
> > do you install it? Now there's Guix, but not everyone has Guix or wants
> to
> > install Guix. I'm on macOS currently so I can't even install Guix
> > unfortunately.
>
> About finding and installing libraries:
>
> Nix and ‘homebrew’ support Mac (MacOS? macOS? OS-X? no idea what the
> ‘proper’ spelling is).  I don't know if Nix and homebrew have much
> Guile stuff though ...
>
>
Homebrew has actually :-). I created Guile Homebrew a couple of years ago
and it now has 51 Guile related formulas between libraries and application.

https://github.com/aconchillo/homebrew-guile

Maybe I didn't phrase it properly. What I would love is something like:

guile add guile-json==4.5.2

This would download guile-json and would create a dependencies file for my
project. The dependencies could be global or per project. And I would love
this to work across different platforms.

Aleix

Re: Newbie thoughts on Guile Hall + Guix

[Vivien]

Hello,

Le mercredi 09 février 2022 à 12:05 -0800, Aleix Conchillo Flaqué a
écrit :
> - The manual is written by very smart people for very smart people.
> Not for
> newcomers.
To be more precise, I had that feeling everywhere I stumbled on the
word "continuation" : it took me days or weeks to understand dynamic
wind, handling exceptions, and prompts. The continuation concept
doesn’t exist in popular programming languages, so it’s hard to make
one of these quick hands-on guide "You did this in python, do that in
guile". I’m not sure there’s an easy solution though.

Vivien

Re: Newbie thoughts on Guile Hall + Guix

[Blake Shaw]

Chris Vine <vine35792468@gmail.com> writes:

> Everything is capable of improvement but the guile manual is a manual
> and not I think primarily intended as a language tutorial (although
> Chapter 3 of the manual does have a very cursory introduction to the
> scheme language).  If you are looking for a tutorial, I suggest reading
> https://www.scheme.com/tspl4/ .  It covers the R6RS flavour, but at the
> tutorial level I don't think the various current standard flavours
> (R5RS, R6RS and R7RS) matter too much.
>
> I would be reluctant to see the manual turned into a tutorial if that
> were to mean abridging any of its current completeness.
>

For sure, but I didn't say anything about the manual here or anything
about a tutorial. 

-- 
“In girum imus nocte et consumimur igni”

Re: Newbie thoughts on Guile Hall + Guix

[Blake Shaw]

adriano <randomlooser@riseup.net> writes:

> Just don't
> That stuff is too low level for human beings
> [...]
> Anyway, I feel your frustration, I've been there myself
>
> Actually I've been there with Guile more than with Guix
>
> But still I feel you
>
> I hope this message of mine can sooth your frustration, to some extent
>

Wasn't intended for me, but I found it soothing!

Somewhat off topic, but I feel like briefly relating these types of
sentiment could even be useful to interject in within the Guix docs at
times.

There are many points of docs where the sales pitch bleeds into points
far past the point of sale, so to speak. There are lots of "Guix makes
this easy by x y z" deep in the docs, but the longer I've been in the
community the more I've seen long time contributors relate that there
are lots of points of frustration around certain things that may be
called easy in the docs. If you're frustrated, and someone is there
telling you what you're confused about this is simple and easy, that
can come across as rubbing salt in wounds. While I share the enthusiasm,
and I realize how much Guix eases things compared to traditional
methods, it has been de-motivating for me at times.

On the other hand, I think briefly relating, for example, "Depending on
the complexity of a package, packagers at times will be exposed to
low-level details that aren't traditionally meant for humans. This can
be a genuinely frustrating experience..." becomes encouraging.  

Hope that makes sense, just food for thought! We could all use a pat on
the back at times, especially given the human-ness of a project like
guix that is waivers between the social and solitary :)  

-- 
“In girum imus nocte et consumimur igni”

Re: Newbie thoughts on Guile Hall + Guix

[Blake Shaw]

Vijay Marupudi <vijaymarupudi@gatech.edu> writes:
> I don't think it's fair to say that using packages in Guile just as
> easy/hard as other languages. Python / Javascript make this incredibly
> easy, and their ecosystem is evidence for that success. Their package
> managers have flaws, but they have benefits too, and those benefits
> would be great for Guile.

I would just like to tag onto this convo that I agree that its not fair
to say that Guile is easy and will quickly bless those who endeavor to
learn it with superpowers. My experience w/Racket was very smooth and I 
got working in it very quickly. I was a contracted to work on a project in
Python a few months ago and without ever studying it I was able to 
start doing production work in it (ridiculous how intuitive it is,
really). Before I started learning Guile I read Edwin Brady's book on
Idris and found Idris much easier to get from start to end of small
projects I was working on (because there is a well written book on it).

While Guile has become my favorite programming language, it took me
several months to learn how to navigate & figure out how to navigate the
SRFIs, how to plan a program so that I can know what to expect along the
way (what features I'll need to implement myself, etc) before I was able
to get productive in it beyond the realm of Guix. And I think most would
agree that Scheme is a less advanced language than Idris (I did some
category theory in school so I have some intuition for the ideas, but
still). And to be honest, I still hit plenty of road blocks.

There were definitely some times where I was digging around trying to
figure out how to do things and came across messages in the archives
saying "its so easy you just do [vague hand wavy explanation]". And I
found that quite frustrating, like there is an insularity meant to weed
out the bad apples. And when this topic popped up on the guix list a few
weeks ago some others expressed similar concerns, folks who are doing
very impressive work. A programming language should never make
programmers feel dumb -- it should make us feel empowered!

[end rant, thanks for humoring me]

-- 
“In girum imus nocte et consumimur igni”

Re: Newbie thoughts on Guile Hall + Guix

[Chris Vine]

On Tue, 08 Feb 2022 19:19:06 +0700
Blake Shaw <blake@nonconstructivism.com> wrote:

> Vijay Marupudi <vijaymarupudi@gatech.edu> writes:
> > I don't think it's fair to say that using packages in Guile just as
> > easy/hard as other languages. Python / Javascript make this incredibly
> > easy, and their ecosystem is evidence for that success. Their package
> > managers have flaws, but they have benefits too, and those benefits
> > would be great for Guile.
> 
> I would just like to tag onto this convo that I agree that its not fair
> to say that Guile is easy and will quickly bless those who endeavor to
> learn it with superpowers. My experience w/Racket was very smooth and I 
> got working in it very quickly. I was a contracted to work on a project in
> Python a few months ago and without ever studying it I was able to 
> start doing production work in it (ridiculous how intuitive it is,
> really). Before I started learning Guile I read Edwin Brady's book on
> Idris and found Idris much easier to get from start to end of small
> projects I was working on (because there is a well written book on it).
> 
> While Guile has become my favorite programming language, it took me
> several months to learn how to navigate & figure out how to navigate the
> SRFIs, how to plan a program so that I can know what to expect along the
> way (what features I'll need to implement myself, etc) before I was able
> to get productive in it beyond the realm of Guix. And I think most would
> agree that Scheme is a less advanced language than Idris (I did some
> category theory in school so I have some intuition for the ideas, but
> still). And to be honest, I still hit plenty of road blocks.
> 
> There were definitely some times where I was digging around trying to
> figure out how to do things and came across messages in the archives
> saying "its so easy you just do [vague hand wavy explanation]". And I
> found that quite frustrating, like there is an insularity meant to weed
> out the bad apples. And when this topic popped up on the guix list a few
> weeks ago some others expressed similar concerns, folks who are doing
> very impressive work. A programming language should never make
> programmers feel dumb -- it should make us feel empowered!

Everything is capable of improvement but the guile manual is a manual
and not I think primarily intended as a language tutorial (although
Chapter 3 of the manual does have a very cursory introduction to the
scheme language).  If you are looking for a tutorial, I suggest reading
https://www.scheme.com/tspl4/ .  It covers the R6RS flavour, but at the
tutorial level I don't think the various current standard flavours
(R5RS, R6RS and R7RS) matter too much.

I would be reluctant to see the manual turned into a tutorial if that
were to mean abridging any of its current completeness.

Re: Newbie thoughts on Guile Hall + Guix

[Catonano]

Hi Blake,

I'm Adriano <randomlooser@riseup.net>, it' just happens that I'm reading
this message of yours from another account

Il giorno mar 8 feb 2022 alle ore 14:39 Blake Shaw <
blake@nonconstructivism.com> ha scritto:

> Vijay Marupudi <vijaymarupudi@gatech.edu> writes:
> > I don't think it's fair to say that using packages in Guile just as
> > easy/hard as other languages. Python / Javascript make this incredibly
> > easy, and their ecosystem is evidence for that success. Their package
> > managers have flaws, but they have benefits too, and those benefits
> > would be great for Guile.
>
> I would just like to tag onto this convo that I agree that its not fair
> to say that Guile is easy and will quickly bless those who endeavor to
> learn it with superpowers. My experience w/Racket was very smooth and I
> got working in it very quickly. I was a contracted to work on a project in
> Python a few months ago and without ever studying it I was able to
> start doing production work in it (ridiculous how intuitive it is,
> really). Before I started learning Guile I read Edwin Brady's book on
> Idris and found Idris much easier to get from start to end of small
> projects I was working on (because there is a well written book on it).
>
> While Guile has become my favorite programming language, it took me
> several months to learn how to navigate & figure out how to navigate the
> SRFIs, how to plan a program so that I can know what to expect along the
> way (what features I'll need to implement myself, etc) before I was able
> to get productive in it beyond the realm of Guix. And I think most would
> agree that Scheme is a less advanced language than Idris (I did some
> category theory in school so I have some intuition for the ideas, but
> still). And to be honest, I still hit plenty of road blocks.
>
> There were definitely some times where I was digging around trying to
> figure out how to do things and came across messages in the archives
> saying "its so easy you just do [vague hand wavy explanation]". And I
> found that quite frustrating, like there is an insularity meant to weed
> out the bad apples. And when this topic popped up on the guix list a few
> weeks ago some others expressed similar concerns, folks who are doing
> very impressive work. A programming language should never make
> programmers feel dumb -- it should make us feel empowered!
>

I personally believe this is a good chunk of why Guile wasn't as successful
as Python

With Guile the overall experience is extremely frustrating

I've been hanging around here for years, on and off, and overall I haven't
done anything, in Guile

I managed to do some widgets in clojurescript, some modest datapipes in
Clojure, a game of life with some 2d graphics library in Clojure

I made some things in Python

In Guile ?

Nothing, nisba, nada

I can relate to the experience of feeling frustrated about how casually
some things are referred to on Guile channels

Last time it was about the new exceptions

But I remember I asked for an example of some usage of the APIs for web
serving in Guile, some years ago

I was kindly offered an example by Andy Wingo nonetheless

But then I could follow up, I got lost, I don't remember why exactly, but I
was ashamed to keep gong n any way

Something similar happened when I asked about lazyness

I don't think I've ever seen a community that suffers the curse of
knowledge more than the Guile community

This is why I was enticed to attempt the only video in my life about how to
read a file (a basic use case) with Guile

And I'm mumbling to do a new series about project management and package
building

And about delimited continuations

And, and, and....

That is, my hope now is that Guile can be made into something empowering,
so that it will be useful to someone else in the future

rather than disempowering as it has always been (for me at least)

I've been terribly frustrated about this in the past and I'm so refreshed
to see you landing here, in Guile land

One final note: while I have been emotional about this in the past, I
believe I'm not being emotional now

My remarks are not meant to disparage the Guile/Guix community, I
acknowledge the generosity of this community, overall

I just think that it's right and useful to raise perceived problems

And I think this initiative to reconsider the structure of the manual is
one of the best things that happened in a very long time

After so many years I still can't tell where to look in it when I need
something

Newbie thoughts on Guile Hall + Guix

[Christine Lemmer-Webber]

Hello!

It's been a while since Guile was my main hacking environment; I've been
returning to it, and one of the nicest things to change about its
ecosystem is the presence of Guile Hall.

I really, really like Guile Hall.  A lot!  I think it has room to grow
but it fills a clearly missing piece of the Guile ecosystem while doing
it in the best way possible: making itself explicitly compatible with
Guix.

I thought I'd write down some impressions while everything is fresh.

 - Its ability to make an autotools-compatible tarball, but without me
   needing to think about autotools at all, is a real delight.

 - Its test suite stuff is also really nice.

 - I found myself surprised that hall.scm is "just data", instead of
   taking the more guix'y approach of being code that actually builds a
   datastucture.  I'm not sure what the goal of this is; there can be
   reasons to take that approach but I'm not sure what it is here?
   My assumption is that the main reason is so that "hall scan" can
   correctly read and then modify and spit out another file, but I'm
   not sure.

 - What I would actually *really* like would be for the Hall package
   definition structure to be a wrapper *around* the Guix package
   structure.  Then the guix.scm would be really simple: it could just
   "peel off" the outer struct.  If I wanted to do some smart
   modifications of things from there maybe I could.  I dunno, something
   like this.

 - "hall scan" is really cool, but I kind of wish I didn't need to use
   it.  I'd rather not keep track of any of this stuff at all.
   I'd be happy just pointing some code at a directory and say "snarf
   up all the .scm files you see therein!"

 - I'm currently writing a manual starting in a .org file that's then
   converted into a .texi file.  I'd prefer if I could find an
   entrypoint to insert this into the compilation workflow: a pre-step
   to the docs compilation that generates the .texi file *from* my
   .org file.
 
 - On that note, it strikes me that Hall's integration with autotools
   is great because it means that existing distros don't need to be
   aware of Guile *or* Guix.  But it also means that Hall probably has
   all of the information that it could do all the steps that autoconf
   and automake do too.  That might be interesting to see that.
   
Anyway, just some thoughts.  Making Guile packages is already much less
intimidating now thanks to Hall's work.  Thank you for it!

 - Christine

Re: Newbie thoughts on Guile Hall + Guix

[Mikael Djurfeldt]

It would also be nice if we could have a Guile package repository.

Den lör 5 feb. 2022 21:11Christine Lemmer-Webber <cwebber@dustycloud.org>
skrev:

> Hello!
>
> It's been a while since Guile was my main hacking environment; I've been
> returning to it, and one of the nicest things to change about its
> ecosystem is the presence of Guile Hall.
>
> I really, really like Guile Hall.  A lot!  I think it has room to grow
> but it fills a clearly missing piece of the Guile ecosystem while doing
> it in the best way possible: making itself explicitly compatible with
> Guix.
>
> I thought I'd write down some impressions while everything is fresh.
>
>  - Its ability to make an autotools-compatible tarball, but without me
>    needing to think about autotools at all, is a real delight.
>
>  - Its test suite stuff is also really nice.
>
>  - I found myself surprised that hall.scm is "just data", instead of
>    taking the more guix'y approach of being code that actually builds a
>    datastucture.  I'm not sure what the goal of this is; there can be
>    reasons to take that approach but I'm not sure what it is here?
>    My assumption is that the main reason is so that "hall scan" can
>    correctly read and then modify and spit out another file, but I'm
>    not sure.
>
>  - What I would actually *really* like would be for the Hall package
>    definition structure to be a wrapper *around* the Guix package
>    structure.  Then the guix.scm would be really simple: it could just
>    "peel off" the outer struct.  If I wanted to do some smart
>    modifications of things from there maybe I could.  I dunno, something
>    like this.
>
>  - "hall scan" is really cool, but I kind of wish I didn't need to use
>    it.  I'd rather not keep track of any of this stuff at all.
>    I'd be happy just pointing some code at a directory and say "snarf
>    up all the .scm files you see therein!"
>
>  - I'm currently writing a manual starting in a .org file that's then
>    converted into a .texi file.  I'd prefer if I could find an
>    entrypoint to insert this into the compilation workflow: a pre-step
>    to the docs compilation that generates the .texi file *from* my
>    .org file.
>
>  - On that note, it strikes me that Hall's integration with autotools
>    is great because it means that existing distros don't need to be
>    aware of Guile *or* Guix.  But it also means that Hall probably has
>    all of the information that it could do all the steps that autoconf
>    and automake do too.  That might be interesting to see that.
>
> Anyway, just some thoughts.  Making Guile packages is already much less
> intimidating now thanks to Hall's work.  Thank you for it!
>
>  - Christine
>
>

Re: Newbie thoughts on Guile Hall + Guix

[Jose Antonio Ortega Ruiz]

On Sat, Feb 05 2022, Mikael Djurfeldt wrote:

> It would also be nice if we could have a Guile package repository.

FWIW, I wish we had an alternative to Guix and autotools for pure-scheme
packages, which don't need all that complication (and that i would love
to see becoming the norm, with that pretty FFI of ours).  Something
like, say, leiningen (or elpa, raco, rebar3, cargo, gobuild, elpa,
cabal...).  For context:

  https://gitlab.com/a-sassmannshausen/guile-hall/-/issues/51

I'd call it "wile", packages would live in "the wilery" (wilery.org is
free) and wile.scm would probably use a simplified dorodango
syntax... and i'd even work on it.  But my feeling is that the community
is heavily invested in autotools and Guix as /the/ build system (and
very happily so!) and i don't have the evangelising chops/time :)

Cheers,
jao
-- 
Nature uses as little as possible of anything.
  -Johannes Kepler, astronomer (1571-1630)

Re: Newbie thoughts on Guile Hall + Guix

[Ricardo Wurmus]

Jose Antonio Ortega Ruiz <jao@gnu.org> writes:

> But my feeling is that the community
> is heavily invested in autotools and Guix as /the/ build system (and
> very happily so!) and i don't have the evangelising chops/time :)

I don’t think anyone really like to use autotools.  When working with
just Guile I find autotools to be an annoying complication.  I don’t
*want* to use autotools and I only use a tiny portion of what it
provides; I use it in recognition of the fact that it works on all
systems I care about.

I we had a simple system that lets people override install locations and
provides good defaults I’d throw out autotools in a heartbeat.

Guix on the other hand … is irreplaceable to me.  Not because of how it
installs Guile packages (it doesn’t do anything special), but because I
don’t need to worry about how any other libraries I might need are
provided or linked.  Guix makes all the problems with non-Guile stuff
disappear, across all supported systems.

-- 
Ricardo

Re: Newbie thoughts on Guile Hall + Guix

[Christine Lemmer-Webber]

IMO, we have, that, and it is Guix.  I'm actually quite happy about
that.  :)

Specific-language-package-repos have caused a lot of the mess we're
currently in; in an unexpected way, it's hurt user freedom a lot,
because mixing these is so hard that software which might be otherwise
reproducible and usable by everyone becomes only deployable by "expert"
devops teams deploying ad-hoc container black boxes who are themselves
very overloaded and have a hard time keeping on top of what's going on.

Guix is great.  I'd love Guix to become the universal package repository
for all FOSS languages. :)

 - Christine

Mikael Djurfeldt <mikael@djurfeldt.com> writes:

> It would also be nice if we could have a Guile package repository.
>
> Den lör 5 feb. 2022 21:11Christine Lemmer-Webber <cwebber@dustycloud.org> skrev:
>
>  Hello!
>
>  It's been a while since Guile was my main hacking environment; I've been
>  returning to it, and one of the nicest things to change about its
>  ecosystem is the presence of Guile Hall.
>
>  I really, really like Guile Hall.  A lot!  I think it has room to grow
>  but it fills a clearly missing piece of the Guile ecosystem while doing
>  it in the best way possible: making itself explicitly compatible with
>  Guix.
>
>  I thought I'd write down some impressions while everything is fresh.
>
>   - Its ability to make an autotools-compatible tarball, but without me
>     needing to think about autotools at all, is a real delight.
>
>   - Its test suite stuff is also really nice.
>
>   - I found myself surprised that hall.scm is "just data", instead of
>     taking the more guix'y approach of being code that actually builds a
>     datastucture.  I'm not sure what the goal of this is; there can be
>     reasons to take that approach but I'm not sure what it is here?
>     My assumption is that the main reason is so that "hall scan" can
>     correctly read and then modify and spit out another file, but I'm
>     not sure.
>
>   - What I would actually *really* like would be for the Hall package
>     definition structure to be a wrapper *around* the Guix package
>     structure.  Then the guix.scm would be really simple: it could just
>     "peel off" the outer struct.  If I wanted to do some smart
>     modifications of things from there maybe I could.  I dunno, something
>     like this.
>
>   - "hall scan" is really cool, but I kind of wish I didn't need to use
>     it.  I'd rather not keep track of any of this stuff at all.
>     I'd be happy just pointing some code at a directory and say "snarf
>     up all the .scm files you see therein!"
>
>   - I'm currently writing a manual starting in a .org file that's then
>     converted into a .texi file.  I'd prefer if I could find an
>     entrypoint to insert this into the compilation workflow: a pre-step
>     to the docs compilation that generates the .texi file *from* my
>     .org file.
>
>   - On that note, it strikes me that Hall's integration with autotools
>     is great because it means that existing distros don't need to be
>     aware of Guile *or* Guix.  But it also means that Hall probably has
>     all of the information that it could do all the steps that autoconf
>     and automake do too.  That might be interesting to see that.
>
>  Anyway, just some thoughts.  Making Guile packages is already much less
>  intimidating now thanks to Hall's work.  Thank you for it!
>
>   - Christine

Re: Newbie thoughts on Guile Hall + Guix

[Aleix Conchillo Flaqué]

I will have to disagree on this one. Not about Guix being great :-). I
believe a simple, lightweight, integrated and cross platform package
manager for Guile would be fantastic.

For reasons that don't matter right now I have been using macOS for the
past two years and I wish I had a package manager. Since I didn't have one
I created Guile Homebrew which I'm probably the only one using. However, I
would love to have something like other languages have as jao and Zelphir
suggest. It is true that Guix would solve the reproducibility issue, but
installing Guix and having a completely separate system of libraries just
to write some project is overkill, at least for me. Maybe it makes sense
for some specific projects but for most of the things that people work on I
would say it probably doesn't. Plus, it doesn't work on macOS but that's
another story.

Speaking about package managers for Guile, some might remember about
Guildhall (https://github.com/ijp/guildhall), maybe it's waiting there for
someone to pick it up.

Aleix

On Sat, Feb 5, 2022 at 4:47 PM Christine Lemmer-Webber <
cwebber@dustycloud.org> wrote:

> IMO, we have, that, and it is Guix.  I'm actually quite happy about
> that.  :)
>
> Specific-language-package-repos have caused a lot of the mess we're
> currently in; in an unexpected way, it's hurt user freedom a lot,
> because mixing these is so hard that software which might be otherwise
> reproducible and usable by everyone becomes only deployable by "expert"
> devops teams deploying ad-hoc container black boxes who are themselves
> very overloaded and have a hard time keeping on top of what's going on.
>
> Guix is great.  I'd love Guix to become the universal package repository
> for all FOSS languages. :)
>
>  - Christine
>
> Mikael Djurfeldt <mikael@djurfeldt.com> writes:
>
> > It would also be nice if we could have a Guile package repository.
> >
> > Den lör 5 feb. 2022 21:11Christine Lemmer-Webber <cwebber@dustycloud.org>
> skrev:
> >
> >  Hello!
> >
> >  It's been a while since Guile was my main hacking environment; I've been
> >  returning to it, and one of the nicest things to change about its
> >  ecosystem is the presence of Guile Hall.
> >
> >  I really, really like Guile Hall.  A lot!  I think it has room to grow
> >  but it fills a clearly missing piece of the Guile ecosystem while doing
> >  it in the best way possible: making itself explicitly compatible with
> >  Guix.
> >
> >  I thought I'd write down some impressions while everything is fresh.
> >
> >   - Its ability to make an autotools-compatible tarball, but without me
> >     needing to think about autotools at all, is a real delight.
> >
> >   - Its test suite stuff is also really nice.
> >
> >   - I found myself surprised that hall.scm is "just data", instead of
> >     taking the more guix'y approach of being code that actually builds a
> >     datastucture.  I'm not sure what the goal of this is; there can be
> >     reasons to take that approach but I'm not sure what it is here?
> >     My assumption is that the main reason is so that "hall scan" can
> >     correctly read and then modify and spit out another file, but I'm
> >     not sure.
> >
> >   - What I would actually *really* like would be for the Hall package
> >     definition structure to be a wrapper *around* the Guix package
> >     structure.  Then the guix.scm would be really simple: it could just
> >     "peel off" the outer struct.  If I wanted to do some smart
> >     modifications of things from there maybe I could.  I dunno, something
> >     like this.
> >
> >   - "hall scan" is really cool, but I kind of wish I didn't need to use
> >     it.  I'd rather not keep track of any of this stuff at all.
> >     I'd be happy just pointing some code at a directory and say "snarf
> >     up all the .scm files you see therein!"
> >
> >   - I'm currently writing a manual starting in a .org file that's then
> >     converted into a .texi file.  I'd prefer if I could find an
> >     entrypoint to insert this into the compilation workflow: a pre-step
> >     to the docs compilation that generates the .texi file *from* my
> >     .org file.
> >
> >   - On that note, it strikes me that Hall's integration with autotools
> >     is great because it means that existing distros don't need to be
> >     aware of Guile *or* Guix.  But it also means that Hall probably has
> >     all of the information that it could do all the steps that autoconf
> >     and automake do too.  That might be interesting to see that.
> >
> >  Anyway, just some thoughts.  Making Guile packages is already much less
> >  intimidating now thanks to Hall's work.  Thank you for it!
> >
> >   - Christine
>
>
>

Re: Newbie thoughts on Guile Hall + Guix

[Mikael Djurfeldt]

I also think that there is a need for something light-weight and cross
platform. I think, e.g., that PyPI is one of the main reasons for the
success of Python and that the lack of something in that direction is
holding Guile back.

Even though Guix is a great project, I can think of many instances where
you would like to use Guile packages but would hesitate to install Guix, or
simply can't.

Maybe it is possible to do it in a way that integrates well with Guix, e.g.
such that the light-weight packages would automatically also be Guix
packages?

I'm not sure that "light-weight" should mean pure scheme, though, since
that would exclude things dependent upon external libraries, like NumPy.
After all, one of the roles of Guile is to be an embedded language. So, the
question is if it would be possible to use aspects of Guix and Hall---to
refactor things, perhaps akin to the peeling off that Christine is talking
about? Maybe with some extra support for the non-Guix case such that the
package would work both within snd outside of Guix? Am I crazy?

Best regards,
Mikael

Den sön 6 feb. 2022 05:54Aleix Conchillo Flaqué <aconchillo@gmail.com>
skrev:

> I will have to disagree on this one. Not about Guix being great :-). I
> believe a simple, lightweight, integrated and cross platform package
> manager for Guile would be fantastic.
>
> For reasons that don't matter right now I have been using macOS for the
> past two years and I wish I had a package manager. Since I didn't have one
> I created Guile Homebrew which I'm probably the only one using. However, I
> would love to have something like other languages have as jao and Zelphir
> suggest. It is true that Guix would solve the reproducibility issue, but
> installing Guix and having a completely separate system of libraries just
> to write some project is overkill, at least for me. Maybe it makes sense
> for some specific projects but for most of the things that people work on I
> would say it probably doesn't. Plus, it doesn't work on macOS but that's
> another story.
>
> Speaking about package managers for Guile, some might remember about
> Guildhall (https://github.com/ijp/guildhall), maybe it's waiting there
> for someone to pick it up.
>
> Aleix
>
> On Sat, Feb 5, 2022 at 4:47 PM Christine Lemmer-Webber <
> cwebber@dustycloud.org> wrote:
>
>> IMO, we have, that, and it is Guix.  I'm actually quite happy about
>> that.  :)
>>
>> Specific-language-package-repos have caused a lot of the mess we're
>> currently in; in an unexpected way, it's hurt user freedom a lot,
>> because mixing these is so hard that software which might be otherwise
>> reproducible and usable by everyone becomes only deployable by "expert"
>> devops teams deploying ad-hoc container black boxes who are themselves
>> very overloaded and have a hard time keeping on top of what's going on.
>>
>> Guix is great.  I'd love Guix to become the universal package repository
>> for all FOSS languages. :)
>>
>>  - Christine
>>
>> Mikael Djurfeldt <mikael@djurfeldt.com> writes:
>>
>> > It would also be nice if we could have a Guile package repository.
>> >
>> > Den lör 5 feb. 2022 21:11Christine Lemmer-Webber <
>> cwebber@dustycloud.org> skrev:
>> >
>> >  Hello!
>> >
>> >  It's been a while since Guile was my main hacking environment; I've
>> been
>> >  returning to it, and one of the nicest things to change about its
>> >  ecosystem is the presence of Guile Hall.
>> >
>> >  I really, really like Guile Hall.  A lot!  I think it has room to grow
>> >  but it fills a clearly missing piece of the Guile ecosystem while doing
>> >  it in the best way possible: making itself explicitly compatible with
>> >  Guix.
>> >
>> >  I thought I'd write down some impressions while everything is fresh.
>> >
>> >   - Its ability to make an autotools-compatible tarball, but without me
>> >     needing to think about autotools at all, is a real delight.
>> >
>> >   - Its test suite stuff is also really nice.
>> >
>> >   - I found myself surprised that hall.scm is "just data", instead of
>> >     taking the more guix'y approach of being code that actually builds a
>> >     datastucture.  I'm not sure what the goal of this is; there can be
>> >     reasons to take that approach but I'm not sure what it is here?
>> >     My assumption is that the main reason is so that "hall scan" can
>> >     correctly read and then modify and spit out another file, but I'm
>> >     not sure.
>> >
>> >   - What I would actually *really* like would be for the Hall package
>> >     definition structure to be a wrapper *around* the Guix package
>> >     structure.  Then the guix.scm would be really simple: it could just
>> >     "peel off" the outer struct.  If I wanted to do some smart
>> >     modifications of things from there maybe I could.  I dunno,
>> something
>> >     like this.
>> >
>> >   - "hall scan" is really cool, but I kind of wish I didn't need to use
>> >     it.  I'd rather not keep track of any of this stuff at all.
>> >     I'd be happy just pointing some code at a directory and say "snarf
>> >     up all the .scm files you see therein!"
>> >
>> >   - I'm currently writing a manual starting in a .org file that's then
>> >     converted into a .texi file.  I'd prefer if I could find an
>> >     entrypoint to insert this into the compilation workflow: a pre-step
>> >     to the docs compilation that generates the .texi file *from* my
>> >     .org file.
>> >
>> >   - On that note, it strikes me that Hall's integration with autotools
>> >     is great because it means that existing distros don't need to be
>> >     aware of Guile *or* Guix.  But it also means that Hall probably has
>> >     all of the information that it could do all the steps that autoconf
>> >     and automake do too.  That might be interesting to see that.
>> >
>> >  Anyway, just some thoughts.  Making Guile packages is already much less
>> >  intimidating now thanks to Hall's work.  Thank you for it!
>> >
>> >   - Christine
>>
>>
>>

Re: Newbie thoughts on Guile Hall + Guix

[Ricardo Wurmus]

Mikael Djurfeldt <mikael@djurfeldt.com> writes:

> I also think that there is a need for something light-weight and cross
> platform. I think, e.g., that PyPI is one of the main reasons for the
> success of Python and that the lack of something in that direction is
> holding Guile back.

PyPI is a good example for the kind of problems that all language
package managers end up having.  Language package managers have no way
of clearly expressing dependencies that are not written in the target
language.  This happens surprisingly often.

When installing something with PyPi you may end up downloading a whole
bunch of pre-compiled (and potentially unusable) binaries.  A good
example of this is pytorch, but sadly it’s far from an unusual case.

R has similar difficulties, and it has probably the sanest way of
dealing with them: it just assumes the system has a suitable toolchain
and libraries and headers and all that and builds everything from source.

> I'm not sure that "light-weight" should mean pure scheme, though, since
> that would exclude things dependent upon external libraries, like
> NumPy.

Requiring the Guile-only package manager to also support installing
system libraries dooms it to reimplementing parts of Guix poorly.

-- 
Ricardo

Re: Newbie thoughts on Guile Hall + Guix

[Vijay Marupudi]

Hello all,

I am similarly impressed by Guile Hall and wish for its continued
development and success.

> PyPI is a good example for the kind of problems that all language
> package managers end up having.  Language package managers have no way
> of clearly expressing dependencies that are not written in the target
> language.  This happens surprisingly often.

Let's not make perfect be the enemy of good here. A language specific
package manager does work to a certain extent. I sometimes struggle to
recommend Guile for beginners to programming, or even those that have
some experience (in academia atleast). That's not because the language
is not friendly, it really is simple and there is plenty of Scheme
learning material around. However, it's really hard to get into the
ecosystem without an understanding of C and its packaging system and
culture. And I want more scientists and beginners to use Guile who don't
have that knowledge.

As a relative new user of Guile, I had to learn a lot of adjacent
concepts about package management before I could become fluent with
Guile and split my code into modules and packages, and more importantly,
using other packages. Reducing the learning and effort barrier in this
regard, would be incredibly exciting, and I would like to help anyway I
can towards this effort.

Asking beginners to use Guix is too much of a jump I think. But get them
hooked on Guile with an easy package manager and a rich ecosystem, and I
think they will come to appreciate Guix and other free software
projects, like I did.

~ Vijay

Re: Newbie thoughts on Guile Hall + Guix

[Ognen Duzlevski]

Vijay Marupudi <vijaymarupudi@gatech.edu> writes:

> Let's not make perfect be the enemy of good here. A language specific
> package manager does work to a certain extent. I sometimes struggle to
> recommend Guile for beginners to programming, or even those that have
> some experience (in academia atleast). That's not because the language
> is not friendly, it really is simple and there is plenty of Scheme
> learning material around. However, it's really hard to get into the
> ecosystem without an understanding of C and its packaging system and
> culture. And I want more scientists and beginners to use Guile who don't
> have that knowledge.

Have you tried Racket? If you haven't - try that and you will find
recommending Guile to beginners to be much easier ;). On a serious note,
there are other schemes that have their own package managers (e.g. Racket).

> As a relative new user of Guile, I had to learn a lot of adjacent
> concepts about package management before I could become fluent with
> Guile and split my code into modules and packages, and more importantly,
> using other packages. Reducing the learning and effort barrier in this
> regard, would be incredibly exciting, and I would like to help anyway I
> can towards this effort.

IMHO, this learning curve is a part of learning any language. The reason
why every language comes with a language "specific" manager is because a
lot of people have tried to solve this problem and failed to find the
magic bullet. At some level you are relying on the language's
portability itself, then on the same level you are wanting to exploit
some of the language's specifics, then on the same level someone comes
along and says for some packages this approach doesn't work... ;)

> Asking beginners to use Guix is too much of a jump I think. But get them
> hooked on Guile with an easy package manager and a rich ecosystem, and I
> think they will come to appreciate Guix and other free software
> projects, like I did.

I agree. I have already been through the learning curve of Emacs, scheme
etc. At what point do I focus on just getting my job done and having a life
outside of the computer instead of constantly being on the treadmill of
learning one more concept/tool/specific to get a small benefit out of
it? People should always remember the 80/20 principle...

-- 
There are 2 mistakes along the way to mastery: 1. Not starting the journey 2. Not going all the way

Re: Newbie thoughts on Guile Hall + Guix

[Maxime Devos]

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

Ognen Duzlevski schreef op zo 06-02-2022 om 09:53 [-0500]:
> > Asking beginners to use Guix is too much of a jump I think. But get
> > them
> > hooked on Guile with an easy package manager and a rich ecosystem,
> > and I
> > think they will come to appreciate Guix and other free software
> > projects, like I did.
> 
> I agree.
> I have already been through the learning curve of Emacs, scheme
> etc. At what point do I focus on just getting my job done and having
> a life outside of the computer instead of constantly being on the
> treadmill of learning one more concept/tool/specific to get a small
> benefit out of it? People should always remember the 80/20
> principle...

In that case, wouldn't a Guile-specific package manager count as yet
another tool to be learned?  Wouldn't using a single package manager
(Guix) for everything -- Emacs, Guile, Racket, Python, C stuff ...,
instead of learning a new language-specific package manager every time
you use a new language?  As such, I cannot reconcile your ‘I agree’
with your explanation, your explanation would seem better fitting with
‘I disagree’.

Anyway, there's already a Scheme package manager, e.g.
https://akkuscm.org/ (supports Racket, Guile, Chibi, ...) and
http://snow-fort.org/, so if we go for a Scheme-specific package
manager anyway, I'd rather avoid reinventing the wheel if possible.

Warning: I've never tried any of these Scheme package managers.
I don't know if they are good.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Newbie thoughts on Guile Hall + Guix

[Vijay Marupudi]

Ognen Duzlevski <maketo@sdf.org> writes:

> Have you tried Racket? If you haven't - try that and you will find
> recommending Guile to beginners to be much easier ;). On a serious note,
> there are other schemes that have their own package managers (e.g.
> Racket).

I have, but I like Guile better, and want everyone to use it :) I think
being an extension language is a very useful and important part of what
makes Guile great.

> IMHO, this learning curve is a part of learning any language. The reason
> why every language comes with a language "specific" manager is because a
> lot of people have tried to solve this problem and failed to find the
> magic bullet. At some level you are relying on the language's
> portability itself, then on the same level you are wanting to exploit
> some of the language's specifics, then on the same level someone comes
> along and says for some packages this approach doesn't work... ;)

I don't think it's fair to say that using packages in Guile just as
easy/hard as other languages. Python / Javascript make this incredibly
easy, and their ecosystem is evidence for that success. Their package
managers have flaws, but they have benefits too, and those benefits
would be great for Guile.

Note that I'm not saying that this package manager has to do everything
expected of a battle-tested production package manager. Just make it
easier for beginners to use and make packages (which will be Guix
compatible by default). And we should not underestimate what beginners
can do for a language. They might be new to Guile, but possess a lot of
other traits that would be great, like domain expertise in science,
writing skills, etc. which would be great for the ecosystem.

Advanced users can use Guix or do the ./configure && make && make
install dance.

~ Vijay

Re: Newbie thoughts on Guile Hall + Guix

[Zelphir Kaltstahl]

On 2/6/22 16:29, Vijay Marupudi wrote:
> Ognen Duzlevski <maketo@sdf.org> writes:
>
>> Have you tried Racket? If you haven't - try that and you will find
>> recommending Guile to beginners to be much easier ;). On a serious note,
>> there are other schemes that have their own package managers (e.g.
>> Racket).
> I have, but I like Guile better, and want everyone to use it :) I think
> being an extension language is a very useful and important part of what
> makes Guile great.
>
>> IMHO, this learning curve is a part of learning any language. The reason
>> why every language comes with a language "specific" manager is because a
>> lot of people have tried to solve this problem and failed to find the
>> magic bullet. At some level you are relying on the language's
>> portability itself, then on the same level you are wanting to exploit
>> some of the language's specifics, then on the same level someone comes
>> along and says for some packages this approach doesn't work... ;)
> I don't think it's fair to say that using packages in Guile just as
> easy/hard as other languages. Python / Javascript make this incredibly
> easy, and their ecosystem is evidence for that success. Their package
> managers have flaws, but they have benefits too, and those benefits
> would be great for Guile.
>
> Note that I'm not saying that this package manager has to do everything
> expected of a battle-tested production package manager. Just make it
> easier for beginners to use and make packages (which will be Guix
> compatible by default). And we should not underestimate what beginners
> can do for a language. They might be new to Guile, but possess a lot of
> other traits that would be great, like domain expertise in science,
> writing skills, etc. which would be great for the ecosystem.
>
> Advanced users can use Guix or do the ./configure && make && make
> install dance.

I find using Guix to be much better than the ./configure && make && make stuff. 
The reason is, that I always think: "What, if it doesn't work and I want to 
clean up my system afterwards?". I can't stand it, if any remains of non-working 
stuff is left on the system.

I am fine with using Guix. I like Guix. It is just that making a package is way 
to hard for newcomers. I needed weeks to make one simple pure Guile package, 
because I burned out trying to do it and had to have pauses in between, before I 
could muster new energy to try again. That still haunts me, so that I still have 
not updated my package, even though I have a newer release for months by now. 
Especially the whole (in the end unnecessary) autotools stuff was exhausting. 
Trying to understand what all those files do in my package. It is sort of my own 
problem, because I cannot leave it alone and just be done with it. I want to 
understand it. And then I dive into that rabbit hole and research decades old 
cruft that was automatically added to some autotools files.

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: Newbie thoughts on Guile Hall + Guix

[David Pirotte]

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

Hello,

> I find using Guix to be much better than the ./configure && make &&
> make stuff. The reason is, that I always think: "What, if it doesn't
> work and I want to clean up my system afterwards?". I can't stand it,
> if any remains of non-working stuff is left on the system.

	cd
	make -p does-it-work/foo
	./configure --prefix=$HOME/does-it-work/foo
	make; make check; make install
	# try it ...

	# you like it, keep it or redo the above with what ever $prefix
	# suites you

	# you don't like it
	rm -rf $HOME/does-it-work/foo

fwiw,
David

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

Re: Newbie thoughts on Guile Hall + Guix

[David Pirotte]

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


> 	cd
> 	make -p does-it-work/foo

	cd <to the foo cloned/untarred dir>

> 	./configure --prefix=$HOME/does-it-work/foo
> 	make; make check; make install
> 	# try it ...

> 	# you like it, keep it or redo the above with what ever $prefix
>	# suites you

> 	# you don't like it and/or did redo ...
> 	rm -rf $HOME/does-it-work/foo

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

Re: Newbie thoughts on Guile Hall + Guix

[Zelphir Kaltstahl]

On 2/7/22 03:11, David Pirotte wrote:
> Hello,
>
>> I find using Guix to be much better than the ./configure && make &&
>> make stuff. The reason is, that I always think: "What, if it doesn't
>> work and I want to clean up my system afterwards?". I can't stand it,
>> if any remains of non-working stuff is left on the system.
> 	cd
> 	make -p does-it-work/foo
> 	./configure --prefix=$HOME/does-it-work/foo
> 	make; make check; make install
> 	# try it ...
>
> 	# you like it, keep it or redo the above with what ever $prefix
> 	# suites you
>
> 	# you don't like it
> 	rm -rf $HOME/does-it-work/foo
>
> fwiw,
> David

Hi David!

That seems like a good option! Thanks.
I guess I would still depend on the Makefile to be properly written to not put stuff elsewhere. But then again I might be relying on that anyway, when installing things using Guix.

Regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: Newbie thoughts on Guile Hall + Guix

[adriano]

Il giorno dom, 06/02/2022 alle 21.34 +0000, Zelphir Kaltstahl ha
scritto:
> On 2/6/22 16:29, Vijay Marupudi wrote:
> > Ognen Duzlevski <maketo@sdf.org> writes:
> > 
> > > Have you tried Racket? If you haven't - try that and you will
> > > find
> > > recommending Guile to beginners to be much easier ;). On a
> > > serious note,
> > > there are other schemes that have their own package managers
> > > (e.g.
> > > Racket).
> > I have, but I like Guile better, and want everyone to use it :) I
> > think
> > being an extension language is a very useful and important part of
> > what
> > makes Guile great.
> > 
> > > IMHO, this learning curve is a part of learning any language. The
> > > reason
> > > why every language comes with a language "specific" manager is
> > > because a
> > > lot of people have tried to solve this problem and failed to find
> > > the
> > > magic bullet. At some level you are relying on the language's
> > > portability itself, then on the same level you are wanting to
> > > exploit
> > > some of the language's specifics, then on the same level someone
> > > comes
> > > along and says for some packages this approach doesn't work... ;)
> > I don't think it's fair to say that using packages in Guile just as
> > easy/hard as other languages. Python / Javascript make this
> > incredibly
> > easy, and their ecosystem is evidence for that success. Their
> > package
> > managers have flaws, but they have benefits too, and those benefits
> > would be great for Guile.
> > 
> > Note that I'm not saying that this package manager has to do
> > everything
> > expected of a battle-tested production package manager. Just make
> > it
> > easier for beginners to use and make packages (which will be Guix
> > compatible by default). And we should not underestimate what
> > beginners
> > can do for a language. They might be new to Guile, but possess a
> > lot of
> > other traits that would be great, like domain expertise in science,
> > writing skills, etc. which would be great for the ecosystem.
> > 
> > Advanced users can use Guix or do the ./configure && make && make
> > install dance.
> 
> I find using Guix to be much better than the ./configure && make &&
> make stuff. 
> The reason is, that I always think: "What, if it doesn't work and I
> want to 
> clean up my system afterwards?". I can't stand it, if any remains of
> non-working 
> stuff is left on the system.
> 
> I am fine with using Guix. I like Guix. It is just that making a
> package is way 
> to hard for newcomers. I needed weeks to make one simple pure Guile
> package, 
> because I burned out trying to do it and had to have pauses in
> between, before I 
> could muster new energy to try again. That still haunts me, so that I
> still have 
> not updated my package, even though I have a newer release for months
> by now. 
> Especially the whole (in the end unnecessary) autotools stuff was
> exhausting. 
> Trying to understand what all those files do in my package. It is
> sort of my own 
> problem, because I cannot leave it alone and just be done with it. I
> want to 
> understand it. 

Just don't

That stuff is too low level for human beings

The only autotools files you should care about are the ones meant to be
written by a human being (the package author)

The ones it produces in its own are not meant to be "understood"

With Guile-Hall you don't even need to understand the autotools files
meant to be edited by human beings

Becaue Hall will edit those for you

BUT

The essential part is short and it's as follows

There are 2 people in ths scenario: you (the package author) and
someone who downloads your package and runs configure; make

The autoconf file you (the package author) edit is meant to produce a
bash script 


Such bash file is called "configure" (it will be called by the user of
your package)

and it does 2 things:

1) checks features available on the system of the user running
configure; make

2) based on the results of the checks (and also based on another file),
writes a makefile that will pilot the building

So now you can call make and make will execute the makefile written
previously

That's all

Now: Guix leverages this machinery to manage your package

Because of that, defining an autotools based package for Guix is easier
than it is to configure a package that has no build system

because if your package has no build system, the building process will
have to be expressed in Guix code

If, instead, it has a build system (the autotools or any other) Guix
will charge the build system with the building process, maybe calling
its APIs, so the definition can be more streamlined

Anyway, I feel your frustration, I've been there myself

Actually I've been there with Guile more than with Guix

But still I feel you

I hope this message of mine can sooth your frustration, to some extent

Re: Newbie thoughts on Guile Hall + Guix

[Vivien]

Hello Christine, Hall, and the rest of Guile! 

Le samedi 05 février 2022 à 15:01 -0500, Christine Lemmer-Webber a
écrit :
> It's been a while since Guile was my main hacking environment; I've
> been
> returning to it, and one of the nicest things to change about its
> ecosystem is the presence of Guile Hall.

I’m starting to convert my project to hall as well :)

> I really, really like Guile Hall.  A lot!  I think it has room to
> grow
> but it fills a clearly missing piece of the Guile ecosystem while
> doing
> it in the best way possible: making itself explicitly compatible with
> Guix.
> 
> I thought I'd write down some impressions while everything is fresh.

Let me do the same thing.


>  - Its ability to make an autotools-compatible tarball, but without
> me
>    needing to think about autotools at all, is a real delight.

The automake and m4 meta-programming languages are good for what they
do, but if we’re also writing scheme for the build system, it would
become too much.


>  - Its test suite stuff is also really nice.

Using the SRFI 64 API lowers the cost to add tests, which is especially
good for such a dynamic and flexible language as guile.

>  - I found myself surprised that hall.scm is "just data", instead of
>    taking the more guix'y approach of being code that actually builds
> a
>    datastucture.  I'm not sure what the goal of this is; there can be
>    reasons to take that approach but I'm not sure what it is here?
>    My assumption is that the main reason is so that "hall scan" can
>    correctly read and then modify and spit out another file, but I'm
>    not sure.

It was a problem for me too. I wanted to compute the version number
from git describe, and it turns out I couldn’t do that in hall.scm. I
had to create a bootstrap script to generate hall.scm, run hall scan
and then other hall commands (and then autoreconf). This approach is
more functional, because there’s less state (I consider auto-generated
Makefile.am, configure.ac and similar files as state because hall and I
are supposed to edit them). It means I can git-ignore most of the stuff
that hall dist generates.

>  - What I would actually *really* like would be for the Hall package
>    definition structure to be a wrapper *around* the Guix package
>    structure.  Then the guix.scm would be really simple: it could
> just
>    "peel off" the outer struct.  If I wanted to do some smart
>    modifications of things from there maybe I could.  I dunno,
> something
>    like this.

From what I remember, the guix package data structure is a guix record;
is specific to guix. Hall would need to depend on guix (or, my
preferred solution, guix would use GOOPS classes instead of guix
records for more things, including packages, but we’re not there yet!).

I also have a more dynamic guix.scm (I wouldn’t call it smart though).
It puts the current commit in the store, runs "hall guix" there, loads
the generated guix.scm file, and fixes the package it evaluates to (so
as to use the current commit as a source and add hall as a native-
input, for instance).

Guix shell doesn’t like stuff that’s too smart in guix.scm though,
because of its cache.

> 
>  - "hall scan" is really cool, but I kind of wish I didn't need to
> use
>    it.  I'd rather not keep track of any of this stuff at all.
>    I'd be happy just pointing some code at a directory and say "snarf
>    up all the .scm files you see therein!"

Such a wildcard pattern was heavily discouraged in the past, because
you could forget to distribute some files and there wouldn’t be a good
way to know why the build would fail on someone else’s computer due to
a missing file. Nowadays, we have git (and other version control
systems) and continuous integration, so I don’t see a reason why what
you want would be a problem.

> 
>  - I'm currently writing a manual starting in a .org file that's then
>    converted into a .texi file.  I'd prefer if I could find an
>    entrypoint to insert this into the compilation workflow: a pre-
> step
>    to the docs compilation that generates the .texi file *from* my
>    .org file.

I think it would be easier for hall to support org->texi conversion
natively, so that we could still code without automake knowledge. For
instance, as you must have noticed, implementing the conversion as an
automake rule means that automake will fail because it won’t know
whether the generated file needs version.texi.

>  - On that note, it strikes me that Hall's integration with autotools
>    is great because it means that existing distros don't need to be
>    aware of Guile *or* Guix.  But it also means that Hall probably
> has
>    all of the information that it could do all the steps that
> autoconf
>    and automake do too.  That might be interesting to see that.

You mean that hall could implement all of the autotools features? Even
if we remove C-related features, hoping that we won’t need to write C
code ever again, that’s still a lot to ask for. I’m not sure it would
be pragmatic for hall to try and do that.

>    
> Anyway, just some thoughts.  Making Guile packages is already much
> less
> intimidating now thanks to Hall's work.

I must add, that gettext support is crucial and missing. Fortunately, I
can fix the generated autotools infrastructure in my custom bootstrap
phase but it isn’t pretty: I have to invoke emacs to fix configure.ac
and Makefile.am, for instance. It shouldn’t be too hard for hall to
support gettext: hall already knows the list of source files, so it can
generate POTFILES.in. We would just need to specify the LINGUAS list in
hall.scm and it could do the rest.

As a conclusion, hall fits exactly what I expect it to do, and it’s
almost always a pleasure to work with, but I wish it were more
functional (not keeping hall.scm, configure.ac and Makefile.am as
state) and I think it should support gettext natively.

Vivien

Re: Newbie thoughts on Guile Hall + Guix

[Zelphir Kaltstahl]

On 2/5/22 21:01, Christine Lemmer-Webber wrote:
> Hello!
>
> It's been a while since Guile was my main hacking environment; I've been
> returning to it, and one of the nicest things to change about its
> ecosystem is the presence of Guile Hall.
>
> I really, really like Guile Hall.  A lot!  I think it has room to grow
> but it fills a clearly missing piece of the Guile ecosystem while doing
> it in the best way possible: making itself explicitly compatible with
> Guix.
>
> I thought I'd write down some impressions while everything is fresh.
>
>   - Its ability to make an autotools-compatible tarball, but without me
>     needing to think about autotools at all, is a real delight.
>
>   - Its test suite stuff is also really nice.
>
>   - I found myself surprised that hall.scm is "just data", instead of
>     taking the more guix'y approach of being code that actually builds a
>     datastucture.  I'm not sure what the goal of this is; there can be
>     reasons to take that approach but I'm not sure what it is here?
>     My assumption is that the main reason is so that "hall scan" can
>     correctly read and then modify and spit out another file, but I'm
>     not sure.
>
>   - What I would actually *really* like would be for the Hall package
>     definition structure to be a wrapper *around* the Guix package
>     structure.  Then the guix.scm would be really simple: it could just
>     "peel off" the outer struct.  If I wanted to do some smart
>     modifications of things from there maybe I could.  I dunno, something
>     like this.
>
>   - "hall scan" is really cool, but I kind of wish I didn't need to use
>     it.  I'd rather not keep track of any of this stuff at all.
>     I'd be happy just pointing some code at a directory and say "snarf
>     up all the .scm files you see therein!"
>
>   - I'm currently writing a manual starting in a .org file that's then
>     converted into a .texi file.  I'd prefer if I could find an
>     entrypoint to insert this into the compilation workflow: a pre-step
>     to the docs compilation that generates the .texi file *from* my
>     .org file.
>   
>   - On that note, it strikes me that Hall's integration with autotools
>     is great because it means that existing distros don't need to be
>     aware of Guile *or* Guix.  But it also means that Hall probably has
>     all of the information that it could do all the steps that autoconf
>     and automake do too.  That might be interesting to see that.
>     
> Anyway, just some thoughts.  Making Guile packages is already much less
> intimidating now thanks to Hall's work.  Thank you for it!
>
>   - Christine

For what it is worth: You do not need to use Hall, if you do not need to run 
tests, when installing via Guix or similar things. If you are fine with running 
tests before publishing a version of a package to Guix, then you only need Guix 
and a package definition. No autotools.

I found all the stuff that is generated by Hall a bit worrying. Lots of 
autotools appearing in my repository, which I do not fully understand. Being 
forced to use hall scan and so on. Too much magic behind the scenes. Packaging 
should be so simple, that I can still easily understand all the things in my 
repository, without studying autotools for a week, searching for archaic 
variable names and what they to and how everything works. I am not a huge fan of 
the JS ecosystem at all, but if we look at the NPM world, there is only one file 
that needs to exist, the package.json, and already you have a valid package. Why 
can it not be the same simplicity for Guile? And if Guix really requires there 
to be a `make` `make check` or whatever, then where is the guide, that tells me 
how to hand-craft the Makefile, so that everything works and I don't need extra 
tooling to generate files.

I want to be able to edit the guix package definition, point it to the tests 
directory, and be done with it. When I use Hall, then I have yet another tool in 
the workflow. Again more commands and things to keep in mind. I want less tools 
and simplicity. I don't run autotools for running my tests locally, so there is 
no theoretical need for that. The maximum I do it a very simple Makefile, which 
provides me with a `make test` to run tests or `make` to run the program. It is 
just that from the Guix side of things, something would have to be done to be 
able to invoke tests properly, without a `make test` command being available, 
but knowing where the tests are. They could be declared in the package 
definition for example. Why do I need any autotools stuff? Just make Guix call 
my SRFI-64 tests.

This is why I decided to not use Hall for guile-fslib. I did not like the 
complexity of having all the autotools stuff in my repo, which I don't even 
fully understand, just for it becoming a package. Even if I don't need to 
manually touch any of those files. I can run tests on my machine before sending 
in a patch for a new version and that will be fine.

Hall is probably a great thing, if you have a package, that is not pure Guile, 
so that one has to do other things than simply running a Guile command to run 
the tests, perhaps to generate documentation or other files. For pure Guile 
packages, I still need to see or learn about a good reason to add the complexity 
of it to a repository.

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: Newbie thoughts on Guile Hall + Guix

[Olivier Dion via General Guile related discussions]

On Sat, 05 Feb 2022, Christine Lemmer-Webber <cwebber@dustycloud.org> wrote:
    
> Anyway, just some thoughts.  Making Guile packages is already much less
> intimidating now thanks to Hall's work.  Thank you for it!

Here's my two cents.  As much as I like hall for pure Guile project,
it's difficult to integrate extension libraries written in C.  I've also
never been a fan of the autotools stuffs.

I personnally end up writting something similar to hall for a project of
mine using Guix records.  From a description like so:
--------------------------------------------------------------------------------
(project
  (name "foo")
  (version "1")
  (configuration-file "config.scm")
  (export-configuration
    '(("include/config.h" . "FOO_CONFIG_H")
      ("foo/config.scm"   . "foo config")))
  (build-directory "./build")
  (cppflags `(-Include ,(pkg-cflags-only-I '(guile-3.0))))
  (guile-root "foo")
  (guile-tests-root "tests")
  (scripts
    (list
      (script
        (name "foo")
        (file "scripts/foo")
        (install? #t))
      (script
        (name "debug")
        (file "scripts/debug")
        (install? #f))))
  (c-modules
    (list
      (c-module
        (name "foo")
        (files '("core/*.c"))
        (packages '(guile-3.0)))
      (c-module
        (name "bar")
        (files '("bar/bar.c"))
        (ldflags '(-lsomelib))
        (packages '(some-other-lib)))))
--------------------------------------------------------------------------------
this description end up generating a `guix.scm`, `makefile`,
`pre-install-env`, `foo/config.scm` and `include/config.h`.  Packaging
is just a matter of shipping the `makefile` with the source codes.

-- 
Olivier Dion
Polymtl

Re: Newbie thoughts on Guile Hall + Guix

[Vivien Kraus]

Hello, 

Le dimanche 06 février 2022 à 11:35 -0500, Olivier Dion via General
Guile related discussions a écrit :
> As much as I like hall for pure Guile project,
> it's difficult to integrate extension libraries written in C. 

While this is certainly true, I think that nyacc is on the right track
to let us use C libraries without writing a single line of C code.

Vivien

Re: Newbie thoughts on Guile Hall + Guix

[Olivier Dion via General Guile related discussions]

On Sun, 06 Feb 2022, Vivien Kraus <vivien@planete-kraus.eu> wrote:
> Hello, 
>
> Le dimanche 06 février 2022 à 11:35 -0500, Olivier Dion via General
> Guile related discussions a écrit :
>> As much as I like hall for pure Guile project,
>> it's difficult to integrate extension libraries written in C. 
>
> While this is certainly true, I think that nyacc is on the right track
> to let us use C libraries without writing a single line of C code.

I agree that when you want to use a C library that's already there, the
state of FFI in Guile is awesome.  However, you sometime need to write
your own C code for low level stuffs.  For example, I require C for
developing custom memory allocators, fast audio mixing with SIMD,
multi-threading with OpenMP, etc.  These require many tweaks in the
build system to integrate correctly with Guile at compile and run times.

-- 
Olivier Dion
Polymtl

Re: Newbie thoughts on Guile Hall + Guix

[Maxime Devos]

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

Olivier Dion via General Guile related discussions schreef op zo 06-02-
2022 om 11:35 [-0500]:
> I personnally end up writting something similar to hall for a project of
> mine using Guix records.  From a description like so:
> --------------------------------------------------------------------------------
> (project
>   (name "foo")
>   (version "1")
>   (configuration-file "config.scm")
>   (export-configuration
>     '(("include/config.h" . "FOO_CONFIG_H")
>       ("foo/config.scm"   . "foo config")))
>   (build-directory "./build")
>   (cppflags `(-Include ,(pkg-cflags-only-I '(guile-3.0))))
>   (guile-root "foo")
>   (guile-tests-root "tests")
>   (scripts
>     (list
>       (script
>         (name "foo")
>         (file "scripts/foo")
>         (install? #t))
>       (script
>         (name "debug")
>         (file "scripts/debug")
>         (install? #f))))
>   (c-modules
>     (list
>       (c-module
>         (name "foo")
>         (files '("core/*.c"))
>         (packages '(guile-3.0)))
>       (c-module
>         (name "bar")
>         (files '("bar/bar.c"))
>         (ldflags '(-lsomelib))
>         (packages '(some-other-lib)))))
> --------------------------------------------------------------------------------
> this description end up generating a `guix.scm`, `makefile`,
> `pre-install-env`, `foo/config.scm` and `include/config.h`.  Packaging
> is just a matter of shipping the `makefile` with the source codes.

This seems like a practical build system to me.  Is it available online
somewhere?  I'd like to investigate it a bit for some common problems
in ad-hoc Makefiles (in particular w.r.t. cross-compilation, tracking
dependency information, choosing installation prefixes...) and
determine if I could extend it for my usecases.

Is it restricted to Makefiles, or can it also be used without
generating Makefiles?  If not, things like progress bars should be easy
to implement and file names containing spaces or ‘special characters’
can be used without any problems.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Newbie thoughts on Guile Hall + Guix

[Olivier Dion via General Guile related discussions]

On Sun, 06 Feb 2022, Maxime Devos <maximedevos@telenet.be> wrote:

> This seems like a practical build system to me.  Is it available online
> somewhere?  I'd like to investigate it a bit for some common problems
> in ad-hoc Makefiles (in particular w.r.t. cross-compilation, tracking
> dependency information, choosing installation prefixes...) and
> determine if I could extend it for my usecases.

I've setup a quick Gitlab repo with a `hello world` project for you and
others that would like to check it out.  Note that this is WIP and very
much glued to my project.  Also, dependencies are resolved at
configuration time of the project (while generating the Makefile), not a
build time.  In the future, I would like to change that so that it's
possible to copy the Makefile on any distro.  There's currently no
installation step also.

Here's the repo: https://gitlab.com/oldiob/cbuild

> Is it restricted to Makefiles, or can it also be used without
> generating Makefiles?  If not, things like progress bars should be easy
> to implement and file names containing spaces or ‘special characters’
> can be used without any problems.

Since it's glued to my project, and since I'm very familiar with
Makefiles, it only support Makefiles for now.  What would be the other
targets you have in mind?

-- 
Olivier Dion
Polymtl

Re: Newbie thoughts on Guile Hall + Guix

[Maxime Devos]

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

Olivier Dion schreef op zo 06-02-2022 om 17:05 [-0500]:
> > Is it restricted to Makefiles, or can it also be used without
> > generating Makefiles?  If not, things like progress bars should be
> > easy
> > to implement and file names containing spaces or ‘special
> > characters’
> > can be used without any problems.
> 
> Since it's glued to my project, and since I'm very familiar with
> Makefiles, it only support Makefiles for now.  What would be the
> other
> targets you have in mind?

I was thinking of something like

$ cd ~/the-source-code
# (I haven't looked much yet, possibly the CLI needs to be very
different)
$ cbuild make --target=aarch64-linux-gnu --prefix=/foo/bar
$ cbuild install --staged-install=/blah

Basically, don't delegate to 'make' or 'ninja' or whatever, just build
it.

That's way less portable than 'make' of course, but people that don't
have 'cbuild' or don't want to learn 'cbuild' can still use the
Makefile.

Seems like I'll have to make some changes to support cross-compilation
(basically, pass --target=aarch64-linux-gnu or the like to "guild
compile", and search for TARGET-gcc/clang instead of gcc/clang)
but otherwise looks mostly ok.

I noted that you are using #nil in some places.
#nil (an amalgation of #false and the empty list ()) is mostly an
implementation detail for Emacs Lisp support, and not something that
needs to be used in pure Guile.  I would use '() instead; it's
also more portable to other Schemes.

There's also some potential reproducibility problems: in
https://gitlab.com/oldiob/cbuild/-/blob/master/config.scm#L19,
D1CACHE_LINE_SIZE is set based on the cache size where it was
compiled, instead of the cache size where it is supposed to run on.

For now, I'll keep using the Autotools-based system (if it works, don't
break it :p, also doing other things at the moment than tweaking build
systems), but I'll keep cbuild in mind for the future.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Newbie thoughts on Guile Hall + Guix

[Olivier Dion via General Guile related discussions]

On Sun, 06 Feb 2022, Maxime Devos <maximedevos@telenet.be> wrote:
> Olivier Dion schreef op zo 06-02-2022 om 17:05 [-0500]:
>> > Is it restricted to Makefiles, or can it also be used without
>> > generating Makefiles?  If not, things like progress bars should be
>> > easy
>> > to implement and file names containing spaces or ‘special
>> > characters’
>> > can be used without any problems.
>> 
>> Since it's glued to my project, and since I'm very familiar with
>> Makefiles, it only support Makefiles for now.  What would be the
>> other
>> targets you have in mind?
>
> I was thinking of something like
>
> $ cd ~/the-source-code
> # (I haven't looked much yet, possibly the CLI needs to be very
> different)
> $ cbuild make --target=aarch64-linux-gnu --prefix=/foo/bar
> $ cbuild install --staged-install=/blah

I'm not a fan of configuration with CLI like `--prefix`.  I like to have
a configuration file that is configurable like so:

.config.scm:
-----------------------
'((TARGET . aarch64)
  (PREFIX . /foor/bar))
-----------------------

> Basically, don't delegate to 'make' or 'ninja' or whatever, just build
> it.

I agree.  In the end `make` is only there for tracking dependencies,
which can be done easily in Guile I guess.  Although, there might be
performance problems at large scale, but I don't think I'm there yet ;-)

> That's way less portable than 'make' of course, but people that don't
> have 'cbuild' or don't want to learn 'cbuild' can still use the
> Makefile.

Across distros or OS?  For other distros, if the only requirements are
Guile and pkg-config then I would say that's quite portabled.  As for
other OS, I personnaly don't care about them.

> I noted that you are using #nil in some places.
> #nil (an amalgation of #false and the empty list ()) is mostly an
> implementation detail for Emacs Lisp support, and not something that
> needs to be used in pure Guile.  I would use '() instead; it's
> also more portable to other Schemes.

I did not know that '() was more portable!  I did find out that #nil has
some problem during syntaxes expansion though.  I will change this in my
style!

> There's also some potential reproducibility problems: in
> https://gitlab.com/oldiob/cbuild/-/blob/master/config.scm#L19,
> D1CACHE_LINE_SIZE is set based on the cache size where it was
> compiled, instead of the cache size where it is supposed to run on.

This is true.  Fortunately, on a good amount of architectures, L1 cache
is 64 bytes.  The only way I can see to fix this is to override the
configuration in `.config.scm` if compiling for another system.  It's
not possible to do this at runtime, because I use it for some struct
alignments of static variables.

-- 
Olivier Dion
Polymtl

Re: Newbie thoughts on Guile Hall + Guix

[Zelphir Kaltstahl]

On 2/6/22 17:35, Olivier Dion via General Guile related discussions wrote:
> On Sat, 05 Feb 2022, Christine Lemmer-Webber <cwebber@dustycloud.org> wrote:
>      
>> Anyway, just some thoughts.  Making Guile packages is already much less
>> intimidating now thanks to Hall's work.  Thank you for it!
> Here's my two cents.  As much as I like hall for pure Guile project,
> it's difficult to integrate extension libraries written in C.  I've also
> never been a fan of the autotools stuffs.
>
> I personnally end up writting something similar to hall for a project of
> mine using Guix records.  From a description like so:
> --------------------------------------------------------------------------------
> (project
>    (name "foo")
>    (version "1")
>    (configuration-file "config.scm")
>    (export-configuration
>      '(("include/config.h" . "FOO_CONFIG_H")
>        ("foo/config.scm"   . "foo config")))
>    (build-directory "./build")
>    (cppflags `(-Include ,(pkg-cflags-only-I '(guile-3.0))))
>    (guile-root "foo")
>    (guile-tests-root "tests")
>    (scripts
>      (list
>        (script
>          (name "foo")
>          (file "scripts/foo")
>          (install? #t))
>        (script
>          (name "debug")
>          (file "scripts/debug")
>          (install? #f))))
>    (c-modules
>      (list
>        (c-module
>          (name "foo")
>          (files '("core/*.c"))
>          (packages '(guile-3.0)))
>        (c-module
>          (name "bar")
>          (files '("bar/bar.c"))
>          (ldflags '(-lsomelib))
>          (packages '(some-other-lib)))))
> --------------------------------------------------------------------------------
> this description end up generating a `guix.scm`, `makefile`,
> `pre-install-env`, `foo/config.scm` and `include/config.h`.  Packaging
> is just a matter of shipping the `makefile` with the source codes.
What is this similar to Hall thing you have written, which generates the files 
from the code you gave?

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: Newbie thoughts on Guile Hall + Guix

[Olivier Dion via General Guile related discussions]

On Sun, 06 Feb 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:

>> is just a matter of shipping the `makefile` with the source codes.
> What is this similar to Hall thing you have written, which generates the files 
> from the code you gave?

I've setup a quick demo here: https://gitlab.com/oldiob/cbuild

Note that this is WIP and highly glued to my project and requirements.
But in the essence, I think it's doing a good job of offering a
descriptive way for defining a Guile+C project instead of managing
Makefiles and auto-tools stuffs.

-- 
Olivier Dion
Polymtl