freenode/#lisp - IRC Chatlog
Search
7:12:00
verisimilitude
C is garbage though and it's unacceptable to have memory errors for doing trivial things just because they've been written in C first.
7:22:46
no-defun-allowed
What was that library that made pretty-looking ASCII equation printouts with the two dimensional fractions named?
7:23:35
verisimilitude
Are you referring to that Maxima or whatever it was called, no-defun-allowed?
7:24:39
no-defun-allowed
Not Maxima, no. There was a separate library that typeset equations into ASCII art.
7:29:10
aeth
verisimilitude: Unicode is the only solution for multilingual documents. As in, there's literally no other solution that has any kind of real support (well, at least for arbitrary multilingual documents... some languages coincidentally can work together). Sometimes you want one standard for interoperability, like IP. Having Unicode as the standard *helps* languages interoperate.
7:29:28
aeth
If there were 10 different ways to do things, 9 of them would only be available in C and Java and Python libraries.
7:32:33
verisimilitude
Being perfectly clear, I don't give a damn about the minor edge case of multilingual documents and even then I think Unicode handles it poorly with its approach.
7:33:12
verisimilitude
But, a real solution wouldn't have worked well with cat and UNIX and other stupid bullshit, so it wasn't used.
7:34:12
verisimilitude
Text is the universal interface, aeth. ASCII, I mean EBCDIC, I mean Shift-JIS, I mean UTF-16, I mean UTF-8 is the universal interface, aeth.
7:35:21
aeth
UTF-8 at the interface, UTF-32 internally in memory when working on a string like an array. Pretty close to universal.
7:36:57
aeth
It seems like you want a perfect way to handle text in an ideal world where you can create a system from complete scratch. That's not how you get a Lisp system that people use. You need ways to interface with the outside world's formats. Lisp machines even had C compilers!
7:40:26
aeth
Well, personally, I like that text is basically the one place that solved https://xkcd.com/927/
7:41:14
verisimilitude
I've been designing a program for a short while, a first step of sorts towards this goal, aeth. Anyway, the first target of this program was a machine that has no need to interface with the outside world and has no notion of text; when I was designing my metadata format for this, I could've very easily used ASCII for storing some things, but I didn't. Instead, I created my own character set just for this purpose; I much prefer it,
7:44:30
fiddlerwoaroof
aeth: the biggest problem with unicode, imo, is the inclusion of emoji and random little pictures
7:45:52
aeth
fiddlerwoaroof: Emoji is its Trojan horse. Don't support Unicode and you don't support Emoji so even monolingual Americans complain, even though what really matters is not supporting é and ə and ° etc.
7:46:06
aeth
Emoji is the hardest part so if you support that you probably support a good chunk of Unicode.
7:47:13
verisimilitude
But, yes, the inclusion of dead languages, emojis including piles of feces, and other superfluous things is just another reason to dislike Unicode.
7:48:43
fiddlerwoaroof
I, for one, am glad that there are code points for me, should I ever decide to learn Linear B
7:48:43
verisimilitude
I really care about the ability to mix English and Mayan in my filenames, yeah.
7:50:05
fiddlerwoaroof
the problem with specialized software is that it disappears and then your data is all locked away in a format no one can deal with anymore
7:50:33
aeth
The problem with specialized software is it's $1999 just because it's rare, not because it has any quality software engineering behind it
7:50:58
fiddlerwoaroof
I've actually worked with people who transcribe manuscripts, and this is a huge issue: they have transcriptions from the 80s that used some random piece of software they had and now they have to re-type 800 pages of manuscripts
7:52:38
verisimilitude
I have my own ideas about computing and I won't be compelled by those who insist their ideas are great, it's only the entire world needs to adopt it.
7:54:50
aeth
Except such documents at this point are probably only mostly ASCII because they might have a random é or ‽ thrown in.
7:55:02
verisimilitude
Remember kids: The best way to make a new standard is to make it backwards compatible with the most common standard and then boast about how many users you have.
7:56:10
aeth
The future trends of text storage are very clearly UTF-8 thanks to the Internet, though
7:58:05
aeth
As for ASCII being smaller, that just means it can only handle 99% of English user uses. Lots of edge cases. And the problem is that that 1% is different for everyone.
8:00:03
verisimilitude
Well, I submitted an article containing some of my thoughts on this earlier; feel free to read it if you want. I'm now busy with something else.
8:01:03
fiddlerwoaroof
aeth: of course we could always insist that non-English languages just use romanizations /s
8:02:16
aeth
(And multilingual documents are apparently too much of an edge case to have encodings, since the combinations would quickly become quite large.)
8:45:53
LdBeth
Thanks for his consideration, vanilla TeX can just handle many CJK encodings well while troff requires to link against iconv to just accept UTF-8
11:32:16
Josh_2
hmm so I have a question about a problem I don't know how to solve. I have an input from a 720p screen and I need to convert the input (which is a coord on the screen) to the same relative position on a 1080p screen or a 4k. This is CL related as I'm using CL for my program :)
11:46:24
Josh_2
beach: worked like a charm thanks :) now if only I didn't have a curved screen on my phone...
11:48:12
shka__
_death: it is a smartphone, not a standalone screen, plain old iron should be enough
13:49:29
flip214
looks like a colliding business appointment won't be colliding now (proposed for Thu/Fri instead of Mon/Tue), so I guess I'll be there as well!
16:34:12
makomo
what's the usual solution to "i would like to establish a binding within a COND clause"?
16:35:21
beach
I used it as an example when I taught "embedded languages" at the engineering school.
16:36:38
dlowe
another option that I use occasionally is (let (val) (cond ((setf val (get-val)) ...))
16:36:47
makomo
but sometimes you need to bind certain stuff before evaluating the condition, in order to avoid recomputing the condition within the clause's body
16:37:38
makomo
in this case i have 2 subexpressions within the condition that i want to save/cache and reuse within the clause's body
16:37:52
beach
trafaret1: The question is strange because you are in a channel dedicated to Common Lisp.
16:38:52
beach
https://common-lisp.net/project/bdb/qbook/mycl-util/api/macro_005FMYCL-UTIL_003A_003ACONDLET.html
16:40:14
makomo
beach: hmm, that's the reverse of what i'm looking for. the bindings are established only after the clause has been selected (i.e. *after* the condition has been evaluated)
16:46:18
makomo
ah also, i just realized, CONDLET's clauses don't have bodies of their own. there's one main body in which the established bindings (acccording to the predicates) are available
16:54:19
makomo
sjl_: now that i wrote out the usage i had in mind, i'm not sure whether it's more clear or not*
17:03:42
Duns_Scrotus
Hi, I am apparently failing to understand global variables. Can someone explain to me why this doesn't work? https://www.irccloud.com/pastebin/iBDphxFw/huh.lisp
17:06:37
Duns_Scrotus
ok, I am apparently failing to understand function bindings in the global environment
17:07:27
pjb
Duns_Scrotus: lisp has a notion of global variables. But it doesn't have a notion of "work" or "doesn't work".
17:22:38
pjb
(let ((x 42)) (flet ((f () x) (g () (declare (special x)) (if (boundp 'x) x :unbound))) (list (f) (g) (let ((x 33)) (declare (special x)) (list (f) (g)))))) #| --> (42 :unbound (42 33)) |#
17:47:14
Josh_2
Can I use CLX to determine the number of physical displays connected to my computer?
17:47:30
sukaeto
I figure it's because CL programmers are being pragmatic, and binding an existing lib is less work than reimplementing the whole thing
17:47:44
Josh_2
I can get the combined resolution of the created display but not the resolutions of each individual physical device
17:48:27
sukaeto
and I think binding to C libraries is common in non-scripting languages where the users know that their language is as efficient as C for the same reason
17:49:34
sukaeto
also, and this is just a dumb anecdote, recently I needed to build a RabbitMQ client in Lisp. I saw there's cl-rabbit (FFI) and cl-bunny (native).
17:49:54
sukaeto
I wanted to try the native one, I really did. But in the install docs I saw it required a third party library installed on the system.
17:50:14
sukaeto
and it had a note saying "the version packaged with Debian is broken and doesn't work with this library, don't use it."
17:52:37
sukaeto
(sorry if that's entirely unhelpful - it's the only thing I remember about doing this myself, and I'm not at home so I can't just look in my StumpWM configs to figure it out)
17:58:56
djeis[m]
Yea there are maybe... a half dozen cases where I consider it not unreasonable to pull in a CFFI lib. One is for tinkering with a particular native lib from somewhere you're comfy, another is for talking platform-level stuff that's only directly exposed as a C API (ie. OpenGL bindings).
18:05:06
sukaeto
beach: if you're suggesting that I should've instead spent the time "fixing" the problems with the native client, consider that I'm being paid to make a thing
18:05:31
sukaeto
as much as I like to improve existing Common Lisp libraries, I can only justify doing so so much
18:06:24
sukaeto
cl-rabbit worked out of the box. loke suggests that he's used it in production for some time and it's been reliable
18:06:32
djeis[m]
A third is for adding support for existing platforms to some more abstract API, ie. a lisp lib that has the option to use SDL in order to expand what platforms it supports but doesn't actually require it. But even then, there's a careful cost/benefit analysis that needs to go on there...
18:06:54
djeis[m]
sukaeto: If I were to guess, his point is just that relying on a native lib will always cause more trouble than it's worth.
18:07:06
sukaeto
downloading the source of libfixposix, or whatever it was, compiling and installing it is a complicated extra step that's honestly not worth it
18:07:34
sukaeto
it's more stuff to put in the docker file that the next person who comes along to maintain it will have to look at and deal with, one more thing that can break down the line
18:09:18
dlowe
the problem with posix is that it allows all kinds of things to be implemented with C macros
18:09:21
djeis[m]
dlowe: that argument hurts me inside, given how much time I spend having to support python code relying on native libs on windows machines...
18:11:17
dlowe
djeis[m]: I bet the windows API doesn't implement basic functions with C macros though :p
18:11:44
sukaeto
er, it was in the IOlib docs, not the cl-bunny docs: https://github.com/sionescu/iolib
18:12:10
sukaeto
"As of Debian 9.0 Stable, the libfixposix package uses code from 2011, which is incompatible with the current IOlib and will cause a SEGFAULT on load. Don't use it."
18:37:49
makomo
does anyone know how to print all of the fractional digits of a floating-point number? for example, https://plaster.tymoon.eu/view/1148#1148
18:38:29
makomo
i've used the IEEE-FLOATS package to confirm that indeed the implementation (SBCL, which should also be using IEEE 754 internally) doesn't lose any information upon the conversion of the rational to a float
18:56:55
verisimilitude
I'm only vaguely aware of what RabbitMQ is, but is there anything in it that can't be done with standard or even semi-standard Common Lisp?
19:01:20
sukaeto
verisimilitude: so, apparently cl-bunny makes no claims of being "native". I'm not sure where I've heard it referred to as such.
19:01:47
sukaeto
I'm guessing here that "native" is a shortcut for "implements the protocol in Lisp, rather than just binds to the C library implementing the protocol"
19:03:49
verisimilitude
I think it somewhat insults Common Lisp to use a C library; it's not Python, where the language is so poorly designed and implemented that you can't do things efficiently in it with a reasonable implementation. Also, they can be a bother to get working, effectively infinitely more bothersome than a real Common Lisp library that can LOAD without issue.
19:05:37
phoe
verisimilitude: unless you want to define a UI that works across multiple implementations and operating systems.
19:06:06
phoe
This one simply does not exist yet, unless you boot X servers on other operating systems to launch McCLIM.
19:07:51
verisimilitude
I don't like it, in any case, but it's certainly easier to argue for using GTK or Qt, since GUIs under UNIX are always going to be awful for no good reason.
19:08:30
djeis[m]
I agree, except for the hating on Python lol. Python was neither poorly designed nor poorly implemented, it intentionally chose representations and dispatch systems that can't be implemented in a highly performant manner in favor of other design choices. Also, there is a 3rd party McClim backend that uses SDL2, it's just really slow and kinda a mess.
19:08:47
verisimilitude
I'm still surprised that I'm apparently the first to try to write something comprehensive, instead of just using an Ncurses linking.
19:09:22
verisimilitude
I've seen I believe one library that didn't link to Ncurses, but it was unfinished and, in my view, rather poorly written.
19:10:34
verisimilitude
The first time I read about Python's one-line limit on lambdas, I thought it was a joke, djeis[m]. There's also no TCO for poor reasons. I've also read an entire article about how Python's halfway equivalent to UNWIND-PROTECT doesn't actually work.