Re: GSoC NPM

[Catonano]

Hi Jelle,

I tried to import jquery with the last version of your code

This is the resulting expression (they are a lot, this is just one)

(define-public node-jquery
  (package
(name "node-jquery")
(version "3.1.0")
(source
  (origin
(method url-fetch)
(uri "
https://github.com/jquery/jquery/archive/3.1.0/jquery-3.1.0.tar.gz";)
(sha256
  (base32
"05jcaa0xg041hpq3xdswf45jbkm6shvinjm3scawwjqqlrc39xca"
(build-system node-build-system)
(propagated-inputs `())
(native-inputs `())
(synopsis
  "JavaScript library for DOM operations")
(description
  "JavaScript library for DOM operations")
(home-page "https://jquery.com";)
(license expat)))


As you can see, there are no native-inputs

I understand that dev-dependencies (as on line 467) is used by
make-npm-sexp to populate native-inputs, so in the terminal I inspected
dev-dependencies  expecting to find it empty and I was wrong, it was
correctly populated

Like this

("node-native-promise-only"
 "node-insight"
 "node-strip-json-comments"
 "node-cross-spawn"
 "node-q"
 "node-grunt-git-authors"
 "node-grunt-contrib-watch"
 "node-eslint-config-jquery"
 "node-husky"
 "node-load-grunt-tasks"
 "node-qunitjs"
 "node-sinon"
 "node-commitplease"
 "node-grunt-eslint"
 "node-sizzle"
 "node-grunt-babel"
 "node-jsdom"
 "node-babel-preset-es2015"
 "node-grunt-npmcopy"
 "node-grunt-contrib-uglify"
 "node-gzip-js"
 "node-qunit-assert-step"
 "node-requirejs"
 "node-grunt"
 "node-promises-aplus-tests"
 "node-grunt-compare-size"
 "node-grunt-jsonlint"
 "node-testswarm"
 "node-core-js"
 "node-grunt-cli"
 "node-grunt-newer")

So now I can't explain why native-inputs is empty.

Maybe I should run this a few times to ensure that the result is always the
same

But this could be worth your attention.

Re: [PATCH] gnu: link-grammar: New module.

[Catonano]

2016-10-23 16:54 GMT+02:00 Amirouche Boubekki 
:

>
>
just a typo: in the synopsys: "... several langageS"

Re: Please review: documentation for python build system

[Catonano]

2016-11-15 9:24 GMT+01:00 Chris Marusich :

> Hi Hartmut!
>
> Thank you very much for the documentation.  It is quite clear, and it
> helps clarify the background and intent of the new python build system.
> My comments below are primarily grammatical or stylistic.  I hope you
> find my feedback helpful.
>
> Hartmut Goebel  writes:
>
> > In Python there are different ways to install packages: distutils,
> > setuptools, easy_install and pip.  All of these are sharing the file
> > setup.py,
>
> I suggest changing "All of these are sharing the file setup.py" to "All
> of these use a file named setup.py".
>

For what it matters, I prefer the original wording.
I think it's clearer

I'm ok with the other suggestions of yours

how to write services (was: Re: Teams)

[catonano]

Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
> 
> I found the documentation to be a bit confusing (understandably, as
> its new), but once the workflow snapped together its been amazing to
> see how easy it is to create new services. 

This is something I'm specifically interested in

In fact, I wrote this toot that got several boosts and likes but NO
answer
https://floss.social/web/@abbienormal/108378060174601402

How to write a service (was: Re: Teams)

[catonano]

Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
> 
> I found the documentation to be a bit confusing (understandably, as
> its new), but once the workflow snapped together its been amazing to
> see how easy it is to create new services. 

I'm specifically interested in this issue

In fact, I posted a toot about this, that received several booosts and
likes but NO answer
https://floss.social/@abbienormal/108378060174601402

Maybe writing a Home service is easier (meaning the process is less
articulated) ?

And then once it's reasonably stable it can be moved to be a system
service ?



> > 

Re: how to write services (was: Re: Teams)

[catonano]

Il giorno mer, 15/06/2022 alle 17.01 +, Blake Shaw ha scritto:
> 
> Catonano:
> I think writing a home-service is much easier given that you don't
> need to do produce an entire system generation before you find out
> what you did wrong; 

I suspected something like this

This is why I hypotized that a gradual passage with a Home service
could be convenient

Ricardo, the general map of the concepts involved in conceiving a
service is useful

But in my toot I asked for something different

I asked for indications about the process (what magic to use in the
REPL)

if you prefer, I asked for something more menial

Which buttons do I have to push (metaforically) ?

As for the semantics involved in thinking a service, I feel I can work
them out myself (to some extent)

This should be covered in the cookbook

I see there's a package for Tryton (that's a relative of Odoo) and the
package definition for Tryton is quite sought after

In fact Tryton modules are not python modules and there's a patch
modifying how Tryton retrieves its modules in Guix

Yet there's no service for Tryton

I asked Hartmut (I remembered they were involved in this) and they
declared their surrender in writing services
(Here https://nerdculture.de/@kirschwipfel/108477739857485544 )

Maybe there's some cognitive friction about how to produce services ?

This reminds me of an argument about Haskell I read

Some "expert" haskellers are deeply involved in "plug ins" to the
compiler that actually change the language and many haskellers with a
lower level of proficiency are confused by this

And this hampers the Haskell field as a whole

Too bad I can't provide a pointer to this

My point being that I think this is a case of curse of knowledge
(mentioned here https://www.hillelwayne.com/post/learning-a-language/ )

I think the friction on how to write a service is not in the semantics
involved

It's more menial

As an blueprint for what I mean, you can think of Smalltalk, the
programming language

There a famous implementation of Smalltalk called Squeak

I played with Squeak myself, many years ago

That's how I learned object orientation ,really

The experience Squeak offers is NOT Posix based (thank God)

A GNU implementation of Smalltalk also exists and it's totally Posix
based (because of the unfortunate "GNU System" delusion)

Do you think the GNU Smalltalk would have been as effective in teaching
me object orientation ?

I honestly doubt it

yet the language is exactly the same

because the problem is not the language, that is something people CAN
work out themselves (roughly)

The problem is the experience

As I'm writing this, I noticed someone replied to my toot
(here
https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 )

as you can see, they also noticed a difference in the experience
between creating home services and system services

While you somewhat downplayed that

Now I want to be clear, here

In the past I have misunderstood some of your contributions about
macros in Guile (that I had asked about)

I came to terms with the fact that you're doing your best and in total
good faith, so I hope it's clear that's not what's happening today

But I also hope you can see why I could get a bit frustrated with your
reply

Guix is being successful, these days but that's an exception in the
free software world and more so in the GNU world

Guile is less exceptional in that it's suffering from its marginality
and it has been doing so for several years now

and I believe these cultural issues are part of why and they are
threatening the whole user freedom movement

Sorry if I went off on a tangent, I just feel a bit about this

> it just depends on if you need your service initialized at startup
> (system-services, globally defined and available prior to login)
> rather than at login (home-services, per-user/locally defined).
> 
> I'm not on Mastodon but feel free to send your service my way for
> some help, I'm still a beginner but a second pair of eyes is always
> nice to have.

That's very kind of you, thank you

I don't know if I'll ever attempt to write a service for Odoo

Or for Tryton

I have a job now (and it has to do with Odoo), I also train in a gym, I
like to spend the free time I have on the beach (as it's evident from
my presence on the fediverse)  so I don't know it's not like I have any
slots to assign to attempt this

It's just that if the _process_ to write a service (home or system) was
made explicit, I could have played with it in the few moments of grace

package requests

[Catonano]

Say that some people file bugs in the Guix issue tracker requesting the
packaging of some software projects

Can a list of such requests be seen in any way ?

I remember reading a thread about this some time ago but I can't find it
anymore and I don't remember how it ended, if it ended

I'd like to be able to file issues for the packaging of some Guile
libraries and follow the development of those

And maybe someone else could use such system to request the packaging of
non Guile related stuff

Is there any repository anywhere hosting a project for extracting such
requests from the issue tracker and displaying them nicely in a web page?

Is there any specific tagging scheme to be used for package requests filing
?

Thanks

Re: package requests

[Catonano]

Il giorno sab 25 apr 2020 alle ore 15:52 sirgazil  ha
scritto:

>   On Sat, 25 Apr 2020 11:38:07 +0000 Catonano 
> wrote 
>  > Say that some people file bugs in the Guix issue tracker requesting the
> packaging of some software projects
>  > Can a list of such requests be seen in any way ?
>  > I remember reading a thread about this some time ago but I can't find
> it anymore and I don't remember how it ended, if it ended
>
> Maybe this one?
> https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00231.html


yes, thanks. This is exactly the thread I saw

Re: package requests

[Catonano]

Il giorno sab 25 apr 2020 alle ore 15:06 Tobias Geerinckx-Rice 
ha scritto:

> Hi Catonano,
>
> Catonano 写道：
> > Say that some people file bugs in the Guix issue tracker
> > requesting the
> > packaging of some software projects
> >
> > Can a list of such requests be seen in any way ?
>
> […]
>
> > Is there any specific tagging scheme to be used for package
> > requests filing ?
>
> Not that I know of.  It's all very ad-hoc and things get lost &
> forgotten.
>
> <https://libreplanet.org/wiki/Group:Guix/Wishlist> is the closest
> thing we have to an ‘official’ list.
>
> While a structured approach would be much better than our wiki
> page, I prefer that wiki page over *our* bug tracker.
>

don't you like Debbugs ?

I can see why

Have you seen this, anyway ?

https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00238.html

Sirgazil proposed to send a patch to allow Debbugs to tag package requests
so that they could be easily searched

I'd be fine with either solution, as long as it's accepted by the wider
community

Re: package requests

[Catonano]

Il giorno lun 27 apr 2020 alle ore 18:07 sirgazil  ha
scritto:

>   On Mon, 27 Apr 2020 04:14:52 +0000 Catonano 
> wrote 
>  >
>  >
>  > Il giorno sab 25 apr 2020 alle ore 15:06 Tobias Geerinckx-Rice <
> m...@tobias.gr> ha scritto:
>  > Hi Catonano,
>  >
>  > Catonano 写道：
>  > > Say that some people file bugs in the Guix issue tracker
>  > > requesting the
>  > > packaging of some software projects
>  > >
>  > > Can a list of such requests be seen in any way ?
>  >
>  > […]
>  >
>  > > Is there any specific tagging scheme to be used for package
>  > > requests filing ?
>  >
>  > Not that I know of.  It's all very ad-hoc and things get lost &
>  > forgotten.
>  >
>  > <https://libreplanet.org/wiki/Group:Guix/Wishlist> is the closest
>  > thing we have to an ‘official’ list.
>  >
>  > While a structured approach would be much better than our wiki
>  > page, I prefer that wiki page over *our* bug tracker.
>  >
>  > don't you like Debbugs ?
>  > I can see why
>  > Have you seen this, anyway ?
>  > https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00238.html
>  > Sirgazil proposed to send a patch to allow Debbugs to tag package
> requests so that they could be easily searched
>
> Not really patch Debbugs, but patch the website with proposed changes to
> make any list of requested packages visible (and add instructions to
> request new packages).
>

Ah sorry , I had misunderstood.

Re: Where is the packaging request backlog

[Catonano]

Il giorno gio 14 mag 2020 alle ore 19:49 Josh Marshall <
joshua.r.marshall.1...@gmail.com> ha scritto:

> If that is an appropriate use, I'll go with that.  Prepare for a few
> hundred reports.
>

Not long ago I was suggested this one (I even added a package to be
packaged)
https://libreplanet.org/wiki/Group:Guix/Wishlist

it seems to be more coarse grained than what you're thinking about, though

I don't know

Re: Outreachy Applicant: An Introduction

[Catonano]

Il giorno mer 14 ott 2020 alle ore 04:28 Magali Lemes <
magalileme...@gmail.com> ha scritto:

> Hi Aniket and Bonface,
> thank you two for the nice suggestions. That was exactly what I
> was looking to get started into emacs.
>
> Magali
>
>
I'd like to suggest also this one
https://www.pluralsight.com/courses/meet-emacs

It's not free and I understand that can be a hurdle

But a similar resource (that's not available anymore, this is a renewed
one) was very helpful for me

Hope this helps







> Em ter., 13 de out. de 2020 às 21:48, Aniket Patil <
> aniket112.pa...@gmail.com> escreveu:
>
>> Hi Lemes,
>>
>> I am also emacs user and Outreachy applicant. I would suggest you to go
>> through tutorial of emacs which is inbuilt and then go through this video
>> series.
>>
>> https://www.youtube.com/playlist?list=PL9KxKa8NpFxIcNQa9js7dQQIHc81b0-Xg
>>
>> I hope you find it helpful.
>>
>> Aniket.
>>
>> On Tue, 13 Oct 2020 at 4:38 PM, Magali Lemes 
>> wrote:
>>
>>> Hey,
>>> I'm using Ubuntu 20.04.1 LTS. I must say I've never used emacs before,
>>> so
>>> I'll try to get the hang of it.
>>> Sharing my progress: I decided to package the arduino IDE, but it turned
>>> out
>>> way harder than I expected, due to its many dependencies. I ended up not
>>> doing it, but it was a good experience because I could learn about some
>>> functions in Scheme - chdir, for example -, some of the phases of
>>> building a package - like unpacking, configuring and building - and I
>>> could
>>> also interact with the community, asking for help, via IRC, which is a
>>> very new thing for me.
>>> As for today, I will continue trying to package something. I'll probably
>>> follow
>>> your previous advice and begin with a R package. It seems easier, so
>>> hopefully
>>> I'll succeed.
>>>
>>> Cheers,
>>> Magali.
>>>
>>> Em seg., 12 de out. de 2020 às 12:06, zimoun 
>>> escreveu:
>>>
 Hi,

 On Mon, 12 Oct 2020 at 13:00, Magali Lemes 
 wrote:

 > Guix was fairly easy to install, I used the shell script to do that.

 Which distribution do you use?

 > I installed emacs using Guix and it worked as expected.

 Nice!
 Personally, I manage the Emacs packages with Guix via a manifest.scm
 file.  And in a separate profile.  My conf [1] is far from perfect but
 if you need inspiration. :-)

 1: 

 > I'll begin by trying to package something. So, I'll go through the
 links you sent
 > and see how that goes.

 Cool!
 Do not hesitate to ask on help-guix or #guix if you encounter issues
 on your path.  And feel free to send your progress, success or
 failure.


 All the best,
 simon

>>>

Re: Posts in languages other than English on help-guix?

[Catonano]

2018-03-02 21:07 GMT+01:00 Andreas Enge :

> On Fri, Mar 02, 2018 at 04:47:45PM +, ng0 wrote:
> > On topic: I think it's too much to suggest to include something that
> indicates
> > the language of the post in the subject?
>
> I think people will easily recognise languages they speak in a post!
>
> Andreas
>

I'd still put a mark for the langage used, you never know, you might want
to process messages with automated tools

Or you may have to deal with extravagant people

I agree in allowing the usage of langages other than English

I will keep using English, for myself

I might reply to a question written in Italian, though

Re: Posts in languages other than English on help-guix?

[Catonano]

2018-03-02 17:47 GMT+01:00 ng0 :

> Ludovic Courtès transcribed 4.8K bytes:
> > Hello Guix!
> >
> > What about allowing posts on help-guix in one of the languages that
> > regular contributors know, in addition to English?
> >
> > The alternative would be to create separate language-specific lists, but
> > some (rightfully) think there’s a risk of a disconnect with actual
> > developers.
> >
> > Of course it’s hard to tell what a multilingual mailing list will be
> > like, but I think it’s worth experimenting (and I don’t expect a
> > significant change overnight).  If we are to reach out to more people,
> > allowing them to use the language they know best is the minimum we can
> > do IMO.
> >
> > WDYT?
> >
> > To experiment with this on help-guix, I propose the patch below for the
> > web site.  If you’re a committer, please provide a translation for the
> > language(s) you know!
>
> Oh... does this mean the translation function for the website is now in
> place?
> It looks like it is from the patch content, or am I wrong?
>
> On topic: I think it's too much to suggest to include something that
> indicates
> the language of the post in the subject?
>
> > Ludo’.
> >
>
> > diff --git a/website/apps/base/data.scm b/website/apps/base/data.scm
> > index 0abcc7a..4ccca9a 100644
> > --- a/website/apps/base/data.scm
> > +++ b/website/apps/base/data.scm
> > @@ -13,7 +13,6 @@
> >  ;;; Data.
> >  ;;;
> >
> > -
> >  (define contact-media
> >(list
> > ;; The first three will be featured in the home page.
> > @@ -30,12 +29,18 @@
> > (contact
> >  #:name "Help Mailing List"
> >  #:description
> > -'(p
> > -  "Subscribe to the Help mailing list to get support from the
> > -  GuixSD and GNU Guix community via email. "
> > -  (a (@ (href "https://lists.gnu.org/archive/html/guix-devel/2015-
> 12/msg00584.html"))
> > -  "Until December 2015")
> > -  ", the Guix-devel mailing list filled that role.")
> > +`(("en"
> > +   "Subscribe to the Help mailing list to get support from the
> GuixSD
> > +and GNU Guix community via email.  You can post messages in English
> though we
> > +also accept other languages.")
>

("it"
  "Iscrivetevi alla mailing list 'Help' per essere aiutati da altri utenti
di Guix e GuixSD.
Potete scrivere sulla mailing list anche in italiano ")



> >
>

npm (Rollup)

[Catonano]

Hello list

there's this project
https://github.com/rollup/rollup

I don't understand what it does, maybe because I don't know the first thing
about javascript

I was wondering if that changes the situation with regard to porting npm
based software in Guix

Comments appreciated

Re: torbrowser

[Catonano]

2018-03-07 16:32 GMT+01:00 Christopher Lemmer Webber :

> ng0 writes:
>
> > The maintainer of the ebuild for Gentoo in the torbrowser-overlay
> > just gave me the last missing pieces of information for building
> torbrowser.
> > Recent commit message subjects in the upstream torbrowser repository
> > make me assume there will be no issues for integration into Guix master.
> > As long as the final build ressembles what I have talked about with them
> > we can even name it torbrowser and have the official design.
> >
> > I hope to be done with this by summer, but you never know with browser.
> > But it's just a Firefox ESR deriv., so (ideally) it should just be a
> matter
> > of 1 or 2 weekends.
>
> This is great, ng0!  Thank you! :)
>
>

I want to express my gratitude too

I cold even try to build your thing if I knew where it is ;-)

Re: how to get the path of the logfile after an unsuccesful build?

[Catonano]

2018-03-09 10:15 GMT+01:00 ng0 :

> Hi,
>
> did we ever talk about that there's too little information on how to get
> the current log file of a failed build? I need this right now (the full
> log)
> and I can't remember how, and making use of the log folder in
> var/log/guix/ won't
> help either.


last time I needed to see a build log, I think it was the "-K" option
passed to guix build

If the build fails, you'll see a line at the end, in the terminal,
reminding you that the build log is reachable at a certain location

Re: how to get the path of the logfile after an unsuccesful build?

[Catonano]

2018-03-11 7:28 GMT+01:00 Catonano :

>
>
> 2018-03-09 10:15 GMT+01:00 ng0 :
>
>> Hi,
>>
>> did we ever talk about that there's too little information on how to get
>> the current log file of a failed build? I need this right now (the full
>> log)
>> and I can't remember how, and making use of the log folder in
>> var/log/guix/ won't
>> help either.
>
>
> last time I needed to see a build log, I think it was the "-K" option
> passed to guix build
>
> If the build fails, you'll see a line at the end, in the terminal,
> reminding you that the build log is reachable at a certain location
>
>
>
Look, there's a manual page about that !

https://www.gnu.org/software/guix/manual/html_node/Debugging-Build-Failures.html#Debugging-Build-Failures

Are we talking about the same thing ?

building GNUNet

[Catonano]

Fellow guixers,

I bilt GNUNet both on my Fedora desktop withh guix on top of Fedora AND on
my GuixSD laptop

In both cases the same problem comes up

This line works

guix build -f ./guix-env.scm

But then, if I try to build GNNet locally, like this

guix environment -f ./guix-env.scm
[env] ./bootstrap
[env] ./configure
[env] make

I get these weird warnings

libtool: warning: '/home/catonano/.guix-profile/lib/libltdl.la' seems to be
moved
libtool: warning: '/home/catonano/.guix-profile/lib/libunistring.la' seems
to be moved
libtool: warning: '/home/catonano/.guix-profile/lib/libunistring.la' seems
to be moved
libtool: warning: '/home/catonano/.guix-profile/lib/libltdl.la' seems to be
moved
libtool: warning: '/home/catonano/.guix-profile/lib/libltdl.la' seems to be
moved
libtool: warning: '/home/catonano/.guix-profile/lib/libltdl.la' seems to be
moved
libtool: warning: '/home/catonano/.guix-profile/lib/libunistring.la' seems
to be moved
libtool: warning: '/home/catonano/.guix-profile/lib/libunistring.la' seems
to be moved
libtool: warning: '/home/catonano/.guix-profile/lib/libunistring.la' seems
to be moved
libtool: warning: '/home/catonano/.guix-profile/lib/libltdl.la' seems to be
moved
libtool: warning: '/home/catonano/.guix-profile/lib/libltdl.la' seems to be
moved
libtool: warning: '/home/catonano/.guix-profile/lib/libunistring.la' seems
to be moved
libtool: warning: '/home/catonano/.guix-profile/lib/libunistring.la' seems
to be moved


literally tons of these

and after that, the line that previously worked, this one

guix build -f ./guix-env.scm

fails with this erorr message

starting phase `configure'
source directory:
"/tmp/guix-build-gnunet-dev-env-0.11-1.dev-env.drv-0/source" (relative from
build: ".")
build directory:
"/tmp/guix-build-gnunet-dev-env-0.11-1.dev-env.drv-0/source"
configure flags:
("CONFIG_SHELL=/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash"
"SHELL=/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash"
"--prefix=/gnu/store/frx76q8g144lnaqsnhrcax8wz9gvr5h2-gnunet-dev-env-0.11-1.dev-env"
"--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
./configure: line 2683: config.log: Permission denied
./configure: line 2693: config.log: Permission denied
phase `configure' failed after 0.1 seconds
note: keeping build directory
`/tmp/guix-build-gnunet-dev-env-0.11-1.dev-env.drv-1'


In order to fix this I have to scrap the gnunet folder, check it out again
and reissue

guix build -f ./guix-env.scm

but if I try to build it locally again, I botch it again

Having a functional dev station for GNUNet could be useful for trying to
help them

Any help appreciated
Thanks

Re: building GNUNet

[Catonano]

2018-04-02 12:12 GMT+02:00 Nils Gillmann :

>
>

> No idea on your guix specific errors, but have you tried make clean instead
> of literally deleting the repository and cloning it again?
>

yes

it doesn't help

a blog post

[Catonano]

Hello fellow guixers,

I posted a brand new post in my little personal somewhat indie blog

It's about Guix, Guile and Free Software in general. From my very own point
of view

You can find it here
http://catonano.v22018025836661967.nicesrv.de/guile-and-free-software.html

There's also a feed, reachable here
http://catonano.v22018025836661967.nicesrv.de/feed.xml

I hope you're not bothered by this shamelessly self promotional post on the
mailing list

But I remember Ludo saying that not only new packages and services would be
needed for the future of Guix but also community oriented stuff such as
blog posts and maybe screencasts and so on

The blog is made with Haunt and it's completely Javascript free. This
should make the consultation easier from Tor

Too bad I couldn't take care of the fonts yet so it still points to some
Google provided fonts 😓

Also, I host it on a vps by netcup.de, a German provider, I don't know how
that fares with Tor either.
I hope not too bad

So, this is it
Thanks

Re: a blog post

[Catonano]

2018-04-07 11:53 GMT+02:00 Hartmut Goebel :

> Am 06.04.2018 um 10:58 schrieb Catonano:
> > It's about Guix, Guile and Free Software in general. From my very own
> > point of view
>
> Quote:
>
> [org.mode…] as far as I understand some Google employees worked on it.
>
> Does one become blessed and enlightened by getting employed by Gugle? Is
> Gugle a magic guild?
>
> Sorry, can't stand this google devoutness.
>

Hartmut,

it's not devoutness

What I was trying to convey is that org-mode reached a wide community, it
entered places where the common attitude towards the gpl is of prudence, to
say at least.

I was not referring to a technological success but rather to a
communitarian (political ?) one.

Guile is light years far away from such a success, sadly.

That said, I also expect the average Google engineer to be quite competent.
But admittedly that's not by direct experience

That's all ☺

Re: Guix-based build tool

[Catonano]

2018-04-09 17:30 GMT+02:00 Ludovic Courtès :

> Hello!
>
> Pjotr Prins  skribis:
>
> > Indeed, I love working with Guix and developing with Guix. Guix takes
> > care of my deployment and configuration requirements.
> >
> > I have written some time in the past that with Guix you don't need
> > autotools. The main thing autotools solve is configuring the build for
> > an environment. At the same time, with Guix you get a predictable
> > environment, so a make file (or similar) suffices. It is what I do in
> > all my development projects - I don't use autotools to develop and
> > deploy them. It greatly simplifies my existence :). Indeed, I have
> > never liked autotools (essentially a nasty hack) and only used them
> > before Nix/Guix. So, my approach is the same as yours :)
>
> +1!
>
> If we could provide tooling with an abstraction level close to that of a
> makefile, that’d help a lot.
>
> Actually, just like we have ‘emacs-build-system’, we could very much add
> ‘guile-build-system’ for simple Guile packages that don’t need/use
> Autoconf & co.
>
> ‘guile-build-system’ would automatically run ‘guild compile’,
> ‘makeinfo’, etc. pretty much like we do here:
>
>   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/
> packages/guile.scm#n870
>
> Once we have that, developers of Guile packages can simply drop a
> ‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
> build’, and ‘guix package’.
>
> That’s coarser-grain than a makefile, of course, but would be a good
> first step to providing tooling for people working on Guile code.
>
> Any takers for ‘guile-build-system’?
>

Ahem... that would be me

This would be the most advanced thing I' ve ever done in Guile until now

Recently rekado observed that (system*... does NOT spawn a shell and
execute commands in it

That was a surprise for me

Also in the Guile manual I found getcwd and a "chdir" (or something) in
order to run a Unix command from within a certain folder

So I feel less in the dark than I felt until a short time ago

And anyway, I' ll pester you, should I get stuck

I won' t be fast, but I' ll keep you updated ;-)



>
>
> A next step could be to add a tool that understands a syntax like that
> of the guildhall, which gets us closer to the makefile/Makefile.am level
> of abstraction:
>
>   https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121


it's early for this one

We' ll see

Re: Guix-based build tool

[Catonano]

2018-04-18 23:09 GMT+02:00 Ludovic Courtès :

> Hello,
>
> Christopher Lemmer Webber  skribis:
>
> > While this is a fun idea, I'd still much rather have a guile-based
> > DSL replacement for autotools type things that's standalone (but maybe
> > also which can export to shell if need be).
>
> Yeah, not depending on Guix would have pros (it’d be more widely
> applicable), and cons (limited world view).
>
> Food for thought!
>
> Ludo’.
>
>
there' s this file guix/buid/emacs-utils.scm

it contains utilities to let Emacs byte-compile elisp files

So that' s an Emacs build system and it' s embedded in Guix

My initial idea was to do something similar with Guile

But then I tought that it could have been a stand alone package

Today in the morning I could manage to take a look at this issue

I made a script that visits the file system tree of a project and compiles
the .scm files

Here' s a short demo
https://www.youtube.com/watch?v=LaypeR8uw3Q

It doesn' t check the availability of dependencies (other guile packages)
yet

I was not sure how to achieve that

I saw that Automake generates snippets of bash scripting that try to run
guile with an expression loading the required module and if that fails then
the module is not available

The same functionality could be reproduced in Guile

I also saw the guildhall files that Ludo mentioned

So the thing is that the interface towards the user should be like those
guildhall files

and the interface towards the system should be like the Automake one

But, like Automake, it should only check if a Guile module is reachable on
the guile load path

If it' s not it shouldn't try manouvres: no sat solving, no fetching,
nothing.

A dependency could be there because you installed it with apt-get or with
dnf or because you used configure make on a manually downloaded guile
package

Or because you installed it with Guix or Nix

If it' s there, fine. if it' s not, that' s bad, the package can' t be built

What I mean is that this should be a build system, not a package management
system

This should address the concern that has been raised

Does it ?

I'll publish this soon, reviews and contributions appreciated ☺

Re: Guix-based build tool

[Catonano]

2018-04-19 18:49 GMT+02:00 Catonano :

>
>
> 2018-04-18 23:09 GMT+02:00 Ludovic Courtès :
>
>> Hello,
>>
>> Christopher Lemmer Webber  skribis:
>>
>> > While this is a fun idea, I'd still much rather have a guile-based
>> > DSL replacement for autotools type things that's standalone (but maybe
>> > also which can export to shell if need be).
>>
>> Yeah, not depending on Guix would have pros (it’d be more widely
>> applicable), and cons (limited world view).
>>
>> Food for thought!
>>
>> Ludo’.
>>
>>
> there' s this file guix/buid/emacs-utils.scm
>
> it contains utilities to let Emacs byte-compile elisp files
>
> So that' s an Emacs build system and it' s embedded in Guix
>
> My initial idea was to do something similar with Guile
>
> But then I tought that it could have been a stand alone package
>
> Today in the morning I could manage to take a look at this issue
>
> I made a script that visits the file system tree of a project and compiles
> the .scm files
>
> Here' s a short demo
> https://www.youtube.com/watch?v=LaypeR8uw3Q
>
> It doesn' t check the availability of dependencies (other guile packages)
> yet
>
> I was not sure how to achieve that
>
> I saw that Automake generates snippets of bash scripting that try to run
> guile with an expression loading the required module and if that fails then
> the module is not available
>
> The same functionality could be reproduced in Guile
>
> I also saw the guildhall files that Ludo mentioned
>
> So the thing is that the interface towards the user should be like those
> guildhall files
>
> and the interface towards the system should be like the Automake one
>
> But, like Automake, it should only check if a Guile module is reachable on
> the guile load path
>


I am experimenting with this line

(system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")

If it finds the module it returns 0

Otherwise it returns a different number

I copied some bits for a configure script for a Guile project instrumented
with the Autotools

I could use an example of usage of "status:Exit-val"

The Guile manual says:

 Return the exit status value, as would be set if a process ended
 normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
 ‘#f’.

this is not enouhg for me to understand

In which scenario is thhis function supposed to be used ? In order to do
what ?
An example would be of great help

Anyway: Is this the idiomatic way ?

Or maybe I should use some try catch form wrapping some module loading
instruction ?
Without launching a different guile process ?

Thanks for any hint

Re: Guix-based build tool

[Catonano]

2018-04-20 8:52 GMT+02:00 Catonano :

> 2018-04-19 18:49 GMT+02:00 Catonano :
>
>>
>>
>> 2018-04-18 23:09 GMT+02:00 Ludovic Courtès :
>>
>>> Hello,
>>>
>>> Christopher Lemmer Webber  skribis:
>>>
>>> > While this is a fun idea, I'd still much rather have a guile-based
>>> > DSL replacement for autotools type things that's standalone (but maybe
>>> > also which can export to shell if need be).
>>>
>>> Yeah, not depending on Guix would have pros (it’d be more widely
>>> applicable), and cons (limited world view).
>>>
>>> Food for thought!
>>>
>>> Ludo’.
>>>
>>>
>> there' s this file guix/buid/emacs-utils.scm
>>
>> it contains utilities to let Emacs byte-compile elisp files
>>
>> So that' s an Emacs build system and it' s embedded in Guix
>>
>> My initial idea was to do something similar with Guile
>>
>> But then I tought that it could have been a stand alone package
>>
>> Today in the morning I could manage to take a look at this issue
>>
>> I made a script that visits the file system tree of a project and
>> compiles the .scm files
>>
>> Here' s a short demo
>> https://www.youtube.com/watch?v=LaypeR8uw3Q
>>
>> It doesn' t check the availability of dependencies (other guile packages)
>> yet
>>
>> I was not sure how to achieve that
>>
>> I saw that Automake generates snippets of bash scripting that try to run
>> guile with an expression loading the required module and if that fails then
>> the module is not available
>>
>> The same functionality could be reproduced in Guile
>>
>> I also saw the guildhall files that Ludo mentioned
>>
>> So the thing is that the interface towards the user should be like those
>> guildhall files
>>
>> and the interface towards the system should be like the Automake one
>>
>> But, like Automake, it should only check if a Guile module is reachable
>> on the guile load path
>>
>
>
> I am experimenting with this line
>
> (system* "guile" "-c" "(use-modules (commonmark)) (exit ((lambda () 0)))")
>
> If it finds the module it returns 0
>
> Otherwise it returns a different number
>
> I copied some bits for a configure script for a Guile project instrumented
> with the Autotools
>
> I could use an example of usage of "status:Exit-val"
>
> The Guile manual says:
>
>  Return the exit status value, as would be set if a process ended
>  normally through a call to ‘exit’ or ‘_exit’, if any, otherwise
>  ‘#f’.
>
> this is not enouhg for me to understand
>
> In which scenario is thhis function supposed to be used ? In order to do
> what ?
> An example would be of great help
>
> Anyway: Is this the idiomatic way ?
>
> Or maybe I should use some try catch form wrapping some module loading
> instruction ?
> Without launching a different guile process ?
>
> Thanks for any hint
>


so

this line (notice the module is named commonmarL)

(system* "guile" "-c" "(use-modules (commonmarl)) (exit ((lambda () 0)))")

returns 256

while this one

(status:exit-val (system* "guile" "-c" "(use-modules (commonmarl)) (exit
((lambda () 0)))"))

returns 1

what's the point ?

Re: Introducing myself as an Outreachy Intern

[Catonano]

2018-04-25 8:27 GMT+02:00 Sahitihi :

> Hi all,
>
> I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
> pursuing my under graduation final semester in Computer Science. I will
> be
>
Hi Sahithi

Welcome !


> 1. Adding package definitions like r-dyn, r-catdap, r-abc to CRAN Packages
> .
>
> 2. Printed colored strings on terminal using Scheme code
>
> 3. Looked at scheme code to find out build output is printed.
>

Great !

What will you be working on during your internship ?

Maybe making the output of the build command more human ?

Best whishes !
Catonano

a guile based build tool at the base of a guile-build-system

[Catonano]

2018-04-23 10:20 GMT+02:00 Ludovic Courtès :

> Hello Ricardo & all!
>
> Ricardo Wurmus  skribis:
>
> > I’m happy to announce that the group I’m working with has released a
> > preprint of a paper on reproducibility with the title:
> >
> > Reproducible genomics analysis pipelines with GNU Guix
> > https://www.biorxiv.org/content/early/2018/04/11/298653
> >
> > We built a collection of bioinformatics pipelines and packaged them with
> > GNU Guix, and then looked at the degree to which the software achieves
> > bit-reproducibility (spoiler: ~98%), analysed sources of non-determinism
> > (e.g. time stamps), discussed experimental reproducibility at runtime
> > (e.g. random number generators, kernel+glibc interface, etc) and
> > commented on the idea of using “containers” (or application bundles)
> > instead.
>
> Very impressive piece of work!  I think it’s important to stress that
> reproducible builds is a crucial foundation for reproducible
> computational experiments, and this paper does a great job at this.
>
> Also nice that you show you can have these bit-reproducible pipelines
> formalized in Guix *and* produce a ready-to-use “container image.”
>
> Hopefully we can soon address the remaining sources of non-determinism
> shown in Table 3 (I think you already addressed some of them in the
> meantime, didn’t you?).
>
> The bit I’m less comfortable with is Autotools.  I do understand how it
> helps capture configure-time dependencies, and how it generally helps
> people package and use the software; I think it’s one of the best tools
> for the job.  However it’s also hard to learn and, whether it’s
> justified or not, it’s considered “scary.”
>
> Given the intended audience, I wonder how we could provide a simpler
> path to achieve the same goal.  It could be a set of Autoconf macros
> leading to high-level ‘configure.ac’ files without any line of shell
> code, or it could be Guix interpreting a top-level .scm or JSON file,
> both of which would ideally be easier to write for bioinformaticians.
>
> What are your thoughts on this?
>

I have explored the possibility to create a guile based tool for building
guile packages

That could be easily expanded to support non guile based projects

It could reproduce all thhe tests that Autoconf generated scripts perform

I thought it would be nice to reproduce the record format used in Guildhall

It seems to me that the pacages defined in pkg-list.scm files are not using
the standard srfi-9 syntax

I also noticed that the guix/records.scm file

So I embarked in the process of learning how the guile macros are used there

It was a tumble, substantially

I couldn't read the code, too much and too articulated

The guile manual was not very helpfful

So I took this article
https://www.cs.indiana.edu/~dyb/pubs/tr356.pdf

to a print shop to have it printed and be able to read it peacefully

I read it. so now I know at least what the whole thing is about

I made this little (< 7 Mb) footage of me expanding a guix defined macro
for creating a record
http://catonano.v22018025836661967.nicesrv.de/resources/videos/expanding.flv

Too bad, it expands the thing completely, so I end up with some code
creating and manipulating structures, rather than srffi-9 records

I remebered aout a macroexpand-1 macro doing only one pass of expansion but
that's in Clojure !
I remembered incorrectly !

So this is where I'm at and where I've been

A stumble in yakk shaving, substantially.

I could give up on macros and use srfi-9 records for now.

The next step would be to test if some guile deps are available (calling
the line I already have briefly discussed here)

should anyone be working on a guile based buld tool, I'd love them to make
their efforts known to the community, maybe publish a repo somewhere


>
> Anyway, kudos on this, thank you!
>
> Ludo’.
>
>

Re: Org-mode for Haunt

[Catonano]

2018-04-26 19:59 GMT+02:00 swedebugia :

> Hi
> The source code is not available via the git repository on that page and
> neither anywhere else according to a quick search.
> Is 0.3 the latest release?
>

You could try to contact Wingo. The last line of the page about
guile-present invites to contact him directly in order to send feedback

Should the code be lost, Guile offers support for creating parsers. There
are a couple of chapters in the manual about that

I suppose that the Markdown parser is built along those lines (I just
suppose: I haven't taken a look at the code)

So you could duplicate that and then start tweaking it in order to make it
gradually become a org-mode parser

[no subject]

[Catonano]

it's 17:05 of april 27th

I just pulled guix and tried to build it

with this result

impossibile aprire ./doc/guix.fr.texi: No such file or directory

ERROR: In procedure lstat:
In procedure lstat: File o directory non esistente:
"/home/catonano/GNU/guix/doc/contributing.fr.texi"

Re:

[Catonano]

2018-04-27 18:30 GMT+02:00 Pierre Neidhardt :

>
> I've run into the same issue.  After a `make clean` it did build properly
> though.
>

yes, thanks

Re: GSoC-2018

[Catonano]

2018-04-27 19:43 GMT+02:00 Sandeep Subramanian <
sandeepsubramania...@gmail.com>:

> Hi all,
>
> I am Sandeep Subramanian (uniq10) and I have been selected for the
> GSoC-2018 project "Continue rewrite build daemon in Guile Scheme".
> (Project description:
> https://libreplanet.org/wiki/Group:Guix/GSoC-2018#Continue_
> rewrite_build_daemon_in_Guile_Scheme
> )
>
> I am very excited to work on this project and am looking forward to
> interacting
> with the community here and on the #guix IRC channel (Nick: uniq10).
> I will mostly be active from UTC 08:00 to UTC 20:00.
>
> I hope to, with your help, successfully complete this project and make a
> meaningful contribution to the community.
>
>
welcome and good luck !!

Re: Dealing with language bindings for libraries.

[Catonano]

2018-05-09 17:21 GMT+02:00 Fis Trivial :

>
> Hi, Guixs.
>
> Recently I encountered some libraries that's written in c++ and have
> multiple language bindings, each of them has their corresponding build
> system, namely, R, Python, Java. And all the bindings are in
> tree. During the build process, One would first build the c++ part by
> cmake, then chdir into each language binding sub-directory and invoke
> its build system.
>
> For packaging them in guix, one way to deal with it is building each
> binding as an independent package, each package has it's own
> dependencies for the specific binding and common dependencies for C++
> part, that way, we will have N independent packages, for N language
> binding. But it will result in a huge waste of computing resource. I
> don't want to waste precious computing time of guix's build farm.
>

Maybe I'm being naive, but I don't understand why this would involve any
further overhead

You could have the c++ part as a dinamically linked library and the
bindings would have it as a dependency

What's the overhead in this ?

Re: Dealing with language bindings for libraries.

[Catonano]

2018-05-10 11:27 GMT+02:00 Fis Trivial :

>
> Catonano writes:
>
> > 2018-05-09 17:21 GMT+02:00 Fis Trivial :
> >
> >>
> >> Hi, Guixs.
> >>
> >> Recently I encountered some libraries that's written in c++ and have
> >> multiple language bindings, each of them has their corresponding build
> >> system, namely, R, Python, Java. And all the bindings are in
> >> tree. During the build process, One would first build the c++ part by
> >> cmake, then chdir into each language binding sub-directory and invoke
> >> its build system.
> >>
> >> For packaging them in guix, one way to deal with it is building each
> >> binding as an independent package, each package has it's own
> >> dependencies for the specific binding and common dependencies for C++
> >> part, that way, we will have N independent packages, for N language
> >> binding. But it will result in a huge waste of computing resource. I
> >> don't want to waste precious computing time of guix's build farm.
> >>
> >
> > Maybe I'm being naive, but I don't understand why this would involve any
> > further overhead
> >
> > You could have the c++ part as a dinamically linked library and the
> > bindings would have it as a dependency
> >
> > What's the overhead in this ?
>
> Thanks for the reply.
>
> This is somehow like dealing with git submodules, people just include
> submodules' directory in their build system, for example in cmake
> script:
>
> add_subdirectory(submodule_directory).
>
> If you want to split it when packaging, you need to write a cmake config
> script for that submodule and then patch the outer cmake file for
> replacing `add_subdirectory` with `find_package`. I don't think there is
> a shortcut for this. But doing so might be welcomed by upstream.
>
>
> In the case of language binding, the build code for bindings would try
> to find the shared object and other meta data required for build inside
> build tree, not in system path.


Ah, now I see what you mean.

[...]
> So, to make the c++ part as shared object and let the bindings find it
> at compile time, I need to rewrite all the build code for bindings,
> which I don't consider necessary for either upstream nor packaging.
>

In my view, this is a form of bundling

Some projects bundle some libraries

This make life harder for packagers

It' s frown upon and considered a bad habit

In fact, in the Guix manual there' s a list of chacks to do when you review
a new package, submitted onto the mailing list

And one of the checks is to see if the packag _bundles_ anything and if it
doesm to try to unbundle and link to system provided resources instead

I think this case is similar

I understand it's boring but I think the right thing to do would be to
unbundle also in this case

Complicating the semantics of the packages (what a package is) is a risky
business.

Of course I'm the less competent system engineer and packager worldwide and
this is just my opinion 🙂

Re: Nairobi Guix talk

[Catonano]

Wow

Good luck !

Il ven 11 mag 2018, 06:46 Pjotr Prins  ha
scritto:

> First white hat GNU Guix talk in Africa (I think):
>
>
> https://www.eventbrite.com/e/pjotr-prins-in-nairobi-on-functional-programming-hpcs-in-research-gnu-guix-tickets-45970402712
>
> :)
>
> Pj.
>
>

Re: [rb-general] Paper preprint: Reproducible genomics analysis pipelines with GNU Guix

[Catonano]

2018-05-11 10:19 GMT+02:00 Ricardo Wurmus :

>
> Ludovic Courtès  writes:
>
> > Perhaps we could add to Autoconf-Archive (if it doesn’t have such things
> > already) macros to deal with the R and Python stuff you had to deal
> > with?  And then publish a simple template that people could use as a
> > starting point.
>
> I submitted my macros for R packages (and they have been accepted), but
> I actually don’t really like them because they are not as useful as it
> may seem.  While they do check for R packages in the environment at
> configure time, nothing is done to record the environment necessary to
> access these packages.
>
> That’s a general problem for software that depends on search path
> environment variables.  I can’t just record the location of each
> individual R package that was detected and use that to set up the
> environment at runtime.  The R packages have other runtime dependencies
> that would also need to be recorded.
>
> It’s not ideal.
>
> --
> Ricardo
>
>
>

Ricardo, I don't understand the problem you're raising here (I didn't read
the article yet, though)

Would you mind to elaborate on that ?

Why would you want to record the environment ?

I have this tiny prototype that checks for the availability of the Guile
module "sqlite3" at configure time and writes this csexp (
https://gitlab.com/dustyweb/guile-csexps ) in a file

(7:sqlite32:no)
(7:sqlite33:yes)

The first line is produced in an environment in which sqlite3 is not
available
The second one is produced in an environment in which sqlite3 is, well
guess what, available

I produce such environments with the Guix "environment" command

I think csexps are cool because they are readable to humans

A user creating their pipeline can easily inspect the result of the
configuration phase

They could even paste excerpts of text on mailing lists, should they want
to ask for help

In my idea a build tool doesn't attempt at managing an environment

You could have sqlite3 because you set up a Guix environment, or because
you installed it with apt-get or dnf or manually

The build tool only worries about the availabilty, not how it's achieved

If every dependency is available (anyhow) it just builds

Because building and package management are supposed to be differrent
concerns.

If you have Guix, fine.
If you haven't Guix, then you're on your own, if you can manage, fine

This should address your concern to let people treat their pipelines as
packages

Doesn't it ?

Is this approach not enough for you ?

May I ask why ?

For now it only tests Guile modules but it could be obviously generalized
to test for more things (libs versions, data structures availability, along
the lines of what Autoconf does)

I'd love to be able to set up my (Guile) packages without having to deal
with the Autotools 😯

Re: [rb-general] Paper preprint: Reproducible genomics analysis pipelines with GNU Guix

[Catonano]

2018-05-13 7:07 GMT+02:00 Ricardo Wurmus :

>
> Catonano  writes:
>
> > Ricardo, I don't understand the problem you're raising here (I didn't
> read
> > the article yet, though)
> >
> > Would you mind to elaborate on that ?
> >
> > Why would you want to record the environment ?
>
> I want to record the detected build environment so that I can restore it
> at execution time.  Autoconf provides macros that probe the environment
> and record the full path to detected tools.  For example, I’m looking
> for Samtools, and the user may provide a particular variant of Samtools
> at configure time.


Thanks for clarifying !

Let me vent some thoughts on te issue !

Under Guix, the way to provide a specific version of the Samtools would be
to run the configuration in an environment that offers a specific Samtools
package, so that the configuration tool can pick that up

Under a traditional distro, it'd be to feed file paths to the configuration
tool

So, how much of the traditional way of doing things do we want to support,
in our pipelines ?

I record the full path to the executable at
> configure time and embed that path in a configuration file that is read
> when the pipeline is run.
>
> This works fine for tools, but doesn’t work very well at all for modules
> in language environments.  Take R for example.  I can detect and record
> the location of the R and Rscript executables, but I cannot easily
> record the location of build-time R packages (such as r-deseq2) in a way
> that allows me to rebuild the environment at runtime.
>
> Instead of writing an Autoconf macro that records the exact location of
> each of the detected R packages and their dependencies I chose to solve
> the problem in Guix by wrapping the pipeline executables in R_SITE_LIBS,
> because I figured that on systems without Guix you aren’t likely to
> install R packages into separate unique locations anyway — on most
> systems R packages end up being installed to one and the same directory.
>
> I think the desire to restore the configured environment at runtime is
> valid and we do this all the time when we run binaries that have
> embedded absolute paths (to libraries or other tools).


I didn't mean to imply it's not valid
I was just trying to understand what are the concerns on the ground and the
context



> It’s just that
> it gets pretty awkward to do this for things like R packages or Python
> modules (or Guile modules for that matter).
>
> The Guix workflow language solves this problem by depending on Guix for
> software deployment.  For PiGx we picked Snakemake early on and it does
> not have a software deployment solution (it expects to either run inside
> a suitable environment that the user provides or to have access to
> pre-built Singularity application bundles).  I don’t like to treat
> pipelines like some sort of collection of scripts that must be invoked
> in a suitable environment.  I like to see pipelines as big software
> packages that should know about the environment they need, that can be
> configured like regular tools, and thus only require the packager to
> assemble the environment, not the end-user.
>

I understand your concern to consider pipelines as packages

But say, for example, that a pipeline gets distributed as a .deb package
with dependencies to R (or Guile) modules

Or, say, that a pipeline is distributed with a bundled guix.scm file
containing R modules (or Guile modules) as inputs

Would that break the idea of a pipeline as a package ?

I'm afraid that the idea of a pipeline as a package shouldn't be entrusted
to the configuration tool, but rather to the package management tool

And the pipeline author shouldn't be assumed to work in isolation,
confident that any package management environment will be able to rus their
pipeline smoothly

The pipelines authors should be concerned with the collocation of their
pipeline in the packaged graph, that shouldn't be a concern of the packager
only

Maybe the sotware authors should provide dependency information in a
standardized format (rdf ? ) and that should be leveraged by packagers in
order to prepare .deb packages or guix.scm files

And if you are a developer and you want to test the software with a
specific version of a dependency, then you should run the configuration
tool in an environment where that version of the dependency is available,
so that the configuration tool can pick that up

If you are on Guix, you will probably create that environment with the Guix
environment tool

If you are on Debian or Fedora, you will have to rely on those distros
development tools



On traditional distros, you can install packages in your user folder or in
/opt or in other positions

And then, you can feed those to the configuration tool

On Guix, the 

Re: Customize GuixSD: Use Stock SSH Agent Everywhere!

[Catonano]

2018-05-28 13:28 GMT+02:00 Ricardo Wurmus :

>
> Pierre Neidhardt  writes:
>
> > This kind of "tutorials" is useful enough it probably deserves a
> > mention in the Guix manual.  What do you think?
>
> The manual is mostly a reference.  I wouldn’t mind having a separate
> Texinfo document as part of the repository that contains only tutorials
> and examples, with cross references to the manual.
>
> --
> Ricar



In this regard, I'd lie to suggest this talk, I think it's relevant
https://archive.fosdem.org/2017/schedule/event/legacy_docs/

It'd be very useful for Guile too and God knows for how many more GNU
projects

Re: Customize GuixSD: Use Stock SSH Agent Everywhere!

[Catonano]

2018-05-29 15:42 GMT+02:00 Ricardo Wurmus :

>
> Hi Catonano,
>
> > In this regard, I'd lie to suggest this talk, I think it's relevant
> > https://archive.fosdem.org/2017/schedule/event/legacy_docs/
> >
> > It'd be very useful for Guile too and God knows for how many more GNU
> > projects
>
> Could you please summarize the key points and how they apply to this
> discussion?
>


Sure ! Thanks for asking ! 😃

I think a good starting point is this picture
https://files.mastodon.social/media_attachments/files/003/855/604/original/b02a794729c184ad.png

The key point of the talk is that the documentation usually illustrates the
technical features of a project

And the process of envisioning solutions for use cases is left to the reader

Instead, the documentation should start from specific use cases. It should
be an anthology of use cases

As for Guile, for example, Thomas Dankaert recently posted a question on
the guile user mailing list about how to use string as ports in calling
external commands; he wanted the error port of an external command to be a
string

The manual deals with input output in several locations scattered all around

Drawing a working solution for reading/writing is not exactly immediate

A bunch of examples would be more funcional, at least for some kinds of
readers/users

And input output is only one kind of use cases

Regarding Guix, having examples of use cases of using packages could be a
good starting point

So, finally, I think your idea of having a separate document providing a
different angle to using Guix is a good one

Other categories of use cases could be envisioned

It could cover not only the usage of specific packages but also some GuixSD
functionalities such as updating, setting up specific desktop environments,
services, reconfiguring

Those things are quite different from the common usage patterns of
mainstream distros and some reading-phobic people could use some quick
general examples to draw a general picture of Guix on their own

Maybe the traditional manual could be a further resource for those who want
to deepen their knowledge of Guix

How much am I ready to contribute to such a document ?

I don't know

I chimed in because I found interesting that a similar idea to that
illustrated in the talk came afloat here

Re: Reference manual + tutorials (was: Customize GuixSD: Use Stock SSH Agent Everywhere!)

[Catonano]

2018-05-29 16:57 GMT+02:00 Ricardo Wurmus :

>
> Hi Catonano,
>
> >> > In this regard, I'd lie to suggest this talk, I think it's relevant
> >> > https://archive.fosdem.org/2017/schedule/event/legacy_docs/
> >> >
> >> > It'd be very useful for Guile too and God knows for how many more GNU
> >> > projects
> >>
> >> Could you please summarize the key points and how they apply to this
> >> discussion?
> >>
> >
> >
> > Sure ! Thanks for asking ! 😃
> >
> > I think a good starting point is this picture
> > https://files.mastodon.social/media_attachments/files/003/
> 855/604/original/b02a794729c184ad.png
>



> How to begin, though…? :)
>
>

The step 0 could be to copy and paste this post by Chris in a Texinfo
document

The step 1 could be to add a "post" about how to configure a desktop
environment based on openbox along the lines of what this post proposes
https://fedoramagazine.org/openbox-fedora/

And then who knows ☺

Re: Videos

[Catonano]

2018-05-29 17:45 GMT+02:00 Julien Lepiller :

> Le 2018-05-29 16:48, Ricardo Wurmus a écrit :
>
>> Hi Guix,
>>
>> I’d like us to produce a series of short videos (< 4 mins each) that
>> introduce functional package management with Guix.
>>
>> This is supposed to be aimed at people who are intimidated by the manual
>> and wouldn’t know where to begin reading.  Each of the videos should
>> focus on a single feature and be on the point.  The final seconds should
>> point the viewer to the manual to learn more.
>>
>> Who would like to be involved in the planning and production of the
>> videos?  There are many tasks such as:
>>
>> * collecting topics that should be covered
>> * writing canonical narration scripts for each episode
>> * translating the scripts into different languages
>> * recording the narrations in different languages
>> * drafting the storyboard for each video (i.e. what exactly is to be
>>   shown and for how long)
>> * recording the video portions
>> * mixing different audio tracks and the video track
>> * designing intro and outro frames
>> * recording or finding freely licensed music for the intro / outro
>> * coordinating with all volunteers
>>
>> What do you think?
>>
>> --
>> Ricardo
>>
>
> That sounds like a great plan! Of course I'd like to be involved in
> translating
> the script into French and I could probably record a French version of the
> videos
> too. I don't have any experience in the other fields, but I guess I could
> learn.
>
>

I think I have demonstrated my aptitude in recording video fragments on the
field 😄

As for storyboarding and scripting, instead, I'd love to receive
suggestions.

Also, I wouldn't know how to mix audio/video. What software could we use ?
I don't know.

my latest blog post

[Catonano]

I just published my latest blog post

In this post I discuss Guix

And I discuss Guile too

I understand that the language is strong and I expect someone to be upset

But I feel this is due

Happy reading

http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

Re: my latest blog post

[Catonano]

Mark,

2018-06-07 19:03 GMT+02:00 Mark H Weaver :

I appreciate you sharing your thoughts on this.  I wanted to apologize
> for making you feel badly; it honestly was not my intent to shame you in
> any way.
>

Thank you for your kind and measured words
I appreciate both the tone and the content of your reply

I am very reassured by your statement that you find my quuestions about
macro expansion reasonable and legitimate

My feeling was not positive and I'm only happy of having been wrong


> To be honest, I felt a bit defensive when you seemed to contradict my
> claim that 'macroexpand-1' would be difficult to implement in a modern
> Hygienic macro expander, when you pointed to the Racket documentation
> and asked (possibly rhetorically) whether Racket had hygienic macros.
> What felt to you like "slight shaming" might have been somehow related
> to my feeling defensive about this.
>

I see

On my side, I was a bit adversary because I feel that a macro stepper is a
fundamental feature of a scheme system and in Guile it's less than an
afterthought

I understand that implementing it is too much work

But I think that the manual should at least mention macro stepping as a
missing feature, it should mention the internal APIs that you indicated in
that thread and the uncertainties around them

What I want to convey is that the user shouldn't be left in the dark about
macro stepping

On the bright side, after this discussion, I offer to contribute a
paragraph for the manual where the macro stepping missing feature is
discussed

It will still be a missing feature, but at least the user will know what
she needs to know

I'd use the enlightening example you provided, the warings you raised and
the notions contained in the paragraph about the syntax helpers

Probably the part that's not about syntax helpers should be pulled out from
there and integrated in the new paragraph



> My lack of response until now to your most recent message in that thread
> was not because my "patience was exhausted", as you wrote, but only
> because I'm stretched far too thin, and I haven't yet figured out how to
> respond to your last message.
>
> I simply don't have enough time for all of the things I'd like to do, so
> many important things get dropped on the floor.  I respond to user
> questions and bug reports sporadically, when I have the time and energy
> to do so.  It's nothing personal.
>

I'm so relieved in learning you didn´t shrug it

Someone else made me notice that the lack of an answer can't always be
interpeted as an aggression, as I did in my post.

I did, indeed.

The lack of an answer hits me, admittedly

I apologize for being emotional about this


>
> For what it's worth, I think that your line of questions about
> 'macroexpand-1' was perfectly reasonable, and neither worthy of shame
> nor of feeling like an idiot.  The details of modern macro expanders are
> quite difficult, and I suspect that even seasoned Scheme hackers rarely
> understand them in depth.
>
>  Regards,
>Mark
>


thanks

Re: my latest blog post

[Catonano]

2018-06-08 6:24 GMT+02:00 Christopher Lemmer Webber 
:

> I think Catonano and Mark discussed things nicely earlier in the thread,
> so I'm not going to weigh in on that (though I do agree that we would
> can and should do better, but that also it's important to realize that
> community members only have so many personal resources to be able to
> respond sometimes).
>

Note taken. My bad


> Guile still matters a lot to me.  I think Guile has a long way to go,
> but I look at it more that there is an opportunity for us to do better
> than that we have failed currently.  What can we do to move in the right
> direction?
>

I think an important step is acknowledging the importance of the quality of
the experience with GNU tools, as Fis also remarked.

To me "the computer for the rest of us" is still a landmark

I know that Apple is not commonly associated with software freedom concerns

But the Apple computing experience has been empowering to countless people,
me included.

The experience does matter.

So, is a macro stepping facility missing ? Clearly state so in the manual

Andy Wingo has a post in which he lists tasks he'd lie to be implemented on
Guile, many of them have to do with the file format of the compiled files.

Some love should go to the quality of the experience too, not only to the
tech issues

Andy and Ludo are way too competent, they unawarely set the bar very high

This is a cognitive issue, I understand that, I'm not blaming anyone

Ludo openly said so in several occasions, he even included an indication
about where a funtion was being declared and where it was being called in a
scrap of Nix code, in one of his talks

And I think he did so because *I* had said that in Nix I could't
distinguish when a function was being declared and when it was being called

So he's aware of the problem

As for me I don't know exactly what cold be done

I tried to elicit some debate

I suggested some edits to the Guile manual

These are tiny steps, more could be envisioned; I just can't come up with
anything more right now

Allow me only one last remark

Fis claimed that the error messages that Guile provides them with don't
include indications about in which file the error occurred

So he's using Chez scheme instead of Guile, if I remember correctly

I take from this that the Chez scheme error mesages are better.

Mark wrote to Fis in that thread on the Guile mailing list that in order to
have better error messages, the compiler should be modified (and that would
be an awful lot of work)

This is similar to the contrast on macro stepping

Racket has a luxury macro stepping experience, Guile has no macro stepper

So how does Chez scheme manage to provide better error messages ?

I'm not trying to be adversarial again, here, Mark

I just think that the problem deserves to be mapped out so that people know
what they're getting into

I praise software freedom myself

But I think the empowerment component is being overlooked

My suspect is that over the years, Andy Wingo made some design choices in
implementing Guix that implicitly sacrificed the experience to the benefit
of performance, or oter technical aspects

Possibly because he was alone in this task and the amount of work he could
devolve into Guile was finite.

So now it's important to map things out so that we know where we are and
where we want to aim.

I know my contributions are extremely modest so I' not the most entitled
person to discuss the design of GNU tools

Please bear with me

Making my concerns known is all I can do right now

But I will look into the Guile manual in the coming days and I will try to
draft a decent tractation of macro stepping in Guile scheme

Re: my latest blog post

[Catonano]

2018-06-08 11:39 GMT+02:00 Nils Gillmann :

> Just my brief encouragement:
>

> I'm not sure how active the Guile documentation writer(s) are, but if you
> know how to write it or initially draft something that would be great.
> Writing the code is good, but documenting it affects much more people and
> would be a good outcome of the discussion :)
>
>
Thank you Nils, 🙏

I'll do my best 😊

(use lots of emojis !!)

Re: my latest blog post

[Catonano]

2018-06-08 15:49 GMT+02:00 Ludovic Courtès :

> Hello!
>
> Catonano  skribis:
>
> > In this post I discuss Guix
> >
> > And I discuss Guile too
> >
> > I understand that the language is strong and I expect someone to be upset
> >
> > But I feel this is due
> >
> > Happy reading
> >
> > http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
>
> Thanks for sharing your thoughts!  I pretty much agree with the kind
> words about the Guix group. ;-)
>
> I didn’t know (I suppose I didn’t pay attention) to what happened to you
> in Guile land, and I’m sad you experienced it and felt bad about the
> whole story.
>
> I feel that “GNU is toxic” and “Guile is toxic” are unhelpful, though.
> I mean, we are GNU, and we are Guile.  GNU has its own set of problems
> that we’ll have to deal with, and it’s a very big organization with its
> own history etc., so improving things is difficult.  But Guile is a
> small community, and I’m sure we can improve.
>

I agree that there's room for improvement

That's the reason why I wrote that post

I could have silently drift away and maybe move to Racket or to Pharo or to
knitting fishing nets, as thousands of people have already done

I thought that in providing my cut on the Guile experience I was providing
ground on which to operate

It was what I could do to help the Guile community to improve a bit.

I was maybe slightly presumptuos, yes


> To me, the lesson as a Guile co-maintainer is that we should be paying
> more attention in general.  I consider myself partly responsible for
> this in that, although I’m still officially co-maintainer,


Ah I didn't know this
I thought you were a _former_ comantainer

Had I nown you were still a comantainer, I wold have pinged you, when the
accident happened

I refrained from pinging you because I had understood that you had
explicitly stripped yourself of the Guile responsibility in order to
dedicate your efforts to Guix


> I haven’t
> been paying much attention to what’s going on on the Guile channels.  We
> shouldn’t let hostile conversations like the one you experienced on
> #guile through.


Definitely. I'm glad you acnowledge this



> Perhaps what we need is someone to step up and help out
> with Guile?  We should all care.
>

Should any initiative to improve the Guile channels come out of this, I
would consider this a huge success of my post 😊




>
> Thank you,
> Ludo’.
>
>
Thank you !

Re: my latest blog post

[Catonano]

Mark,

thank you again for your remarks

2018-06-08 20:05 GMT+02:00 Mark H Weaver :

> Hi Catonano,
>
> Thank you for your email.  I don't have time to make a proper response
> yet, but for now I will respond to just one point:
>
> Catonano  writes:
> > On my side, I was a bit adversary because I feel that a macro stepper
> > is a fundamental feature of a scheme system and in Guile it's less
> > than an afterthought
>
> As far as I know, Racket is the only Scheme implementation with a macro
> stepper for hygienic macros.  Do you know of any others?
>

Admittedly, no


> So, I strongly disagree that a macro stepper is a "fundamental feature
> of a scheme system".  In fact, Scheme first appeared in 1975, and first
> gained hygienic macros in 1986, but it was not until ~2007 that a macro
> stepper for Scheme appeared, for Racket (called PLT Scheme at the time).
> The paper, <https://www2.ccs.neu.edu/racket/pubs/gpce07-cf.pdf>,
> described it as "the first macro stepper for Scheme".
>

Oh wow !
I didn'tnow this article existed, I'll go to print it today !
Thanks for indicating that !


> > I understand that implementing it is too much work
>
> It's not that it's too much work; it just hasn't yet been done.
>
> > But I think that the manual should at least mention macro stepping as
> > a missing feature,
>
> If it were part of a Scheme standard, or even a very commonly
> implemented extension, then I would agree that we should document its
> absence.  However, as far as I know, Racket is the only Scheme
> implementation that has a macro stepper.  So, this is not a feature that
> users generally expect to have in a Scheme implementation.
>
> I disagree that the Guile manual should specifically call attention to a
> missing feature that almost no other Scheme implementation includes.
>
> Whenever people switch from one Scheme implementation to another, they
> will notice many missing features and APIs, and some new ones.  In your
> case, you noticed that Guile lacks Racket's macro stepper, but there are
> a great many other things in Racket which Guile lacks.
>
> If we were to start documenting all of the features that exist in at
> least one Scheme implementation as missing features, that's quite a
> slippery slope.  I don't want to go down that slope.
>
> If this were a common confusion among our users, then there would be
> some justification for this, but it's not a common confusion.  In the
> decade since the first Scheme macro stepper was invented, you are the
> _only_ person who has reported confusion from the absence of this
> feature in Guile.
>
> That's not to say that you're unreasonable; it's simply due to your
> particular experience of being acquainted with this feature of Racket
> and perhaps being surprised that Guile didn't have it.  This same thing
> could happen with _any_ feature of _any_ Scheme implementation.
>
> Does that make sense?
>

Yes, it does mae sense.

But I respectfully disagree

It's not that I don't see your point. Documenting Racet features as missing
features is not a slope you want to roll along and I wouldn't want either

But I still think a macro stepper is a fundamental feature of any scheme
system

The fact that only Racket provides a macro stepper is quite sad

But that says something of why scheme is a niche language, albeit being so
elegant and powerful

Tooling is not optional and it shouldn't be an afterthought

It shouldn't be, because the experience of the naive programmer _does
matter_

The maturity of tooling is one of the ranks used to evaluate the viability
of programming environments

I have been playing with Clojurescript before approaching Guix and in the
beginnings the clourescript tooling was sorely lacking many features and
lagging in many ways

But that was acnowledged as a problem or at least as a legitimate whish
list issue

In my post I argued that the communities of other programming languages are
way more thriving than the Gule one

I think that your approach to macro stepping is an example of what's wrong
with this culturre, that is in part academic, in part GNU

I acknowledged that this is  a cognitive problem, I acknowledged that
there's a lack of resources

But I won't acknowledge that this is ok

It's not

So I understand that you don't want the manual states macro stepping as a
missing feature

But I think that macro stepping should be explicitly mentioned

Maybe it could be somethiing along the lines of

"
a tool that should go along with hygienic macrro expansion is a macro
stepping facility, in order to allow people to dissect and learn macro
based libraries

Guile has no macro stepper but not al

Re: my latest blog post

[Catonano]

2018-06-08 16:25 GMT+02:00 Ricardo Wurmus :

>
> Hi Catonano,
>
> > Andy Wingo has a post in which he lists tasks he'd lie to be implemented
> on
> > Guile, many of them have to do with the file format of the compiled
> files.
> >
> > Some love should go to the quality of the experience too, not only to the
> > tech issues
>
> These are very closely linked.  I mention this because it may not be
> obvious to people like myself who don’t work on compilers.
>
> FWIW, people *are* working on improving the experience of programming
> with Guile.  Some do this by working on Geiser, others by writing
> libraries that are well-suited for exploratory programming with Geiser,
> etc.
>

I know

I'm not negating anyone's efforts

> Mark wrote to Fis in that thread on the Guile mailing list that in order
> to
> > have better error messages, the compiler should be modified (and that
> would
> > be an awful lot of work)
>
> Exactly.  Please note that the compiler is currently being modified, so
> it is not a good idea to start other big architectural changes right
> now.
>
> > I just think that the problem deserves to be mapped out so that people
> know
> > what they're getting into
>
> Certainly.  We cannot demand of other people to do this work for us,
> though.


I'm not demanding anything to anyone

I *offered* to edit the manual in a way that is more bearable in my
opinion, in regard to macro expansion.

I don't now if I will ever be able to offer a proper macro stepping tool

Should I be able, I'd be glad to provide the community with it


> If you follow guile-devel you will also see that some compiler
> changes have resulted in certain regressions, which are debugged,
> addressed, and ultimately fixed.  Losing certain means of debugging
> things would also be considered a regression, and they can generally be
> handled in the same way.
>

Again: I didn't negate anyone's work

I explicitl wrote that what made the difference is not the technology


> Andy’s time is still limited.  What other people can do is discuss
> *specific* cases on guile-devel and work towards a solution.  But please
> do not demand of others to explain everything in detail.  (I’m directing
> this at everyone who heeds my advice to go to guile-devel, not at any
> one person in particular.)  In order to have a positive impact you also
> need to learn enough about the state of the art to ensure that the
> discussions can be productive.
>

I think I demonstrated I am ready to put some effort into this

And I think this remark is unfair

I know Andy was in good faith. I acknowledged again and again that there is
a cognitive (cultural ?) problem

What I proposed is to focus on where we are now so that the right direction
can be envisioned

I didn't scream that I want better error messages _right now_

Maybe the lesson here should be that the quality of the experience should
be taken into account in the first place and not as an afterthough, as if
it was the need of a random user

I was trying to underline the feedback that was brought here by a user

And I brought some feedback myself

Believe it or not, I am trying to _help_ Guile to improve

And the improvement is not technological, it's cultural

And saying I should come on guile-dev and actually provide what I thin is
useful, nowing that I can't (not immediately is not a fair answer either

Because it's equivalent to a "fuck you"

This is discussed in some of the links I provided too

I devolved some time in making my case

It's some articulated and well thoug feedback. Of the kind that the Guile
community is sorely missing

As for macro expansion, how would I have been supposed to know the context
of macro expansion ?

Shouldn't I have been asking ?



> For compiler design I have a lot of things to read before being able to
> contribute meaningfully to a discussion; all I can do is record
> instances where Guile produces poor error messages and try to figure out
> what led to this outcome.  Once I’ve done my work I can share this with
> other developers and get their input.
>

I don't know if I will ever delve into the compiler

For now, I just wanted to understan the store monad

Macro expansion is the first step of compiling, as far as I understand,
anyway.

So taking care that it's reasonably discussed could be a first step in
having more compiler hackers, some day

I am trying to contribute from where I am, not from where you require me to
be

And this is valuable too, to some extent

If you don't see this, than you are confirming the cultural problem that I
strived to depict

Some final remarks:
>
> I should say that I’m rather unhappy with your labelling of the Guile
> community as “toxi

Re: my latest blog post

[Catonano]

2018-06-09 12:39 GMT+02:00 Ricardo Wurmus :

>
> Catonano  writes:
>
> > Assuming that users read academic articles about programming languages in
> > order to know your way aroung Guile is not reasonable
>
> I fail to see how this follows from Guile’s lack of a macro stepper.


Then you were not following

Mark indicated me a paper about the first macro stepper in history


> To
> be honest, I never even heard of a macro stepper before.


I haden't heard of it neither

I am following Mark's distinction, here, between a macro stepper and
macroexpand-1

I don't know if other schemes lack macroexpand-1 too but at this point it
wouldn't be relevant anymore


> And I have
> never felt the need to read computer science papers to “know my way
> around Guile”.  (I have not studied computer science, so it isn’t that
> my background allowed me to skip papers that are mandatory for other
> users of Guile.)
>
> The sentence above seems like an exaggeration to me.
>

Ok, thans for your contribution


> (I say this with no hostility, just with surprise.)
>

we have a lng way to go



>
> > The monad accessing the daemon, how would I delve in it ?
>
> The Guix manual should explain it fully, while assuming that the concept
> of a monad is known (because that’s not a Guix or Guile invention).


And how would I know what a monad is without reading academic materials ?

Maybe Haskell is a requirement in order to use Guile//Guix ?

"assuming that the concept of a monad is known" is a problem.

Someone would want to _learn_ what a monad is AND how it can be implemented
in scheme, by dissecting this Guix macro based feature

Do you think that the code should be kept obscure and unaccessible ?

So much for the Emacs of distros

Re: my latest blog post

[Catonano]

Ricardo,

you are right that in my last interaction there was some animosity and the
message was below the standard

I apologize

I see that you are maing an effort to deescalate. I appeciate that. Really

I also see that you are suggesting some techical remediation about the
store monad

And that is probably the most interesting result that came out of this
discussion until now

After all, I just wanted to understad what this monad macro does.

I'm sure you are in god faith and we are just having a misunderstanding due
to the fact that we come from different bacgrounds, even if you didn't
study computer science

In this very moment, I'm not abe to keep interacting lucidly, though

Because I lost my cool and I got tired

So I can't bring myself to read your technical contribution.

I probably need some time to regain my composture

I will probably go to the  beach to blow some steam off

I'll try again starting next monday, if you don't mind

So I can be more consequential, hopefully

For now, just a few notes

The first note is that macro expanding and macro stepping are not the same
thing


2018-06-09 14:14 GMT+02:00 Ricardo Wurmus :

>
> Hi Catonano,
>
> > 2018-06-09 12:39 GMT+02:00 Ricardo Wurmus :
> >
> >>
> >> Catonano  writes:
> >>
> >> > Assuming that users read academic articles about programming
> languages in
> >> > order to know your way aroung Guile is not reasonable
> >>
> >> I fail to see how this follows from Guile’s lack of a macro stepper.
> >
> >
> > Then you were not following
> >
> > Mark indicated me a paper about the first macro stepper in history
>
> I did follow the discussion and I did see Mark mentioning the paper.
> Since Guile does not *have* a macro stepper, reading a paper about how a
> macro stepper was implemented is certainly not a requirement to use
> Guile.


Ok. I was following a thought of mine, I had to mae more explicit, probably

In my view, hacking a quick and dirt macro stepper and then use it to
explore some existing macros *IS* a requirement to use guile

Because there are some macro based libraries, so using a macro stepper is a
requirement for common usage

As I wrote, if you provide a language feature, you need to provide the
tooling for it too

The fact that Guile has no macro stepper is not enough to thin that using a
macro stepper is not a requirement
It's enough to think that Guile is missing a fundamental bit

But I understand that we can disagree on this

Obviously, to implement a macro stepper it is useful to know how
> to do this.  But implementing a macro stepper is not what a Guile user
> like myself would ever do.
>

Eh.
It seemed to me that implementing a macro stepper was reqired to me in
order to undertsand some existing macros

Maybe your last techical contribution, the one that I can't read rright
now,  proves this false

I'll try again next week and report back

Thanks for clarifiyng


> >> And I have
> >> never felt the need to read computer science papers to “know my way
> >> around Guile”.  (I have not studied computer science, so it isn’t that
> >> my background allowed me to skip papers that are mandatory for other
> >> users of Guile.)
> >>
> >> The sentence above seems like an exaggeration to me.
> >>
> >
> > Ok, thans for your contribution
> >
> >
> >> (I say this with no hostility, just with surprise.)
> >>
> >
> > we have a lng way to go
>
> I sense a lot of hostility in your responses to me and I don’t know why
> that is.  The first sentence reads like unwarranted sarcasm to me,
> because it does not seem to relate to what I wrote; the second sounds
> belittling, as if my surprise at what seems like an exaggeration to me
> is evidence of how far behind I am in my efforts to ensure that Guix and
> Guile a welcoming to newcomers.
>
> I’m sorry that you don’t find anything useful in my response above,
> which relates my personal experience with Guile as someone who is not a
> computer scientist.  I hoped it would be a useful data point.
>

I' sure it is a data point

I'm not sure what you think it means

Does it mean that I had it coming ?

You think that I indiced David Pirotte in assaulting me in that way ?



> As I find discussions like this exceptionally draining and discouraging,
> detrimental to my ability to volunteer time to free software, I will
> take some time off from this discussion after trying to respond to your
> other message to me in this thread.
>
> >> > The monad accessing the daemon, how would I delve in it ?
> >>
> >> The Guix manual should explain it fully, while assuming that the concept
> >> o

Re: my latest blog post

[Catonano]

2018-06-09 14:24 GMT+02:00 Ricardo Wurmus :

>
> Catonano  writes:
>
> >> Andy’s time is still limited.  What other people can do is discuss
> >> *specific* cases on guile-devel and work towards a solution.  But please
> >> do not demand of others to explain everything in detail.  (I’m directing
> >> this at everyone who heeds my advice to go to guile-devel, not at any
> >> one person in particular.)  In order to have a positive impact you also
> >> need to learn enough about the state of the art to ensure that the
> >> discussions can be productive.
> >>
> >
> > I think I demonstrated I am ready to put some effort into this
> >
> > And I think this remark is unfair
>
> I wrote this:
>
>But please do not demand of others to explain everything in detail.
>(I’m directing this at everyone who heeds my advice to go to
>guile-devel, not at any one person in particular.)
>
> Rephrasing: I’d like to point this out to people who take this
> opportunity to bemoan the lack of other features or who disagree with
> what they think are different priorities.  You do not feel addressed if
> you know you’ve made efforts in this area.
>

This is another of your points I can't process now

I'll try again later



>
> > And saying I should come on guile-dev and actually provide what I thin is
> > useful, nowing that I can't (not immediately is not a fair answer either
> >
> > Because it's equivalent to a "fuck you"
>
> Wow.  No.
>
> I think that’s an *extremely* uncharitable reading of what I wrote.  I
> will refrain from further comments in this thread lest what I write will
> be misconstrued in a similar fashion.
>

O, I'll try to clarify this one too.
Just not now



>
> >> With regards to the shouting match on #guile that you linked in your
> >> blog post, I can only say that I would have likely stepped in had this
> >> happened when I was around.  Textual communication certainly should not
> >> reach these levels of apparent aggression.
> >>
> >
> > What do you mean with "apparent" ?
>
> I’m pretty bad at gauging emotion in textual communication and it’s
> generally not easy to infer the intended tone in short text messages.
> That said, the exchange you linked to appeared to me to be of an
> aggressive nature.  That’s what I mean by “apparent”.
>


It was of an aggressive nature

I was assaulted in an arbitrary, unwarranted and uncalled for way

It was wild

Because I had used G-golf as an example

I had also used Skribilo as another example

You now what Ludo did ?

Instead of calling me an hopeless moron unwilling to learn, he went and
updated Skribilo, without saying a single word

I noticed

And I appreciated it

So, yes, it was aggressie indeed

Again. I'll try to be more complete later

Re: my latest blog post

[Catonano]

2018-06-10 2:51 GMT+02:00 Mark H Weaver :

> myg...@gmail.com writes:
>



>
> Are there any other acceptable responses, in your view?
>

I already proposed a way forward and I even asked you if you would refuse
to merge it

I see you attitute towards that, now.

Also:

yesterday night, before going to bed, I tought that you were nt answering
because you were "busy"

Maybe you were in a different time zone

the lack of an answer is not necessarily aggresion, someone of you noted

But then, when someone agrees with me, you reply instantly, with the usual
pathetic superiority and smugness

There, you have the Guile utter failure

You are a asshole, Mark

Regards

Re: my latest blog post

[Catonano]

2018-06-10 0:49 GMT+02:00 :

> On 06/07/2018 at 17:25 Catonano writes:
>
> > I just published my latest blog post
> >
> > In this post I discuss Guix
> >
> > And I discuss Guile too
> >
> > I understand that the language is strong and I expect someone to be upset
> >
> > But I feel this is due
> >
> > Happy reading
> >
> > http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
>
> Hi Catonano,
>
> Thank you for taking the time to contribute your thoughts. I am sorry to
> see you getting so beat up by the responses.  Unfortunately the
> nit-picking of criticisms and the "we are busy, why don't you dig in and
> fix it" responses occur too often on the Guix lists.
>
> Such responses are fundamentally unhelpful: A defensive response of
> counter-criticism that spirals out of control buries the original input
> and alienates potential new contributors. I agree with you that the
> suggestion that you dig in and fix something you are struggling with is
> a fundamentally unfriendly response.
>
> I appreciate the effort you made to learn Guix and the risk you took to
> report on the problems you experienced. I am interested in getting to
> the root causes of your frustration. I re-read your post and
> emails. Would it be fair to say ...
>
> 1) The monad/daemon/store is presented as central to Guix and is very
> difficult to understand. If a Guix user really needs to understand it,
> it needs to be explained better.
>
> 2) Sending Guix users upstream for Guile support is not working.
>
> If these are correct, the reality is that only a few people on the
> planet are in a position to address these issues. The rest of us have to
> hope that they can see why it is important to stop coding long enough to
> do so, perhaps in collaboration with a confused user or two ;-)
>
> - George
>

Thank you George, I appreciate this

I alredy had 2 people writing to me _in private_ acknowledging my efforts

I invited them to "come out" but they didn't

So much for Guile friendliness

People are scared to speak their minds

Now, don't worry I won't revelate who you are

I just want to record the sorry state of this community

Re: my latest blog post

[Catonano]

2018-06-10 8:55 GMT+02:00 Pjotr Prins :

> On Sat, Jun 09, 2018 at 08:51:59PM -0400, Mark H Weaver wrote:
> > myg...@gmail.com writes:
> > > Thank you for taking the time to contribute your thoughts. I am sorry
> to
> > > see you getting so beat up by the responses.  Unfortunately the
> > > nit-picking of criticisms and the "we are busy, why don't you dig in
> and
> > > fix it" responses occur too often on the Guix lists.
> > >
> > > Such responses are fundamentally unhelpful: A defensive response of
> > > counter-criticism that spirals out of control buries the original input
> > > and alienates potential new contributors. I agree with you that the
> > > suggestion that you dig in and fix something you are struggling with is
> > > a fundamentally unfriendly response.
> >
> > What kind of response would you consider acceptable?
> >
> > I suppose the most helpful response would be for one of us to volunteer
> > our time to fix the bug, or to implement the feature you desire.
> >
> > Are there any other acceptable responses, in your view?
> >
> >Mark
>
> And here we arrive at a fundamental problem that all *complex* free
> software projects that have with many users. And these discussions end
> up hurting/upsetting everyone involved!
>
> The fact is that only a few people really understand any chosen part
> of the project.
>
> And these people tend to have day jobs, families and work on the
> project in their spare time. In that spare time (maybe only a few
> hours a week) they make choices what to work on - and, yes, it tends
> to be what they think most important. Not what others think most
> important. The Clojure developers are considered haughty and give
> others the cold shoulder.  The Dlang people are very open, and get a
> lot of abuse and kranks on their forum in return. You just can't win!!
> It is easy to find examples about this. Some projects, notably Elixir,
> are exceptionally good at the balancing act. But, it is not for
> everyone. If you take Guile, what started this thread, it is really
> one core language maintainer. What talent! Nothing to stop you from
> jumping in...
>
> I think Guix is a great project. Not only does it scale (ref.
> the number of weekly contributors), the maintainers do a good job of
> being nice where it matters. Guix had a community day at FOSDEM and out
> of that came the recent work on 'guix pull' which is a great
> improvement, ultimately asked for by the user community! I think that
> is amazingly good.
>
> Mark, indeed, from a contributor perspective the natural response is
> to volunteer work on a topic users ask for. Since we write code, we
> think in terms of responding in code. But that is not what this thread
> is about. Here we have users who want *attention* for their
> concern(s).


Ok. So ... ?


> My response to such users is two-fold: (1) dig in and prove
> you understand the issue first. A lot of response goes by merit you
> acquire. People tend to spend time on people they like/respect. So,
> George, it is not a knee-jerk reaction. It is easy to talk, much less
> easy to do. And coders and project maintainers know that. And (2)
> bring up real issues on the bug tracker and try to fix them. That way
> you get attention.
>
> So, yes, dig in and try to fix it ;)
>

