Re: 01/01: gnu: Update SELinux packages.

[Ricardo Wurmus]

Hi Mark,

> rek...@elephly.net (Ricardo Wurmus) writes:
>
>> rekado pushed a commit to branch master
>> in repository guix.
>>
>> commit ca56021c2636130244ba41018161ca69805bc6b9
>> Author: Ricardo Wurmus 
>> Date:   Thu Jan 25 00:30:37 2018 +0100
>>
>> gnu: Update SELinux packages.
>>
>> * gnu/packages/selinux.scm (libsepol): Update to 2.7, release 20170804.
>
> Hydra failed to build this on both i686 and armhf, whereas version 2.6
> built successfully on those platforms.

I forgot to inform you that I’ve since fixed this by patching libsepol.
Thank you for notifying me of this build failure!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Looking for a sysadmin colleague to work on Guix and more

[Ricardo Wurmus]

Hello there,

the research group where I’m working is currently looking for a new
colleague for me to increase the size of our support team to three
people.

Unlike the previous job ads, this one explicitly mentions work on Guix
to support researchers using the HPC cluster.  Regular sysadmin tasks
will take up about two thirds of the time, with the remaining one third
being support for Guix on HPC.  The Guix work involves packaging
scientific applications upon user request, improving our use of Cuirass
for building package variants, but also debugging problems with using
Guix on the cluster (such as problems due to inconsistent legacy
profiles that aren’t use manifests).

We are a small team embedded in a core facility research group and have
relative autonomy within our domain.  We also facilitate communication
with the central IT department who administer the cluster and core
infrastructure.

I speak from experience when I say that this can be a lot of fun – you
get to regularly spend some of your work hours on advancing free
software, some more hours to support exciting medical research by
helping scientists solve problems, and yet more hours fighting
performance problems, legacy systems, half-baked solutions, and hardware
failures.

Note that this is not a remote job offer although the current location
of the institute is kinda remote: you would work in the northern fringes
of Berlin, just a couple dozen meters from the border to Brandenburg.
Our institute is planning to move to the city centre by the end of the
year.

Feel free to pass this job ad to people who might be interested.  Let me
know if you have any questions and I’ll try to answer them.  Note that
I’m just a lowly sysadmin, so contacting me does not constitute any
official communication wrt a job application.  To apply please follow
the instructions in the ad.

Attached is a copy of the job ad.

(Note that the only the text of the job ad is binding wrt the evaluation
of applications.)



Stellenangebot-10914 2018 System administrator.rtf
Description: RTF file

--
Ricardo Wurmus

System administrator
BIMSB - Scientific Bioinformatics Platform
Max Delbrueck Center for Molecular Medicine

Robert-Rössle-Str. 10, 13125, Berlin, Germany
Building 89, Room 1.08

email: ricardo.wur...@mdc-berlin.de
tel:   +49 30 9406 1796

Re: Dinner in Brussels?

[Thomas Danckaert]

From: l...@gnu.org (Ludovic Courtès)
Subject: Dinner in Brussels?
Date: Tue, 30 Jan 2018 13:34:46 +0100

To those going to the Guix workshop in Brussels this Friday: who’s 
in

for dinner (+ drink) on Friday evening?


Hi,

I probably won't be able to come tomorrow (all day and evening) due 
to unforeseen extra work.  With a lot of luck, I might be able to 
join late afternoon/evening.


I wish you a fun and fruitful meeting!

Thomas

Re: Pre-built binaries vs. performance

[Ludovic Courtès]

Fis Trivial  skribis:

> So, we can build packages in a generic way, and then provide optional
> dependencies.
> In this case, we treat SSE as default dependency and AVX2 as an optional
> dependency, let users specify whether they want it or not.
> AVX2 need not to be actual packages, it's just an abstraction.
>
> It's just a thought that we can abstract architecture as part of the
> dependency graph.

We do that in the form of the “system type”—“x86_64-linux”, etc.  That
captures what’s otherwise not captured in the graph: the architecture
and the kernel.

Someone proposed having, say, “x86_64avx2-linux”, which is similar in
spirit to what you’re proposing, I think.  However that’d be
inconvenient because every single package in the graph would have to be
rebuilt compared to “x86_64-linux”.

Also, I don’t see how to make that an _optional_ dependency.

Thanks,
Ludo’.

Re: Export environment variables only in `guix environment`.

[Chris Marusich]

Fis Trivial  writes:

> * Problem
> The exported environment variables can cause various problems in foreign
> distribution(1)(2). And besides, The long list of environment variables(4)
> injected into user's login shell makes the user's environment impure.

A lot of software is intended to be dynamically composed with other
software at run-time through the use of mechanisms like environment
variables.  Other mechanisms of dynamic composition at run-time also
exist, such as configuration files (e.g., ~/.emacs).  Consider the
EDITOR environment variable, which is traditionally used to indicate the
user's default text editor.  We COULD try to control the EDITOR
environment variable with Guix, but then you would have to update your
Guix profile every time you wanted to change your default text editor.
It would be "more pure," but less convenient.

To a certain extent, I think it is desirable (and unavoidable?) to use
these mechanisms to dynamically configure and compose software.
However, sometimes you can still let Guix control the environment
variables without making it inconvenient, and without letting the
environment variables set by Guix "leak" into the user's environment.
For example, you can wrap programs in a script that sets their
environment variables explicitly, rather than relying on the environment
variables being set correctly by the user.  Guix does this already for a
variety of packages (see the "asunder" package for a simple example).

For more information, check out section 7.1.1 "Principles" of the the
Nix thesis [1].  The entire section surrounding that phrase is also relevant
and interesting.

Footnotes: 
[1]  https://nixos.org/~eelco/pubs/phd-thesis.pdf

-- 
Chris


signature.asc
Description: PGP signature

Re: Pre-built binaries vs. performance

[Fis Trivial]

Fis Trivial writes:

> Ludovic Courtès writes:
>
>> Hello,
>>
>> Fis Trivial  skribis:
>>
>>> Ludovic Courtès writes:
>>>
 Hello Guix!

 This post is a followup to our previous discussions on how to handle
 architecture-specific optimizations:

   
 https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-binaries-vs-performance/

 Comments welcome!

 Ludo’.
>>>
>>> Instructions support seems like just another kind of runtime dependency,
>>> can we reconsider this:
>>> https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00166.html
>>
>> What do you mean?  The thread you’re referring to doesn’t discuss
>> architecture-specific optimizations.
>>
>> Ludo’.
>
> It's not architecture specific. But we can treat architecture as one of
> the runtime dependency, right? For example, openBlas depends on SSE
> instructions set, but, optionally it can depends on AVX2. (Not a perfect
> example since openblas can optimize itself at runtime, but hopefully you
> can understand the idea)
>
> So, we can build packages in a generic way, and then provide optional
> dependencies.
> In this case, we treat SSE as default dependency and AVX2 as an optional
> dependency, let users specify whether they want it or not.
> AVX2 need not to be actual packages, it's just an abstraction.
>
> It's just a thought that we can abstract architecture as part of the
> dependency graph.
>
> Thanks for you time.

Replying to myself, if this is doable, it will not only benefit
performance, but also all the other packages who have optional language
bindings, optional GUI backends or any other optional runtime
dependencies/feature. 

Re: Pre-built binaries vs. performance

[Fis Trivial]

Ludovic Courtès writes:

> Hello,
>
> Fis Trivial  skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hello Guix!
>>>
>>> This post is a followup to our previous discussions on how to handle
>>> architecture-specific optimizations:
>>>
>>>   
>>> https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-binaries-vs-performance/
>>>
>>> Comments welcome!
>>>
>>> Ludo’.
>>
>> Instructions support seems like just another kind of runtime dependency,
>> can we reconsider this:
>> https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00166.html
>
> What do you mean?  The thread you’re referring to doesn’t discuss
> architecture-specific optimizations.
>
> Ludo’.

It's not architecture specific. But we can treat architecture as one of
the runtime dependency, right? For example, openBlas depends on SSE
instructions set, but, optionally it can depends on AVX2. (Not a perfect
example since openblas can optimize itself at runtime, but hopefully you
can understand the idea)

So, we can build packages in a generic way, and then provide optional
dependencies.
In this case, we treat SSE as default dependency and AVX2 as an optional
dependency, let users specify whether they want it or not.
AVX2 need not to be actual packages, it's just an abstraction.

It's just a thought that we can abstract architecture as part of the
dependency graph.

Thanks for you time.

Re: Pre-built binaries vs. performance

[Ludovic Courtès]

Hello,

Fis Trivial  skribis:

