Re: Sanitizer of record fields?

[zimoun]

Hi,

On Thu, 8 Sept 2022 at 13:36,  wrote:

> > srfi/srfi-1.scm:241:2: In procedure map:
> > In procedure map: Wrong type argument: "https://www.qt.io/;
> > building pages in '/tmp/gnu.org/software/guix'...
> >
>
> ISTM this "wrong type argument" is an infuriatingly common
> and typically useless error message.

The complete backtrace is showed in the bug report; see:



I just pasted what I consider as the relevant snippet.

> Would it be possible to have a debugging hook where the message is output
> which if activated would show the call stack, so one could see where in
> the user code it happened?

To my knowledge, it is not possible.  Note that here Guix is used as a
library called by 'haunt'.


Cheers,
simon

Re: Sanitizer of record fields?

[Maxime Devos]

On 08-09-2022 13:35, b...@bokr.com wrote:

Hi Simon, et al

On +2022-09-08 09:59:15 +0200, zimoun wrote:

Hi,

The website is currently failing [1] to build because a typo in some
package declaration.  The error message is not very helpful,

 srfi/srfi-1.scm:241:2: In procedure map:
 In procedure map: Wrong type argument: "https://www.qt.io/;
 building pages in '/tmp/gnu.org/software/guix'...


ISTM this "wrong type argument" is an infuriatingly common
and typically useless error message.

Would it be possible to have a debugging hook where the message is output
which if activated would show the call stack, so one could see where in
the user code it happened?

Activation could I imagine be by guile checking e.g.
"GUILE_THROW_DEBUG_WRONG_ARGUMENT" on invocation, to turn on the hook
in a way that would have zero performance effect if not activated.


Why a hook / environment variable in Guile? Backtraces are printed
by default, I do not see the benefit of disabling them by default and
adding an environment variable to enable them:


antipode@antipode ~$ guile -c '(map 0 1)'
Backtrace:
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   5 (apply-smob/0 #)
In ice-9/boot-9.scm:
    724:2  4 (call-with-prompt ("prompt") # …)
In ice-9/eval.scm:
    619:8  3 (_ #(#(#)))
In ice-9/command-line.scm:
   185:19  2 (_ #)
In unknown file:
   1 (eval (map 0 1) #)
In ice-9/boot-9.scm:
    218:9  0 (map 0 1)

ice-9/boot-9.scm:218:9: In procedure map:
In procedure map: Not a list: 1

Problem is already solved.

It appears that the website code catches exceptions and prints the error 
message,
but forgets to print the backtrace, but that seems to be a choice that 
the website

code made, not Guile. (Likely, an accidental choice, that can be improved.)

Greetings,
Maxime.




OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Sanitizer of record fields?

[Maxime Devos]

On 08-09-2022 13:35, b...@bokr.com wrote:

Can geiser trace stuff? IWBN to have something analogous to bash's
shopt for printing expression sources as they are read and/or executed.
Does something like that exist?


See: 'trace' in the Guile manual.  (This is a Guile feature, not a 
geiser feature.)


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Sanitizer of record fields?

[Maxime Devos]

On 08-09-2022 13:16, zimoun wrote:

Hi,

On Thu, 08 Sep 2022 at 11:32, Maxime Devos  wrote:

On 08-09-2022 09:59, zimoun wrote:

We could add a lint checker.  Is it a “good” idea?

We already have one, 'check-license'.

Yeah, but I was talking about check if the field return the expected
record type.  Not only for the license one.

Then maybe add more checkers, for the other fields as well? I'm not seeing
any downsides.

Because lint is not always applied, a check should be done when running
’make’ or a special target.  Is it a “good” idea?

I suppose it is a possibility, but it adds a few seconds to every 'make':

time ./pre-inst-env guix lint --checkers=license
make  all-recursive  [...]
gnu/packages/qt.scm:1373:13: qtshadertools@6.3.1: invalid license field
gnu/packages/tex.scm:11816:2: texlive-setspace@59745: invalid

It means that “guix lint” is not systematically run. :-)

I agree that the overhead on ’make’ is probably not worth.  Maybe, more
checks could be run by the pre push hook.  WDYT?

I suppose?  Not seeing any immediate problems, but I haven't ever pushed
to the Guix repo or ever used pre-push hooks ...

Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Sanitizer of record fields?

[bokr]

Hi Simon, et al

On +2022-09-08 09:59:15 +0200, zimoun wrote:
> Hi,
> 
> The website is currently failing [1] to build because a typo in some
> package declaration.  The error message is not very helpful,
> 
> srfi/srfi-1.scm:241:2: In procedure map:
> In procedure map: Wrong type argument: "https://www.qt.io/;
> building pages in '/tmp/gnu.org/software/guix'...
>

ISTM this "wrong type argument" is an infuriatingly common
and typically useless error message.

Would it be possible to have a debugging hook where the message is output
which if activated would show the call stack, so one could see where in
the user code it happened?

Activation could I imagine be by guile checking e.g.
"GUILE_THROW_DEBUG_WRONG_ARGUMENT" on invocation, to turn on the hook
in a way that would have zero performance effect if not activated.

Alternatively, could a wrapper start one's problem code using GDB
to put a break point at the hook place, pre-setting up the call
args etc and starting GDB so you could type run or step etc.?

Can geiser trace stuff? IWBN to have something analogous to bash's
shopt for printing expression sources as they are read and/or executed.
Does something like that exist?

Thoughts? :)

> and it was not straightforward to find the issue.  Using some ’pk’ in
> the website builder restricted the origin of the failure; but still.
> Thanks to Florian, they found this commit [2] introducing the package
> qtshadertools where a field is unexpected,
> 
> +(license (package-home-page qtbase
> 
> and boum!
> 
> It seems impossible to detect that typo at compile-time because fields
> do not have a specific type (except by convention).  Therefore, how can
> we detect such typo?
> 
> We could add a lint checker.  Is it a “good” idea?
> 
> Because lint is not always applied, a check should be done when running
> ’make’ or a special target.  Is it a “good” idea?
> 
> 
> 1: 
> 2: 
> 
> 
> 
> Cheers,
> simon
>
--
Regards,
Bengt Richter

Re: Sanitizer of record fields?

[zimoun]

Hi,

On Thu, 08 Sep 2022 at 11:32, Maxime Devos  wrote:
> On 08-09-2022 09:59, zimoun wrote:

>> We could add a lint checker.  Is it a “good” idea?
>
> We already have one, 'check-license'.

Yeah, but I was talking about check if the field return the expected
record type.  Not only for the license one.

>> Because lint is not always applied, a check should be done when running
>> ’make’ or a special target.  Is it a “good” idea?
>
> I suppose it is a possibility, but it adds a few seconds to every 'make':
>
> time ./pre-inst-env guix lint --checkers=license
> make  all-recursive  [...]
> gnu/packages/qt.scm:1373:13: qtshadertools@6.3.1: invalid license field
> gnu/packages/tex.scm:11816:2: texlive-setspace@59745: invalid

It means that “guix lint” is not systematically run. :-)

I agree that the overhead on ’make’ is probably not worth.  Maybe, more
checks could be run by the pre push hook.  WDYT?


Cheers,
simon

Re: how does antioxidant work?

[Maxime Devos]

On 08-09-2022 03:17, jgart wrote:

Hi Maxime,

how does antioxidant build system for rust work at a high level?

https://notabug.org/maximed/cargoless-rust-experiments

all best,


There are two parts:

 * The actual build system (antioxidant.scm) -- it reads the Cargo.toml
   to see what the dependencies are, looks for the (compiled!)
   dependencies in the 'inputs' and 'native-inputs', runs build.rs,
   compiles it (with 'rustc') and install the compiled result (sources
   aren't installed).  It also runs tests.
 * The cargo -> antioxidant transformation code.  The procedure
   vitaminate/auto* takes a package, and rewrites it to fit with
   antioxidant -- one of these is moving #:cargo-inputs into 'inputs',
   and (recursively) rewriting these inputs. Sometimes phases need to
   be adjusted, sometimes for cargo there was #:skip-build? but
   antioxidant doesn't do that, and it runs tests, so it sometimes
   turns out tests need to be disabled.

   (This will have to later be changed to _source code_
   transformations, maybe with "guix style", to integrate things into
   Guix proper)

There are also some other small things with some checks for vendoring, 
#:test-options


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Sanitizer of record fields?

[Maxime Devos]

On 08-09-2022 09:59, zimoun wrote:

We could add a lint checker.  Is it a “good” idea?

We already have one, 'check-license'.

Because lint is not always applied, a check should be done when running
’make’ or a special target.  Is it a “good” idea?


I suppose it is a possibility, but it adds a few seconds to every 'make':

time ./pre-inst-env guix lint --checkers=license
make  all-recursive  [...]
gnu/packages/qt.scm:1373:13: qtshadertools@6.3.1: invalid license field
gnu/packages/tex.scm:11816:2: texlive-setspace@59745: invalid

real    0m1,492s
user    0m3,331s
sys    0m0,214s

As such, here's an alternative proposal: instead of checking it at 
compile-time
(which is currently impossible), let's check them at runtime, with a 
field sanitizer.


Given that, unless I'm mistaken, build-aux/compile-all.scm loads every Guix
module anyway, and given that 'license' isn't thunked or delayed, 'the 
runtime

check' would also a compile-time check.

(Performance impact on "guix ..." commands would need to be checked.)

Alternatively, some error checking could be added to the website code, 
to indicate
which package and which is wrong.  Or maybe the website code can run the 
'license'

linter first.

Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Sanitizer of record fields?

[zimoun]

Hi,

The website is currently failing [1] to build because a typo in some
package declaration.  The error message is not very helpful,

srfi/srfi-1.scm:241:2: In procedure map:
In procedure map: Wrong type argument: "https://www.qt.io/;
building pages in '/tmp/gnu.org/software/guix'...

and it was not straightforward to find the issue.  Using some ’pk’ in
the website builder restricted the origin of the failure; but still.
Thanks to Florian, they found this commit [2] introducing the package
qtshadertools where a field is unexpected,

+(license (package-home-page qtbase

and boum!

It seems impossible to detect that typo at compile-time because fields
do not have a specific type (except by convention).  Therefore, how can
we detect such typo?

We could add a lint checker.  Is it a “good” idea?

Because lint is not always applied, a check should be done when running
’make’ or a special target.  Is it a “good” idea?


1: 
2: 



Cheers,
simon

Re: [IDEA] lint the whole dang thang

[zimoun]

Hi,

On Wed, 07 Sep 2022 at 17:18, jgart  wrote:

> wdyt if we have the following option for `guix lint`?
>
> ```
> -f, --whole-file   lint all the packages in the given file(s)
> ```

I would prefer -m/--manifest first. :-)


Cheers,
simon