libera/#commonlisp - IRC Chatlog
Search
8:22:43
loke_
jackdaniel: I'm trying to get climaxima back up with the latest version of mcclim and maxima, and I suffered a regression at McCLIM commit: d04aef1a194ea2129e07d829b656d40d80f505a5
8:23:23
loke_
I need to understand what the change does in order to figure out how to solve the issue.
9:10:31
loke[m]
jackdaniel: sorry, no. I've been busy with a million things for the last several months.
9:16:10
loke[m]
jackdaniel: It does ring a bell. It may have passed by my screen, but I didn't pay much attention. Sorry.
9:37:13
loke[m]
I did not know it was broken. When I used it, it worked fine. But I may have used it backwards. :-)
9:44:10
jackdaniel
well, I'm not sure whether it is broken, so I've asked for clarification! https://irclog.tymoon.eu/libera/%23clim?around=1679253495#1679253495
9:44:26
jackdaniel
I've started using the computer now, so I'll see to the commit you've asked about. perhaps we should move to #clim
9:56:07
jackdaniel
yes, and note that the second argument is NIL, so it is computing the line that goes from left to right
9:58:28
loke[m]
I'm testing with this: `(mcclim-bidi:directions "This is a test. في هذا اليوم. Another string." nil)`
12:33:36
loke[m]
jackdaniel: You're definitely right. You can just `NREVERSE` the list `RESULT` at the end of `DIRECTIONS`
12:35:44
loke[m]
There are a set of functions which accept and returns lists of symbols, where the list is always the same size as the string. We can gain a lot of speed by changing it to an array and modifying it in place.
13:22:02
jackdaniel
because there are a few moving parts: there is a page direction, a line direction and finally the text direction that may vary within the line
13:22:38
jackdaniel
page and line direction are the compositor things while the individual fragment of text direction should be handled by the renderer
15:04:49
jcowan
It shows images of Arabic text in a Mongolian matrix where the Arabic text has been rotated either counter-clockwise (read down, like the Mongolian) or clockwise (read up).
15:10:52
jcowan
There is also a neat example of English text reading upwards at the left edge of a table, but with embedded Chinese that is read downwards (in the normal direction for Chinese), thus requiring the bidi algorithm even though both English and Chinese are LTR when horizontal.
15:25:13
gendl__
(this format statement is from cl-pdf by the way, I'm setting up regression pipeline testing which includes some PDF output and trying to get the same input to yield identical output on all three of these impls)
15:26:18
gendl__
it seems CCL is prepending an extra space of padding - it feels like internally it's treating the -0.0 as 0.0 and not counting the `-` as a character.
15:27:56
gendl__
As far as I understand, the Allegro CL output is compliant - implementations are allowed for format `-0.0` as `0.0` -- Allegro does this, and prepends 5 spaces as does CCL, but in the case of Allegro the 5 spaces prepended appears correct because the `-` is not there.
15:28:54
semz
~8f is explicitly supposed to always output 8 characters, so CCL is definitely wrong here
15:31:34
gendl__
Are there any printer parameters or format directives to make it always include, or always suppress, the `-` ?
15:31:42
semz
(well, always*, since it can output more if it's impossible to fit the value in there. but this isn't the case here)
15:35:51
gendl__
In order to get my regression tests working with currently existing CCL (and with Allegro CL and SBCL, which both appear compliant but are giving different outputs) I think I will have to pre-process my test data to replace the `" -0.0"` or `" -0.0"` or `" 0.0"` with a normalized string e.g. `" 0.0"` (i.e. normalize on the Allegro version). So I'll need a regular expression which matches those three strings
15:35:51
gendl__
but is unlikely to match other strings in my output. ChatGPT suggests `^\s*[-0\.]+0$`
15:36:47
gendl__
i'll test that, but at first glance it looks like it will miss `" 0.0"` (maybe that doesnt' matter because i'm normalizing to that anyway)
15:48:32
gendl__
semz: thanks, ah, I see it will print either `-` or `+`. Good to know. In this case, the format code in question is in the cl-pdf library, so I don't have direct control over that nor would I ask the cl-pdf maintainers to change anything just for this reason. But the regexp provided by chatGPT does match all 3 variants, so i'll just run the seed data and my test output through a replace-regexp, before comparing.
15:50:08
gendl__
and the issue appears to be captured already in this CCL issue: https://github.com/Clozure/ccl/issues/406. CK-DE provided a long test case for formatting floats with ~f. SBCL and Lispworks appear compliant. I'll comment on that issue with Allegro output for the given test suite.
15:53:48
jackdaniel
regarding clockwise/counter-clockwise render I'm aware of that, that basically comes with the fact that vertical page may go left-to-right (lines), or right-to-left
15:54:37
jcowan
Mongolian however always goes left to right, and still Arabic can be embedded in it either way.
15:57:04
jcowan
My answer to https://www.quora.com/Why-are-some-language-scripts-like-Mongolian-written-vertically-instead-of-horizontally may provide some historical insight into the issue