Ah, I see

So: nothing.

Pjotr I ALREADY offered a contribution

The manual discusses some internal APIs in a paragraph about something else

That's unrespectful of reader's time

I proposed some edits

I keep reading, all around, that also not coding contributions are valuable

Are they ?

I also argued that macros are a part of scheme but the debugging
infrastructure doesn't cover them, at all

But of course, this is "talking", maybe I'm too entitled



> As in chess or football, people who acquire merit get taken seriously.
> Not the person shouting on the side-line - unless they are respected
> in some other way (maybe by giving money or other resources).
>

I'm glad I'm flushing out, people

You are expressing all your jerkiness in all its glory :-)



> Talk is cheap. Coding is hard.


Thinking is even harder


We are always balancing this. I don't
> contribute much to Guix at this point (other than talk ;), but we face
> the exact same problems in other projects I am involved in. I get most
> upset by the sense of entitlement that people have just because they
> *use* my  work. Many an E-mail I wrote, but did not send, to users,
> just to vent steam. I have a feeling I am not the only one. I.e., it
> is not easy running a free software project. We want and like our
> users, but not at all cost.
>

All costs ?

I repeat: the manual sucks and I proposed an edit to make it suck a bit less


I think we should close this topic unless there are concrete
> suggestions on how to improve and scale Guix development. As George
> writes, we can encourage new contributors and users more,


