Re: OCaml 5.0 and Guix

[pukkamustard]

Hi,

zimoun  writes:

>> Still very much WIP, but a way to give OCaml 5.0 with multicore support
>> a try.
>
> What is the status of OCaml bootstrapping for this new version?

Currently 5.0 is not bootstrapped with camlboot.

> Can we have a chain from camlboot -> OCaml 4.07 -> ?? -> v5.0?

That would be very nice! I don't know what the chain would look like. Do
we need to go trough all versions up to 4.14 to compile 5.0 or can 4.09
compile 5.0?

>From what I understand, currently only OCaml 4.07 is bootstrapped with
camlboot in Guix. I think Julien has done some work towards
bootstrapping 4.09 (https://github.com/Ekdohibs/camlboot/issues/59).

Also just read this comment
(https://github.com/Ekdohibs/camlboot/issues/1#issuecomment-452905768):

>  As I said on IRC (repeating it here for the record), the idea is to
> replace the interpreter written in OCaml by one written in C. That
> way, it is possible to use all the primitives of the runtime for free.
> I am still unsure as to what I should do for the parsing, since
> several options are possible. It probably needs more thinking.

Sounds like a job for Guile with some C interop and PEGs? :)

Cheers,
pukkamustard

Re: Proposal: A new build-system API

[Philip McGrath]

Hi,

On 9/26/22 14:07, Mája Tomášek wrote:

For example, there's currently no guarantee
that #:phases will contain list of functions and the error from that
will be cryptic. Contrast that with the service-configuration API. There
are field sanitizers that ensure that the configuration is propper and
easily one can introspect what the build system accepts and what are the
defaults.



This in particular is absolutely a valid point. It reminds me that there 
was some discussion a while ago about error checking/reporting generally 
in Guix in which I advocated for adopting contracts à la Racket. I'd 
started putting together a minimal implementation at the time, but I got 
diverted by other things: I'll try to get back to it.


-Philip

Re: Emacs integration for 'guix shell'

[Thompson, David]

On Mon, Sep 26, 2022 at 10:44 PM Maxim Cournoyer
 wrote:
>
> Hi,
>
> Olivier Dion via "Development of GNU Guix and the GNU System
> distribution."  writes:
>
> [...]
>
> > I have the following in my .dir-locals.el for my library libpatch.  The
> > idea is the same, but without direnv:
> >
> > ((nil
> >   . ((eval .
> >   (let ((root (locate-dominating-file
> >default-directory ".dir-locals.el")))
> > (when root
> >   (let ((real-root (directory-file-name (expand-file-name root
> > (setq-local geiser-guile-binary (concat real-root 
> > "/.geiser-guile"))
> > (setq-local projectile-project-compilation-cmd
> > (concat real-root "/.projectile-compile"))
> > (setq-local projectile-project-test-cmd
> > (concat real-root "/.projectile-test")
> >
>
> It seems to me it'd help everyone if Geiser should handle the above by
> itself.  It'd be cool to have the above functionality merged into Geiser
> itelf.  Just saying; thank you for sharing!

With Emacs 28 and new versions of Geiser (such as the one in Guix) I
highly recommend enabling per-project REPLs.  By setting
geiser-repl-per-project-p to 't', commands like M-x run-guile and C-c
C-a will open/switch to a REPL associated with the current project as
determined by project.el.  This is useful for when you are working on
multiple projects at once as it makes it harder to mix up REPLs, but
Geiser also automatically inserts the project root directory into
Guile's load path.  When combined with emacs-direnv, emacs-envrc,
emacs-buffer-env, or emacs-guix-shell, the Guile binary that Geiser
uses when launching a per-project REPL will be the one from the 'guix
shell' profile, and it will honor the
GUILE_LOAD_PATH/GUILE_LOAD_COMPILED_PATH settings.  So now, at long
last, my Geiser REPLs automatically use the proper build of Guile, it
can load the external libraries my project depends on, *and* it can
load my local project modules.  I'm quite happy with this setup.
Maybe I could write a blog post specifically about setting up a Guile
development environment with Guix and include all these details.

- Dave

Re: OCaml 5.0 and Guix

[zimoun]

Hi,

On Tue, 27 Sep 2022 at 06:57, pukkamustard  wrote:

>> What is the status of OCaml bootstrapping for this new version?
>
> Currently 5.0 is not bootstrapped with camlboot.

My question is: what does 5.0 require to compile?  Against which
previous OCaml version, is it possible to compile OCaml 5.0?


>> Can we have a chain from camlboot -> OCaml 4.07 -> ?? -> v5.0?
>
> That would be very nice! I don't know what the chain would look like. Do
> we need to go trough all versions up to 4.14 to compile 5.0 or can 4.09
> compile 5.0?

This is my question. :-)  I am not following closely enough the OCaml
development.  Well, I thought you knew what previous features is
required to compile next compiler. :-)


> From what I understand, currently only OCaml 4.07 is bootstrapped with
> camlboot in Guix. I think Julien has done some work towards
> bootstrapping 4.09 (https://github.com/Ekdohibs/camlboot/issues/59).

>From what I understand based on [1], yes only OCaml 4.07 is bootstrapped
with camlboot – this is currently used in Guix.  Somehow the resulting
OCaml 4.07 is considered as “trusted” and I am not sure there is some
plan to upgrade camlboot to support more recent OCaml; at least not in
the short term, maybe I have misunderstood.

1: 


Cheers,
simon

Re: git guix checkout automation for contributors

[zimoun]

Hi,

On Mon, 26 Sep 2022 at 22:37, Josselin Poiret  wrote:

>> When running “guix time-machine” (inferiors), all the machinery
>> “./bootstrap && ./configure --localstatevar=/var && make” is
>> transparently done.  We discussed that at the 10 Years event with
>> Josselin.
>
> Yes!  Although FTR none of bootstrap, configure or make are actually run
> when using time-machine, it's a totally different way of building :).

Yeah, I simplified since it is somehow a detail. :-) Interested reader
can read Josselin’s explanations [1] about the differences.

1: 

> The upshot is that we could even provide a flag like `guix time-machine
> --issue=N` that would provide the corresponding guix branch at
> https://git.guix-patches.cbaines.net/guix-patches/, and benefit from the
> built substitutes if there are.  It would need some more formal URL and
> discussion around this feature, but everything's in place for it to
> happen.

Well, I think it would be better to have another subcommand.  There is a
“guix review” draft somewhere but I do not currently find it.

It could be nice to see if it already just work using ’guix time-machine
-C channels.scm’ where the file channels.scm points to some QA.


>> Therefore, we could imagine something similar for helping people to
>> contribute:
>>
>>  1. use (test?) unmerged patches
>>  2. update and/or create new patches
>
> I think the second part would need a bit of work though, refer to Chris'
> mail [1] for what would need to be done (namely, making `git send-email`
> easier and refactoring the contribution guidelines).

I do not think git-send-email is the major roadblock here.  From what I
have seen two steps appear more difficult for infrequent contributors:

 a) commit message
 b) correct format-patch

About a) it could be nice to have a tool roughly checking.  For
instance, we have Emacs yasnippets for adding packages; we could imagine
a tool that check is the commit message respect some standards; at least
help to detect many common “mistakes“.

About b), from the feedback I get, people used to Merge/Pull Request do
not get at first why this step is required; since they usually git-pull
and send a request.  Then, many patches do not contain some base-commit
information because people miss the option --base; implicitly
self-contained with MR/PR.  Idem  the missing --reroll-count.


Cheers,
simon

Re: Emacs integration for 'guix shell'

[zimoun]

Hi,

Thanks for sharing.

On Mon, 26 Sep 2022 at 14:30, Olivier Dion via "Development of GNU Guix and the 
GNU System distribution."  wrote:

> dev-env:
> --8<---cut here---start->8---
> #!/bin/sh
> guix shell\
>  --pure   \
>  dyninst  \
>  gdb  \
>  git  \
>  guix \
>  lcov \
>  guile-quickcheck \
>  perf \
>  lttng-ust\
>  lttng-tools  \
>  --development libpatch   \
>  -- $@
> --8<---cut here---end--->8---
>
> Note the latest script where I have development packages for libpatch,
> but also other utitilies that are good to have for developer.

Well, I am not happy with my workflow but I have something similar for
some projects.  However, instead of this list, I have a “general” script
(named guixify) under ~/.local/bin/ which roughly reads:

--8<---cut here---start->8---
#!/bin/sh

guix time-machine -C channels.scm  \
 -- shell --pure   \
 -m manifest.scm   \
 -- $@
--8<---cut here---end--->8---

where manifest.scm and channels.scm are kept with the Git project.  I
prefer to pin a specific Guix revision to avoid bad surprises. :-) Well,
in a project, I just run:

guixify make   # run make using the Guix environment
guixify# enter in the environment


I thought to write an extension but I am not convinced by the interface
I want. :-)


Cheers,
simon

Re: Emacs integration for 'guix shell'

[Development of GNU Guix and the GNU System distribution.]

On Tue, 27 Sep 2022, zimoun  wrote:
>
> --8<---cut here---start->8---
> #!/bin/sh
>
> guix time-machine -C channels.scm  \
>  -- shell --pure   \
>  -m manifest.scm   \
>  -- $@
> --8<---cut here---end--->8---

How about:
--8<---cut here---start->8---
#!/bin/sh
 guix time-machine -C channels.scm\
 -- shell --pure  \
 --development $(basename $(pwd)) \
  -- $@
--8<---cut here---end--->8---

Of course you need to A) have a channels.scm in your project and B) have
your project directory named after the package's name in your channel. 

> where manifest.scm and channels.scm are kept with the Git project.  I
> prefer to pin a specific Guix revision to avoid bad surprises. :-) Well,
> in a project, I just run:
>
> guixify make   # run make using the Guix environment
> guixify# enter in the environment
>
>
> I thought to write an extension but I am not convinced by the interface
> I want. :-)

I was using channel too before!  It felt good to pin dependencies to a
version so it does not break while you're developing.  Howeverff, I felt
that the time-machine was taking enormous time everytime a push was made
to a channel.

My biggest usage of the channel was to have the definition of my package
before it was merged into Guix channel.  But this could also be used for
a development version that differs.

-- 
Olivier Dion
oldiob.dev

Re: GNU Guix on iPad2 (A1395)

[Timothy Sample]

Hi Jacob,

Jacob Hrbek  writes:

> The issue is that i can't get libusbmuxd (the daemon used to
> communicate with iDevices from Linux) to work on GNU Guix likely due
> to a configuration error in guix to perform the exploit and install
> guix, can someone help?
> https://github.com/libimobiledevice/ideviceinstaller/issues/147
>
> [...]
>
> It seems to be guix specific as the usbmuxd seems to work fine on
> other distros, but has issues on NixOS and Guix thus why asking here

