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, ,
> 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 all is lost !
...""

and then it would go on in explaining what you explained to me on the
mailing list

Honestly I think that keeping this inforrmation hidden deep in the guts of
a paragraph about something else is plainly unfair to users

Assuming that users read academic articles about programming languages in
order to know your way aroung Guile is

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 “toxic” or “full of jerks”.  This has not been my
> experience at all, neither in my communications with the maintainers,
> nor in the response to my modest contributions.
>

Good for you
My experience was different


> I will say that it is a rather quiet community, though.  What you called
> “the silent tr

2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[swedebugia]

Hi

On June 8, 2018 4:49:34 PM GMT+02:00, l...@gnu.org wrote:
>Hi Pierre,
>
>Pierre Neidhardt  skribis:
>
>> * gnu/packages/emacs.scm (emacs-google-translate): New variable.
>
>[...]
>
>> +  (home-page "https://github.com/atykhonov/google-translate";)
>> +  (synopsis "Emacs interface to Google Translate")
>> +  (description
>> +   "Setup:
>> +@code{
>> +(require 'google-translate)
>> +(require 'google-translate-default-ui)
>> +(global-set-key \"\\C-ct\" 'google-translate-at-point)
>> +(global-set-key \"\\C-cT\" 'google-translate-query-translate)}
>> +
>> +or
>> +
>> +@code{(require 'google-translate)
>> +(require 'google-translate-smooth-ui)
>> +(global-set-key \"\\C-ct\" 'google-translate-smooth-translate)}
[...] 
>> +(license license:gpl3+
>
>Applied but I removed the documentation: I don’t think it’s the right
>place to document the package. 

In Arch there is a post-install hook that enables informing the user of 
additional steps needed to actually use the software as intended. 

I find that useful. Is there a guix alternative? 
If not is this something we should implement? 

Also pacman logs all messages about packages installed to a logfile in /var/log 
which is very very useful if you missed a message while installing multiple 
packages and it no longer is in the scrollbuffer or just high up. 

Maybe the need for this is much smaller with Guix because we have no breaking 
changes that the user must act on as here sometimes is in arch. 

Idea of changing the way we handle emacs add on packages:


In the example above we might want to modify the emacs packages to have two 
.emacs-files in total:
1)
The usual .emacs where the user puts in changes and where we by default load 
.emacs-guix-packages. 

2)
.emacs-guix-packages where the setup information for add ons installed is 
automatically added. 
In the example above this would be added to the botten of .emacs-guix-packages:
"(require 'google-translate)
(require 'google-translate-default-ui)
(global-set-key \"\\C-ct\" 'google-translate-at-point)
(global-set-key \"\\C-cT\" 'google-translate-query-translate)"

What do you think?

This would enable us to create an out of the box working emacs experience with 
loads of add ons that by default do not collide with each other e.g. by 
cleverly choosing the default key bindings for the add ons.
-- 
Cheers Swedebugia 

New ‘guix pull’

[Ludovic Courtès]

Hello Guix!

For those who haven’t been following along on
, I have just
pushed a new ‘guix pull’.

To summarize, ~/.config/guix/latest no longer exists.  Instead
~/.config/guix/current is populated with a complete Guix (without
‘guix-daemon’ though), including an up-to-date manual and so on.
~/.config/guix/current is a regular profile, meaning that you can
roll-back to a previously-pulled Guix and so on.

There are also problems that this does *not* solve: in particular,
building Guix still takes too much time if you don’t have substitutes
available (berlin.guixsd.org provides substitutes for it, but
mirror.hydra.gnu.org does not.)  We’ll get there!

There are also now many ways in which we could improve the API:
implementing ‘guix pull -l’ that would show not just the generations but
also the commit IDs, recording more meta-data so that ‘guix pull’ can
for instance list all the new/upgraded packages between two generations,
adding support for “channels”, etc.

Feedback welcome!

Ludo’.


signature.asc
Description: PGP signature

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: 2 ideas (Was: Re: bug#31518: [PATCH 10/21] gnu: Add emacs-google-translate.)

[Nils Gillmann]

swedebugia transcribed 2.8K bytes:
> Hi
> 
> On June 8, 2018 4:49:34 PM GMT+02:00, l...@gnu.org wrote:
> >Hi Pierre,
> >
> >Pierre Neidhardt  skribis:
> >
> >> * gnu/packages/emacs.scm (emacs-google-translate): New variable.
> >
> >[...]
> >
> >> +  (home-page "https://github.com/atykhonov/google-translate";)
> >> +  (synopsis "Emacs interface to Google Translate")
> >> +  (description
> >> +   "Setup:
> >> +@code{
> >> +(require 'google-translate)
> >> +(require 'google-translate-default-ui)
> >> +(global-set-key \"\\C-ct\" 'google-translate-at-point)
> >> +(global-set-key \"\\C-cT\" 'google-translate-query-translate)}
> >> +
> >> +or
> >> +
> >> +@code{(require 'google-translate)
> >> +(require 'google-translate-smooth-ui)
> >> +(global-set-key \"\\C-ct\" 'google-translate-smooth-translate)}
> [...] 
> >> +(license license:gpl3+
> >
> >Applied but I removed the documentation: I don’t think it’s the right
> >place to document the package. 
> 
> In Arch there is a post-install hook that enables informing the user of 
> additional steps needed to actually use the software as intended. 
> 
> I find that useful. Is there a guix alternative? 

I think we discussed something similar briefly. Or at least package
attached metadata which ends up in a '/guix' folder of the output.
I've been following (not yet implementing) a similar idea, where
such messages are either local mail and/or end up in a (mapped to guix:)
'/guix/doc/' folder, where files are named like 
$applicationname-$version.number.NAME.note
where '.note' is just a basic txt file.
These notes could contain messages specific to the OS, the architecture, general
advice, etc.

Not really well thought through yet, but that's a start.

Think of it not as description or synopsis part, but rather let's say
(in theory):
(note "STRING") or (note (list "NOTE 1"
   "NOTE 2")).

> If not is this something we should implement? 
> 
> Also pacman logs all messages about packages installed to a logfile in 
> /var/log which is very very useful if you missed a message while installing 
> multiple packages and it no longer is in the scrollbuffer or just high up. 
>
> Maybe the need for this is much smaller with Guix because we have no breaking 
> changes that the user must act on as here sometimes is in arch. 
> 
> Idea of changing the way we handle emacs add on packages:
> 
> 
> In the example above we might want to modify the emacs packages to have two 
> .emacs-files in total:
> 1)
> The usual .emacs where the user puts in changes and where we by default load 
> .emacs-guix-packages. 
> 
> 2)
> .emacs-guix-packages where the setup information for add ons installed is 
> automatically added. 
> In the example above this would be added to the botten of 
> .emacs-guix-packages:
> "(require 'google-translate)
> (require 'google-translate-default-ui)
> (global-set-key \"\\C-ct\" 'google-translate-at-point)
> (global-set-key \"\\C-cT\" 'google-translate-query-translate)"
> 
> What do you think?
> 
> This would enable us to create an out of the box working emacs experience 
> with loads of add ons that by default do not collide with each other e.g. by 
> cleverly choosing the default key bindings for the add ons.
> -- 
> Cheers Swedebugia 

Re: my latest blog post

[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.  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.

>> 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.

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
>> 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.

By analogy, do you think that assuming the concept of recursion would be
a problem?  Or the concept of a closure?  Would you say that this should
be explained in the *Guix* manual?  (These are sincere questions.)

We are using both of these constructs.  We are also using delayed
evaluation in the form of streams.  Luckily, those are provided as a
Guile library and are thus documented in the *Guile* manual.

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

I used “,expand” in the past to see the expansion of a macro
expression.  Here’s an example with the state monad:

--8<---cut here---start->8---
scheme@(guile-user)> ,expand (with-monad %state-monad (return 1))
$3 = (let ((value 1))
  (lambda (state)
((@@ (guix monads) values) value state)))
--8<---cut here---end--->8---

This shows us that returning a monadic value in the state monad is the
same as returning a procedure that takes some state and returns it
alongside the value.

The Guix manual says about the things that we used:

--8<---cut here---start->8---
 -- Scheme Syntax: with-monad MONAD BODY ...
 Evaluate any ‘>>=’ or ‘return’ forms in BODY as being in MONAD.

 -- Scheme Syntax: return VAL
 Return a monadic value that encapsulates VAL.
--8<---cut here---end--->8---


Earlier, it also says something about what monads are all about:

--8<---cut here---start->8---
   This is where the ‘(guix monads)’ module comes in.  This module
provides a framework for working with “monads”, and a particularly
useful monad for our uses, the “store monad”.  Monads are a construct
that allows two things: associating “context” with values (in our case,
the context is the store), and building sequences of computations (here
computations include accesses to the store).  Values in a monad—values
that carry this additional context—are called “monadic values”;
procedures that return such values are called “monadic procedures”.
--8<---cut here---end--->8---

We’ve just seen the first part about associating “context” (in this case
some state) with values.  The second part requires a larger expression
to see how this is useful.

The Guix manual has an example right there:

--8<---cut here--

Re: my latest blog post

[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.  To
be honest, I never even heard of a macro stepper before.  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.

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

> 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).  If
it fails to do that then the Guix manual should be updated.

--
Ricardo

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
> >> 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.
>
> By analogy, do you think that assuming the concept of recursion would be
> a problem?  Or the concept of a closure?  Would y

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

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> Catonano  writes:
>
> 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.
>
>> 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"

I think at a moment like this it's important to step back a
moment... Wikipedia has a good philosophy here called "Assume Good
Faith":

  https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

Making Guile into a friendlier environment for newcomers is important.
But if we are to have a friendly environment, the only way that can
happen is if we believe that in general we have a culture of
collaboration.  That doesn't mean we don't hold people accountable if
they are clearly demonstrating disrespectful or hostile behavior.  But
there's no way to have a collaborative environment if we don't try to
give people the benefit of the doubt that they wish to work together to
improve things.

New ‘guix pull’ dosen’t update the guix manual in GuixSD

[宋文武]

l...@gnu.org (Ludovic Courtès) writes:

> Hello Guix!
>
> For those who haven’t been following along on
> , I have just
> pushed a new ‘guix pull’.
>
> To summarize, ~/.config/guix/latest no longer exists.  Instead
> ~/.config/guix/current is populated with a complete Guix (without
> ‘guix-daemon’ though), including an up-to-date manual and so on.
> ~/.config/guix/current is a regular profile, meaning that you can
> roll-back to a previously-pulled Guix and so on.

Great!


After run ‘guix pull’ twice, I have got ‘~/.config/guix/current’, then
use it to do a system reconfigure for ‘/etc/profile’.

But the guix manual doesn’t got updated, my ‘INFOPATH’ contains:

- /home/iyzsong/.guix-profile/share/info
- /run/current-system/profile/share/info
- /home/iyzsong/.config/guix/current/share/info
- /home/iyzsong/.guix-profile/share/info
- /run/current-system/profile/share/info

The last there are from the ‘export’ statement of ‘/etc/profile’, the
first two are added by ‘source’ the profiles.  Since there is a guix in
the system profile contains the old info manual, the current one won’t
be picked.

I think we should make ‘INFOPATH’ a search path of the ‘current’ guix
profile, so that it overrides previous ones.

Re: my latest blog post

[Christopher Lemmer Webber]

Catonano writes:

> 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

I think it's great that Ludovic responded so nicely with Skribilo.
Though I read what Ricardo wrote... I think he never called you anything
of the sort, and if I had read only your email I would have gotten the
impression that he had (I am not sure if this is what you intended here,
maybe you were referring to something else, but I think it applies to at
least the comment where you interpreted what Ricardo said as "f--- you").
If I were in Ricardo's situation I think I would feel very hurt.

I think part of the conflict here is you're saying you're seeing some
things that you think are clearly missing from the project, and here are
some things that you'd like to see changed, and here are some things you
are offering to change.  And that I think is very good.  But you are
also identifying some things you'd like to see changed that you don't
yet know how to change.  Ricardo is suggesting that you learn more about
them and jump in to help change them.

Is this a hostile thing to do?  Well, if it were used as a way to
dismiss the request entirely, probably.  But what I think Ricardo is
trying to say is that the Guile community is resource-strapped (which it
is, being run by volunteers).  We cannot demand that anyone who is
volunteering work on a specific thing, but we can ask and make
suggestions.  And one excellent way to make changes happen is to learn
and step into the role of making them happen.

Not everyone can, and this is true and I fully agree.  To that end, I
think that's where bug reports come in, and making an appeal to the
community to work on a specific thing is useful.  But I also think that
it is true that everyone can help in some ways, and that we also
remember that everyone is volunteering.  We cannot expect that
everything that we would like done will be done because all volunteers
only have so much energy.  To that end, a call to "please help" is not
necessarily dismissive... it may be a call to ask you to be empowered,
and a call to say that your contributions would be welcome and
appreciated.

Most importantly, I think we should not put negative words in another
person's mouth that they did not say or intend.  I linked "Assume Good
Faith" earlier because I think we cannot build a strong community
together without doing so.  To put more negative words in place of what
someone said puts them on the defensive and makes it hard to come
towards further progress.  This is a collaborative game... let's
recognize that, and all work together to make it a better place.

Re: Fwd: Re: Patch file for colorize module

[Sahitihi]

Hi Ricardo,

When I used "(colorize-string "hello" '(GREEN))" in REPL that gave me a
error unbound variable colorize-string

When i used the same in attached file this gave me a colorless output

However when I tried with "(colorize-string "hello" 'GREEN)" in same
file this gave me colored output but in REPL still a unbound-variable.

So, I tried changing "(GREEN)" to "GREEN" in ui.scm but resulted with a
colorless output.

> I found the error already, but I’m sure you can too.  Here’s a hint:
> play around with “(colorize-string "hello" '(GREEN))”.  Does this look
> right?  If not, why is that?  Look closely at the definition of
> “colorize-string”.  What arguments does it expect?  How are arguments
> bound to variables?  How many arguments does “colorize-string” accept?
> Are you really sure about that…?
Attached file contains the details can you please review it once.

---
Thanks!
Sahithi
(define-module (term ansi-color)
 #:export  (color
colorize-string)
 #:use-module (srfi srfi-1))  ; for 'remove'

(define ansi-color-tables
  `((CLEAR   .   "0")
(RESET   .   "0")
(BOLD.   "1")
(DARK.   "2")
(UNDERLINE   .   "4")
(UNDERSCORE  .   "4")
(BLINK   .   "5")
(REVERSE .   "6")
(CONCEALED   .   "8")
(BLACK   .  "30")
(RED .  "31")
(GREEN   .  "32")
(YELLOW  .  "33")
(BLUE.  "34")
(MAGENTA .  "35")
(CYAN.  "36")
(WHITE   .  "37")
(ON-BLACK.  "40")
(ON-RED  .  "41")
(ON-GREEN.  "42")
(ON-YELLOW   .  "43")
(ON-BLUE .  "44")
(ON-MAGENTA  .  "45")
(ON-CYAN .  "46")
(ON-WHITE.  "47")))

(define (color . lst)

"The allowed values for the attributes are listed below.  Unknown
attributes are ignored.

@table @asis
@item Reset Attributes
@samp{CLEAR} and @samp{RESET} are allowed and equivalent.

@item Non-Color Attributes
@samp{BOLD} makes text bold, and @samp{DARK} reverses this.
@samp{UNDERLINE} and @samp{UNDERSCORE} are equivalent.  @samp{BLINK}
makes the text blink.  @samp{REVERSE} invokes reverse video.
@samp{CONCEALED} hides output (as for getting passwords, etc.).

@item Foregrond Color Attributes
@samp{BLACK}, @samp{RED}, @samp{GREEN}, @samp{YELLOW}, @samp{BLUE},
@samp{MAGENTA}, @samp{CYAN}, @samp{WHITE}

@item Background Color Attributes
@samp{ON-BLACK}, @samp{ON-RED}, @samp{ON-GREEN}, @samp{ON-YELLOW},
@samp{ON-BLUE}, @samp{ON-MAGENTA}, @samp{ON-CYAN}, @samp{ON-WHITE}
@end table"

  (let ((color-list 
 (remove not 
 (map (lambda (color) (assq-ref ansi-color-tables color))
  lst
(if (null? color-list)
""
(string-append 
 (string #\esc #\[)
 (string-join color-list ";" 'infix)
 "m"
  
(define (colorize-string str . color-list)
"Returns a copy of @var{str} colorized using ANSI
escape sequences according to the attributes specified in
@var{color-list}.  At the end of the returned string, the color
attributes will be reset such that subsequent output will not
have any colors in effect.

The allowed values for the attributes are listed in the
documentation for the @code{color} function."
  (string-append
   (apply color color-list)
   str
   (color 'RESET)))

(display (colorize-string "Hello!\n" 'RED))

(for-each display
  (list (color 'RED)
"Hello!"
 (color 'RESET)))

Re: my latest blog post

[myglc2]

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

Re: my latest blog post

[Mark H Weaver]

myg...@gmail.com writes:

> 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.

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

Re: Cleaning up make clean's behavior

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Could you clarify what the problem is?
>
> (Besides I agree with Mark that “make clean” should not delete files it
> doesn’t know about.)

I also agree.

FYI, to delete everything and return to a pristine Git repository state,
I usually do this:

# Clean everything the Makefile knows about.
make distclean
# Clean everything Git doesn't track.
git clean -dfx
# Reset anything else back to whatever is in HEAD.
git reset --hard

Be careful though, because doing that is, of course, destructive.

-- 
Chris


signature.asc
Description: PGP signature

Re: Software Heritage archive is now live!

[Chris Marusich]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> The Software Heritage archive is now accessible:
>
>   https://www.softwareheritage.org/2018/06/07/opening-the-door/
>
>  [...]
>
> Anyway, I find this pretty exciting, and I think we’ll be able to use it
> as a fallback in ‘git-fetch’ without much work, since SWH supports Git
> sha1 object ids.

Cool!

> It’s unclear whether we’ll be able to use it for plain old tarballs
> since in general SWH is about storing commits or similar objects.  They
> injected ftp.gnu.org though, which is why the GCC tarball above is
> available, but I think it’s more of an exception.

I would have thought they'd archive releases, such as those distributed
as tarballs.  Either way, it's nice to have another archive around!

-- 
Chris


signature.asc
Description: PGP signature

Re: my latest blog post

[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). 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 ;)

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).

Talk is cheap. Coding is hard. 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.

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, but I doubt
the route is to take core contributors away from their work. I think
the route is to improve our web presence by tutorials, blogs and
internationalization. And, in fact, those already are priorities.

Pj.