like you're doing with me ?


> but I doubt
> the route is to take core contributors away from their

Re: my latest blog post

[Catonano]

2018-06-10 11:26 GMT+02:00 Ricardo Wurmus :

>
> Catonano,
>
> this language is not at all acceptable anywhere on Guix as you can see
> by referencing the Code of Conduct.
>
> --8<---cut here---start->8---
> Examples of unacceptable behavior by participants include:
>
> * The use of sexualized language or imagery and unwelcome sexual attention
> or
> advances
> * Trolling, insulting/derogatory comments, and personal or political
> attacks
> * Public or private harassment
> * Publishing others’ private information, such as a physical or electronic
> address, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
> professional setting
> --8<---cut here---end--->8---
>
> It is one thing to call for a more welcoming community and quite another
> to call people names and to assert that they act in bad faith as you
> have been doing in the past days.  Please stop right now.
>
> I encourage all to re-read the Code of Conduct.  You can find it in the
> Guix git repository or online here:
>
> http://git.savannah.nongnu.org/cgit/guix.git/plain/CODE-OF-CONDUCT
>
> --
> Ricardo
>


you chose to enfforce only some violations, not all of them

I am not surpried at all

Re: my latest blog post

[Catonano]

2018-06-10 11:29 GMT+02:00 Ricardo Wurmus :

