libera/#clim - IRC Chatlog
Search
13:49:25
scymtym
DEFINE-COMMAND is specified to define two functions. the first "is" the command while second is the argument parser. the specification says "The name of the other function defined by define-command is unspecified. It implements the code used by the command processor for parsing and returning the command's arguments.". does anybody see how client code could detect whether this second function is actually being defined or not?
13:50:14
scymtym
i'm asking because i'm considering turning a command into a single funcallable object
13:50:58
polygon-op
I think that it is stored in the command table, but I dont think that you can do that portably
13:51:41
polygon-op
I think that I' ve suggested something similar in the past - there is one prerequisite for that I think
13:52:52
polygon-op
regarding the prerequisite- mcclim currently doesn't work well with standard funcallable classes (it specialcases standard-class and presentation-class)
13:53:16
scymtym
i would say there has been a consensus to turn commands into funcallable objects, but i actually approached the issue from a different direction. i started by replacing the giant generated parser function by a parser protocol and parser state object
13:54:26
polygon-op
imlementing that is just a matter of adding special cases here and there to handle standard funcallable class just as the standard class is handled, still that code is not there as of now
13:55:29
scymtym
though, what gets presented mostly frequently are either command /names/ or command names and arguments, right?
13:55:30
polygon-op
being able to extract the parser from the command without knowing the command table would be useful
13:56:14
scymtym
not compiling and retaining in memory giant parser functions also seems desirable to me
13:57:06
polygon-op
I can imagine that some internal machinery does (accept 'whatever) and calls (presentation-type-of <object>) - the object may be a command
13:57:35
polygon-op
(and if that command is a standard funcallable instance you'll have a nasty error afair)
14:00:20
polygon-op
I'm not certain about failure scenarios - all I'm saying that I've encountered some issues (originating in the problem I've described) when I've beeing playing with commands as funcallables
14:03:42
scymtym
i can see that. but sounds like it's just some technical busywork and not a blocker
14:04:55
scymtym
but first i want to try and change the partial parser and unparser functions in a similar way
14:05:32
polygon-op
I agree, there doesn't seem to be anything tricky in adding that; just plenty of ifs (yuck) and specializations
14:19:07
scymtym
while you wait: this is the slightly improved heap usage visualization in the performance analyzer: https://techfak.de/~jmoringe/sbcl-garbage-retention-2.png
14:38:39
beach
Don't work too hard for this. I just thought you might have something already in your archives.
15:04:04
scymtym
https://techfak.de/~jmoringe/font-finder-1.ogv ; interesting in terms of McCLIM is the use of incremental redisplay in the large list panes. noteworthy behind the scenes are (partial) opentype and fontconfig implementations in CL, the former including an efficient interpreter for the compact type 2 encoding of glyph programs. from a practical perspective, this allows working with "otf" files while zpb-ttf only supports "ttf" files
15:08:55
scymtym
that said, it is very unlikely that the otf implementation will ever be complete. newer features are extremely complex
15:10:00
scymtym
things like https://docs.microsoft.com/en-us/typography/opentype/otspec190alpha/colr
15:15:00
polygon-op
ACTION waits for the font format that allows embedding javascript (like svg allows for vector graphics)
15:18:34
polygon-op
I wouldn't be surprised if they did that either; what I thought when I wrote that: "text is hard, but overengineering makes it much harder"
15:19:39
polygon-op
svg is a prime example of that: how sane is putting a javascript engine requirement in a vector graphics format? not very (imo)
15:25:58
scymtym
btw, the SVG comparison is accurate. the authors say "It is our understanding that this brings the capabilities of COLR/CPAL to nearly match those of SVG Native for vector graphics." on their repository: https://github.com/googlefonts/colr-gradients-spec
15:29:23
|3b|
ACTION has been running into limitations of zpb-ttf, but not enough to write a new parser yet :)
15:29:32
scymtym
|3b|: let me check. i think i kept the zpb-ttf license since i use (used?) some code from that library
15:31:34
scymtym
2-clause BSD it seems. but i could still change it since the code is not yet published
15:35:09
beach
As I recall, the new free music music font designed by Tantacrul uses the OTF format, so this work could become essential for Clovetree (= Gsharp v 2).
15:42:15
scymtym
on my system, the format distribution is around 2/3 ttf and 1/3 otf at the moment so support is becoming essential for "regular" (no pun intended) fonts as well
18:03:06
polygon-op
well, that's disappointing. after measuring the algorithm over-sweep-bands seems to be O(n³)