I’ve run into this before.  Guix is currently on libusb 1.0.24, which
has a bug: .

Here’s the workaround I use:

;; Use this version of usbmuxd to access an iPhone.
;; Cf. .

(use-modules ((gnu packages libusb) #:select (libusb usbmuxd))
 (guix download)
 (guix packages)
 (ice-9 match))

(define libusb-1.0.25
  (package
(inherit libusb)
(version "1.0.25")
(source
 (origin
   (method url-fetch)
   (uri (string-append "https://github.com/libusb/libusb/releases";
   "/download/v1.0.25/libusb-1.0.25.tar.bz2"))
   (sha256
(base32 "0j88ym7afy4wj3x789zzxsr04asyjy0mw29gf31blzkrg8cyya4a"))

(package
  (inherit usbmuxd)
  (inputs (modify-inputs (package-inputs usbmuxd)
(replace "libusb" libusb-1.0.25

With this, I just use “guix shell -f” to launch a shell with access to
the fixed usbmuxd.

There are 1.5K packages that depend on libusb, so an update will have to
wait for the next core-updates cycle.

HTH!


-- Tim

Some concerns on the current situation on Go packaging

[Gabriel Arazas]

Hello! I'm a bit concerned about the current situation of packaging of 
Go applications in Guix.


Go modules also use semantic versioning [1] similarly to Rust packages. 
In Guix, some of the Rust packages are packaged with different versions 
[2]. This is nice (and tedious) as applications are more likely to work 
as intended.


However, there doesn't seem to be documented practice of packaging 
different versions for Go applications. The lack of such section from 
the manual also gives an additional impression unlike Rust packaging 
[2]. I don't know much examples that can be found committed in Guix repo 
but this makes adding Go applications to be more of a pain. I mean 
packaging Rust apps is also a pain as much as packaging Go apps (at 
least in my experience) but at least there are some explicit guidelines 
you can follow which is also present when exploring the code.


For example, I'm about to package gum [3] and it needs a different 
version of termenv (some commit after 0.11.0) compared to the packaged 
version in Guix (0.8.1). I'm very tempted to add a different package for 
it with a different version (which is thankfully easy to add).


In the long term, I'm more concerned about adding and maintaining of 
these applications. I thought I should point them out and hopefully get 
the community to reach to a consensus for Go packaging. Or is there 
already some initiatives (or a consensus or even some discussions) that 
I missed?


[1]: https://go.dev/doc/modules/version-numbers
[2]: 
https://guix.gnu.org/manual/devel/en/html_node/Rust-Crates.html#Rust-Crates

[3]: https://github.com/charmbracelet/gum

Re: Emacs integration for 'guix shell'

[zimoun]

Hi,

On Tue, 27 Sep 2022 at 08:06, Olivier Dion via "Development of GNU Guix and the 
GNU System distribution."  wrote:

> --8<---cut here---start->8---
> #!/bin/sh
>  guix time-machine -C channels.scm\
>  -- shell --pure  \
>  --development $(basename $(pwd)) \
>   -- $@
> --8<---cut here---end--->8---
>
> Of course you need to A) have a channels.scm in your project and B) have
> your project directory named after the package's name in your
> channel.

Personally, I prefer the ’-m manifest.scm’ approach.  Or maybe the ’-f
guix.scm’ approach.

Because I use ’guixify’ for more than just “developing“.  I mean
sometimes the manifest is just a list of packages, sometimes it contains
some development dependencies, sometimes some extra package definition,
etc.

Then this file manifest.scm or guix.scm is part of the project, i.e.,
included in the Git tree of the project.  I can re-use it for ‘guix pack
-f docker -m mnifest.scm’ and generate a Docker pack for colleagues.  I
can use it for ‘guix weather’ and know if the substitutes are there
before upgrading.  Etc.



> I was using channel too before!  It felt good to pin dependencies to a
> version so it does not break while you're developing.  Howeverff, I felt
> that the time-machine was taking enormous time everytime a push was made
> to a channel.

It is because you are not using a pinned channel and instead following
the HEAD of some channels.

Because if you store:

guix describe -f channels.scm > channels.scm

then the first time you can ‘guix time-machine -C channels.scm’ I agree
it can take some time (because a compute derivation).  But then, each
new invocation should be faster because it is cached.

However, indeed it is possible that ‘guix gc’ cleans up the temporary
profile; depending on how often you are working inside this project
environment.

To avoid this issue, sometime I create a profile inside the project
directory,

guix time-machine -C channels.scm \
 -- package -m manifest.scm   \
 -p profile

then sometime I run ‘guix package --search-paths -p profile’; using some
options of search-paths as prefix, suffix or exact.

Well, the point with this profile is to protect against garbage
collection; although it is not a bullet-proof protection.  I have never
really used ‘guix shell --root’ but it is probably what is needed.

All that to say that I am not totally happy with my workflow because I
do not know what interface I want. :-)


Cheers,
simon