Closed cage2 closed 4 years ago
Hello, I've not used the groveler before. How portable or reliable is it? Have you had experience with it in other projects?
It seems to cause a few problems for cl-charms: https://common-lisp.net/project/cl-test-grid/library/cl-charms.html
I'm reluctant introducing external dependencies on libraries and files other than Lisp because that is something I can not reproducibly test.
On Fri, Apr 10, 2020 at 12:48:03PM -0700, McParen wrote:
Hello,
Hi McParen!
I've not used the groveler before. How portable or reliable is it? Have you had experience with it in other projects?
This is the first time i actually used, but i am confident that it is a valid instrument as is part of CFFI and used in a lot of CL projects: just on my computer i have
That depends on it.
There is also iolib that uses this features.
And i think there ore many others.
It seems to cause a few problems for cl-charms: https://common-lisp.net/project/cl-test-grid/library/cl-charms.html I'm reluctant introducing external dependencies on libraries and files other than Lisp because that is something I can not reproducibly test.
I understand your concerns, my best guess is that there are problems on ARM with that package, usually this is because on missing header file, in our case we are just including "locale.h", a standard POSIX header, and defining some constants (even if some of said constants are GNU extensions and may be removed). In my opinion this should not results in any problems; in fact I tried to load croatoan on ARM (a raspberry pi 3) and i was able to play snake via ssh :)
In conclusion: the advantages (portability of the code) are more than the disadvantages (another dependency with, potential, slightly more difficult to track bug).
So, my opinion is: yes we can use cffi-groveler and sleep with no worries! :D
Bye! C.
Hello, sorry, but after checking how some other people do it, I do not think that introducing such a big dependency (a C compiler is needed, proper header files need to be installed, who knows if that works on Windows or Macs) is worth the benefits. Essentially we only need one single constant, LC_ALL. I think hardcoding is preferable until it causes enough problems to make groveling the lesser of two evils.
On Sat, Apr 11, 2020 at 03:37:01AM -0700, McParen wrote:
Hi!
I think hardcoding is preferable until it causes enough problems to make groveling the lesser of two evils.
I guess it will, because i do not think anyone could be sure that LC_ALL values 6 across differents POSIX/libc implementation, or even the same implementation in future or in the past, the code will be not portable.
Of course this is not true if the standard specify the value of the variable.
Bye! C.
Hi!
I have thought that would be a good idea to use cffi-groveller intead of hardcoded valies for all "LC_*" POSIX constants as the latter ~metod~ method could be not portable across different operating systems.
Also i have downcased constant names as some implementation (allegro if I remember correctly) are able to discriminate string case.
Bye! C.