>
> Catonano  writes:
>
> > They made a conduct report but nothing happened, eventually they had to
> > talk to Ludo directly
>
> From the Code of Conduct:
>
>Instances of abusive, harassing, or otherwise unacceptable behavior
>may be reported by contacting the project team at
>guix-maintain...@gnu.org. All complaints will be reviewed and
>investigated and will result in a response that is deemed necessary
>and appropriate to the circumstances.
>
> Reports made to the maintainers (i.e. Ludovic and myself) are taken
> seriously.
>
> --
> Ricardo
>
>

I reported the assault David Pirotte made to me

it was not taken seriously

Apologies

[Catonano]

In my last interaction on this list, my behaviour was inappropriate

I used some foul language

I shouldn't have

I understand I hurt Ricardo's, Pjotr's and Mark's feelings

Of course there's some difference in our backgrounds, but instead of
properly discuss it, I ended up resorting to unfairness

In so doing I undermined not only people's willingness to engage in Guix as
a project but also my own arguments.

It happened simply because I lost it, I got carried away

I apologize

Re: [outreach] Help trying to create R package

[Catonano]

Hi Laura !

Il giorno sab 13 ott 2018 alle ore 15:37 Laura Lazzati <
laura.lazzati...@gmail.com> ha scritto:
>
>  Hi!
> I'm creating a new thread so that it does not end up messy.
> I am reading about defining new packages, and since I have always
> installed R with apt, I am trying to do so with ./configure make make
> install to have it running on my VM, and then try to create the
> package and check if both works

