Search
Sunday, 8th of July 2018, 4:18:25 UTC
9:07:08
loke
I'm confused. If I install more than one presentation-to-command translators, one of them (the first?) gets invoked whenevr I click on a presentation.
9:07:26
loke
If I right-click, I get a menu displaying all of the translators available.
9:07:43
loke
Is there a way for me to _not_ invoke one of them on left-click?
9:10:06
beach
I wish I could help, but I don't know the answer.
9:16:39
Inline
loke: can you select the one you want to invoke with a right click and does it get executed that way ?
9:17:19
Inline
or is the menu read-only like
9:18:21
loke
I want the menu, but I don't want any of them to be invoked when left-clicking (as that is supposed to be a different operation which I'm trying to capture using with-input-context
9:33:09
loke
Previous code was something like this:
9:34:17
loke
(clim:with-input-context (`(or (clim:command :command-table ,command-table) maxima-native-expr)) (...) (maxima-native-expr THIS-NEVER-GETS-CALLED))
9:35:08
loke
(clim:with-input-context (`(clim:command :command-table ,command-table)) (...) (clim:with-input-context ('maxima-native-expr) (...) (maxima-native-expr THIS-WORKS))
9:38:00
loke
In other words, if an input context supports more than one type, then the command type gets priority (I tried changing the order in the (OR ...) form, and no difference.
9:38:15
loke
I solved it by creating two recursive input contexs
9:38:25
loke
Oh, and the inner one needs :OVERRIDE NIL
9:43:12
loke
https://github.com/lokedhs/maxima-client/blob/master/src/cmdline.lisp#L273
9:43:28
loke
I'm starting to understand this stuff now. It's somewhat complicated though.
10:11:27
Inline
loke did you change your branch name from freetype2 to freetype ?
10:13:15
Inline
you have an mcclim-font::blah in your src/renderer-util.lisp
10:13:24
Inline
instead of mcclim-fonts::blah
10:23:11
Inline
so where is find-replacement-text-styles supposed to be ?
10:25:38
loke
Inline: It's been merged into mainline
10:26:08
loke
But, right not the maxima stuff needs a different branch that I'm working on:
10:26:45
loke
Inline: check out the "replace-font" branch
10:27:06
loke
https://github.com/lokedhs/McCLIM/tree/replace-font
10:27:26
loke
I'm hoping this will get merged into mainline
10:31:41
loke
Shortly I'll submit a fix that allows you to diplay any character in DREI panes
10:31:59
loke
I was just able to properly paste to chinese into DREI, and it displayed properly :-)
10:32:16
loke
I will not attack right-to-left eiditing in drei though.
10:32:25
loke
So arabic will still look wrong
10:32:37
loke
It displays correctly when outputting normally though
10:39:32
loke
Inline: You can try i tnow. I just pushed
10:44:50
Inline
add :mcclim-fonts to drei-mcclim.asd in :depends-on
10:45:21
Inline
it's a system which it depends on
10:45:34
Inline
otherwise the package mcclim-font won't be found....
10:46:03
Inline
i did it locally here and now it loads
10:46:19
Inline
otherwise it stops and complains on loading my repl
11:02:01
loke
it seems it's still confused when pasting a character with a different width
11:02:12
loke
Perhaps overriding just text-size wasn't enough
11:04:08
loke
Please experiment, and let me know how things work
11:07:36
Inline
ok, got another issue not
11:07:39
Inline
ok, got another issue now
11:07:51
Inline
cl-freetype::blah is not found either
11:07:56
Inline
in maxima-client this time
11:13:14
Inline
arright i also had to delete some symbols from the harfbuzz package like hb-script:newa etc...
13:35:30
loke
Inline: That's probably because you have too old versions of freetype/harfbuzz
13:36:20
loke
Inline: If you could #+whatever around the symbols from harfbuzz that fails, I'd be appreciatelive
13:37:43
Inline
yah, but i already installed harfbuzz-1.7.6
13:37:56
loke
I also only have new versions available :-)
13:47:48
Inline
yah but loke newer versions maybe not considered stable, if they are not to be found on the stable packages list.....
13:48:26
loke
I've been trying it on Arch, Fedora-28 and Ubuntu. I don't have any missing symbols on any of them
13:48:46
Inline
i tried it on both mint and trisquel
13:48:57
Inline
and each time i get problems with the groveler
13:49:07
loke
Ubuntu comes with harfbuzz 1.7.2
13:49:25
Inline
so the problem is elsewhere ?
13:49:27
loke
You need to install the devel libraries for harfbuzz freetype and fontconfig
13:50:52
loke
I just pushed a fix that makes DREI work properly with font replacement
13:51:00
loke
Inline: WHat erorr are you gettinbg?
13:51:21
Inline
some scripts are defined for which the library lacks the symbols or so....
13:51:28
Inline
it errors on the groveler stage
13:51:50
Inline
i edited your groveler.lisp to get rid of some of the scripts
13:52:00
loke
You can comment out the entire section that defines symbols for the different languages
13:52:08
Inline
and then the compilation proceeds but i get thrown into the debugger anyway
13:52:20
loke
Inline: Can you give me a stack trace?
13:52:47
Inline
wait a little, it seems to proceed normally now
13:53:19
Inline
it's too late for a stacktrace, as i purged some of the symbols and retried starting my repl, i even got into ldb
13:54:02
Inline
so i repulled the groveler.lisp
13:54:08
Inline
and it seems to proceed ok now
13:54:33
Inline
as i also put the "/usr/local/lib/" onto the asdf registry
13:54:55
Inline
maybe it gives preference to the newer harfbuzz libs that way
13:55:27
Inline
anyway i'll see if it really gets ok to the end of starting my repl now
13:56:52
Inline
cause my installation of harfbuzz put the libs there and before it was maybe linking against the old libs
13:57:04
Inline
i think that might have been it
13:57:25
Inline
i also changed my ld.so.conf
13:57:52
Inline
from include ld.so.conf.d/*.conf to include ld.so.conf.d/libc.conf include ld.so.conf.d/*.conf
13:58:13
Inline
giving preference to /usr/local/lib first, not sure if that was the case anyway
13:58:27
Inline
hmm, i get thrown into debugger now again
13:58:47
Inline
error is: The alien function "hb_ft_font_set_load_flags" is undefined.
13:59:38
Inline
before starting my repl, but after having compiled harfbuzz etc all allready
14:01:56
loke
Inline: Did you ever get a version of this stuff working?
14:02:29
loke
Anyway, here's the current state: https://photos.app.goo.gl/b9WFHeV6u9NcFwxq9
14:02:42
Inline
yes, once where i removed that reference to that function before compiling and installing harfbuzz from sources
14:03:00
Inline
i'm cloning harfbuzz via git now
14:03:06
Inline
i'll try the git version
14:03:15
Inline
maybe it's better suited
14:03:33
loke
Inline: Can you check with "ldd" if your harfbuzz actually has that function?
14:03:40
loke
(it's supposed to, it's quite fundamental)
14:04:14
loke
also use "pldd" to check your sbcl process which harfbuzz you're using./
14:08:34
Inline
that symbol does not exist
14:08:50
Inline
i only have hb_ft_font_set_funcs
14:09:17
loke
Inline: Have you confirmed what harfbuzz you're using?
14:09:24
Inline
and all is rather to be found in the .a file, the .so 's seem to lack any symbols
14:09:48
loke
Inline: Ah, no. That's a linuxism
14:10:49
Inline
i just restarted it, i'll have to wait, and then check with pldd
14:12:02
loke
If pld fails, just use cat /proc/PID/maos | grep harfbuzz
14:12:47
loke
And for nm, use "nm -D libname.so"
14:13:11
loke
-D gives you the dynamic symbols
14:17:51
Inline
yah, it's using the old system provided libs
14:18:14
Inline
i already installed a newer version of harfbuzz in /usr/local/lib
14:18:41
Inline
pldd failed, as sbcl got into a sleeping phase on throwing me into the debugger
14:18:52
Inline
as cat /proc/pid/status reveals
14:19:07
Inline
but the maps tell me it's using the old version
14:19:17
Inline
so how can i override that ?
14:20:39
Inline
and the symbol is findable in the newer version
14:20:42
loke
Inline: the search order is specified in ld.so.conf
14:21:07
Inline
yes but ld.so.conf already has as first entry libc.so which just has 1 entry
14:21:22
loke
Inline: Then I don't know.
14:21:31
loke
I haven't seen this issue with any other linux I tried with.
14:21:50
Inline
wait a little i'll just purge all of .cache/common-lisp
14:22:38
loke
It's possible it always picks up /usr/lib first.
14:22:49
loke
How old version of harfbuzz does your system come with, really?
14:25:10
Inline
no, as i saw it compile the libs, before getting to the grovel stage, it consults pkgconfig
14:25:35
Inline
and guess which one will pkgconfig tell ?
14:25:52
loke
Inline: WHich version of harfbuzz does you system come with?
14:27:21
Inline
hmmm, nvm, pkgconfig reports ok via --cflags and --libs
14:27:29
Inline
-L/usr/local/lib -lharfbuzz
14:27:35
loke
Inline: CFFI doesn't use pkgconfig, I don't think
14:27:37
Inline
-I/usr/local/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
14:27:47
loke
Now... for the 100'th time: What version of harfbuzz does your system come with?
14:28:36
Inline
Version: 1.0.1-1ubuntu0.1
14:28:45
loke
Oh wow... That's positively ancient
14:28:58
loke
Are you sure you shouldn't just upgrade your distro?
14:29:20
Inline
there's nothing left to upgrade
14:29:38
Inline
i even added the backports repo now
14:29:44
Inline
and still there's nothing to be done
14:30:01
Inline
but the problem was the same on mint
14:30:11
Inline
i suppose i'd have to change to the testing versions or so
14:30:44
Inline
and everytime i do such things, i shoot myself in the knee
14:31:51
loke
Yes. Just checked here: http://archive.trisquel.info/trisquel/dists/flidas/main/source/
14:32:02
loke
The latest release version really does come with an outdated harfbuzz
14:32:09
loke
What kind of crap distro is that?
14:32:56
Inline
ya i think i should change back to slack or so.....
14:34:00
Inline
with all the occasional corruption....
14:34:14
loke
I'm looking at the trsiquel web site. I see no explanation as to why it exists. :-)
14:34:40
loke
Maybe the FAQ has something to say
14:35:42
loke
Oh... it's a "freedom or death" distro
14:35:57
loke
If that's what you want, you're probably better off with debian
14:36:14
Inline
i even saw it use the correct pkg-config --cflags
14:36:24
Inline
but it threw me into debugger again
14:36:26
loke
Anyway, at least we now know what the problem is.
14:36:38
loke
Inline: I don't think CFFI uses pkg-config to find the libs
14:36:55
Inline
but somewhere on loading it i saw pkg-config mentioned
14:39:55
Inline
grovel.lisp uses pkg-config
14:40:25
loke
Ah. So it uses the new version when compiling the grovel files, but probably loads the old library when you run the code.
14:40:31
loke
That's why compiling works.
14:41:21
loke
try setting CFFI:*FOREIGN-LIBRARY-DIRECTORIES* before loading
14:41:38
loke
set it to (list #p"/usr/local/lib/")
14:54:06
Inline
it uses (include "hb-ft") in grovel.lisp
14:54:16
Inline
and maybe that one refers to the /usr/include path
14:54:25
Inline
not sure what's wrong really
14:54:39
Inline
and both attempts failed
14:55:32
Inline
i'll put it just before i (ql:quickload :maxima-client)
14:55:41
Inline
and cleanse .cache first
14:57:31
loke
Inline: the include stuff is used by the griveller. Not when running.
14:59:07
Inline
are globals not visible from closures ?
14:59:21
Inline
cause i start it from within a closure
14:59:33
Inline
but i suppose they are not visible from within threads right ?
15:23:47
Inline
ok putting that stuff globally doesn't work
15:27:18
Inline
i put it in harbuzz.lisp
15:27:42
loke
By it, I believe you meant the load-path?
15:28:53
Inline
it defines the foreign-library harfbuzz
15:29:02
Inline
(cffi:define-foreign-library libharfbuzz
15:29:02
Inline
(:darwin "libharfbuzz.dylib")
15:29:02
Inline
(:unix "libharfbuzz.so"))
15:29:14
Inline
(setq cffi:*foreign-library-directories* (list #p"/usr/local/lib/"))
15:29:14
Inline
(cffi:use-foreign-library libharfbuzz)
15:29:46
Inline
only changing :unix "/usr/local/lib/libharfbuzz.so" works
15:30:24
Inline
i previously used that, and discovered the other stuff is not responsible for the success
15:31:26
Inline
one last attempt by putting it before the cffi:define-foreign-library
15:31:38
Inline
maybe that changes the order again
15:33:07
Inline
now i removed all but the change in the :unix line
15:35:08
Inline
what if you don't define the library ?
15:36:42
Inline
ok i now commented all the library defining form
15:37:05
Inline
and put the cffi:*foreing-library-directories* form just after it
15:37:16
Inline
not sure which it will find now
15:38:53
Inline
so it seems cffi doesn't obey the usual unix/linux search order
15:40:02
Inline
it all works with changing :unix "/usr/local/lib/libharfbuzz.so"
15:40:35
Inline
otherwise i'm not sure why *foreing-library-directores* has no influence whatsoever
15:41:32
Inline
anyway, this way i can be sure which lib will be used
15:42:03
Inline
independent of the system provided ones
16:08:24
Inline
ok i made yours run as a separate process
16:10:52
Inline
http://dpaste.com/1Y1JG1F
16:11:38
Inline
and i don't need the clim:disown-frame fm frame form cause it's not a child sheet
16:12:26
Inline
otherwise it complains on :quit itself
16:13:40
Inline
and your initialize-runtime-globals seems to fail too somehow
16:14:50
Inline
but it maybe that's my failure, some hard-coded path in my init file maybe
Sunday, 8th of July 2018, 16:18:25 UTC