freenode/#clim - IRC Chatlog
Search
4:00:04
loke
Nothing much. Been thinking about how to deal with output records recordingtrnasformations
4:00:26
loke
I managed to do it, but it was so ugly that I didn't even want to commit it as a work-in-progress (I don't want any record of me actually writing that code)
4:01:26
loke
Note how I use a dynamic variable to pass the override transformation to be used by the text rendering
4:02:23
loke
What I really need is to ament the MEDIUM-DRAW-TEST function to accept a transformation
4:25:42
loke
at first I thought that transformation should belong there too, but no... that wouldn't work.
4:26:03
loke
I can't think of any solution other than changing the interface of MEDIUM-DRAW-TEXT to accept a transformation
4:26:44
beach
We should consider changes like that. It is not as though we have to support some legacy software that does arbitrary stuff.
4:27:12
beach
I mean "consider", i.e. we should think about it and not be tied too much to the specification.
4:37:45
loke
Someone, at some point, implemented proper transformations for the postscript engine, but it was rolled back because the “spec”
4:38:54
loke
https://github.com/lokedhs/McCLIM/blob/freetype2/Backends/PostScript/graphics.lisp#L562
4:45:47
loke
My opinion is that the spec is incomplete. Broken, if you want to be blunt, in this case.
4:46:21
loke
...which is why I intedn to extend the specification of MEDIUM-DRAW-TEXT to take a transformation into account.
4:46:40
loke
I guess at the time when this code was written, only postscript had the ability to transform text.
4:49:18
loke
beach: Is there a difference between (SHEET-NATIVE-TRANSFORMATION (MEDIUM-SHEET <medium>)) and (MEDIUM-TRANSFORMATION <medium>) ?
4:50:21
loke
beach: What are those differences? So far, I only ever paid any attention to the latter.
4:51:22
beach
The latter is used to transform from coordinates given to (draw-...) to sheet coordinates.
4:52:01
loke
beach: Yes. That' smy understanind (and making that assumption makes my text drawing work :-) )
5:01:03
beach
The native transformation transforms between the sheet coordinate system and the coordinate system of the (not necessarily direct) mirror of the sheet.
7:20:26
loke
It was remarkably easy to make the change to MEDIUM-DRAW-TEXT, once I figured out what to do.
7:31:40
jackdaniel
the first time I've got interrupted by a phone, the second time I've confused myself with some code passage and spent >15m on that
8:06:50
hjek
Hi, I still have the problem of McCLIM taking quite a while to load (on a reasonably new laptop). In this nice video tutorial, https://www.youtube.com/watch?v=kfBmRsPRdGg , the clim-listener loads in a matter of seconds, but when I load it, it takes exactly 5 minutes. I am getting McCLIM from Quicklisp, and I have no additional operating system repository common lisp packages installed that could possibly interfere.
8:07:42
hjek
Are there any caching tricks or tweaks that are good for speeding up Quicklisp loading?
8:09:25
hjek
@loke: when I was on Debian, previously, and loaded McCLIM via ASDF from the debian repos, then it would display compilation messages too.
8:10:20
hjek
@loke: only happens with McCLIM of what I've seen so far. But I've not used too many CL packages yet
8:10:40
jackdaniel
loke: McCLIM is probably the biggest library in Quicklisp with a lot of dependencies
8:11:17
loke
Stull, 5 minutes? It can't take more than 45 seconds for me to load all of mcclim on my old computer.
8:11:47
hjek
What configuration do you use to cache things? Should it work automagically or do I need to set stuff?
8:14:07
hjek
like, ./asdf-output-translations/home/pelle/quicklisp/dists/quicklisp/software/mccli -20180328-git/Core/clim-basic/encapsulate.o
8:15:42
jackdaniel
it will be either this slow, or you can use sbcl or ccl (they load McCLIM much faster)
8:16:29
jackdaniel
hjek: it is a bug in ASDF, not in QL (or even a bug in our mcclim.asd system definition)
8:18:38
hjek
Ok, but ASDF is likely the issue? So it might make sense to look at ASDF cache options? (Right now using SBCL is not really an option for me, as the packages provided on sbcl.org don't work here, because of musl... etc etc)
8:20:18
jackdaniel
this is not a configuration bug. It is either a problem in mcclim.asd definition (what causes recompilation), or ASDF internals which doesn't recognize, that system is already compiled and cached
8:20:53
jackdaniel
if the problem is with mcclim.asd (or any other *.asd in mcclim) fix should be considerably easy
8:21:11
jackdaniel
if that are asdf internals, then I wouldn't bether if I were you if you are not familiar with asdf internals
8:23:55
jackdaniel
it is easy, but it doesn't work with mcclim (another known issue which i didn't investigte yet0
8:35:14
hjek
ok, another question: How is the Windows support in McCLIM? Is it kinda alright or just a no-go?
11:29:57
jackdaniel
nb: since we introduce new behavior, we should provide demo in clim-demo/drawing-demos
11:31:05
jackdaniel
also, since we change draw-text, we will break *every* application which uses it
11:36:55
jackdaniel
TMA: this was more stylistic question, I know how #+ works – like: do we need another mysterious disabled code?
11:37:19
jackdaniel
because that's how I see all these #+xxx #+nil #+disable-this #+broken things – no explanations, just a dead code
12:44:49
loke
jackdaniel: That's something that is no longer needed, but I wanted to keep it there while testing. I never intended to commit it.
12:45:13
loke
I named it like that in order to not forget to remove before commit. Seems it didn't work :-)
12:57:22
drunk_foxx[m]
ACTION sent a long message: drunk_foxx[m]_2018-04-27_12:57:22.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/UucUpmSMszEiqpNFDBgtuNgT>
13:02:29
loke
jackdaniel: I just realised there is more work for me. The RENDER-MEDIUM needs freetype support too
13:06:14
drunk_foxx[m]
ACTION sent a long message: drunk_foxx[m]_2018-04-27_13:06:14.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/TxzMHmmgsTJeMapixzIZRTnk>
13:08:04
jackdaniel
fact that uiop is bundled with the implementation makes it a no-go (because it's not downloaded from ql, you have to clone it yourself)
13:08:32
jackdaniel
if ASDF had it's own asdf-uiop system, and ql shipped uiop, then there would be no problem
13:08:52
jackdaniel
but right now asdf always may find uiop, so there is no need to query external resources (and in effect uiop is never upgraded)
13:16:08
jackdaniel
as first part of the video (still wip) I've made a recap of the previous one: https://www.youtube.com/watch?v=GUUpyG_6aIw&feature=youtu.be should I include it?
13:18:02
jackdaniel
drunk_foxx[m]: this is the right way. but clim-listener won't work on the version currently published on quicklisp and sbcl <= 1.4.0
13:21:21
jackdaniel
any comments on this 12m video? (you may see a mindmap on the screen – it shows other parts which will be discussed)
13:22:30
jackdaniel
nothing new in light of the previous screencast, but I thought that adding such recap might be useful
13:28:40
loke
the output record bounds (x,y,width,height,etc) should reflect the _translated_ coordinates, right?
13:28:54
jackdaniel
I think I've read in the specification, that output records can, but doesn't have to record the transformation (so basically it is an undefined behavior, when you try to reply record in different transformation context than the one on which it was originally displayed)
13:29:25
loke
OK. Because DRAW-RECTANGLE does it... But DRAW-STRING seems to have never worked right.
13:29:56
jackdaniel
so that means, that both strategies are valid: recording transformation and applying it on reply, or applying transformation and then recording transformed output