> Ludovic Courtès writes:
>
>> Hello Guix!
>>
>> This post is a followup to our previous discussions on how to handle
>> architecture-specific optimizations:
>>
>>   
>> https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-binaries-vs-performance/
>>
>> Comments welcome!
>>
>> Ludo’.
>
> Instructions support seems like just another kind of runtime dependency,
> can we reconsider this:
> https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00166.html

What do you mean?  The thread you’re referring to doesn’t discuss
architecture-specific optimizations.

Ludo’.

Re: Pre-built binaries vs. performance

[Fis Trivial]

Ludovic Courtès writes:

> Hello Guix!
>
> This post is a followup to our previous discussions on how to handle
> architecture-specific optimizations:
>
>   
> https://guix-hpc.bordeaux.inria.fr/blog/2018/01/pre-built-binaries-vs-performance/
>
> Comments welcome!
>
> Ludo’.

Instructions support seems like just another kind of runtime dependency,
can we reconsider this:
https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00166.html

Thanks for your time.

Re: Export environment variables only in `guix environment`.

[Fis Trivial]

Pjotr Prins writes:

> On Thu, Feb 01, 2018 at 12:40:39AM +0100, Ludovic Courtès wrote:
>> Hello,
>> 
>> Fis Trivial  skribis:
>> 
>> > * Problem
>> > The exported environment variables can cause various problems in foreign
>> > distribution(1)(2). And besides, The long list of environment variables(4)
>> > injected into user's login shell makes the user's environment impure.
>> > So, I believe that if I want to run guix safely on a foreign 
>> > distributions, I
>> > need to eliminate the need for exporting environment variables from guix 
>> > to my
>> > login shell.
>
> Not a problem, just don't do it :). To import the invironments 
> run
>
>   . $PROFILE/etc/profile
>
> I do that in scripts or when I need something. Even so, many programs
> work with just the PATH set.
>
> Pj.

Currently my solution is separating the profile file into two parts, one
contains PATH and SSL related envs, the second part contains all the
others exported by guix. Then I source the first part in login shell
while the second part in interactive shell.

It's a little hack, which means not the way it should work, to me that's
a problem. Guix is still young, we don't have many legacy problems that
needs hacks to solve. I love guix project, which is elegant from the
choice of scripting language and the underlying functional logic. I hope
that if we be picky enough, Guix can stay this way. So lets eliminate
these hacks. :)

Thanks for your time.

Re: Export environment variables only in `guix environment`.

[Fis Trivial]

Hi:

Ludovic Courtès writes:

> Hello,
>
> Fis Trivial  skribis:
>
>> * Problem
>> The exported environment variables can cause various problems in foreign
>> distribution(1)(2). And besides, The long list of environment variables(4)
>> injected into user's login shell makes the user's environment impure.
>> So, I believe that if I want to run guix safely on a foreign distributions, I
>> need to eliminate the need for exporting environment variables from guix to 
>> my
>> login shell.
>
> Can you clarify what problems you are facing?
>

There are 2 footnote notations after "foreign distributions", (1) and
(2), the footnotes are appended at the end of origin mail. Those are 2
bug reports from me:). (3) from the origin mail is a github issue about
this problem from NixOS.

> I remember one problematic case on foreign distros, that of XDG_DATA_DIRS:
>
>   https://bugs.gnu.org/26202
>

I read this bug report before, this particular env is about gnome shell
accessing installed GUI applications, not directly related to accessing
libraries. It's hard to avoid if you want to use GUI apps from guix. But
libraries related envs like PYTHONPATH can be avoided.

> The environment variable settings that ‘guix package’ produces are here
> to ensure that software installed with Guix will work as expected.
> Ignoring them wholesale (à la Nix) doesn’t sound like a good idea.  :-)
>
> Thanks,
> Ludo’.

Thanks for your time.

Re: Dualbooting with guixsd not handling grub installation

[Félicien Pillot]

Hi Oleg,

Le Thu, 01 Feb 2018 09:14:54 +0300,
Oleg Pykhalov  a écrit :
> We could start by adding a way to add anything.  Here is a patch.
> Probably ugly, but as a draft and idea about additional-options.
> 

When I try your patch (to solve the dualboot problem I have too) I
get this error:

/etc/config.scm:17:10 : error: extraneous field initializers 
(additional-options)

Why me and not you?

--
Félicien Pillot
2C7C ACC0 FBDB ADBA E7BC 50D9 043C D143 6C87 9372
felic...@gnu.org - felicien.pil...@riseup.net


