proj-oot-ootLibrariesNotes14

https://github.com/millsp/ts-toolbelt rec. by https://news.ycombinator.com/item?id=23122438

---

rozab on May 4, 2020 [–]

Other great tools in the python terminal sphere are colorama, blessings and urwid.

Colorama is just for cross platform colouring, blessings is a very elegant wrapper over curses which is still useful for not-fullscreen things, and urwid is a full-blown widget library for TUI stuff.

jquast on May 5, 2020 [–]

please also consider blessed, an API-compatible fork of blessings that adds Windows 10 support, 24-bit color, keyboard input, and more. https://blessed.readthedocs.io/en/latest/intro.html#brief-ov...

jnwatson on May 5, 2020 [–]

Don’t forget prompt-toolkit. Notably it is a dependency of the truly excellent IPython shell.

also rich

---

things to look at for dates:

https://js-joda.github.io/js-joda/

commentary from moment.js, which is popular:

https://momentjs.com/docs/#/-project-status/recommendations/

https://www.npmtrends.com/date-fns-vs-dayjs-vs-js-joda-vs-luxon https://www.npmtrends.com/date-fns-vs-js-joda-vs-luxon-vs-moment

https://medium.com/swlh/best-moment-js-alternatives-5dfa6861a1eb

https://www.skypack.dev/blog/2021/02/the-best-javascript-date-libraries/

https://blog.logrocket.com/more-alternatives-to-moment-js/

https://news.ycombinator.com/item?id=27661667 https://2ality.com/2021/06/temporal-api.html

usually i would say just go thru these and take the simplified/sorta-intersection but here my lack of experience with date issuses makes me reluctant. Still, that's probably the best option, because we need to end up with something small.

one thing that ppl mention about some newer ones (eg temporal) and dislike about some older ones (eg moment) is immutability.

---

hyc_symas on April 14, 2020 [–]

The standard string library is still pretty bad. This would have been a much better addition for safe strcpy.

Safe strcpy

    char *stecpy(char *d, const char *s, const char *e)
    {
     while (d < e && *s)
      *d++ = *s++;
     if (d < e)
      *d = '\0';
     return d;
    }
    main() {
      char buf[64];
      char *ptr, *end = buf+sizeof(buf) ;
      ptr = stecpy(buf, "hello", end);
      ptr = stecpy(ptr, " world", end);
    }

Existing solutions are still error-prone, requiring continual recalculation of buffer len after each use in a long sequence, when the only thing that matters is where the buffer ends, which is effectively a constant across multiple calls.

What are the chances of getting something like this added to the standard library?

pascal_cuoq on April 14, 2020 [–]

For what it's worth, I personally like this approach, because there are some cases in which it requires less arithmetic in order to be used correctly. And it lends itself better to some forms of static analysis, for similar reasons, in the following sense:

There is the problem of detecting that the function overflows despite being a “safe” function. And there is the problem of precisely predicting what happens after the call, because there might be an undefined behavior in that part of the execution. When writing to, say, a member of a struct, you pass the address of the next member and the analyzer can safely assume that that member and the following ones are not modified. With a function that receives a length, the analyzer has to detect that if the pointer passed points 5 bytes before the end of the destination, the accompanying size it 5, if the pointer points 4 bytes before the end the accompanying size is 4, etc.

This is a much more difficult problem, and as soon as the analyzer fails to capture this information, it appears that the safe function a) might not be called safely and b) might overwrite the following members of the struct.

a) is a false positive, and b) generally implies tons of false positives in the remainder of the analysis.

(In this discussion I assume that you want to allow a call to a memory function to access several members of a struct. You can also choose to forbid this, but then you run into a different problem, which is that C programs do this on purpose more often than you'd think.)

msebor on April 14, 2020 [–]

There are many improved versions of string APIs out there, too many in fact to choose from, and most suffer from one flaw or another, depending on one's point of view. Most of my recent proposals to incorporate some that do solve some of the most glaring problems and that have been widely available for a decade or more and are even parts of other standards (POSIX) have been rejected by the committee. I think only memccpy and strdup and strdndup were added for C2X. (See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2349.htm for an overview.)

AceJohnny?