Search
Monday, 21st of May 2018, 6:36:39 UTC
8:19:01
loke
oleo: What tests are failing?
8:19:01
Colleen
loke: oleo said 11 hours, 12 minutes ago: tell me how far you got with the mcclim-freetype2 backend, i obviously get many errors and am also in the process of checking the old mcclim sources of it to see what has changed since then, i'm not sure i could see errors right away especially if they are ffi/cffi specific, old code also seems to have had a different facility like alien or so for a more generic ffi than just cffi i think
8:19:21
loke
oleo: I've used my branch exclusively for a while now and for the most part it works very well.
8:23:12
oleo
loke: i get an error with http://dpaste.com/22F1R3C as http://dpaste.com/1QRCND6
8:24:02
oleo
loke: i'm dumping an image, and so far the image gets dumped but when trying to start the image i get that error there, and additionally cl-freetype2 fails it's tests too
8:24:04
loke
oleo: Did you use SAVE-LISP-AND-DIE?
8:24:23
loke
You have to dump _before_ starting any CLIM code.
8:24:38
loke
Once you inisialise CLIM, it'll load the libs and create references to the native librarie4s.
8:24:48
loke
SBCL can't dump binaries with loaded libraries.
8:24:54
oleo
the extra store for C, which is outside of lisp store
8:25:10
oleo
that's the issue not ?
8:25:19
loke
Well, it's because a native pointer into a library is not valid after a dump is loaded.
8:25:44
loke
In theory you can detect this and reload the library after loading a dump, but it's a huge ahassle.
8:25:46
oleo
arright, then i have to move my code a litte bit around
8:26:12
loke
It's similar to the case where you can't dump after you've created threads.
8:26:20
loke
threads are similar to libraries, they can't be dumped.
8:27:15
loke
You have to make it so that you dump before the first call to CLIM:FIND-PORT
8:27:53
oleo
i have clim-listener:run-listener :new-process t
8:28:00
oleo
isn't that a thread too ?
8:30:34
loke
looking at its code, it seems as though that one creates a process... But is that process still running by the time you dump?
8:30:56
loke
The SBCL restriction is that you can only have a single thread live when you dump.
8:34:17
oleo
no, it's not running at dump time, it's running after dump
8:37:01
oleo
ok, now i'm starting all without dumping and i got another error
8:37:12
loke
So what are you doing prior to dump? Do you call _any_ CLIM functions?
8:37:15
oleo
#<THREAD "main thread" RUNNING {10005F85B3}>:
8:37:15
oleo
The alien function "hb_ft_font_set_load_flags" is undefined.
8:37:28
oleo
no i'm not doing dumps anymore
8:37:33
loke
oleo: OK, that's because your Harfbuzz library is too old.
8:37:51
oleo
i used the system provided one
8:37:52
loke
I'm not actually using that one, so I could remove it.
8:37:59
loke
oleo: What Linux are you using?
8:38:23
loke
The one that comes with Fedora-26 works finer (and that one is pretty old)
8:38:34
oleo
which version is that ?
8:38:45
oleo
i mean the one you use
8:39:03
oleo
i'll just install a newer version in /usr/local if possible then
8:41:07
loke
I saw you had some other errors with missing symbols, and that's also because of your harfbuzz lib version
8:41:27
loke
(like I mentioned, I don't actually use those, so for CLIM I could disbale that to make it work on older versions)
8:49:54
oleo
no idea who decides to use which version of harfbuzz when it comes to distros, it's not obvious from the version spec of the distro package manager which version it corresponds to actually
8:56:57
oleo
wait a little, does that also mean all the other libs i depend on are old too ?
8:57:06
oleo
like libfontconfig etc
8:57:51
loke
oleo: Probably, but for the most part you wouldn't notice since I don't really use any of the new features.
8:58:30
loke
For harfbuzz, however, I've added support for a bunch of functions that I don't actually call (the functions that are listed in the header files of the version I was using when developing the CFFI wrapper)
8:58:56
loke
That might not have been the best idea for CLIM, but I didn't realise that there were so many new functions.
12:36:27
oleo
ok i installed all the required libs manually
12:36:37
oleo
and am restarting my repl now
12:43:32
oleo
err, obviously my repl start now ok
12:43:43
oleo
i just got an error with fontconfig
12:43:55
oleo
just telling me failed reading config file
12:44:05
oleo
not sure why that happened
12:44:27
oleo
but it does not hinder the clim-listener from running
12:44:34
oleo
so everything should be ok
12:49:22
jdz
oleo: this might be relevant: https://bugs.chromium.org/p/chromium/issues/detail?id=829890#c4
12:50:21
jdz
Basically fontconfig project decided to make some incompatible changes.
14:29:58
oleo
loke: can't get your maxima-client running, no matter what i try
14:30:20
oleo
loke: i linked maxima/src to quicklisp/local-projects/maxima
14:30:49
oleo
and even when i start with a maxima.core it does not load properly
15:01:03
loke
oleo: You shouldn't link maxima-code/src. You should link maxima-code
15:01:13
loke
(there is another package in another subdirectory that is also needed)
15:03:37
loke
oleo: Oh, and you need to actually build maxima first (just make && make install in the maxima-code directory)
15:04:32
loke
OK, and what error do you get?
15:14:35
oleo
wait a little that was because of config error in my asdf system definitions
15:14:50
oleo
i had to copy one by one some of the compiled fasls into the .cache at the proper places....
15:15:20
oleo
hope to resolve the isse now
15:15:45
loke
oleo: Just delete all the fasls
15:15:56
loke
they will be automatically rebuilt
15:16:43
oleo
no i was calling asdf:clear-system-registry at some point after loading quicklisp etc....
15:17:01
oleo
and defining my own system-registry
15:19:07
oleo
well what's happening is that upon loading maxima-client, basically maxima code gets recompiled
15:19:27
oleo
tho it was already compiled.....
15:19:35
oleo
and living in src/binary-sbcl
15:19:46
loke
Because now you compile the fasls into $HOME/.cache/common-lisp
15:32:34
oleo
yes loke but that step fails somehow that's my problem
15:32:57
oleo
i.e. stuff does not get compiled into the .cache and i have to move them one by one there
15:33:06
loke
what is the error message?
15:33:23
loke
Why do you have to move it?
15:33:25
oleo
i always get a pop-up window with uiop telling me the fasl doesn't exist there....
15:33:37
oleo
err, i mean the debugger window ofc
15:33:51
oleo
that's what i'm trying to understand
15:34:02
loke
All you have to do is to start SBCL, do (ql:quickload "maxima-client") followed by (maxima-client:maxima-client)
15:34:13
loke
Assuming this is what you did, at what point did you get an error?
15:42:26
oleo
#<THREAD "main thread" RUNNING {10005E05B3}>:
15:42:26
oleo
#P"/home/oleo/.cache/common-lisp/sbcl-1.4.7-linux-x64/home/oleo/binary-sbcl/quicklisp/local-projects/mcclim-master/patch.fasl":
15:45:08
oleo
that was from the wrong image
15:45:25
oleo
i mean from the right script executed...
15:45:28
oleo
#P"/home/oleo/.cache/common-lisp/sbcl-1.4.7-linux-x64/home/oleo/binary-sbcl/maxima-source/maxima-5.41.0/src/maxima-package.fasl":file does not exist.
15:46:07
loke
oleo: Start with a clean image
15:46:09
oleo
i have maxima mcclim-freetype2 and maxima-client all in quicklisp/local-projects
15:46:15
loke
Standard SBCL. Nothing fancy preloaded.
15:47:42
loke
The only thing you should have in your $HOME/.sbclrc should be the Quicklisp initialisation
15:47:53
loke
After that, start the clean SBCL and run the two commands I told you.
15:53:51
oleo
i cleared all caches, and am using only rlwrap sbcl --load quicklisp/setup.lisp
15:54:10
oleo
and now i'm loading (ql:quickload :maxima-client) right after starting into the repl
15:54:17
oleo
and still get the same issue
15:54:34
oleo
#<THREAD "main thread" RUNNING {10005E05B3}>:
15:54:34
oleo
#P"/home/oleo/.cache/common-lisp/sbcl-1.4.7-linux-x64/home/oleo/binary-sbcl/quicklisp/dists/quicklisp/software/trivial-gray-streams-20180328-git/package.fasl":
15:58:19
loke
Can you Quickload trivial-gray-streams?
15:58:49
oleo
yes where it gets built is in /home/oleo/binary-sbcl/quicklisp/dists/quicklisp/software/trivial-gray-streams-20180328-git
15:59:04
oleo
as /home/oleo/binary-sbcl/quicklisp/dists/quicklisp/software/trivial-gray-streams-20180328-git/package.fasl
15:59:11
loke
Wait a minute. You've configured Quicklisp. You don't have aclean installation
15:59:20
loke
A clean Quicklisp install puts the quicklisp directory in the home.
15:59:33
loke
I don't know if it's related, but it is something that is not vanialla
15:59:36
oleo
yes quicklisp itself is in my home
16:00:01
loke
Why does things end up in binary-sbcl then? Normally it's in $HOME/.cache/common-lisp
16:00:24
loke
what does you $HOME/.sbclrc contain?
16:00:28
oleo
and no i can't load trivial-gray-streams alone either
16:00:34
oleo
i think, my quicklisp is botched then
16:00:48
loke
Where did you install SBCL from?
16:01:18
loke
oleo: compield and then run ./install.sh ?
16:01:31
oleo
both the linux-binary to bootstrap it and the source and then compiled the source
16:01:51
loke
Hmm... You _must_ have an .sbclrc
16:01:57
loke
Otherwise Quicklisp wouldn't work
16:02:26
oleo
sh make.sh --prefix=/usr/local --dynamic-space-size=2Gb --fancy --xc-host=../sbcl-<version>-x86-64-linux/run-sbcl.sh
16:03:03
oleo
quicklisp installs itself to the dir quicklisp
16:03:10
oleo
after that you load it via quicklisp/setup.lisp
16:03:26
loke
You only do that once, then you run ql:add-to-init-file
16:03:39
oleo
no need to if you don't use one
16:04:03
loke
I honestly have no idea what's going on, but it's certainly not something to do with my code.
16:04:04
oleo
rlwrap sbcl --load quicklisp/setup.lisp
16:04:19
loke
I've never seen it drop the files in any place other than $HOME/.cache
16:04:19
oleo
maybe i should just delete all of quicklisp
16:06:10
loke
get back to as pristine configuration as possible. Re-download everytihing :-)
16:06:22
loke
I have heard of people having corrupt Quicklisp installs
16:06:29
loke
Dont' think it ever happened to me though
16:06:37
oleo
ok i did all from scratch now
16:06:50
oleo
rlwrap sbcl --load /mnt/sdb5/quicklisp.lisp
16:07:10
oleo
(quicklisp-quickstart:install) (ql:quickload :maxima-client)
16:08:50
oleo
oleo@oleo-System-Product-Name ~ $ cat .config/common-lisp/source-registry.conf.d/systems-registry.conf
16:08:50
oleo
(:tree "/home/oleoo/common-lisp/source/asdf-3.3.1")
16:08:50
oleo
(:tree "/home/oleo/clocc")
16:09:05
loke
oleo: Delete that stuff :-)
16:09:13
oleo
so for quicklisp i don't have to add another tree, since it manages that itself
16:09:16
loke
Delete all of .config/common-lisp I guess?
16:09:31
loke
I don't have such a directory
16:09:44
loke
I'm pretty sure that's where your problem is.
16:09:47
oleo
it's describe in the asdf manual
16:10:06
loke
Right. But now re're trying to find out where the problem is so you have to start with a clean config. That means getting rid of that one.
16:10:11
oleo
no it's not cause i put that systems-registry.conf file out of that dir for a while
16:10:54
oleo
i got the same problem again
16:11:00
loke
Then the weird directory configuration comes from somewhere else, and you have to find it and delte it.
16:13:27
oleo
yah, that's what i think too
16:13:38
loke
Anyway, good luck. I have to go to sleep now :-)
16:13:49
loke
How about creating anew account on your machine?
16:13:59
oleo
i don't think that's the problem really
16:14:00
loke
Then do a super-clean setup from there, compeltely empty home directoy.
16:14:05
oleo
something intervenes there
16:14:23
loke
If that works, you can start moving stuff from your main directory until you find the diffrerence.
16:14:45
loke
I did that once when I had a problem where my main account had an error logging into GNOME, but a new user didn't.
16:15:09
loke
Finally figured out that it was caused by my main used authentiating via Kerberos, while the other was using a local password
16:15:28
loke
really bizarre, and I still don't know why they GNOME desktop wouldn't start when authenticating via Kerberos :-)
16:16:47
loke
oleo: Xach is on #lisp right now, he might be able to help?
16:20:58
oleo
wait a little, i created a new user and am trying
16:28:35
oleo
hmmm, wait a little i moved local-projects/mcclim-freetype2 to quicklisp/dists/quicklisp/software/
16:35:47
loke
You should never have to do that.
16:36:07
loke
Anyway, I need to disconnect now. Back in some number of hours :-)
16:36:26
oleo
whatever i tried, even with a new user (pristine) and nothing compromised it fails at some point
Monday, 21st of May 2018, 18:36:39 UTC