Re: GNU Shepherd 0.10.2 released

[Dr. Arne Babenhauserheide]

Ludovic Courtès  writes:

> We are pleased to announce the GNU Shepherd version 0.10.2, a bug-fix
> release of the new 0.10.x series, representing 28 commits over 7 weeks.
>
> The 0.10.x series is a major overhaul towards 1.0, addressing shortcomings
> and providing new features that help comprehend system state.

>   https://www.gnu.org/software/shepherd/

The changes look really cool! Thank you all!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Caching test results separately?

[Dr. Arne Babenhauserheide]

Hi,

A large part of the build time is being consumed by tests … could we
separate those phases so a package whose tests succeeded once does not
have to be rebuild just because its package got garbage collected?

(⇒ keep the test result (boolean) longer than the build result)

Keeping just a boolean that says whether the tests for a given hash
succeeded could make that pretty cheap and it could avoid half the build
time for packages that got garbage collected before.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?

[Dr. Arne Babenhauserheide]

Maxime Devos  writes:

> Blake Shaw schreef op wo 29-06-2022 om 01:34 [+0700]:
>> Which brings up another thing I've been considering working on thats
>> been discussed in the Guix community: the need for click-to-edit
>> wiki, written in Guile. [...]
>
> I don't think ‘written in Guile’ has been discussed?
>
> Also, I don't see the point in writing our own wiki software in Guile
> when there's already plenty of Wiki software in existence with lots of
> tools for moderation, version control, backups, lots of testing, etc.
> Why not reuse pre-existing work instead of reinventing the wheel (likely
> poorly, at least at first)?

There are at least two good reason for re-inventing the wheel:

- learning the domain
- experimenting with how the ways to a good implementation differ in another 
language

If those were rejected out of hand, most existing wiki software would
have never been written.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Dr. Arne Babenhauserheide]

Leo Famulari  writes:

> On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote:
>> * Disable substitutes for relevent packages. Technically correct as
>>   license incompatibility is only triggered on transmission of binary,
>>   though maybe missing something about the spirit of the GPL.
>
> Maybe, but did anyone with standing ever take action regarding these
> licensing incompatibilities?
>
> Perhaps, looking at these issues too closely is also missing something
> about the spirit of the GPL.

It just needs one person. Also see this weeks newsletter from Cory
Doctorov on the lawsuit against Vizio. It might soon only take one user.

Best get licensing problems fixed sooner than later. GPLv2-only is a
problem quickly getting closer.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Regarding copyright assignment to FSF

[Dr. Arne Babenhauserheide]

Michael Banck  writes:

> I don't mind that, but I also think the Hurd is not a tactical FSF asset
> anymore that needs to be kept under tight control. The FSF has enough
> copyright in the Hurd that it can enforce it whenever it likes, even if
> other people's copyrighted code (as is already the case with the pfinet

I wouldn’t be so sure about that.

1. Without copyright assignment of all code involved, enforcement
   becomes much harder.
2. The Hurt still provides capabilities other OS’es don’t — while
   maintaining POSIX compatibility. We’ve seen audacity basically
   being taken over by a company in the past months, so the danger of
   losing Hurd to proprietarization rather got bigger than smaller.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Regarding copyright assignment to FSF

[Dr. Arne Babenhauserheide]

Maxime Devos  writes:

> Upgrading the GPLv2-only code might be dificult if multiple people hold
> the copyright, so for the GPLv2-only code, it might be a good idea to still
> require copyright assignment.

When we did it for Mercurial, going from GPLv2 only to or later took
years and a *lot* of work. That’s why I consider copyright assignment to
the FSF as a good idea. They still get restricted to only use that to
further Free Software (if they violate that, the assignment loses the
reliablility that they need).

>> Even if you do keep it yourself, it makes it more difficult for anyone to 
>> enforce
>> the GPL for that project.
>
> A fair point, though I don't know how accurate that is.

From what I read, it’s the most important point, because the first
answer the other sides lawyers always give is „you’re not authorized by
*all* authors to enforce the GPL, so you lose.“

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Guile-zstd 0.1.1 released

[Dr. Arne Babenhauserheide]

Hi Ludo,

that’s pretty cool! Thank you!