you don't need to package R yourself, R is already packaged and available
in Guix, i believe.

If you want to package a R based package for Guix you can use the so called
Cran importer

Try this line at the prompt

guix import cran your-R-package

This line invokes a so called importer and the importer should return you
the recipe of your R package written in scheme

You could append such definition to an existing Guix file (probably with
some minor tweaks) and that should allow you to build the package and all
the dependencies will be taken care of automatically

I did this myself some time ago

In order to append the definition of your package to an existing Guix file
you will probably need some more guidance, but for now you could just run
the importer and let us now what you obtained

Probably you'll need to build the package, then modify the recipe a bit,
build it again... for a few times; that's ok

You can read about the importers here

https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-import.html#Invoking-guix-import


> substitute: guile: warning: failed to install locale
> substitute: hint: Consider installing the `glibc-utf8-locales' or
> `glibc-locales' package and
> substitute: defining `GUIX_LOCPATH', along these lines:
> substitute:
> substitute:  guix package -i glibc-utf8-locales
> substitute:  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
> substitute:
> substitute: See the "Application Setup" section in the manual, for more
info.
>
> When I run guix package -I I get:
> hello2.10out
 /gnu/store/bihfrh609gkxb9dp7n96wlpigiv3krfy-hello-2.10
> recutils1.7out
> /gnu/store/6h02na6yz9smc7c7g62ss03kp4yhqpc1-recutils-1.7
> glibc-locales2.27out
> /gnu/store/s28fmfrq8r0c688x59cj0fcyh2pv87nj-glibc-locales-2.27
> glibc-utf8-locales2.27out
> /gnu/store/mbns811n696fl7g060cx6jqjh75mlj8i-glibc-utf8-locales-2.27
> gfortran7.3.0out
> /gnu/store/mw65pcca7x7mmq8v2r427f3plrahhyxl-gfortran-7.3.0
> zlib1.2.11out
 /gnu/store/fxiwj2wpp11sif613axdax7gmwzsg6kp-zlib-1.2.11
> bzip21.0.6out
 /gnu/store/rw1ilvs76rf2p4p0bi1fx3bffprwwb7g-bzip2-1.0.6
>
> And even at the bottom of my .bashrc I have:
>
>   export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
> export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
> export CPATH="/home/laura/.guix-profile/include${CPATH:+:}$CPATH"
> export
LIBRARY_PATH="/home/laura/.guix-profile/lib${LIBRARY_PATH:+:}$LIBRARY_PATH"

when running Guix on top of a foreign distribution, this problem is very
common.
I lived with this for several months myself

Reaching a solution to this can be tedious and often the solutions are
short lived

Because this has to do with how the basic C libraries provided by Guix and
those provided by the foreign distro relate with each other (usually not so
well)

But this is not critical, you can successfully package some R based
packages for Guix anyway

Hope this helps !

Re: guix pull: error: symlink: File exists

[Catonano]

Il mer 31 ott 2018, 12:53 Gábor Boskovits  ha scritto:

> Hello Laura,
>
> It took me some time time to get this working, as
> there are some confusions around the startup files, so here it goes:
>
> There is no need for .bash_profile, I added the PATH export to:
> .profile : to have it when logging in through ssh or on the console.
> (this file did exists)
> .xsessionrc : to have them when I start a terminal on my desktop (it is
> xfce)
> (i had to create this file)
>
>

Re: [Feature idea] Adding wikidata, wikipedia & screenshot-url fields to package-recipes

[Catonano]

Il giorno ven 2 nov 2018 alle ore 00:20 swedebugia 
ha scritto:

> Hi Amirouche
>
> On 2018-11-01 14:37, Amirouche Boubekki wrote:
>
>
> Implementation:
>
> It could be implemented by adding the fields to package-objects.
>
> nitpick, those are records in guile scheme.
>
> Did you mean to correct my use of "object" here?
> Your are right about that.
>
> Scheme Syntax: *define-record-type*
>
>
>
> *type (constructor fieldname …) predicate (fieldname accessor [modifier])
> … *
> I finally begin to understand all these words an Scheme-ways of doing
> things.
>
> Have I understood correctly that we have at least 1 nested record types in
> guix? E.g. the package record contains an origin record and a lot of other
> fields.
>

yes, that's correct

Re: Membership disabled due to excessive bounces

[Catonano]

Il giorno dom 11 nov 2018 alle ore 12:02 Amirouche Boubekki <
amirou...@hypermove.net> ha scritto:

> On 2018-11-11 11:58, Pierre Neidhardt wrote:
> > Hi Guix,
> >
>
> Hi!
>
> >
> > I've re-enabled my membership both times.
> >
> > My email is hosted by https://gandi.net (I use their email hosting
> > service).  I send emails with Emacs' mu4e if that matters.
> >
> > Does anyone know why this happens?  I've never had this issue before
> > with any other mailing list (most of them also hosted by Mailman).
>
> I have the same issue with gandi, I use the webmail.
>
>
>
it happened to me too

Obviously, I use gmail

Re: Bug in my WIP-npm-importer with blacklist

[Catonano]

Il giorno dom 25 nov 2018 alle ore 14:21 swedebugia 
ha scritto:

> Hi
>
> I am still a novice in guile so I humbly ask for help with this error
> trying to get the blacklisting to work:
>
> sdb@komputilo ~$ ~/guix-tree/pre-inst-env guix import npm leaflet
> ice-9/boot-9.scm:222:17: In procedure map1:
> Syntax error:
> /home/sdb/guix-tree/guix/import/npm.scm:304:2: source expression failed
> to match any pattern in form (if (member (cut guix-name "node-" <>)
> blacklist))
>
> The relevant code is in npm.scm as detailed in the error above.
>
> The files are attached.
>
> Thanks in advance!
>
>
There are 2 observations I can give

The first one is that member" returns a boolean value (#t or #f) and your
function can return just that, you don't need the if

But even if you needed the if, you have to pass it at least 2 forms: a test
and another expression whose value will be returned if the tests succeeds
(that is, it evaluates to #t)

In your code you are passing the if form only one expression.

The only expression you are passing to the if is

(member (cut guix-name "node-" <>) blacklist)

if this subexpression evaluates to #t, what is the if supposed to do ?

You could have written


(define (blacklisted? guix-name)
  "Check if guix-name is blacklisted. RETURN #t if yes, else #f."
  (if (member (cut guix-name "node-" <>) blacklist) #t #f))

in this exaple, if the subexression evaluates to #t, the if form can return
#t, which is

but as you can see (this is my second observation), this formulation is a
bit redundant

It can be rewritten without the if at all, lie this

(define (blacklisted? guix-name)
  "Check if guix-name is blacklisted. RETURN #t if yes, else #f."
  (member (cut guix-name "node-" <>) blacklist)))


In this formulation, if the subexpression

(member (cut guix-name "node-" <>) blacklist))

returns #t, your function will return #t, because your function returns the
value off its last subform

if the subexpression returns #f, of course your function will return  #f

That's supposedly what you wanted to achieve, isn't it ?

You can achieve it without the if 😊

Usually when Guile laments that a source expression doesn't match any
pattern, that's because you messed up the parenses or because you passed
the wrong number of subexpressions to a form

Please note that in this case Guile is not denouncing that the wrong number
of arguments were passed to a function

Because the "if" is not a function, it's a special form (I think), and the
expander tries to recognize a known "pattern" in it

It fails and it gives up

Hope this helps

Re: Bug in my WIP-npm-importer with blacklist

[Catonano]

because I made so many typing mistakes, I corrected my text and I'm posting
it again, corrected







There are 2 observations I can give

The first one is that "member" returns a boolean value (#t or #f) and your
function can return just that, you don't need the if

But even if you needed the if, you have to pass it at least 2 forms: a test
and another expression whose value will be returned if the tests succeeds
(that is, it evaluates to #t)

In your code you are passing the if form only one expression.

The only expression you are passing to the if is

(member (cut guix-name "node-" <>) blacklist)

if this subexpression evaluates to #t, what is the if supposed to do ?

You could have written


(define (blacklisted? guix-name)
  "Check if guix-name is blacklisted. RETURN #t if yes, else #f."
  (if (member (cut guix-name "node-" <>) blacklist) #t #f))

in this exaple, if the subepxression evaluates to #t, the if form can
return #t, which is the second (sub)expression passed to it

Of course, if the (first) subexpression evaluates to #f, then your if form
will return #f, wich is the third (sub)expression passed to it

but as you can see (this is my second observation), this formulation is a
bit redundant

It can be rewritten without the if at all, like this

(define (blacklisted? guix-name)
  "Check if guix-name is blacklisted. RETURN #t if yes, else #f."
  (member (cut guix-name "node-" <>) blacklist)))


In this formulation, if the subexpression

(member (cut guix-name "node-" <>) blacklist))

returns #t, your function will return #t, because your function returns the
value off its last subform

if the subexpression returns #f, of course your function will return  #f

That's supposedly what you wanted to achieve, isn't it ?

You can achieve it without the if 😊

Usually when Guile laments that a source expression doesn't match any
pattern, that's because you messed up the parenses or because you passed
the wrong number of subexpressions to a form

Please note that in this case Guile is not denouncing that the wrong number
of arguments were passed to a function

Because the "if" is not a function, it's a special form (I think), and the
expander tries to recognize a known "pattern" in it

It fails and it gives up

Hope this helps



Il giorno lun 26 nov 2018 alle ore 20:39 Catonano  ha
scritto:

>
>
> Il giorno dom 25 nov 2018 alle ore 14:21 swedebugia 
> ha scritto:
>
>> Hi
>>
>> I am still a novice in guile so I humbly ask for help with this error
>> trying to get the blacklisting to work:
>>
>> sdb@komputilo ~$ ~/guix-tree/pre-inst-env guix import npm leaflet
>> ice-9/boot-9.scm:222:17: In procedure map1:
>> Syntax error:
>> /home/sdb/guix-tree/guix/import/npm.scm:304:2: source expression failed
>> to match any pattern in form (if (member (cut guix-name "node-" <>)
>> blacklist))
>>
>> The relevant code is in npm.scm as detailed in the error above.
>>
>> The files are attached.
>>
>> Thanks in advance!
>>
>>
> There are 2 observations I can give
>
> The first one is that member" returns a boolean value (#t or #f) and your
> function can return just that, you don't need the if
>
> But even if you needed the if, you have to pass it at least 2 forms: a
> test and another expression whose value will be returned if the tests
> succeeds (that is, it evaluates to #t)
>
> In your code you are passing the if form only one expression.
>
> The only expression you are passing to the if is
>
> (member (cut guix-name "node-" <>) blacklist)
>
> if this subexpression evaluates to #t, what is the if supposed to do ?
>
> You could have written
>
>
> (define (blacklisted? guix-name)
>   "Check if guix-name is blacklisted. RETURN #t if yes, else #f."
>   (if (member (cut guix-name "node-" <>) blacklist) #t #f))
>
> in this exaple, if the subexression evaluates to #t, the if form can
> return #t, which is
>
> but as you can see (this is my second observation), this formulation is a
> bit redundant
>
> It can be rewritten without the if at all, lie this
>
> (define (blacklisted? guix-name)
>   "Check if guix-name is blacklisted. RETURN #t if yes, else #f."
>   (member (cut guix-name "node-" <>) blacklist)))
>
>
> In this formulation, if the subexpression
>
> (member (cut guix-name "node-" <>) blacklist))
>
> returns #t, your function will return #t, because your function returns
> the value off its last subform
>
> if the subexpression returns #f, of course your function will return  #f
>
> That's

Re: Naming of node packages with @ and /

[Catonano]

Il giorno mar 27 nov 2018 alle ore 21:58 swedebugia 
ha scritto:

> Hi
>
> There are some crazy naming going on in the node-community. How do we
> deal with this?
>
> Note: there is another package called "babel-core" so just
> stripping/replacing the weird characters won't work well.
>
> Any ideas?
>
> Look this example:
> https://github.com/babel/babel/blob/master/packages/babel-core/package.json
>
> Extract:
> {
>"name": "@babel/core",
>"version": "7.1.6",
>"description": "Babel compiler core.",
>"main": "lib/index.js",
>"author": "Sebastian McKenzie ",
>"homepage": "https://babeljs.io/";,
>"license": "MIT",
>
> snip
>
>"dependencies": {
>  "@babel/code-frame": "^7.0.0",
>  "@babel/generator": "^7.1.6",
>  "@babel/helpers": "^7.1.5",
>  "@babel/parser": "^7.1.6",
>  "@babel/template": "^7.1.2",
>  "@babel/traverse": "^7.1.6",
>  "@babel/types": "^7.1.6",
>  "convert-source-map": "^1.1.0",
>  "debug": "^4.1.0",
>  "json5": "^2.1.0",
>  "lodash": "^4.17.10",
>  "resolve": "^1.3.2",
>  "semver": "^5.4.1",
>  "source-map": "^0.5.0"
>},
>"devDependencies": {
>  "@babel/helper-transform-fixture-test-runner": "^7.0.0",
>  "@babel/register": "^7.0.0"
>}
> }
>
> --
> Cheers Swedebugia
>
>
I think those are the so called "scoped packages"

https://docs.npmjs.com/misc/scope

https://nitayneeman.com/posts/understanding-scoped-packages-in-npm/

Re: Re-approaching package tagging

[Catonano]

Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia 
ha scritto:

> Hi :)
>
> On 2018-12-17 20:01, Christopher Lemmer Webber wrote:
> > Hello,
> >
> > In the past when we've discussed package tagging, I think Ludo' has been
> > against it, primarily because it's a giant source of bikeshedding.  I
> > agree that it's a huge space for bikeshedding... no space provides more
> > bikeshedding than naming things, and tagging things is a many to many
> > naming system.
> >
> > However, I will say that finding packages based on topical interest is
> > pretty hard right now.  If I want to find all the available roguelikes:
> >
> > cwebber@jasmine:~$ guix package -A rogue
> > hyperrogue10.5out gnu/packages/games.scm:3652:2
> > roguebox-adventures   2.2.1   out gnu/packages/games.scm:1047:2
> >
> > Hm, that's strange, there's definitely more roguelikes that should show
> > up than that!  A more specific search is even worse:
> >
> > cwebber@jasmine:~$ guix package -A roguelike
> > cwebber@jasmine:~$
> >
> > What I should have gotten back:
> >   - angband
> >   - cataclysm-dda
> >   - crawl
> >   - crawl-tiles
> >   - hyperrogue
> >   - nethack
> >   - roguebox-adventures
> >   - tome4
> >
> > So I only got 1/4 of the entries I was interested in in my first query.
> > Too bad!
> >
> > I get that we're opening up space for bikeshedding and *that's true*.
> > But it seems like not doing so makes things hard on users.
> >
> > What do you think?  Is there a way to open the (pandora's?) box of tags
> > safely?
>
> Yes and no.
>
> Pjotr and I have discussed this relating to biotech software. He said
> that many scientists have a hard time finding the right tools for the job.
>
> I proposed tight integration with wikidata[1] (every software in the
> world will eventually have an item there) and Guix (QID on every package
> and lookup/catogory integration) and leave all the categorizing to them.
> Ha problem sidestepped, they are bikeshedding experts over there in
> wikiland! :D
>
> The advantage of this is that everyone using wikidata (every package
> manager) could pull the same categorization so we only do it once in a
> central
>
> What do you think?
>
> --
>
>

There is also the Free Software Directory
https://directory.fsf.org/wiki/Main_Page

I don't know what the relationship between Wikidata and the FSD is

Does Wikidata import data from the FSD ? Or viceversa ?

Re: Re-approaching package tagging

[Catonano]

Il giorno mar 18 dic 2018 alle ore 08:48 Catonano  ha
scritto:

>
>
> Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia 
> ha scritto:
>
>> Hi :)
>>
>> On 2018-12-17 20:01, Christopher Lemmer Webber wrote:
>> > Hello,
>> >
>> > In the past when we've discussed package tagging, I think Ludo' has been
>> > against it, primarily because it's a giant source of bikeshedding.  I
>> > agree that it's a huge space for bikeshedding... no space provides more
>> > bikeshedding than naming things, and tagging things is a many to many
>> > naming system.
>> >
>> > However, I will say that finding packages based on topical interest is
>> > pretty hard right now.  If I want to find all the available roguelikes:
>> >
>> > cwebber@jasmine:~$ guix package -A rogue
>> > hyperrogue10.5out gnu/packages/games.scm:3652:2
>> > roguebox-adventures   2.2.1   out gnu/packages/games.scm:1047:2
>> >
>> > Hm, that's strange, there's definitely more roguelikes that should show
>> > up than that!  A more specific search is even worse:
>> >
>> > cwebber@jasmine:~$ guix package -A roguelike
>> > cwebber@jasmine:~$
>> >
>> > What I should have gotten back:
>> >   - angband
>> >   - cataclysm-dda
>> >   - crawl
>> >   - crawl-tiles
>> >   - hyperrogue
>> >   - nethack
>> >   - roguebox-adventures
>> >   - tome4
>> >
>> > So I only got 1/4 of the entries I was interested in in my first query.
>> > Too bad!
>> >
>> > I get that we're opening up space for bikeshedding and *that's true*.
>> > But it seems like not doing so makes things hard on users.
>> >
>> > What do you think?  Is there a way to open the (pandora's?) box of tags
>> > safely?
>>
>> Yes and no.
>>
>> Pjotr and I have discussed this relating to biotech software. He said
>> that many scientists have a hard time finding the right tools for the job.
>>
>> I proposed tight integration with wikidata[1] (every software in the
>> world will eventually have an item there) and Guix (QID on every package
>> and lookup/catogory integration) and leave all the categorizing to them.
>> Ha problem sidestepped, they are bikeshedding experts over there in
>> wikiland! :D
>>
>> The advantage of this is that everyone using wikidata (every package
>> manager) could pull the same categorization so we only do it once in a
>> central
>>
>> What do you think?
>>
>> --
>>
>>
>
> There is also the Free Software Directory
> https://directory.fsf.org/wiki/Main_Page
>
> I don't know what the relationship between Wikidata and the FSD is
>
> Does Wikidata import data from the FSD ? Or viceversa ?
>


There happens to be this thread on their mailing list, I think it's
relevant (the whole thread is interesting)

https://lists.gnu.org/archive/html/directory-discuss/2018-11/msg0.html

Re: GNOME 3.30: help needed!

[Catonano]

Il giorno ven 4 gen 2019 alle ore 10:55 Ricardo Wurmus 
ha scritto:

>  * On the other hand how to know if GNOME is using wayland?.
>
> I don’t know!
>
> --
> Ricardo
>



I asked this question on the fediverse and I've been pointed to this answer

(tl dr: obtain your session id with

loginctl

and then

loginctl show-session  -p Type

if the session is on Wayland this should return

Type=wayland )

https://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used

Re: GNOME 3.30: help needed!

[Catonano]

another answer arrived rigt now

If you open xeyes, the eyes will not move if your pointer is on top of a
Wayland window.

Also, the combination

Alt+F2

and then

R + return

restarts Gnome if it's on X. It doesn't if it's on Wayland

Re: GNOME 3.30: help needed!

[Catonano]

I received a new answer right now

echo $WAYLAND_DISPLAY (if it outputs "wayland-0" or something it's a
Wayland session),
or echo $XDG_SESSION_TYPE

I don't know how and why these variables should be set on GuixSD but people
on the fediverse don't know that I asked on behalf of you ☺


Il giorno ven 4 gen 2019 alle ore 12:52 Catonano  ha
scritto:

> another answer arrived rigt now
>
> If you open xeyes, the eyes will not move if your pointer is on top of a
> Wayland window.
>
> Also, the combination
>
> Alt+F2
>
> and then
>
> R + return
>
> restarts Gnome if it's on X. It doesn't if it's on Wayland
>
>
>

Re: GDM future work

[Catonano]

Il giorno mer 9 gen 2019 alle ore 23:33 Timothy Sample 
ha scritto:

> Hi Ludo,
>
> Ludovic Courtès  writes:
>
> > Hello Timothy!
> >
> > Timothy Sample  skribis:
> >
> >> It should be okay for testing as it is.  It will not work unless
> >> “gnome-desktop-service” is included in your services.  It does work with
> >> other window managers, but the session switching UI doesn’t seem to
> >> work.  With a bit of fiddling, I got it to start EXWM, but I suspect
> >> it’s only because “exdm” comes before “gnome” when sorted.  (For the
> >> record, I had to remove the “TryExec” key from its desktop entry file.)
> >
> > I tested in ‘guix system vm’ on ‘master’.  The welcome screen is fairly
> > gray (do you know how we can change the background image?);
>
> I’m not sure about this yet.  The manual says that the default “greeter”
> (UI for logging in) can be themed using “gnome-settings-daemon”.  I’d
> like something more fun, too, but it is low on the priorities list right
> now.  :)
>
> > it does show the list of users, specifically those that have a proper
> > password set:
> >
> >
> >
> > Logging into GNOME works and screen locking works as well.
>
> \o/
>
> > I didn’t find a way to select a session other than GNOME, though.
> > How’s that supposed to work?
>
> Like I said before, this is broken.  Looking at screenshots on the Web,
> there’s supposed to be a little gear icon that shows up beside the “Sign
> In” button.  We have a problem with GNOME right now where some buttons
> are invisible but still work (e.g., the calendar month changing
> buttons).  The session switching button is not just invisible, though.
> Clicking where it should be doesn’t do anything.  So far, I have no
> leads, but I haven’t spent much time on it yet.
>
> Thanks for testing!
>
>
> -- Tim
>


On Ubuntu there are  these files:

:~$ ls /usr/share/xsessions/
gnome-classic.desktop  ubuntu-communitheme-snap.desktop
gnome.desktop  ubuntu.desktop
gnome-xorg.desktop xfce.desktop

and

~$ ls /usr/share/wayland-sessions/
gnome.desktop
ubuntu-communitheme-snap-wayland.desktop
ubuntu-wayland.desktop


These are the sessions that the greeter proposes

For example, the contents of /usr/share/xsessions/ubuntu.desktop are
[Desktop Entry]
Name=Ubuntu
Comment=This session logs you into Ubuntu
Exec=env GNOME_SHELL_SESSION_MODE=ubuntu gnome-session --$
TryExec=gnome-shell
Type=Application
DesktopNames=ubuntu:GNOME
X-Ubuntu-Gettext-Domain=gnome-session-3.0

and the contents of /usr/share/wayland-sessions/gnome.desktop are

[Desktop Entry]
Name=GNOME
Comment=This session logs you into GNOME
Exec=gnome-session --session=gnome
TryExec=gnome-shell
Type=Application
DesktopNames=GNOME
X-Ubuntu-Gettext-Domain=gnome-session-3.0

Re: FOSDEM social dinner

[Catonano]

2017-01-06 10:46 GMT+01:00 Alex Sassmannshausen <
alex.sassmannshau...@gmail.com>:

> Hello,
>
> Guile has a dev room at FOSDEM this year — for a whole day!  The dev
> room will be on Sunday.
>
> Whilst organising it, we had the idea that it would be fun to have a
> Guile/Guix user & dev dinner on the Saturday evening.  I'm hereby
> officially opening registration for that :-D
>
> I have not chosen a restaurant yet, but it will be something that
> provides a varietary of dietary options (omnivore, veggie, vegan).  If
> you are interested in coming along, just drop me a line to confirm.
>
> So — who's in for Guile social dinner on Saturday 4 February 2017 in
> Brussels?
>
> Best wishes,
>
> Alex
>
>
It seems that  I will manage to be there, too.

So count me in !

I'm an omnivore !

Re: FOSDEM 2017 audio/video volunteers needed

[Catonano]

2017-01-11 11:52 GMT+01:00 Amirouche Boubekki :

>
> No response. We need help! Two people can take turns over the day.
>>> Please volunteer, it is important we capture all talks.
>>>
>>
>> I could do some of it, but I’m also giving talks, so we need at least
>> one more person to help out.
>>
>
> I hope I will be up to the task; count me in.
>
>

I can take a share of the burden. Count me in

gnunet (again)

[Catonano]

Tonight I'm discussing gnunet with ng0.

He gave me some instructions he had about how to debug the gnunet build,
assuming that I'm running into the same issue that he run into (I found the
log, there are 8 failed tests, just so you know).

In a phase of such instructions I should attach the gdb to a core dump file.

Such file should be "src/util/.libs/lt-test_foo", sometimes wiithout the lt-

Now in src/util/.libs there is no file with a name starting with lt- and
there are a ton of test_foo files.

So I'm lost.

I copied the ls of that path and here it is
https://paste.gnome.org/poysk7sbu

jquery 3.1.1

[Catonano]

I made a crawler and I let it loose on the jquery 3.1.1 dependencies on
registry.npmjs.com

It recursevely fetched the dependencies of jquery 3.1.1, then the
dependencies of the dependencies, then the dependencies of the dependencies
of the dependencies... and so on

Until there were no more dependencies to fetch.

It stored all such dependencies in a graph database made by the amazing
amz3 for their project, Culturia. They wrote about such project several
times on the guile-users mailing list.

It took days to download. And it took me months to produce a working
version of this code. Because I don't know Guile very well and maybe I'm
not that smart overall.

Anyway, now I have a COMPLETE graph of the dependencies of jquery 3.1.1

It's made of
47311 vertices and
324569 edges

I made a graph of a subset (graphviz chocked a bit on this ;-) )
It's here
http://catonano.altervista.org/grafo.svg

There are 448 "broken" packages. Probably I should explain how I classified
packages as "broken". Maybe not in this email.

Anyway, these broken packages pose a challenge to the mission of porting
Jquery into Guix, in my opinion, and they should be considered with some
attention.
Here's the list
http://catonano.altervista.org/broken_packages.txt

There are 1314 packages with NO dependencies that could be used as starting
points in porting Jquery into Guix.
Here's the list
http://catonano.altervista.org/broken_packages.txt

If there's anyone interested, I can give you the data folder so you can try
all the queries you want on these data without having to to run this thing
for a bunch of hours

In the future, I'd like to run this thing on some other package and merge
the graphs so I will be able to investigate which are the common
fundamental dependencies for SEVERAL important packages in Nodejs.

So if someone wants to dedicate time to porting Nodejs stuff in Guix they
will be able to select most urgent packages to start from.

The same could be said of broken packages taht affect several important
packages.

The porting of Nodejs in Guix cannot be done with brute strength. A data
oriented approach can help, in my opinion.

The ideal would be to have something that, like bitcoin, coordinates a
swarm in such a way that every node can contribute a tiniy bit of data to a
common data structure, so all the nodes would have a complete copy of the
database.

Collecting a mantaining of datasets should be freed of the client server
model too. Not only the social media.

But that's more than I can handle, anyway.

I'd like to talk about the stumbling blocks I run into to discuss Guile and
my knowledge of it.

For example, I can't use that thing in the autotools that processes
configure.am files so I just forked amz3's project and added my files in
there. As guests. Thanks amz3 !

I'd also like to describe te screw ups in the format I put the data into. I
realized my mistakes when hours of crunching had already been done.

They can be migrated to a better format though

If you don't mind, I will discuss these issue in the future, not now.

The code is here
https://gitlab.com/humanitiesNerd/Culturia

One last fun fact: while I was watching the output flowing in my terminal,
I saw a package called

"broccoli-funnel"

No, really. It's here
https://registry.npmjs.org/broccoli-funnel

Ok, that's all for now.

Re: jquery 3.1.1

[Catonano]

2017-01-19 22:07 GMT+01:00 Jelle Licht :

> Hello Catonano,
>
>
>




> These pictures are very informative indeed. I will try to be brief, but I
> quickly wanted to share
> that I find your efforts (and results!) amazing.
>

Thanks :-)

>

Something of note: a big chunk of the packages you classified as being
> 'broken' are
> making me recall some (unpleasant) memories; From my own crawling
> experiments,
> which were not nearly as complete as this one, I also ran into a lot of
> the same
> show-stoppers. In a very real sense, resolving node dependencies quickly
> devolves into
> resolving dependencies for most of the popular build systems as well as
> plugins like
> broccoli-funnel. What I am trying to get at here is that fixing and
> packaging these 448 packages
> will likely contribute a lot towards making an npm-enriched guix possible.
>

Yes. They're important. Some of them require you to be logged in in order
to be downloaded. Or anyway the download fails with an error message in the
response (the body is empty in those cases).

These are those with "nope" in the value

Others return error messages. I'm affraid I overlapped some error
conditions, though :-/
The errors I recorded are not completely accurate.

The errors. But the fact that they can't be downloaded stands.

They are still a bit too many but I'm afraid thhey have to be explored
manually


>
>>
>> There are 1314 packages with NO dependencies that could be used as
>> starting points in porting Jquery into Guix.
>> Here's the list
>> http://catonano.altervista.org/broken_packages.txt
>>
>
> These could probably make use of the npm importer I worked on earlier. Do
> you make use of your own? Otherwase I'll get to
> rebasing my version on the current guix master branch.
>

I used some code that I wrote on purpose.
This is the repo
https://gitlab.com/humanitiesNerd/Culturia

The file you want to consider is "npmjs.scm", the function is
"populate-store" on line 178

The other files were there when I forked amz3's repository. They're theirs



>
>
>>
>>
>> If there's anyone interested, I can give you the data folder so you can
>> try all the queries you want on these data without having to to run this
>> thing for a bunch of hours
>>
>
> If possible, yes please. What would be the most convenient way you to
> share this data?
>

Yes, here it is
http://catonano.altervista.org/npmjsdata.tar.gz

decompress it somewhere, then read amz3's instructions about their Culturia
http://hyperdev.fr/notes/a-graph-based-movie-recommender-engine-using-guile-scheme.html
http://hyperdev.fr/notes/somewhat-relational-database-library-using-wiredtiger.html
https://github.com/amirouche/Culturia


>
>
>>
>> In the future, I'd like to run this thing on some other package and merge
>> the graphs so I will be able to investigate which are the common
>> fundamental dependencies for SEVERAL important packages in Nodejs.
>>
>> So if someone wants to dedicate time to porting Nodejs stuff in Guix they
>> will be able to select most urgent packages to start from.
>>
>> The same could be said of broken packages taht affect several important
>> packages.
>>
>> The porting of Nodejs in Guix cannot be done with brute strength. A data
>> oriented approach can help, in my opinion.
>>
>> Indeed.
>
>
>> The ideal would be to have something that, like bitcoin, coordinates a
>> swarm in such a way that every node can contribute a tiniy bit of data to a
>> common data structure, so all the nodes would have a complete copy of the
>> database.
>>
>> Collecting a mantaining of datasets should be freed of the client server
>> model too. Not only the social media.
>>
>> I have no idea what you are referring to. Could you please elaborate a
> bit at a later point in time?
>

Briefly, bitcoin keeps a ledger among a swarm of peers. They cooperate to
keep a common datastructure, mantaining consense about the order of the
transactions, in a distributed way.

In my idea, some software (based on gnunet ?) could be made such that every
node would download a piece of the graph and contribute it to te common
data structure.

Because how will we deal with the fact that you could merge this graph with
the one off CoffeeScript and in the same time I could merge it with the one
of some other package ?

And what about other people tha would like to collaborate ?

Coordination will be needed.

The most immediate way would be with a central server

But I'm a nobody in the middle of nowhere, I don't want to set up a server
and keep it on line

Something similar to bitcoi

Re: jquery 3.1.1

[Catonano]

2017-01-19 23:44 GMT+01:00 Catonano :

> 2017-01-19 22:07 GMT+01:00 Jelle Licht :
>
>> Hello Catonano,
>>
>>
>>
>
>
>
>
>> These pictures are very informative indeed. I will try to be brief, but I
>> quickly wanted to share
>> that I find your efforts (and results!) amazing.
>>
>
> Thanks :-)
>
>>
>
> Something of note: a big chunk of the packages you classified as being
>> 'broken' are
>> making me recall some (unpleasant) memories; From my own crawling
>> experiments,
>> which were not nearly as complete as this one, I also ran into a lot of
>> the same
>> show-stoppers. In a very real sense, resolving node dependencies quickly
>> devolves into
>> resolving dependencies for most of the popular build systems as well as
>> plugins like
>> broccoli-funnel. What I am trying to get at here is that fixing and
>> packaging these 448 packages
>> will likely contribute a lot towards making an npm-enriched guix possible.
>>
>
> Yes. They're important. Some of them require you to be logged in in order
> to be downloaded. Or anyway the download fails with an error message in the
> response (the body is empty in those cases).
>
> These are those with "nope" in the value
>
> Others return error messages. I'm affraid I overlapped some error
> conditions, though :-/
> The errors I recorded are not completely accurate.
>
> The errors. But the fact that they can't be downloaded stands.
>
> They are still a bit too many but I'm afraid thhey have to be explored
> manually
>
>
>>
>>>
>>> There are 1314 packages with NO dependencies that could be used as
>>> starting points in porting Jquery into Guix.
>>> Here's the list
>>> http://catonano.altervista.org/broken_packages.txt
>>>
>>
>> These could probably make use of the npm importer I worked on earlier. Do
>> you make use of your own? Otherwase I'll get to
>> rebasing my version on the current guix master branch.
>>
>
> I used some code that I wrote on purpose.
> This is the repo
> https://gitlab.com/humanitiesNerd/Culturia
>
> The file you want to consider is "npmjs.scm", the function is
> "populate-store" on line 178
>
> The other files were there when I forked amz3's repository. They're theirs
>
>
>
>>
>>
>>>
>>>
>>> If there's anyone interested, I can give you the data folder so you can
>>> try all the queries you want on these data without having to to run this
>>> thing for a bunch of hours
>>>
>>
>> If possible, yes please. What would be the most convenient way you to
>> share this data?
>>
>
> Yes, here it is
> http://catonano.altervista.org/npmjsdata.tar.gz
>
> decompress it somewhere, then read amz3's instructions about their Culturia
> http://hyperdev.fr/notes/a-graph-based-movie-recommender-
> engine-using-guile-scheme.html
> http://hyperdev.fr/notes/somewhat-relational-database-
> library-using-wiredtiger.html
> https://github.com/amirouche/Culturia
>
>
>>
>>
>>>
>>> In the future, I'd like to run this thing on some other package and
>>> merge the graphs so I will be able to investigate which are the common
>>> fundamental dependencies for SEVERAL important packages in Nodejs.
>>>
>>> So if someone wants to dedicate time to porting Nodejs stuff in Guix
>>> they will be able to select most urgent packages to start from.
>>>
>>> The same could be said of broken packages taht affect several important
>>> packages.
>>>
>>> The porting of Nodejs in Guix cannot be done with brute strength. A data
>>> oriented approach can help, in my opinion.
>>>
>>> Indeed.
>>
>>
>>> The ideal would be to have something that, like bitcoin, coordinates a
>>> swarm in such a way that every node can contribute a tiniy bit of data to a
>>> common data structure, so all the nodes would have a complete copy of the
>>> database.
>>>
>>> Collecting a mantaining of datasets should be freed of the client server
>>> model too. Not only the social media.
>>>
>>> I have no idea what you are referring to. Could you please elaborate a
>> bit at a later point in time?
>>
>
> Briefly, bitcoin keeps a ledger among a swarm of peers. They cooperate to
> keep a common datastructure, mantaining consense about the order of the
> transactions, in a distributed way.
>
> In my idea, so

Re: jquery 3.1.1

[Catonano]

One last note

I pasted the wrong url for the packages with no dependencies

The right one is this
http://catonano.altervista.org/no-deps.txt

I noticed now that this list contains ALSO the broken ones. They have no
dependencies, but they shold be excluded from this list

Because I screwed up the data format, the queries are not exactly
immediate, they need honing :-/

I will fix this in the future

Re: jquery 3.1.1

[Catonano]

2017-01-20 22:23 GMT+01:00 Ludovic Courtès :

> Hi!
>
> Catonano  skribis:
>
> > I made a crawler and I let it loose on the jquery 3.1.1 dependencies on
> > registry.npmjs.com
> >
> > It recursevely fetched the dependencies of jquery 3.1.1, then the
> > dependencies of the dependencies, then the dependencies of the
> dependencies
> > of the dependencies... and so on
> >
> > Until there were no more dependencies to fetch.
> >
> > It stored all such dependencies in a graph database made by the amazing
> > amz3 for their project, Culturia. They wrote about such project several
> > times on the guile-users mailing list.
>
> Neat!
>
> > It took days to download. And it took me months to produce a working
> > version of this code. Because I don't know Guile very well and maybe I'm
> > not that smart overall.
> >
> > Anyway, now I have a COMPLETE graph of the dependencies of jquery 3.1.1
> >
> > It's made of
> > 47311 vertices and
> > 324569 edges
>
> Impressive.
>
> I suppose the data you gathered about the graph could help guide usage
> of Jelle’s importer?  (… which we should consider merging BTW!)
>
>
I would be honored if my data could help guide usage of Jelle's importer.

That was exactly my idea when I started this. The Nodejs stuff can't be
treated with brute force.
A data oriented approach can help, here.

Re: jquery 3.1.1

[Catonano]

2017-01-19 23:51 GMT+01:00 Catonano :

> One last note
>

One more quick note

>
> I pasted the wrong url for the packages with no dependencies
>
> The right one is this
> http://catonano.altervista.org/no-deps.txt
>
> I noticed now that this list contains ALSO the broken ones. They have no
> dependencies, but they shold be excluded from this list
>
> Because I screwed up the data format, the queries are not exactly
> immediate, they need honing :-/
>
> I will fix this in the future
>

I produced a correct version of the "no-deps.txt" file

Also, a notion of "scoped" packages exists in npm

They can't be downloaded, as explained here
https://github.com/npm/registry/issues/34

These packages have the cons cell "(broken-package . nope)"

Yes, they are broken and they have the symbol "nope" nonetheless. It's
conterintuitive, I know. I messed this thing up. I made the download
function return "nope" when a download isn't allowed.

I marked them as broken and moved on. The subtree under these packages has
NOT been explored.

I could use some help, here, by someone used the the Nodejs intricacies

I don't know what they mean with "scoped" and I don't know what this could
mean exactly for the "Nodejs in Guix" mission

Re: jquery 3.1.1

[Catonano]

2017-01-21 20:12 GMT+01:00 Catonano :

I could use some help, here, by someone used the the Nodejs intricacies
>
>
I don't know what they mean with "scoped" and I don't know what this could
> mean exactly for the "Nodejs in Guix" mission
>

The same goes for packages like this

scheme@(guile-user)> ,m (npmjs)
scheme@(npmjs)> (downloaded-package "@types/minimatch" "^2.0.29")
$1 = (@ ("code" . "MethodNotAllowedError") ("message" . "GET is not
allowed"))
scheme@(npmjs)>

I don't know what this means exactly but the subtree of packages like this
one couldn't be explored either

Re: jquery 3.1.1

[Catonano]

The 2 symbols

'the-package-does-not-exist
'the-version-does-not-exist

are clearer.

Some other package declares these as a dependency. But such dependency
doesn't exist

Will these dependants be buildable ? I don't know

There are many of these cases

Re: jquery 3.1.1

[Catonano]

2017-01-21 22:41 GMT+01:00 Mike Gerwitz :

> On Sat, Jan 21, 2017 at 20:12:25 +0100, Catonano wrote:
> > I could use some help, here, by someone used the the Nodejs intricacies
>
> Scoped packages are described here:
>
>   https://docs.npmjs.com/misc/scope


thanks


>
>
> I've never actually used them, but they're installed normally:
>
>   https://docs.npmjs.com/cli/install
>
> What's a specific package you're having trouble with?
>

For example @types/minimatch ^2.0.29

I'm afraid it is set to restricted access, as it can't be downloaded.

It's in the dependencies tree of Jquery

Another one is @ljharb/eslint-config ^8.0.0

Another one is @remy/snyk-shrink-test ^1.0.0

Another one is @types/chalk ^0.4.28

How would Guix deal with these ?

[PATCH] update haunt to 0.2.1

[Catonano]

Hello guixers,

the attached patch updates Haunt to the recently released version 0.2.1
From 015719506600bcb674b1d47398af27c2b4f32d18 Mon Sep 17 00:00:00 2001
From: humanitiesNerd 
Date: Tue, 24 Jan 2017 14:55:12 +0100
Subject: [PATCH] gnu: haunt: Update to 0.2.1

* gnu/packages/guile.scm (haunt): Update to 0.2.1.
---
 gnu/packages/guile.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 00f587d..ba45a63 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -938,14 +938,14 @@ Guile's foreign function interface.")
 (define-public haunt
   (package
 (name "haunt")
-(version "0.2")
+(version "0.2.1")
 (source (origin
   (method url-fetch)
   (uri (string-append "https://files.dthompson.us/haunt/haunt-";
   version ".tar.gz"))
   (sha256
(base32
-"1id83n8fs7jxys1d8jy70vylg8gzcvlw1y7hb41y3qxv5zi4671m"
+"1fpaf1vm6s7j13fs35barjh5yajcc2rc3pi8r7278wpgp4i2vs3w"
 (build-system gnu-build-system)
 (arguments
  `(#:modules ((ice-9 match) (ice-9 ftw)
@@ -975,7 +975,8 @@ Guile's foreign function interface.")
 (inputs
  `(("guile" ,guile-2.0)))
 (propagated-inputs
- `(("guile-reader" ,guile-reader)))
+ `(("guile-reader" ,guile-reader)
+   ("guile-commonmark" ,guile-commonmark)))
 (synopsis "Functional static site generator")
 (description "Haunt is a static site generator written in Guile
 Scheme.  Haunt features a functional build system and an extensible
-- 
2.7.4

[PATCH] update wiredtiger to 2.9.1

[Catonano]

I couldn't manage to connect to the new Wiredtiger through Amz3's machinery
(I have a hard time with dynamic ffi) but the tests pass. All of them
From b965e3c92ec55252fc2bd73712ae5b0c02127fa2 Mon Sep 17 00:00:00 2001
From: humanitiesNerd 
Date: Tue, 24 Jan 2017 19:35:58 +0100
Subject: [PATCH] gnu: wiredtiger: Update to 2.9.1

* gnu/packages/databases.scm (wiredtiger): Update to 2.9.1.
---
 gnu/packages/databases.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index b70d48c..fb0266e 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -1085,7 +1085,7 @@ database and supports many programming languages.  It is a NoSQL database.")
 (define-public wiredtiger
   (package
 (name "wiredtiger")
-(version "2.8.0")
+(version "2.9.1")
 (source (origin
   (method url-fetch)
   (uri (string-append
@@ -1093,7 +1093,7 @@ database and supports many programming languages.  It is a NoSQL database.")
 version ".tar.bz2"))
   (sha256
(base32
-"1qh7y5paisdxq19jgg81ld7i32lz920n5k30hdpxnr8ll9c4hgjr"
+"0krwnb2zfbhvjaskwl875qzd3y626s84zcciq2mxr5c5riw3yh6s"
 (build-system gnu-build-system)
 (arguments
  '(#:configure-flags '("--enable-lz4" "--enable-zlib")
-- 
2.7.4

Re: [PATCH] update haunt to 0.2.1

[Catonano]

Leo,

2017-01-24 15:11 GMT+01:00 Catonano :

> Hello guixers,
>
> the attached patch updates Haunt to the recently released version 0.2.1
>

Would you mind to take care of this one too ? This is even simpler than
Wiredtiger

Thanks

Fosdem

[Catonano]

I will arrive in Bruxelles tomorrow at lunch time

I' d like to follow this talk
https://fosdem.org/2017/schedule/event/all_ages/

and this one
https://fosdem.org/2017/schedule/event/copyleft_defense/

I'd love to meet anyone of you guixers, while there.

Contact me in private for arrangements

Ciao

Re: FOSDEM 2017 audio/video volunteers needed

[Catonano]

2017-01-11 4:49 GMT+01:00 Pjotr Prins :

> On Tue, Jan 10, 2017 at 04:02:32AM +, Pjotr Prins wrote:
> > Hi all,
> >
> > FOSDEM provides live streaming of talks and archiving. We need
> > volunteers to man the FOSS setup that handles the camera and mike.
> > Ideally two people who expect to be in the room all day :). It is
> > mostly automated and does not require special skills.
>
> No response. We need help! Two people can take turns over the day.
> Please volunteer, it is important we capture all talks.
>

Because of a hitch, Amirouche won't be there

So Ricardo and I are the only volunteers

We' ll try to manage but I won' t be offended if someone would like to step
in :-)

Re: Packaging leiningen (feedback desired)

[Catonano]

2017-02-08 0:00 GMT+01:00 Ben Woodcroft :

> Hi Danny, Alex,
>
>
> On 07/02/17 18:19, Danny Milosavljevic wrote:
>
>> Hmmm... works for me with:
>>
>> $ java -cp "${HOME}/.guix-profile/share/java/clojure-1.8.0.jar"
>> clojure.main
>>
>> (Note: java -> /gnu/store/4lnjmsr4szhqyixy238xjl83k8h5f0ck-icedtea-3.2.0/
>> bin/java)
>>
>> Also works within guix environment --ad-hoc clojure.
>>
> I was unable to use that command with that exact environment (clojure
> doesn't propagate any java), but it does work when icedtea is added i.e.
>
> guix environment --container --ad-hoc clojure icedtea
>
> I'm not expert enough to comment on whether the clojure package itself
> needs to be changed, but this is a workaround at least.
> ben
>
>
>
>
>
The Clojure compilation target is the Jvm. Any Clojure based software needs
a Jvm in order to run

And the Clojure REPL is a Clojure based program. Without a Jvm it won' t
run.

I don' t remember now if the compiler is written in Java or in Clojure.
Anyway, the compiler too needs a Jvm in order to run.

That is to say that as far as I understand both Clojure and Guix, a Java
runtime should be a propagated input of any Clojure package.

Re: Packaging leiningen (feedback desired)

[Catonano]

2017-02-08 16:53 GMT+01:00 Ricardo Wurmus :

I’d like to avoid propagating inputs.  Could we add a wrapper instead?
> The wrapper would set the appropriate environment variables and retain a
> reference to the JVM.
>

Good. So I can see how a wrapper is arranged

Re: jquery 3.1.1

[Catonano]

Just as a note, there was this talk at the Fosdem and I think it adds some
bits I had missed (mostly because I don' t know nodejs)

http://ftp.osuosl.org/pub/fosdem/2017/K.4.601/deploying_npm_packages_with_nix.vp8.webm

Re: How to M-x debbugs-gnu with new guix-patches

[Catonano]

2017-02-12 15:21 GMT+01:00 Christopher Allan Webber 
:

> So!  We have a new debbugs tracking of guix-patches.  Great!  Those who
> are emacs users in the know probably like to use the M-x debbugs-gnu
> interface.  Here's what you need to do:
>
> Add this to your .emacs:
>   (add-to-list 'debbugs-gnu-all-packages "guix-patches")
>
> Now open up debbugs-gnu:
>   C-u M-x debbugs-gnu   guix-patches  n y
>
> And now you have a nice emacs interface!
>
> I found this documentation on debbugs useful:
>   https://www.debian.org/Bugs/Reporting
>
> And also, maybe you want to tag bugs or etc.  Use the 'C' key from the
> emacs interface!
>
> Happy bug triaging!
>

Say you want to test one patch that has been submitted to patches-guix

How do you do that ?
How do you extract the patch from within the Emacs Debbugs buffer ?

I see there's a menu that pops up with the mouse-3 button with a "save
as..." issue.

Do you just save it somewhere and then you continue from there ?

Further, there are 2 issues in that menu that make me curious

"View interactively..." that asks me to indicate a Viewer. Which viewer ?
What is this about ?

"Take action on part..." that asks me to indicate an Action. Again, what is
this about ?

Thanks

Re: [PATCH] update haunt to 0.2.1

[Catonano]

Hi David,

2017-01-25 19:03 GMT+01:00 Ludovic Courtès :


> > Agreed, but even better would be if I knew how to make upstream just
> > do the right thing to begin with. ;)  Do you know how this could be
> > done?
>
> For Haunt’s own modules, you could set the right search path in the
> ‘haunt’ command itself, like the Shepherd and Guix do.
>
> For these external dependencies, you could always use ‘search-path’ at
> configure time to hard-wire their locations in ‘haunt’ as well.  (Guix
> does not do that and I don’t know of any project that does, but IWBN.)
>
> Ludo’.
>

is there any progress on this ?

I'd love to use both Haunt and Artanis but I'm not autonomous because of
these autotools related issues.

If you understood what Ludo suggested, would you mind to apply the
suggestions ?
I'd love to borrow the edits to use them on Artanis too.

Thanks

Re: gnu-patches back log

[Catonano]

2017-03-01 17:07 GMT+01:00 Pjotr Prins :

> On Wed, Mar 01, 2017 at 10:51:14AM -0500, Leo Famulari wrote:
> > On Wed, Mar 01, 2017 at 02:45:51PM +, Pjotr Prins wrote:
> > > OK. I was not planning to badger ;). Sometimes describing a problem
> > > can be valuable.  Feel free to ignore.  We all have different itches
> > > to scratch.  I'll shut up again.
> >
> > Okay, I really don't want you to shut up. As you say, we all have our
> > own itches to scratch (my phrase is "motivation is not fungible"), and
> > Guix should try to make use of everyone's energy.
> >
> > But I got the impression (probably mistaken) that you felt the
> > committers / reviewers were choosing to spurn contributions, and it
> > really bothered me. Like I said, many of us are giving as much time and
> > energy as we can.
>
> Yes, I don't think anyone is ducking responsibilities or work. I have
> a huge appreciation for what everyone here is doing. Maybe I should
> have been clearer. Even a one-line commit is a great contribution. And
> then there are people who put thousands of lines in. It is awesome.
> And then there are people contributing documentation. This is a
> massive project in almost all dimensions.
>
> Even so, packaging is no rocket science and it scales with people
> contributing.  That is my starting point.
>
> Pj.


Wrapping up, I think 2 interesting ideas popped up in this thread

One is the automation of building of new packages patches

Another one is the weekly report about pending patches and merged patches

Both these things could be done and I think both could be useful

Re: org.gtk.Settings.FileChooser bomb out fix (aka GNOME Settings Schemas)

[Catonano]

2017-03-13 15:54 GMT+01:00 Pjotr Prins :

> I finally found a way of getting around the feared
>
>   (gnumeric:1974): GLib-GIO-ERROR **: Settings schema
> 'org.gtk.Settings.FileChooser' is not installed
>
> by setting XDG_DATA_DIRS before running a GTK tool (gnumeric, gnucash,
> some browsers):
>
>   env XDG_DATA_DIRS=/usr/local/share:/usr/share
> ~/.guix-profile/bin/gnumeric
>
> This is on a Debian base distribution. Not sure what package is
> missing on Guix, but there appears to be a missing dependency.
>
>
Could this be related to this (occurring on GuixSD) ?
https://lists.gnu.org/archive/html/bug-guix/2017-03/msg00032.html

Re: gnu-patches back log

[Catonano]

2017-03-07 13:09 GMT+01:00 Ricardo Wurmus :

>
> Catonano  writes:
>
> > Wrapping up, I think 2 interesting ideas popped up in this thread
> >
> > One is the automation of building of new packages patches
>
> I wouldn’t know how to set this up.  Hydra isn’t powerful enough for our
> *current* purposes, so I wouldn’t want to increase the load at this
> point.
>

Ok :-)


>
> > Another one is the weekly report about pending patches and merged
> >patches
>
> I’d rather not have a weekly report (I get enough email through the
> various Guix mailing lists already).  The debbugs interface shows all
> open patches already.  (We should get more people to use guix-patches
> instead of guix-devel, though.)
>

Ok ! This is also what Ludo is proposing


>
> Other than that I’d like to second everything Leo has written.
>

Sure ! I didn't mean to put off anyone's work !

If that was your impression I apologize, I gave the wrong impression !

I agree with Pjotr that obviously it would be nice to have faster/more
> reviews/mentoring.  That’s something everybody can help with, even if it
> is just a matter of reviewing licenses or trying to build or run the
> package.  But this all falls apart under stress (speaking from
> experience here), so it’s best not to force it.
>

I reviewed one patch only so far, so I take your word for it

I am gearing up with a viable email service and soon I'll be able to use
the Emacs-Debbugs thing to its full potential ;-)

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[Catonano]

2017-03-18 13:10 GMT+01:00 John Darrington :

> On Sat, Mar 18, 2017 at 11:52:16AM +, ng0 wrote:
>
>  May I remind you that the first reaction of John is being rude to
> anyone
>  who isn't a native speaker?
>
> That is absolutely not true.  I have reviewed this current thread and I do
> not
> see any instance of rudeness on my part.
>
> As I have explained *most* people appreciate it when offerred corrections
> - be
> it code, language or whatever.  I certainly appreciate corrections of my
> mistakes,


Do you ? You are fiercely fighting a correction that has been offered to
you by ng0 and by mantainers too.

Corrections are not about linguistics or programming langages only. There
are community (people) issues too.


and on occassion people have taken the time to thank me for the time
> I take to correct theirs.


Well, this is not the case, is it ?


> That is what collaboration is about.  You have
> explicitly asked me not to correct you - and I respect that request - I
> will not
> do so in future.  However, if I see you giving erroneous advice to a third
> party
> I may interject with my own opinion.
>

In so doing, you would be actively assaulting a member of this community.


>
> I'm sorry that you feel this way.


No, you're not


> I would still like to work with you - and
> that means I appreciate constructive criticism from anyone, about anything.
>

Plenty of constructive critism iis being offered, here, and you seem to be
belligerent against it

On the only basis that the criticism is not about language.


>
> For example, we don't often speak German in Guix, but if we were to do so,
> I would be very grateful to you, as a native German speaker, if you would
> correct
> me when I make a grammatical mistake.
>

Well, other people is not being grateful, here

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[Catonano]

2017-03-18 12:45 GMT+01:00 Mathieu Lirzin :

> ng0  writes:
>
> > John Darrington transcribed 2.0K bytes:
> >
> >> I am glad that at least one person can express a point of view  and be
> polite about
> >> it at the same time.   If you think it is fine, then it is your right
> to use it.
> >>
> >> I find it confusing and clunky in most cases, and I refuse to use it.
>   I also
> >> reserve the right, when others advocate its use, to present my own
> point of view.
> >>
> >> If anyone chooses  to  interpret that as rude, sexist, intolerant or
> whatever - then
> >> that is their problem and not mine.  They will have to get over it.
> >
> > Okay, so you are just one of those ignorant assholes who drive people
> > away from projects because they think their are the middle of the
> > universe and other problems don't exist because they have never
> > experienced them and oh deity forbid if someone insults their holy
> > grammarbooks and linguists. Cool. Glad that we have solved that.
> >
> > That's actually the first time that I'm not polite. But I can't be
> > polite to ignorant people. I just won't work with you anymore and ignore
> > you, as you choose to ignore other people with your behavior and
> > invalidate their existence and bother them with your view of what's
> > "correct" and what's not.
>
> This reaction is highly intolerant and not acceptable in this community.
> Disagreeing doesn't justify being rude or insulting people.
>

I wholeheartedly disagree

ng0's reaction is legitimate and due.

ng0 is being shown hostility.

I don't see why hostility is legitimate when one side expresses it but it's
not legitimate anymore when a reaction comes.

I don't see why John should be allowed to say "I will raise this and if
anyone feels hit they will have to deal with it"

and people's reaction to this wold be not acceptable.

The result of ng0's reaction to be deemed unacceptable would be that a
transgender person raising the issue of gendered pronouns would be dealt
with a shrug and their reaction would be dealt with... what ?

I find your remark not only ridiculous. I find it discriminating.

Re: Being excellent to one another

[Catonano]

2017-03-20 7:36 GMT+01:00 John Darrington :

> On Sun, Mar 19, 2017 at 07:57:07PM -0700, dian_ce...@zoho.com wrote:
>  On Sun, 19 Mar 2017 17:40:27 -0500
>  Christopher Allan Webber  wrote:
>  > The important thing is to not assume someone's preferred pronouns
>  > without knowing them.  Singular they isn't your only option; I also
>  > happen to like Spivak pronouns:
>  >
>  >   https://en.wikipedia.org/wiki/Spivak_pronoun
>
>  The problem here is that I'd be suprised if many people have even
> heard
>  about these. I used to play MUDs quite a bit and have /never/ heard
> any
>  of those. They are certainly not a part of common usage, and I'd say
>  should be avoided for something more standard (them et al). It's a
> nice
>  idea, but overall seems like it would cause confusion, and probably
>  more than a few "Hey, there is a typo in the manual"-type bugs than
>  anything.
>
>  At least, if I picked up a random bit of documentation and saw things
>  like "e" used constantly, I'd assume it was a typo and not some
> archaic
>  gender-neutral pronoun.
>
> I tend to agree.  These invented aspects of language are kindof fun for
> informal use but out of place in a user manual.In a manual we should
> stick to proper English - put yourself in the position of a person who
> is learning English as a second language.  That person has spent months
> attending language school and is starting to become confident then picks
> up a manual and sees the words "pis" and "per".  It's enough to throw you
> off your stride. (I remember something similar happening to me when
> learning
> a foriegn language: I started reading a novel, and there was lots of
> dialogue
> all in regional dialect. I felt like giving up.)
>
> Fortunately in a user manual one very rarely needs a personal *definite*
> pronoun.
> In GNU manuals, the long standing practise is to refer to the person using
> the
> program, as "you".  Occasionally a personal *indefinite* pronoun is called
> for and
> luckily in English we have a perfect gender neutral one, viz: "one".
>
> Some authors religiously avoid the whole issue altogether by writing every
> sentence in the passive voice - but that makes the manual extremely hard to
> understand even for very patient readers.
>
>
Ok, it' s evident that John has his own weaknesses about linguistics.
I feel compelled to write something anyway, so that a publicly available
record of this remains.

When writing texts, such as this email, and absolutely  *have* to use a
> personal
> definite pronoun, I default to "she" because whereas vigilantes will
> pounce upon
> you whenever they see "he" (ironically those people are invariably male),
> I've
> never had anyone complain when "she" occurs where the gender of the subject
> might well be masculine.
>

In life, I've had my share of hardship because of assumed social norms
related to sexual orientation.

And a scene has been described to you of people breaking in tears and
leaving places because of having been misgendered.

So your observation about who raises the issue, associated to the word
"vigilantes" means that you are negating my reasons.

You are implicitly claiming that this is not about suffered discrimination,
but rather it' s about imposing discrimination, possibly on an idelogical
basis, using the issue of sexual orientation/gendering as a tool.

Like when you wrote that being addressed with a pronoun of the wrong number
is not that terrible.

You were negating the issue raised by ng0.

You are being gratuitously offensive, aggressing people and you are being
dismissive about people weaknesses that are being represented to you
repeatedly.

On the ground of formal linguistic correctness, as if it was a matter or
death or life.
And it seems that your argument about your native language is not that
convincing, anyway.

What does this make of you ?

Re: Being excellent to one another

[Catonano]

2017-03-20 11:44 GMT+01:00 John Darrington :

>
> There is a broad concensus that Donald Trump, Rodrigo Duterte and
> Recep Erdogan are awesome.However I do not agree.
>

It seems to me that, on some issues you perfectly agree with those three.

Re: How to M-x debbugs-gnu with new guix-patches

[Catonano]

2017-02-26 20:02 GMT+01:00 Christopher Allan Webber 
:

> Pjotr Prins writes:
>
> > I submitted my first patch on debbugs. It is a fairly trivial one for
> > speedtest-cli which I need because I move around so much ;)
>

Yes, this writeup is way cool

A great reference !

Thank you Pjotr !

BUT ! ;-)

In asking for directions I was referring to the workflow in using the
debbugs-emacs thing, how to save a patch locally when receiving it on the
mailing list, how to apply it

The way I found is a tiny button in the toolbar that saves a patch locally.

But is there anymore to know ? or example, does the debbugs-emacs thing
offer a way to apply a patch to a branch ?

Thanks again !