Hi, On +2020-07-30 00:15:56 +0200, Ricardo Wurmus wrote: > > Jan Wielkiewicz <tona_kosmicznego_smie...@interia.pl> writes: > > > Dnia 2020-07-29, o godz. 22:17:01 > > Ricardo Wurmus <rek...@elephly.net> napisał(a): > > > >> > >> “avr-toolchain” is a procedure, not a package. Use > >> “avr-toolchain-4.9” or “avr-toolchain-5”. > >> > > > > Success! > > > > What about the strange message though? > > "incorrect package definition" would be better. > > “Unbound variable: ~S” looks like a format string with a placeholder > that didn’t get replaced with an actual value. It would be marginally > better if it said “Unbound variable: avr-toolchain”.
I suspect there are also bugs lurking in the exception-reporting chain between a (throw 'exception args ...) and the ultimate format statement that produces a message with "~S" in it. Perhaps one got fixed or avoided in the upgrade? It seems like something must receive a malformed (key . args) pair where the args don't match the standard(?) tuple expected for the key. I'd look for dynamic format string generation splitting arg strings and mistakenly recomposing a format string and args for it, such that "~S" got placed in the arg list instead of string-appended into the proper final format. Just a hunch. IIRC I've seen mangling the final format string and its args wind up with a mismatch in number of args and interpolation "~s" elements and if not papered over, that gets reported as a formatting error (which it is, but which hides the real error). > > We should, I think, take advantage of the fact that the type of inputs > is known: it can only be an origin or a package value. Perhaps we can > catch unbound variables in inputs and print a more valuable error > message. I think you are right. And all implicit meta-data should be seen as potential security vulnerabilities IMO :) Who do you trust to do a reinterpret-cast for you? > > -- > Ricardo > > > -- Regards, Bengt Richter
