When running "guix lint -c archival ugrep" I get this backtrace show below. Expected behavior: No crash, but a useful error message. Reproduce: * Guix 947aed127a48ef41bab3bdbb4252eb2a56dafc10 (2021-01-01 13:55:11) * ugrep (new package) see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45614 $ ./pre-inst-env guix lint ugrep -c archival … Backtrace:grep@3.1.1 [archival]... In ice-9/boot-9.scm: 1736:10 15 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 14 (apply-smob/0 #<thunk 7f1688172740>) In ice-9/boot-9.scm: 718:2 13 (call-with-prompt _ _ #<procedure default-prompt-handle?>) In ice-9/eval.scm: 619:8 12 (_ #(#(#<directory (guile-user) 7f1687daff00>))) In guix/ui.scm: 2127:12 11 (run-guix-command _ . _) In ice-9/boot-9.scm: 1736:10 10 (with-exception-handler _ _ #:unwind? _ # _) 1731:15 9 (with-exception-handler #<procedure 7f1685072a20 at ic?> ?) In srfi/srfi-1.scm: 634:9 8 (for-each #<procedure 7f1685dc8880 at guix/scripts/lin?> ?) In guix/scripts/lint.scm: 65:4 7 (run-checkers #<package ugrep@3.1.1 /home/hartmut/deve?> ?) In srfi/srfi-1.scm: 634:9 6 (for-each #<procedure 7f16756f69f0 at guix/scripts/lin?> ?) In guix/scripts/lint.scm: 74:21 5 (_ _) In guix/lint.scm: 1225:4 4 (check-archival _) 1092:2 3 (call-with-networking-fail-safe _ _ _) In ice-9/boot-9.scm: 1736:10 2 (with-exception-handler _ _ #:unwind? _ # _) 1669:16 1 (raise-exception _ #:continuable? _) 1667:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1667:16: In procedure raise-exception: In procedure string-prefix?: Wrong type argument in position 2 (expecting string): #<unspecified> -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Hi, Thanks for the report. It comes from 'visit-snapshot-url' returning #<unspecified> instead of #f. Then 'swh-url' fails because the 'path' argument is not a string. Well, I do not how to fix it. I am confused by: --8<---------------cut here---------------start------------->8--- ;; <https://archive.softwareheritage.org/api/1/origin/52181937/visits/> (define-json-mapping <visit> make-visit visit? json->visit (date visit-date "date" string->date*) (origin visit-origin) (url visit-url "origin_visit_url") (snapshot-url visit-snapshot-url "snapshot_url" string*) ;string | #f (status visit-status "status" string->symbol) ;'full | 'partial | 'ongoing (number visit-number "visit")) --8<---------------cut here---------------end--------------->8--- and why it is not string or #f. Ludo, any tips? :-) All the best, simon
Hi!
zimoun <zimon.toutoune@gmail.com> skribis:
> It comes from 'visit-snapshot-url' returning #<unspecified> instead of
> #f. Then 'swh-url' fails because the 'path' argument is not a string.
>
> Well, I do not how to fix it. I am confused by:
>
> ;; <https://archive.softwareheritage.org/api/1/origin/52181937/visits/>
> (define-json-mapping <visit> make-visit visit?
> json->visit
> (date visit-date "date" string->date*)
> (origin visit-origin)
> (url visit-url "origin_visit_url")
> (snapshot-url visit-snapshot-url "snapshot_url" string*) ;string | #f
> (status visit-status "status" string->symbol) ;'full | 'partial | 'ongoing
> (number visit-number "visit"))
>
> and why it is not string or #f.
As discussed on IRC the other day, the culprit seems to be the recent
guile-json upgrade (from 4.3.2 to 4.4.1, commit
f9e1baa8933ea2ed385d0272dbfbe4e22f192bde).
Were you able to check the raw JSON and see where the value is getting
lost?
Thanks,
Ludo’.
Hi Ludo, On Mon, 11 Jan 2021 at 14:12, Ludovic Courtès <ludo@gnu.org> wrote: >> (snapshot-url visit-snapshot-url "snapshot_url" string*) ;string | #f [...] >> and why it is not string or #f. > > As discussed on IRC the other day, the culprit seems to be the recent > guile-json upgrade (from 4.3.2 to 4.4.1, commit > f9e1baa8933ea2ed385d0272dbfbe4e22f192bde). > > Were you able to check the raw JSON and see where the value is getting > lost? Well, maybe I miss something. The JSON looks like: https://archive.softwareheritage.org/api/1/origin/https://github.com/Genivia/ugrep/get/ as we already discussed [1] the other day. From my understanding, when the field does not exist, before guile-json sets to #f and now it sets to #<unspecified>; I guess that it is related to the NEWS entry: --8<---------------cut here---------------start------------->8--- - Record-JSON mapping now allows using *unspecified* values to indicate a field record should not be serialized. (Fixes #61) --8<---------------cut here---------------end--------------->8--- and the behaviour change is described here: --8<---------------cut here---------------start------------->8--- Unspecified fields will now have the value *unspecified*. You mention that json->link-record would assign a #f but that's not actually correct, since a field could be a boolean in which case there would not be a way to identify it. --8<---------------cut here---------------end--------------->8--- <https://github.com/aconchillo/guile-json/issues/61#issuecomment-703212590> I am not familiar enough with Guile-JSON to see how to fix. Any tips? Cheers, simon 1: <http://logs.guix.gnu.org/guix/2021-01-07.log#180852>
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > Well, maybe I miss something. The JSON looks like: > > https://archive.softwareheritage.org/api/1/origin/https://github.com/Genivia/ugrep/get/ > > as we already discussed [1] the other day. From my understanding, when > the field does not exist, before guile-json sets to #f and now it sets > to #<unspecified>; I guess that it is related to the NEWS entry: > > - Record-JSON mapping now allows using *unspecified* values to indicate a > field record should not be serialized. > (Fixes #61) > > > and the behaviour change is described here: > > Unspecified fields will now have the value *unspecified*. You mention > that json->link-record would assign a #f but that's not actually > correct, since a field could be a boolean in which case there would not > be a way to identify it. > > <https://github.com/aconchillo/guile-json/issues/61#issuecomment-703212590> > > > I am not familiar enough with Guile-JSON to see how to fix. Any tips? Thanks for investigating! Looking more closely, I think the issue is related to this change, but to me it’s a bug: it’s now impossible to set a field to #f. Reported at <https://github.com/aconchillo/guile-json/issues/69>. Unfortunately, I can’t think of a way to work around it since it’s pretty fundamental. At any rate, we should add a test that exercises this in ‘tests/swh.scm’ so we don’t get caught by surprise next time. Thanks, Ludo’.
Hi! For the record, I reported the issue here: https://github.com/aconchillo/guile-json/issues/69 It was promptly fixed and released in 4.5.1, but at first sight this version introduces other issues. To be continued… Ludo’.
Hi Ludo, Can you share what other issues might arose after the fix? I'd be happy to look into it. Thanks! Aleix
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
> For the record, I reported the issue here:
>
> https://github.com/aconchillo/guile-json/issues/69
>
> It was promptly fixed and released in 4.5.1, but at first sight this
> version introduces other issues. To be continued…
Updated Guile-JSON in commit 5f7f4e16d64135291fc5b3d12e57476a52a97105,
followed by a test specifically for this issue in
5225732b9b54ffa92b9d199246b87dae666a3f77.
Thanks,
Ludo’.
Hi Alex! Thanks for reaching out to us. :-) Aleix via web <issues.guix.gnu.org@elephly.net> skribis: > Can you share what other issues might arose after the fix? > > I'd be happy to look into it. There were problems in JSON bindings we had that were not prepared to handle unspecified values, but that was easily fixed: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3d43b7aef3d5b7ad2ba0418d2afd657e5fedeaf5 I’m glad we have good test coverage here, otherwise adjusting to these changes can be very error-prone! Thanks, Ludo’.