pgpLOqUmaVEEv.pgp
Description: Signature digitale OpenPGP

Re: Maintaining implementations of similar utility functions like json-fetch

[Gábor Boskovits]

2018-02-01 12:54 GMT+01:00 Catonano :

>
>
> 2018-01-31 18:32 GMT+01:00 Jelle Licht :
>
>> Hi Ludo',
>>
>>
>> 2018-01-27 17:09 GMT+01:00 Ludovic Courtès :
>>
>>> Hello!
>>>
>>> Jelle Licht  skribis:
>>>
>>> > I noticed that there are currently two very similar functions for
>>> fetching
>>> > json data; `json-fetch' in (guix import json) and `json-fetch*' in
>>> (guix
>>> > import github).
>>> >
>>> > Some things I noticed:
>>> > - Dealing with http error codes seems to be a bit more robust in
>>> > `json-fetch*'.
>>> > - Making sure that (compliant) servers give responses in the proper
>>> format
>>> > seems more robust in `json-fetch' due to using Accept headers.
>>> > - Dealing with the fact that json responses are technically allowed to
>>> be
>>> > lists of objects, which `json-fetch' does not handle gracefully.
>>> >
>>> > For this issue specifically, would it make sense to combine the two
>>> > definitions into a more general one?
>>>
>>> Definitely, we should just keep one.  It’s not even clear how we ended
>>> up with the second one.
>>>
>>
>> I even had a third one in my local tree which happened to have a
>> conflict, which
>> is how I found out in the first place, so I understand how these things
>> can happen.
>>
>>>
>>> > My more general concern would be on how we can prevent bug fixes only
>>> being
>>> > applied to one of several nearly identical functions. IOW, should we
>>> try to
>>> > prevent situations like this from arising, or is it okay if we somehow
>>> make
>>> > sure that fixes should be applied to both locations?
>>>
>>> We should prevent such situations from arising, and I think we do.
>>>
>>> Regarding this could we consider implementing on of these funtions in
terms of each other, or
use the common generic one to implent both, as this would mitigate the
problem where only
one of these is fixed.

> The difficulty is that avoiding duplication requires knowing the whole
>>> code base well enough.  Sometimes you just don’t know that a utility
>>> function is available so you end up writing your own, and maybe the
>>> reviewers don’t notice either and it goes through; or sometimes you need
>>> a slightly different version so you duplicate the function instead of
>>> generalizing it.
>>>
>>> Anyway, when we find occurrences of this pattern, we should fix them!
>>>
>>
>> I basically added the robust features of `json-fetch*' to the exported
>> `json-fetch'
>> instead, and all existing functionality seems to work out as far as I can
>> see.
>>
>> I did notice that I now produce hash-tables by default, and some of the
>> existing usages of `json-fetch*' expect an alist instead. What would be a
>> guile-
>> appropriate way of dealing with this? I currently have multiple
>> `(hash-table->alist (json-fetch <...>))' littered in my patch which seems
>> suboptimal,
>> but always converting the parsed json into an alist seems like it might
>> also not be
>> what we want.
>>
>
> of course I' d wait for a thought by some more competent guiler,  but I' d
> like to offer my take on this
>
> The new function could take one further argument, a boolean
>
> If the boolean is true, it could return a hash table
>
> Otherwise, it could return a list
>
> If the majority of call sites expect a list, the further argument could
> set to false as default
>
> So you' d only have to fix those call sites that want a hash table instead
>
> If, instead, the majority of call sites want a hash table, your procedure
> would return a hash table by default and a list by a further argument, so
> you' d have to fix a minority of call sites anyway
>
> I hope I didn' t make myself a fool :-/
>
>
>> Thanks,
>> Ludo’.
>>
>
>> - Jelle
>>
>
>

Re: Maintaining implementations of similar utility functions like json-fetch

[Catonano]

2018-01-31 18:32 GMT+01:00 Jelle Licht :

> Hi Ludo',
>
>
> 2018-01-27 17:09 GMT+01:00 Ludovic Courtès :
>
>> Hello!
>>
>> Jelle Licht  skribis:
>>
>> > I noticed that there are currently two very similar functions for
>> fetching
>> > json data; `json-fetch' in (guix import json) and `json-fetch*' in (guix
>> > import github).
>> >
>> > Some things I noticed:
>> > - Dealing with http error codes seems to be a bit more robust in
>> > `json-fetch*'.
>> > - Making sure that (compliant) servers give responses in the proper
>> format
>> > seems more robust in `json-fetch' due to using Accept headers.
>> > - Dealing with the fact that json responses are technically allowed to
>> be
>> > lists of objects, which `json-fetch' does not handle gracefully.
>> >
>> > For this issue specifically, would it make sense to combine the two
>> > definitions into a more general one?
>>
>> Definitely, we should just keep one.  It’s not even clear how we ended
>> up with the second one.
>>
>
> I even had a third one in my local tree which happened to have a conflict,
> which
> is how I found out in the first place, so I understand how these things
> can happen.
>
>>
>> > My more general concern would be on how we can prevent bug fixes only
>> being
>> > applied to one of several nearly identical functions. IOW, should we
>> try to
>> > prevent situations like this from arising, or is it okay if we somehow
>> make
>> > sure that fixes should be applied to both locations?
>>
>> We should prevent such situations from arising, and I think we do.
>>
>> The difficulty is that avoiding duplication requires knowing the whole
>> code base well enough.  Sometimes you just don’t know that a utility
>> function is available so you end up writing your own, and maybe the
>> reviewers don’t notice either and it goes through; or sometimes you need
>> a slightly different version so you duplicate the function instead of
>> generalizing it.
>>
>> Anyway, when we find occurrences of this pattern, we should fix them!
>>
>
> I basically added the robust features of `json-fetch*' to the exported
> `json-fetch'
> instead, and all existing functionality seems to work out as far as I can
> see.
>
> I did notice that I now produce hash-tables by default, and some of the
> existing usages of `json-fetch*' expect an alist instead. What would be a
> guile-
> appropriate way of dealing with this? I currently have multiple
> `(hash-table->alist (json-fetch <...>))' littered in my patch which seems
> suboptimal,
> but always converting the parsed json into an alist seems like it might
> also not be
> what we want.
>

of course I' d wait for a thought by some more competent guiler,  but I' d
like to offer my take on this

The new function could take one further argument, a boolean

If the boolean is true, it could return a hash table

Otherwise, it could return a list

If the majority of call sites expect a list, the further argument could set
to false as default

So you' d only have to fix those call sites that want a hash table instead

If, instead, the majority of call sites want a hash table, your procedure
would return a hash table by default and a list by a further argument, so
you' d have to fix a minority of call sites anyway

I hope I didn' t make myself a fool :-/


> Thanks,
> Ludo’.
>

> - Jelle
>

Re: Dinner in Brussels?

[Björn Höfling]

On Thu, 01 Feb 2018 00:43:33 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> Hello,
> 
> Björn Höfling  skribis:
> 
> > If there is space left, I would join for the dinner on Friday. Has
> > someone reserved a restaurant yet? I enjoyed the Lebanese food from
> > last year very much, though it was maybe a bit of a small and narrow
> > room?  
> 
> I enjoyed it too, but if we’re going to be 20–30 on Friday, that may
> be too small indeed.
> 
> (Were you volunteering to actually book something?  :-))

This looks like it's a bigger job. First, I have to program an AI that
scans through the restaurants pictures and analyzes its capacity...

No, really, I have the felling many restaurants I found are quite nice
and cozy, but as small as the one we had last year. The second night we
ran into a quite big one with 3 floors and much space, but I can't
remember its name/location any more.

Here is one shot I got:

https://www.tripadvisor.com/Restaurant_Review-g188644-d8461423-Reviews-Le_Bistro-Brussels.html

It has an upper floor, so we can be a bit separated, but maybe it's too
far away from ICAB (45m walk,
https://maps.openrouteservice.org/directions?n1=50.841693=4.359813=14=50.849937,4.374543,50.833454,4.3452=2=0=-1=0=en-US=km)?
 

What do you think? Maybe it would be easier to ran into one tonight in
RL instead of spending hours in internet search?

Björn




pgpLmUuRsOrto.pgp
Description: OpenPGP digital signature

Re: 03/03: gnu: python-dateutil: Update to 2.6.1.

[Marius Bakke]

Alex Vong  writes:

> Ben Woodcroft  writes:
>
>> On 31/01/18 16:18, Alex Vong wrote:
>>> Ben Woodcroft  writes:
>>>
 Hi Mark, Marius,


 On 31/01/18 12:52, Mark H Weaver wrote:
> Hi,
>
> mba...@fastmail.com (Marius Bakke) writes:
>
>> mbakke pushed a commit to branch master
>> in repository guix.
>>
>> commit b94502bed69c0fb5033d702fd0308209efb8815c
>> Author: Alex Vong 
>> Date:   Sat Jan 27 22:58:58 2018 +0800
>>
>>   gnu: python-dateutil: Update to 2.6.1.
>>* gnu/packages/python.scm (python-dateutil,
>> python2-dateutil): Update to
>>   2.6.1.
> This seems to have broken 'python-pandas'.
 'python-pandas' on master needs to be updated to 0.22, but testing the
 updated version requires adding further packages and doing a few
 updates. I have been working on this (slowly) on 'core-updates' since
 it requires updates to some of the more core python testing
 packages. I have a draft set of packages

 WDYT about updating it on the master branch but disabling automated
 tests until 'core-updates' is merged?

>>> or maybe revert the python-dateutil commit for now? I don't think there
>>> is a package relying on the latest version of python-dateutil. I am
>>> going to package something depending on python-dateutil, but I think it
>>> should work on the older version of python-dateutil as well. WDYT?
>>
>> Sure, if you like.
>>  ben
>
> Oh, I forget to mention: to apply it to core-updates instead.

I reverted it on 'master' and will merge it to core-updates and add it
there shortly.


signature.asc
Description: PGP signature

Re: Thursday dinner in Brussels

[Gábor Boskovits]

2018-02-01 11:12 GMT+01:00 julien lepiller :

> Le 2018-02-01 10:47, Chris Marusich a écrit :
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>> Hey hey!
>>>
>>> For those of us available on Thursday evening (that’s ~4 people
>>> currently?), I suggest meeting in the bar called “Au Bon Vieux Temps”
>>> downtown around 7PM, and from there we can look for a place to eat:
>>>
>>>   https://www.openstreetmap.org/node/4120134090
>>>
>>> If anyone has a mobile phone, perhaps you can share your number off-list
>>> with Chris Baines, who said will arrive later.
>>>
>>> I expect to be on #guix in the late afternoon, too.
>>>
>>> See you soon!  :-)
>>>
>>> Ludo’.
>>>
>>
>> I arrived just now; I'm staying at ICAB.  I'd love to join you and the
>> others for dinner tonight (Thursday) and tomorrow (Friday)!
>>
>> For tonight, that location looks great!  I'm going to spend most of
>> today wandering around central Brussels, so I'll meet you and the others
>> there at 7 pm.
>>
>> I have a mobile phone.  It's cheap to send/receive data (like email) and
>> texts, but it's expensive to make voice calls.  I'll share some more
>> detailed contact info privately with you and the others who have said
>> they will be coming tonight, including Chris Baines.
>>
>> I'm looking forward to it!
>>
>
> Hi,
>
> I think there was a misunderstanding, I received contact information from
> two
> people already so you probably thought I would be there on thursday.
> Actually
> I will be arriving around noon on Friday. I'm in for Friday dinner of
> course.
> Sorry for the confusion.
>
> I will also arrive only on Friday

Re: Thursday dinner in Brussels

[julien lepiller]

Le 2018-02-01 10:47, Chris Marusich a écrit :

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


Hey hey!

For those of us available on Thursday evening (that’s ~4 people
currently?), I suggest meeting in the bar called “Au Bon Vieux Temps”
downtown around 7PM, and from there we can look for a place to eat:

  https://www.openstreetmap.org/node/4120134090

If anyone has a mobile phone, perhaps you can share your number 
off-list

with Chris Baines, who said will arrive later.

I expect to be on #guix in the late afternoon, too.

See you soon!  :-)

Ludo’.


I arrived just now; I'm staying at ICAB.  I'd love to join you and the
others for dinner tonight (Thursday) and tomorrow (Friday)!

For tonight, that location looks great!  I'm going to spend most of
today wandering around central Brussels, so I'll meet you and the 
others

there at 7 pm.

I have a mobile phone.  It's cheap to send/receive data (like email) 
and

texts, but it's expensive to make voice calls.  I'll share some more
detailed contact info privately with you and the others who have said
they will be coming tonight, including Chris Baines.

I'm looking forward to it!


Hi,

I think there was a misunderstanding, I received contact information 
from two
people already so you probably thought I would be there on thursday. 
Actually
I will be arriving around noon on Friday. I'm in for Friday dinner of 
course.

Sorry for the confusion.

Re: Thursday dinner in Brussels

[Chris Marusich]

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

> Hey hey!
>
> For those of us available on Thursday evening (that’s ~4 people
> currently?), I suggest meeting in the bar called “Au Bon Vieux Temps”
> downtown around 7PM, and from there we can look for a place to eat:
>
>   https://www.openstreetmap.org/node/4120134090
>
> If anyone has a mobile phone, perhaps you can share your number off-list
> with Chris Baines, who said will arrive later.
>
> I expect to be on #guix in the late afternoon, too.
>
> See you soon!  :-)
>
> Ludo’.

I arrived just now; I'm staying at ICAB.  I'd love to join you and the
others for dinner tonight (Thursday) and tomorrow (Friday)!

For tonight, that location looks great!  I'm going to spend most of
today wandering around central Brussels, so I'll meet you and the others
there at 7 pm.

I have a mobile phone.  It's cheap to send/receive data (like email) and
texts, but it's expensive to make voice calls.  I'll share some more
detailed contact info privately with you and the others who have said
they will be coming tonight, including Chris Baines.

I'm looking forward to it!

-- 
Chris


signature.asc
Description: PGP signature

Re: System calls interrupted by signals - or not

[Danny Milosavljevic]

Hi Mark,

On Thu, 01 Feb 2018 03:13:33 -0500
Mark H Weaver  wrote:

> Guile is a library meant for use within existing applications, and
> therefore needs to be able to cope with whatever signal handling policy
> those applications have chosen.  We certainly cannot assume that all
> kinds of signals will be configured for SA_RESTART.

That's too bad.  It can't be helped, then.
Then see the table for a little overview.

(I've tried very hard to sensibly handle EINTR in the past and it's
surprisingly difficult - that table is what I got out of it - and
the decision to avoid PC-losering signals whenever I can)

And even for the purported use of EINTR (so that you can have complicated
signal-unsafe handler actions after an "if (errno == EINTR)" block)
it's difficult to get right.  That's because you only get EINTR when a system
call has been interrupted by a signal.  It can happen that you aren't yet in
the system call, the signal handler runs (to completion), and then you enter a
system call.
You *don't* get EINTR for the missed signal then.
I don't know what they were thinking.

> There are cases where you may want the
> ability to interrupt a system call without killing the thread.  Suppose
> you are waiting for a large I/O operation to complete over a slow
> network or device.  Signals are the only way I know of in POSIX to
> interrupt a system call, but it can only be done if there's at least one
> kind of signal that's not configured for SA_RESTART.

That's a good point.

But many people just use

  do { syscall } while (errno == EINTR);

in random libraries and then you can't interrupt the system call after all
in your user program.

Also, there's a race because you can be right before entering a system call,
your signal handler runs, and then the system call isn't interrupted after
all (because there was nothing to interrupt - and now you can't branch
on it anymore.  That's how I started to enter this EINTR rabbit hole -
one of my programs had such a bug).

>   "When you don’t specify with ‘sigaction’ or ‘siginterrupt’ what a
>particular handler should do, it uses a default choice.  The default
>choice in the GNU C Library is to make primitives fail with ‘EINTR’."

:-(

Re: System calls interrupted by signals - or not

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic  writes:

>>This can happen if interrupted by a signal, 
>
> If only BSD-style signals (SA_RESTART) are used, as is very likely, this
> should not happen.

Guile is a library meant for use within existing applications, and
therefore needs to be able to cope with whatever signal handling policy
those applications have chosen.  We certainly cannot assume that all
kinds of signals will be configured for SA_RESTART.

> It only happens with old "PC-losering" style signal handlers - which even
> signal(2) doesn't install anymore (and I know of no reason why anyone
> should ever use those).

Although SA_RESTART is more convenient, less error prone, and arguably
the sensible default, it is also strictly less powerful than what you
can do without SA_RESTART.  There are cases where you may want the
ability to interrupt a system call without killing the thread.  Suppose
you are waiting for a large I/O operation to complete over a slow
network or device.  Signals are the only way I know of in POSIX to
interrupt a system call, but it can only be done if there's at least one
kind of signal that's not configured for SA_RESTART.

At least that's my understanding.  Please correct me if I'm wrong.

Note that EINTR is the default behavior in GNU libc when using the
advanced signal handling interfaces:



  "When you don’t specify with ‘sigaction’ or ‘siginterrupt’ what a
   particular handler should do, it uses a default choice.  The default
   choice in the GNU C Library is to make primitives fail with ‘EINTR’."

  Mark