freenode/#clim - IRC Chatlog
Search
15:27:30
TMA
smokeink: indoeuropean languages are actively helping you (a speaker of an idoeuropean language), because there is the shared vocabulary that gets you up to speed and there are mostly no gotchas that get you completerly off-guard. other language families are more alien in that respect
15:29:43
TMA
smokeink: admittedly, the vocabulary help kicks in fully for the third (and further) language (it also helps when the second language is latin or ancient greek)
15:31:49
smokeink
but an even more important factor is the passion for the language, no matter how different it is from your mother tongue
15:34:35
smokeink
my mother tongue is Romanian, which is very similar to Russian, and I still have a difficult time learning it
15:35:21
smokeink
and I think the reason for that is because I'm not focusing on it as I did when I started learning Chinese for example
15:35:48
loke
smokeink: I'm not travelling to Russia anymore, so my incentive to learn it has been decreased.
15:40:32
smokeink
http://www.guidetojapanese.org/blog/2006/07/20/which-is-harder-japanese-or-chinese/ "I can’t help but get the feeling that Chinese is like the easiest language in the world. Of course, I’m still a complete beginner but from what I can tell, Chinese is just so much simpler than Japanese."
15:41:20
loke
In trying to get RTL text to play nicely with CLIM, I scovered that the function TEXT-SIZE returns a “direction” value. That's incredibly pointless, and clearly designed by someone who did not give any thought to such languages.
15:41:57
loke
I'm getting very close to unilaterally deciding to redesign some of these API's. Because they just don't work.
15:43:55
loke
I was think about that, and I concluded that there are very few people who are both qualified in the necessary topics, and at the same time crazy enough to actually spend time doing this. In fact, the number may actually be zero.
15:45:27
smokeink
the number is close to 0. As far as I'm concerned, I have the craziness , it's only that I 've never done big lisp projects before so I 'll have to do my homework before I'll be able to participate with some real work
15:47:07
loke
smokeink: The good thing about participating in Lisp projects is that all you have to do is to press M-. on the function you're interested in, make some changes, press C-c C-c and test it.
15:48:48
loke
smokeink: The hardest part with ibus is to integrate it in Lisp. You'll havet ot write a CFFI wrapper around it (like I did for fontconfig and harfbuzz)
15:49:14
loke
You don't have to do anything with CLIM when testing that, just write a small separate project and try to call out to the GNOME libraries.
1:21:35
smokeink
loke: for linux there are at least 3 popular IME frameworks: iBus, SCIM (Smart Common Input Method platform) and fcitx . All three of them are good and all three of them have their limitations/bugs
1:25:31
smokeink
that's for the graphics mode. For text console mode (framebuffer console actually) there's fbterm-ucimf which works well. There are a couple of others as well but I couldn't get them working. The console mode IME's are rarely used nowdays so we won't bother to integrate them with CLIM
1:27:00
smokeink
on Windows I'm not sure, it might be the case that the IMEs work by default when mcclim uses the native backend
1:57:13
loke
Now I have a problem... To get Harfbuzz to shape the fonts correctly, I have to set the language code prior to rendering.
1:57:52
loke
Arabic will be completely screwed up if I set anything but AR. But Elish doesn't look good unless I choose EN. I expect all other scripts to require similar behaviour.
1:58:27
loke
I guess I could look at the code points and choose a reasonable default based on the Unicode block, but that feels very ugly.
2:46:50
loke
it looks at a buffer (a line of text, basically) and guesses the parameters that I haven't supplied. In this case, it guesses the appropriate script parameter.
3:01:20
fittestbits
I ran into a code pattern today that I wanted to ask mcclim supporters about. It's near the bottom of Extensions/render/backend/port.lisp.
3:02:05
fittestbits
At top level in the file there's (let (<some hash tables>) <some function definitions using the local bindings> )
3:03:12
fittestbits
I had a problem I was trying to track down related to those hash tables, but there was no way to get access to them.
3:03:44
fittestbits
So, yes the data was encapsulated, but it seems like it was overly encapsulated.
3:05:31
fittestbits
The exact same code (almost) is at the bottom of xrender-fonts as well, I saw it in port.lisp.
3:06:12
fittestbits
And the key was a list created on the fly, so there was never a hit in the has table.
3:06:47
loke
Stuff like that (and other stupidities) was the reason I threw out all of xrender-fonts.lisp and started working on a brand new font engine.
3:06:59
fittestbits
I noticed that xrender-fonts was using equal for all of the hash tables - which lead me to the fix for port.lisp.
3:07:36
loke
Another “great” idea they had was to override the the font engine by adding an :AROUND method around some central functions so they could replace the rendering part.
3:10:30
loke
Guess what happened when I wanted to implement my own renderer? The code was never called... funny that.
3:19:40
fittestbits
froggey has a repository Iota which is an LLVM to common lisp transpiler. I don't know what the status of that is.
3:20:58
froggey
yeah, Iota converts C (or LLVM IR in general) to CL. it's more of a proof of concept than anything useful right now
3:21:39
froggey
with a bunch of work it could be used to interface with C libraries, but I haven't really thought about how to make that work
3:24:55
loke
Unless anyone is willing to spend a ridiculous amount of time replicating the functionality of Harfbuzz and Freetype in Lisp, the Iota seems to be the only reasonable approach.