Looking at the readme I get the feeling that two little helpers could be
useful:

   (call-with-zstd-output-file "compressed.zstd"
(lambda (port)
  (define data
;; Read the input file in memory.
(call-with-input-file "input-file.txt"
  get-bytevector-all))

  ;; Write data to PORT.
  (put-bytevector port data)))

  (call-with-zstd-input-file "compressed.zst"
(lambda (port)
  ;; Read decompressed data from PORT.
  ...))

Potentially with streaming added (if that’s possible from the library):

   (call-with-zstd-output-file "compressed.zstd"
(lambda (outport)
  (call-with-input-file "input-file.txt"
(lambda (inport)
  (let loop ((data (get-bytevector-some inport)))
(when (not (eof-object? data))
  (put-bytevector outport data)
  (loop (get-bytevector-some inport

Also maybe a minimal representation of the commandline-interface:

   (zstd-compress "input-file.txt" #:output "compressed.zst")
   (zstd-decompress "compressed.zstd" #:output "cleartext-file.zst")

Best wishes,
Arne

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> I’m pleased to announce the first release of Guile-zstd:
>
> Oops, a file was missing from the repo, so here’s a brand new release!
>
>   git clone https://notabug.org/guile-zstd/guile-zstd
>   cd guile-zstd
>   git checkout v0.1.1  # or f853c8eb81088f8fbf33d38e62cddea9a4984180
>   git tag -v v0.1.1
>
> Ludo’.


-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [BLOG] A "Hello World" VM running the Hurd!

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> We have just published a new blog post---a follow-up, in a way to last
> week's April 1 post---about some real achievement: Using Guix we have
> cross-built a VM image for the Hurd.  Read more...
>
> 
> https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/

Wow, that’s awesome!

Thank you!

Best wishes,
Arne

PS: typo: fine-grain → fine-grained
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Arne Babenhauserheide]

Hi zimoun,

zimoun  writes:
> Konrad's example. So, nothing new on the table; except you are
> starting to throw "feelings" with the "traumatic change" words.

I do not see this as feelings, but as strategy. That’s what the article
is about: Many small breakages add up, and repeated changes to
best-practices also add up.

The volatile software article describes that software differs in how
much work it is to keep using it. The traumatic change article discusses
one aspect why people stop using projects.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Arne Babenhauserheide]

zimoun  writes:
> First, have you read the proposal?

Yes.

> Or are you (maybe a bit) "overreacting" about the backward compatibility?

I don’t think so. I am definitely reacting strongly, but that’s because
breakages in Guix have already cost me the evenings of several weeks
this year.

But before I write anything more, I’d like to ask you to take a step
back to breathe.

We’re discussing a change in software. We disagree on the way forward,
but I’m not attacking you as a person, and I hope it does not feel that
way to you.

If it does: This is not my intention. Please take a moment to sigh
deeply, shake your head, relax, and smile — because that actually helps.
It’s what I try to do when discussions get vexing.

I am grateful that you’re taking up improvements in Guix, and there are
situations where viewpoints are different. That is OK.

>> This is taking this a bit too easy. If I can no longer pull, because
>> that breaks my Emacs or Gnome, then Guix is broken for me: I can no
>> longer update my system without first adjusting my config.
>
> So you expect that we would push a patch changing "guix environment"
> and in the same time break "guix pull, isn't it?

No, this is an example which shows that being able to roll back does not
mean that there is no problem with breaking the way forward. Using only
old versions is often not an option. Just imagine running audio software
from 5 years ago on a system that only provides pulseaudio (or whatever
will come after it). Imagine using an old KDE DCOP-based automation
workflow on a dbus-system. You need to update the libraries you use to
get it working at all.

>> > Hum? I am not convinced that the cost would be high... Because 1. the
>> > number of people using Guix is not so high (yet!), so 2. I am almost
>> > sure we can name the people using "guix environment" in scripts ;-).
>>
>> I’m not so sure. Guix is already used in scientific workflows, and there
>> is existing third-party documentation about using `guix environment`.
>
> Please point me where.
> It will save me time instead of reinventing the wheel.

It was mentioned on this list.

For the scientific workflows, see https://hpc.guix.info/

>> And can you name the people using `guix environment` by searching
>> backwards in their bash history?
>
> So what would break?
> Your workflow: spending 5 minutes to read the warning message and then 
> pressing:
> C-a GUIX_ENVIRONMENT_DEPRACATED=1 guix environment 
> 
>
> (unfair and bitter; sorry!)

I’m sorry that this makes you bitter. This is not my intention.

I’ll answer without bitterness: The original environment does not spawn
instantly. It takes many minutes until it is ready. If I then have to go
back, find the warning (it’s likely that I’d miss it, because these are
things that work, and suddenly they break, which I’m likely to only
figure out when the followup steps don’t work) and run it again, that
often means that I’m out of time to do what I actually wanted to do.

Despite that: Yes, this is a viable way. It is one of the less painful
ones. Maybe avoid calling it "DEPRECATED" and instead give it a more
descriptive name that does not imply that it will go away.

Mercurial uses HGPLAIN=1 to say "I want the version which will never
change established API". Best practice is to always use that in scripts
— and that is a stable best practice. But this is also slow to receive
new features.

If the old way to use guix environment is intended to actually be legacy
only, then it could be a way forward to also provide
GUIX_ENVIRONMENT_STABLE=1 which gives an API that is guaranteed to never
change the meaning of options again *after the change that’s been
started to brew in 2017*.

That would be a purely append-only API then, and while it would break
once, it would prevent such changes for the future.

For PR it might be possible to state that with this change, guix
environment as a tool reaches version 0.99 (to be updated to 1.0 after
sufficient testing).

>> > And 3. the time to figure out what changed is really low -- especially
>> > with warnings and hints -- and "guix environment foo -- make" would
>> > return an error because of dependencies missing.
>>
>> It took me days to figure out the exact guix environment invocation that
>> allows me to build the tools for a paper I’m still working on. If that
>> breaks, that causes massive anxiety, because I then don’t know whether
>> I’ll find the time to fix it before I run into deadlines.
>
> Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 at the top of your script?

Yes, at every script. And remember to add it to every command I still
have in history.

>> > Other said, I do not see myself use-cases where the scripts using
>> > "guix environment" need to be robust for time-travelling -- the same
>> > script used with current, past and future Guix versions -- because as
>> > it was said elsewhere: "environment" can be seen like "temporary
>> > profile". And temporary means... well temporary. ;-)
>>
>> The 

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Arne Babenhauserheide]

Hi zimoun,

zimoun  writes:

>>  Should Guix be volatile software?
>>  http://stevelosh.com/blog/2012/04/volatile-software/
>
> Guix is not a volatile software and will never be. Because it is
> rooted in time-travelling.
> The tools "guix pull --commit=", "guix  --manifest=", "guix
> time-machine" or the "--roll-back" avoid to break what is currently
> working.

This is taking this a bit too easy. If I can no longer pull, because
that breaks my Emacs or Gnome, then Guix is broken for me: I can no
longer update my system without first adjusting my config.

> Number of people Time it takes each person
> using that part of   X   to figure out what changed
> the program  and how to fix it
>
> Hum? I am not convinced that the cost would be high... Because 1. the
> number of people using Guix is not so high (yet!), so 2. I am almost
> sure we can name the people using "guix environment" in scripts ;-).

I’m not so sure. Guix is already used in scientific workflows, and there
is existing third-party documentation about using `guix environment`.

And can you name the people using `guix environment` by searching
backwards in their bash history?

> And 3. the time to figure out what changed is really low -- especially
> with warnings and hints -- and "guix environment foo -- make" would
> return an error because of dependencies missing.

It took me days to figure out the exact guix environment invocation that
allows me to build the tools for a paper I’m still working on. If that
breaks, that causes massive anxiety, because I then don’t know whether
I’ll find the time to fix it before I run into deadlines.

> Other said, I do not see myself use-cases where the scripts using
> "guix environment" need to be robust for time-travelling -- the same
> script used with current, past and future Guix versions -- because as
> it was said elsewhere: "environment" can be seen like "temporary
> profile". And temporary means... well temporary. ;-)

The same script must always work with future versions. Otherwise the
software is volatile.

You don’t need to be able to go back in time, but the path forward must
be without breakage.

> Then, the section "The Tradeoff" advices "from newmodule import
> new_foo as foo" and IMO it is what the plan proposes with the variable
> GUIX_ENVIRONMENT_DEPRECATED (tricky point #4).

No, that’s the opposite: from newmodule import new_foo as foo means,
that you allow users to define an environment variable called
`GUIX_ENVIRONMENT_MODERN`.

> Last, "volatile" vs "stable" is mitigated by "The future of 'guix
> environment'" [1] which really predates the 1.0. ;-)

Yepp, but we’re after 1.0 now. This might have been a blocker for 1.0,
but it wasn’t.

>> Also: Software developers should avoid traumatic changes
>>   https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html
>
> "Traumatic changes"? Maybe a bit extreme for the change we are talking 
> about...

I don’t think so. There’s the strong version where it’s obvious: It
leads people to leave a project instantly.

There’s the weaker version which is less obvious: That’s where people
who invested efford to follow best practices suddenly find their project
to be written in legacy style, because the best practices changed.

> Well, at the end, what is explicitly your personal opinion?
>  a. Change the behaviour of "guix environment" using the proposed plan?
> or
>  b. Add a new command? Which one? "guix shell", "guix env" or "guix
> "?

I would opt for b. And then for changing guix to give the most common
commands when called without argument (as `guix`) — excluding
guix environment.

That would not avoid the slow version of traumatic changes, but if
guix environment would keep working and both guix env/guix shell/… and
guix environment used the same backend (just with different options),
then they would be minimized, because guix environment would not become
a second-class citizen.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Arne Babenhauserheide]

Konrad Hinsen  writes:

> Hi Simon,
>
>> Maybe I miss a point. It is not: "watch out, this will do something
>> else in the future" but "watch out, this was doing something else in
>> the past and the change happened the  in ".
>
> Concrete example: I am writing a tutorial about using Guix for
> reproducible research. It shows several uses of "guix environment", some
> of them without '–add-hoc' or '–inputs-of'. I know my examples will
> cease to work in a few months. What am I supposed to do about this?

This is the point where we need to ask ourselves:

 Should Guix be volatile software?
 http://stevelosh.com/blog/2012/04/volatile-software/

Also: Software developers should avoid traumatic changes
  https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

guix import crate wraps #:cargo-inputs twice

[Arne Babenhauserheide]

Hi,

When using guix import crate flamer, it generates a pattern like

  (arguments
`((#:cargo-inputs
   (("rust-flame" ,rust-flame)
("rust-quote" ,rust-quote)
("rust-syn" ,rust-syn)

the correct pattern would however be 

  (arguments
`(#:cargo-inputs
   (("rust-flame" ,rust-flame)
("rust-quote" ,rust-quote)
("rust-syn" ,rust-syn

The same is true for cargo-development-inputs.

I’m currently fixing that by hand, but a fix would be really useful.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Shepherd 0.6.1 released

[Arne Babenhauserheide]

Hi Nala Ginrut,

Nala Ginrut  writes:
> I saw it describes that "intended for use on GNU/Hurd", is it still
> workable on GNU/Linux?

Since that’s where it’s mainly used: definitely yes.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Shepherd 0.6.1 released

[Arne Babenhauserheide]

Ludovic Courtès  writes:

> We are pleased to announce the GNU Shepherd version 0.6.1, a bug-fix
> release.

Congrats!

>   interface.  The GNU Shepherd may also be used by unprivileged users to
>   manage per-user daemons (e.g., tor, privoxy, mcron, etc.)

Is there a tutorial about using shepherd for per-user daemons? I don’t
really know how to start with it, but I would very much like to
move services from "just start this in ~/.bashrc" to shepherd.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [bootstrappable] Re: GNU Mes 0.19 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:
> `make-mesboot0' is the initial build of GNU make.  You can read the full
> Guix bootstrap build recipe here:
>
> 
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/commencement.scm?h=core-updates

Ah, nice!

Again: Thank you very much!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [bootstrappable] Re: GNU Mes 0.19 released

[Arne Babenhauserheide]

Ricardo Wurmus  writes:

> Hi Arne,
>
>> Do you have a document showing the bootstrap path — ideally in graph
>> form, i.e. with plantuml activity diagram?
>> http://plantuml.com/activity-diagram-legacy
>
> You can see the current bootstrap path here:
>
> https://bootstrappable.org/projects/mes.html
>
> This is without the path from virtually nothing to mes + mescc tools,
> i.e. mes and mescc tools currently are bootstrap binaries here.

This is really cool! Thank you!

>>>  - use Gash to remove bash, coreutils, grep, sed, tar from the Guix
>>>bootstrap binaries
>>
>> Is this about configure+make?
>
> You can see in the graph that “bootstrap-binaries” is a collection of
> statically linked binaries including tar, gzip, patch, coreutils, etc.
> Most if not all of these could be removed with Gash.

I do not see gmake in there. Is that covered by one of them, or can it
be built with them?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Mes 0.19 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
> a GNU/Linux system without binary GNU toolchain or equivalent)

That’s awesome!

> This release introduces strings as byte-array, hash-tables and native
> structs.  While that does increase the footprint somewhat, it fixes
> our performance issue; tinycc is now compiled in ~8min (WAS: ~1h30).

Wow! I did not expect such a huge difference.

> Next targets:
>
>  - translate mes.c into unsnarfed mes.M2
>  - use Gash to remove bash, coreutils, grep, sed, tar from the Guix
>bootstrap binaries

Is this about configure+make?

>  - bootstrap gcc-3.x or 4.x directly, drop initial gcc-2.95.3 target?

Do you have a document showing the bootstrap path — ideally in graph
form, i.e. with plantuml activity diagram?
http://plantuml.com/activity-diagram-legacy

>  - Debian?
- Gentoo?

>  - ARM, the Hurd?

The Hurd would be nice!

Thank you for your great work!

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [bootstrappable] Re: GNU Mes 0.18 released

[Arne Babenhauserheide]

Orians, Jeremiah (DTMB)  writes:

>> What is M2 Planet?
> My project https://github.com/oriansj/M2-Planet
>
> That is both written in Assembly: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/cc_x86.s (That can 
> be bootstrapped from a hex0 monitor)
> And in C (That it can self-host from)
> That way you can build it with any C compiler you like or bootstrap it from 
> stage0 https://savannah.nongnu.org/projects/stage0/

Nice! I’m happy to see you two working together on this!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Mes 0.18 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> Mes is now bringing a Reduced Binary Seed bootstrap to GuixSD; the
> size of bootstrap binaries has been halved and no regular toolchain
> binaries are used as binary seeds (i686-linux and x86_64-linux only).
>
> MesCC has been refactored to use an abstracted assembly language and
> can now (cross-)build x86_64 binaries.

That’s awesome! Thank you!

What is M2 Planet?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: GNU Mes 0.17 released [alpha]

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> We are delighted to announce the release of GNU Mes 0.17, representing
> 64 commits over 6 weeks.
>
> Mes is now an official GNU package and we have bootstrapped gcc-4.7.4
> for x86-linux with a reduced binary seed (i.e., without regular toolchain).

You are awesome! Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Mes 0.13 released

[Arne Babenhauserheide]

Hi Jan,

Jan Nieuwenhuizen  writes:
> I am pleased to announce the release of Mes 0.13, representing 45
> commits over 3 weeks.  MesCC can now compile a functional tcc when
> running on Mes (in ~1h45') or on Guile (in ~3min).

That is absolutely awesome! My deepest, deepest respekt for your work!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Mes 0.11 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> I am pleased to announce the release of Mes 0.11, representing 16
> commits over 10 weeks.  MesCC now compiles a less heavily patched
> TinyCC into a mes-tcc that in turn passes 41/69 of mescc's C tests.
>
> When mes-tcc passes all 69 tests, this almost-full-source-bootstrapped
> version of TinyCC should be able to compile itself.  An unpatched, GNU
> Gcc-compiled tcc is known to compile GNU Gcc.

Nice!

Thank you for tackling the bootstrapping!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Mes 0.10 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen <jann...@gnu.org> writes:
> Arne Babenhauserheide writes:
>>> For details, see
>>>
>>> [8] https://gitlab.com/janneke/tinycc
>>>
>>> TinyCC uses (imho) unnecessarily complex C constructs.  Therefore it is 
>>> (imho)
>>> not too well suited as a bootstrap dependency, at least not in an
>>> unpatched state.
>> It still works with GCC, right?
> Yes.  Luckily, GCC can still handle simple C constructs ;-)
>
> When running i686-unknown-linux-tcc and mes-tcc to compile a trivial C
> program, the output produced by `lotsa debug printing' from both
> compiler runs is now identical, as is the resulting ELF binary.

That’s awesome!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Mes 0.10 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> I am pleased to announce the release of Mes 0.10, representing 82
> commits over 6 weeks.  Mescc now compiles a bootstrappable-modified
> TinyCC into a mes-tcc that in turn can successfully compile a trivial
> C program.

Nice! How big are your changes to TinyCC?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Mes 0.9 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> I am pleased to announce the release of Mes 0.9, representing 107
> commits over 5 weeks.

Congrats!

> Mescc now compiles to a surprisingly readable
> stage0 M1 macro assembler output format.

Nice! Can you give a short example of that format?

> Also, mescc can now compile a
> modified TinyCC into a running [mostly segfaulting] executable.

Very cool!

Thank you for your great work!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Mes 0.5 released

[Arne Babenhauserheide]

Jan Nieuwenhuizen writes:

> I am pleased to announce the release of Mes 0.5, representing 249
> commits over 4 months.  Mes is now self-hosting, or rather it features
> a mutual self-hosting Scheme interpreter and C compiler: mes.c and
> mescc; a Nyacc-based C compiler backend that also works separately
> with Guile.

Wow! Congratulation on full bootstrapping of mes!

So we can now build mes.c with mescc driven by Guile and then use mes to
run mescc again to build mes.c?

Best wishes,
Arne

Re: guix is the guildhall that we always wanted!

[Arne Babenhauserheide]

Andy Wingo  writes:

> On Thu 16 Mar 2017 20:26, Amirouche Boubekki  writes:
>
>>> So!  My proposal for this new "guildhall" would be:
>>>
>>> 1. a web service
>>>
>>
>> What would be the cli interface associated with that web service?
>> Some thing like the following will do:
>>
>>   $ guildhall register
>
> So I think we could re-use the "guild" command; see the original
> "guildhall" on how this is done.  I dunno though, maybe that's not
> desireable.  If it's not, maybe guildhall isn't the right name?  I don't
> know.

I’d think

$ guild register # register with the guild

What I long wanted to do:

$ guild hall # show and change the defined package sources

Adding guild sub-commands within guildhall is pretty easy. See
https://github.com/ArneBab/guildhall/commit/3c9b78a91088cc66ecfc9ca7b62cf2a1d8f90781

I’d assume it’s similarly easy when starting fresh.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: FOSDEM 2016 slides

[Arne Babenhauserheide]

Alex Sassmannshausen writes:

>>
>> These are great — and I hope I can use guile-config.
>
> Thank you! And great you want to use it — I'll try to get a proper
> release ASAP then :-)

Cool, thank you!

> I'd definitely be really keen in getting a config file writer/reader
> working using wisp too.  The more I think about it, the more I like the
> idea!

If it works with scheme code, it should directly work with Wisp, too —
thanks to the language integration in Guile.

That said, I’d like to see how it looks when written in Wisp. Looking
forward to a release!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: FOSDEM 2016 slides

[Arne Babenhauserheide]

Hi Alex,

> And my slides from the FOSDEM devroom (for my Guile Config
> presentation), for anyone interested (copying in Guile User as it isn't
> Guix related…):
>
> http://alex.pompo.co/presentations/fosdem-16-conf.html

These are great — and I hope I can use guile-config. I tend to write
quick commandline tools which sometimes begin to grow wild. Elegant
commandline parsing is still one of the things with which I had problems
in Guile, and I hope that guile-config can fix that. It already shows
what can be gained in expressivity by macros.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Add Package Mercurial

[Arne Babenhauserheide]

Hi,

I adapted the patch: Disabled tests and added a FIXME note which links
to the required nose testing framework.

I hope it’s fit for getting into guix, now.
(it’s attached and inline)

Best wishes,
Arne

$ hg export --git tip
# HG changeset patch
# User Arne Babenhauserheide arne.babenhauserhe...@kit.edu
# Date 1381502708 -7200
#  Fri Oct 11 16:45:08 2013 +0200
# Node ID 4e60285e8bf65478dccd96d8304f7c026a364e18
# Parent  a34f735e8b79e33072e37f2d1a8a750b0fb24a40
gnu: Add mercurial.

* gnu/packages/version-control.scm (mercurial): New variable.

diff --git a/gnu/packages/version-control.scm
b/gnu/packages/version-control.scm
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -180,6 +180,36 @@
(license gpl2)
(home-page http://git-scm.com/;)))

+
+(define-public mercurial
+  (package
+(name mercurial)
+(version 2.7.1)
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append http://mercurial.selenic.com/release/mercurial-;
+  version .tar.gz))
+  (sha256
+   (base32
+121m8f7vmipmdg00cnzdz2rjkgydh28mwfirqkrbs5fv089vywl4
+(build-system python-build-system)
+(arguments
+ `(;; Restrict to python2, as python 3 would require
+   ;; the argument --c2to3
+   #:python ,python-2
+   ;; FIXME: Disabled tests because they require the nose unit
+   ;; testing framework: https://nose.readthedocs.org/en/latest/
+   #:tests? #f))
+(home-page http://mercurial.selenic.com;)
+(synopsis Decentralized version control system)
+(description
+ Mercurial is a free, distributed source control management tool.
+It efficiently handles projects of any size
+and offers an easy and intuitive interface.)
+(license gpl2+)))
+
+
 (define-public subversion
   (package
 (name subversion)


Am 02.10.2013 00:04, schrieb Ludovic Courtès:
 Hi,
 
 Arne Babenhauserheide (IMK) arne.babenhauserhe...@kit.edu skribis:
 
 I attached an adapted version of the patch reusing the solution from Bazaar.
 
 Thanks.  I had to add #:tests? #f so that it would build (because
 ‘python setup.py test’ is not supported):
 

# HG changeset patch
# User Arne Babenhauserheide arne.babenhauserhe...@kit.edu
# Date 1381502708 -7200
#  Fri Oct 11 16:45:08 2013 +0200
# Node ID 4e60285e8bf65478dccd96d8304f7c026a364e18
# Parent  a34f735e8b79e33072e37f2d1a8a750b0fb24a40
gnu: Add mercurial.

* gnu/packages/version-control.scm (mercurial): New variable.

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -180,6 +180,36 @@
(license gpl2)
(home-page http://git-scm.com/;)))
 
+
+(define-public mercurial
+  (package
+(name mercurial)
+(version 2.7.1)
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append http://mercurial.selenic.com/release/mercurial-;
+  version .tar.gz))
+  (sha256
+   (base32
+121m8f7vmipmdg00cnzdz2rjkgydh28mwfirqkrbs5fv089vywl4
+(build-system python-build-system)
+(arguments
+ `(;; Restrict to python2, as python 3 would require
+   ;; the argument --c2to3
+   #:python ,python-2
+   ;; FIXME: Disabled tests because they require the nose unit
+   ;; testing framework: https://nose.readthedocs.org/en/latest/
+   #:tests? #f))
+(home-page http://mercurial.selenic.com;)
+(synopsis Decentralized version control system)
+(description
+ Mercurial is a free, distributed source control management tool.
+It efficiently handles projects of any size
+and offers an easy and intuitive interface.)
+(license gpl2+)))
+
+
 (define-public subversion
   (package
 (name subversion)


signature.asc
Description: OpenPGP digital signature

Add Package Mercurial

[Arne Babenhauserheide (IMK)]

Hi,

I include the patch and file for adding Mercurial to version-tracking.

I cannot test it right now, because the package requires a new version
of guix, but guix pull does not work. But since I’ll be away till
tuesday, I want to get it out of my
unfinished-business-need-to-care-for-that list.

The patch is in git diff format with commit message, so I hope you can
apply it.

Best wishes,
Arne
-- 
Doktorand
Gruppe: GHG

Raum: 435/410
Tel.: +49 721 608-22885
arne.babenhauserhe...@kit.edu

Karlsruher Institut für Technologie
IMK-ASF
Postfach 36 40
76021 Karlsruhe


0xA70DA09E.asc
Description: application/pgp-keys
# HG changeset patch
# User Arne Babenhauserheide arne.babenhauserhe...@kit.edu
# Date 1380276186 -7200
#  Fri Sep 27 12:03:06 2013 +0200
# Node ID a034a79b8daff0be283971de80116dcb594ac2f4
# Parent  dc6b27bf766ba543f64a38fab93ea9bcee6eb165
gnu: Add mercurial.

* gnu/packages/version-control.scm (mercurial): New variable.

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -112,6 +112,27 @@
(license gpl2)
(home-page http://git-scm.com/;)))
 
+(define-public mercurial
+  (package
+(name mercurial)
+(version 2.7.1)
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append http://mercurial.selenic.com/release/mercurial-; 
+  version .tar.gz))
+  (sha256
+   (base32
+121m8f7vmipmdg00cnzdz2rjkgydh28mwfirqkrbs5fv089vywl4
+(build-system python-build-system)
+(home-page http://mercurial.selenic.com;)
+(synopsis Decentralized version control system)
+(description
+ Mercurial is a free, distributed source control management tool.
+It efficiently handles projects of any size
+and offers an easy and intuitive interface.)
+(license gpl2+)))
+
 (define-public subversion
   (package
 (name subversion)
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2013 Nikita Karetnikov nik...@karetnikov.org
;;; Copyright © 2013 Cyril Roelandt tipec...@gmail.com
;;; Copyright © 2013 Ludovic Courtès l...@gnu.org
;;; Copyright © 2013 Andreas Enge andr...@enge.fr
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see http://www.gnu.org/licenses/.

(define-module (gnu packages version-control)
  #:use-module ((guix licenses) #:select (asl2.0 gpl1+ gpl2 gpl2+ gpl3+))
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system python)
  #:use-module (guix build utils)
  #:use-module ((gnu packages gettext)
#:renamer (symbol-prefix-proc 'guix:))
  #:use-module (gnu packages apr)
  #:use-module (gnu packages curl)
  #:use-module (gnu packages nano)
  #:use-module (gnu packages openssl)
  #:use-module (gnu packages perl)
  #:use-module (gnu packages python)
  #:use-module (gnu packages sqlite)
  #:use-module (gnu packages system)
  #:use-module (gnu packages xml)
  #:use-module (gnu packages emacs)
  #:use-module (gnu packages compression))

(define-public bazaar
  (package
(name bazaar)
(version 2.5.1)
(source
 (origin
  (method url-fetch)
  (uri (string-append https://launchpad.net/bzr/2.5/; version
  /+download/bzr- version .tar.gz))
  (sha256
   (base32
10krjbzia2avn09p0cdlbx2wya0r5v11w5ymvyl72af5dkx4cwwn
(build-system python-build-system)
(inputs
 ;; Note: 'tools/packaging/lp-upload-release' and 'tools/weavemerge.sh'
 ;; require Zsh.
 `((gettext ,guix:gettext)))
(arguments
 `(#:tests? #f ; no test target
   #:python ,python-2)) ; Python 3 apparently not yet supported, see
; https://answers.launchpad.net/bzr/+question/229048
(home-page https://gnu.org/software/bazaar;)
(synopsis Decentralized revision control system)
(description
 GNU Bazaar is a distributed version control system, which supports both
central version control and distributed version control.  Developers can
organize their workspace in whichever way they want.  It is possible to work
from a command line or use a GUI application.)
(license gpl2+)))

(define-public git
  (package
   (name git)
   (version 1.8.4)
   (source (origin
(method url-fetch)
(uri (string-append http

Add Mercurial to version-control.scm

[Arne Babenhauserheide]

Hi,

Here’s a patch to add Mercurial as package:


--- /usr/local/share/guile/site/2.0/gnu/packages/version-control.scm
2013-09-04 16:27:21.495618474 +0200
+++ /home/arne/version-control.scm  2013-09-06 11:13:57.080871243 +0200
@@ -64,6 +64,26 @@
 from a command line or use a GUI application.)
 (license gpl2+)))
 
+(define-public mercurial
+  (package
+(name mercurial)
+(version 2.7.1)
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append http://mercurial.selenic.com/release/mercurial-; 
version .tar.gz))
+  (sha256
+   (base32
+121m8f7vmipmdg00cnzdz2rjkgydh28mwfirqkrbs5fv089vywl4
+(build-system python-build-system)
+(home-page http://mercurial.selenic.com;)
+(synopsis Decentralized version control system)
+(description
+ Mercurial is a free, distributed source control management tool. 
+It efficiently handles projects of any size and offers an easy and intuitive 
interface.)
+(license gpl2+)))
+
+
 (define-public subversion
   (package
 (name subversion)


I put Mercurial between bazaar and subversion to keep alphabetic
ordering. Later items might not be ordered alphabetically, but that’s
out of my responsibility :)


Best wishes,
Arne