Re: guile-hall issues converting my project to a hall project
Yes, I forgot to mention this in my wall of text. Vladimir's solution is correct. Hall does this in master too. Alex On Wed, 17 Feb 2021, 23:47 Vladimir Zhbanov, wrote: > > Hi Zelphir, > > On Tue, Feb 16, 2021 at 01:23:34AM +0100, Zelphir Kaltstahl wrote: > ... > > > The line in the generated `configure` file looks quite simple. It is > only: > > > > > > GUILE_PKG(3.0 2.2 2.0) > > > > > It looks like there could be a simple fix, but I do not know what to do > > about this error and how that error could happen in the first place. > > IIUC, the macro args should be in square brackets: > > GUILE_PKG([3.0 2.2 2.0]) > > -- > Vladimir > >
Re: guile-hall issues converting my project to a hall project
Hi Alex! I am willing to test/try some more. When you say "since commit xyz", do you mean commit of guile-hall itself, or a commit of Guix, where an updated version of guile-hall is available? How would I test the master branch version? I would guess install it in a guix environment and then use that environment to try and convert a project. What would you suggest testing? It was quite OK to edit hall.scm in an editor. Perhaps, if a project is significantly bigger than my project, it would become cumbersome, but for me personally it is fine, now that I know what goes in there and how it needs to look. I have not yet begun writing a guide for converting a project. Hopefully I'll be able to do so soon. Best regards, Zelphir On 2/17/21 10:17 PM, Alex Sassmannshausen wrote: > Hi Zelphir and Tim, > > I am the author of guile hall — apologies for only now getting into this > thread. I'm afraid I have been somewhat distracted with other things. > > First of all I want to echo what others have said — thank you very much > for your detailed descriptions of what exactly happened when you tried > to migrate the project to guile hall. > > The aim of the project is to massively reduce the barrier of entry to > creating new, portable, high quality guile projects — and to contribute > them to Guix. Your descriptions suggest it's not there yet! > > In any case, some comments inline: > > Zelphir Kaltstahl writes: > >> Hello Tim! >> >> Thank you, it works now! >> >> Removing the duplicate entry of `fslib` in hall.scm fixed it. > Fwiw, since commit ac76541a this issue can be automatically resolved by > running scan once more: it should remove duplicate entries in hall.scm. > >> Regarding the license: OK, I have no problem moving my license to >> `COPYING`. However, I still think, that it should not put GPL there, >> when I specified AGPL in `hall.scm`. This looks like a hardcoded >> fallback, which does not take the license specification into account. >> Something like: "If there is no `COPYING` file just put GPL into a file >> `COPYING`." instead of "If there is no `COPYING` file just put >> into a file `COPYING`.". I could be >> wrong though, as I do not know anything about guile-hall's internals. > This is odd — Hall should respect your license choice. It should, for > (A)GPL licenses automatically download those from the internet and > install them in COPYING. There was an issue with those licenses hiding > behind a 302 status code, which resulted in fallback text being loaded > in COPYING. But even that fallback text should respect your license. > > I just tried changing my license to AGPLv3+ in one of my projects, > running hall from Master (the most recent commit fixes the 302 license > issue), and it's fetching the license correctly. > > I'd be interested in seeing what your experience is if you are willing > to try? > > In any case, Hall is undergoing active development, and I'm hoping to > have a fresh release end of this month, with a whole bunch of > improvements and bug fixes. Definitely feel free to drop issues to me > directly by email or on gitlab (though some of the ones you raised have > been fixed, like the unknown filetype issue). > > Best wishes, > > Alex > >> Follow up question would be, how to bring the package into the guix >> repository, but I am guessing, that it will be answered at >> https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html, >> which I have not read yet. >> >> Another question is, whether I should put you into the authors file and >> write something like "help with packaging" there. What is the common >> practice? >> >> Best regards, >> Zelphir >> >> On 2/16/21 5:48 PM, Tim Van den Langenbergh wrote: >>> Err, looking at your hall.scm file, you have the fslib file added to your >>> libraries twice. >>> >>> Guix environment is not needed if you have all the requirements for building >>> the package installed locally, but if you want to distribute your package >>> it's >>> good practise to ensure it builds in a clean environment (see also https:// >>> guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html for more >>> information about Guix environments). >>> >>> The "COPYING" file is hardcoded as license file in Hall, to ensure >>> compatibility >>> with GNU standards: https://www.gnu.org/licenses/gpl-howto.en.html >>> >>> Hope this helps, >>> >>> Vale >>> >>> -Tim >>> >>> -- repositories: https://notabug.org/ZelphirKaltstahl
Guile Hacker Handbook - Character sets
Dear Guilers ! I happily managed to find some time to write a new chapter for the Guile Hacker Handbook ! https://jeko.frama.io/en/char-sets.html It deals with char-sets, something new to me. The exercise was fun, I liked how convenient it is to play with these data type. As always, I would be glad to start a conversation around my code snippets, the handbook, test driven development, or whatever linked to Guile ! :-) The next chapter will probably introduce macros (syntax-rules) ! For those who missed it, I am also starting a work towards a guile-ide.el for Emacs. https://framagit.org/Jeko/guile-ide Actually it's just a set of extensions I use (or will) and some feature I would like it to provide. I plan to engage with the Emacs team to see how we can work together to enhance the Guile hacking experience ! Thank you ! Cheers ! Jérémy -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Guile Hacker Handbook - Character sets
Hi Jérémy, > For those who missed it, I am also starting a work towards a guile-ide.el for > Emacs. > > https://framagit.org/Jeko/guile-ide Interesting. Do you think there is some overlap with guile-studio[1]? (It’s available in Guix.) [1]: https://git.elephly.net/software/guile-studio.git -- Ricardo
Re: Guile Hacker Handbook - Character sets
Jérémy Korwin-Zmijowski writes: > For those who missed it, I am also starting a work towards a guile-ide.el for > Emacs. > > https://framagit.org/Jeko/guile-ide Forgot to include a screenshot of Guile Studio: https://elephly.net/downies/guile-studio.png -- Ricardo
Re: Guile Hacker Handbook - Character sets
Hello Jeremy! I am looking forward to seeing a new chapter of your handbook, especially, if there is more stuff that explains macros and how to get something useful done with macros. : ) There is guile-studio as well: https://guix.gnu.org/en/packages/guile-studio-0.1.0-1.93622e7/ (That's what I found on a quick guix search.), which is already making use of Emacs, as far as I remember. I think someone on the guile IRC channel mentioned it and might be here on the mailing list. Perhaps the goals of that project are different from guile-ide, but I thought I should probably mention it. Best regards, Zelphir On 2/18/21 8:54 PM, Jérémy Korwin-Zmijowski wrote: > Dear Guilers ! > > I happily managed to find some time to write a new chapter for the Guile > Hacker Handbook ! > > https://jeko.frama.io/en/char-sets.html > > It deals with char-sets, something new to me. The exercise was fun, I liked > how convenient it is to play with these data type. > > As always, I would be glad to start a conversation around my code snippets, > the handbook, test driven development, or whatever linked to Guile ! :-) > > The next chapter will probably introduce macros (syntax-rules) ! > > For those who missed it, I am also starting a work towards a guile-ide.el for > Emacs. > > https://framagit.org/Jeko/guile-ide > > Actually it's just a set of extensions I use (or will) and some feature I > would like it to provide. I plan to engage with the Emacs team to see how we > can work together to enhance the Guile hacking experience ! > > Thank you ! > Cheers ! > > Jérémy -- repositories: https://notabug.org/ZelphirKaltstahl
Re: Guile Hacker Handbook - Character sets
Hello, Le jeudi 18 février 2021 à 20:54 +0100, Jérémy Korwin-Zmijowski a écrit : > I happily managed to find some time to write a new chapter for the > Guile Hacker Handbook ! > > https://jeko.frama.io/en/char-sets.html > > It deals with char-sets, something new to me. The exercise was fun, I > liked how convenient it is to play with these data type. The use of unicode makes it tempting to think that each thing you can index in a string is a character. This will work most of the time, except in some cases with foreign languages. This remark is general, and applies in many situations, including the previous chapter about characters. I suggest reading: https://manishearth.github.io/blog/2017/01/14/stop-ascribing-meaning-to-unicode-code-points/ . Fortunately, there are very few international problems that need to look at individual characters of a string. Your password rules example is arguably one of them, although it may make non-latin users angry (this upper case / lower case distinction does not work in chinese, as far as I know). The other example that I'm aware of is limiting the size of a message so that the reader does not get bored (so, not for storage reasons). One website famously limits the number of unicode code points for a message, although it is in fact much more complex and opinionated than expected ( https://developer.twitter.com/en/docs/counting-characters). I think that the approach of demonstrating general code that works with latin except "special characters" is rude to the rest of the world and should not be put in such a strategic place as the Guile Hacker Handbook. For your example, I suggest switching to something that has more structure and is purposedly latin, for instance checking the validity of IBAN accounts, car license plates in an applicable country, maybe your grocery store's customer ID... You can also invent your own. The previous chapter about characters gives a good importance to letter intervals, which is even more difficult because the locale order would put 'é' after 'e' and before 'f', but the char>=? predicate would put it after everything. So, this does not even work for all latin. And if you use the locale order, then you won't even have meaningful character ranges anymore. Unicode is a very complex beast, with very few general use cases. Don't let that discourage you. Fortunately, most of everyday computing tasks can be solved without going down to the unicode character semantics. As a general idea, I would suggest to stay away from characters, and start with strings.
Re: Guile Hacker Handbook - Character sets
On Thu, Feb 18, 2021 at 6:17 PM divoplade wrote: > Fortunately, there are very few international problems that need to > look at individual characters of a string. Your password rules example > is arguably one of them, although it may make non-latin users angry > (this upper case / lower case distinction does not work in chinese, as > far as I know). The 2017 (U.S.) NIST password guidelines no longer limit what characters can appear in a password: in particular, spaces, Chinese characters, and emoji are fine. Here is the complete list of guidelines, which are binding on the U.S. government but recommended for everyone: 1) Passwords must be 8 characters or more but not more than 64 characters, and must be hashed and salted before being stored. Password length is the primary defense against password cracking. (Note that a password assigned by the system such as a PIN may have as few as 6 digits.) 2) All Unicode characters should be allowed unless they are forbidden by the underlying system. Runs of repeated or consecutive characters, however, are not allowed. 3) Pasting text should be allowed wherever possible, so as to encourage the use of password managers. 4) Password hints are not allowed. They weaken security. 5) Enforcing periodic password changes is not allowed. They decrease usability and encourage users to use the same or similar passwords, which causes the increased security to be negligible. 6) Enforcing password complexity requirements like the use of lower case, upper case, digits, etc. is not allowed. The security they add is negligible. 7) Passwords must be screened against a list of commonly used passwords, known compromised passwords, and dictionary words, as password cracking programs will usually try such passwords first. John Cowan http://vrici.lojban.org/~cowanco...@ccil.org Work hard / play hard, co...@ccil.org die young / rot quickly.
Re: Guile Hacker Handbook - Character sets
Hi Jérémy, Thank you for your book! How you’re describing char-sets using a clear use-case looks really good! A few comments: # Try and run the test here you write “the test fails”, which is slightly unprecise. The precise wording would be “the test will fail to run”. # Write the minimal … I wonder why the test-suite returns "passes 1" in the second try (with undefined password-valid?). Jérémy Korwin-Zmijowski writes: > The next chapter will probably introduce macros (syntax-rules) ! If you want to see the extend to which you can play with macros, you can have a look at my natural-script-writing entry-point (from enter-three-witches): https://hg.sr.ht/~arnebab/dryads-wake/browse/enter.w?rev=tip#L349 Thank you for your book! Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
