freenode/#clim - IRC Chatlog
Search
21:27:01
jackdaniel
left and right margins: https://files.mastodon.social/media_attachments/files/009/916/750/original/c28c2833ddf55378.png
21:27:48
jackdaniel
I have also wip top and bottom margins (whole margines jazz has been factored into a mixin)
21:39:08
jackdaniel
I don't know drei well, but if you have questiosn about the core/ module I'll be happy to answer
21:41:15
jackdaniel
I can hint , that it might be that drei is built to work fine with emacs-ish abstractions (i.e one buffer accross multiple panes)
22:14:08
Inline
but when i opened that file in climacs, without doing anything further, the file is displayed like there are no tabs, looks like it's all writ together words....
22:15:15
Inline
i suppose i have to not only fix tabify and untabify but also the view, the rendering of tabs over again
4:41:44
loke
When defining a presentation method for CLIM:ACCEPT, what am I actually expected to do inside it? Bascially, if, in it, I decide that I'm done editing and X is the value to return.
4:42:13
loke
So, I return it... But nothing happens and once I click the entry box again, it calls my accept presentation method again
4:42:47
loke
I have implemented a presentation method for a MAXIMA-FUNCTION-NAME (just a string, but with a presenbtation type that indicates that it's the anme of a maxima function)
4:43:40
loke
But, I need to still be able to accept a user clicking on a function reference in the documentation, so I wrap it in an input context like this:
4:45:35
loke
(clim:with-input-context ('maxima-function-reference) (obj type ...) (clim:complete-input ...) #|here are the cases for w-i-c|# (maxima-function-reference (values (values XXXX 'maxiam-function-name))
4:49:10
loke
I've only ever used ACCEPT presentation methods which eventually regusively calls ACCEPT with some different paramteres.
4:49:39
loke
there is some magic going on, and I've seen some code do (FUNCALL (CDAR *INPUT-CONTEXT*) magic-goes-here)
4:50:49
beach
I see. Well, I don't think I was involved in writing any part of the presentation machinery, nor have I ever written an ACCEPT method I think. As I recal moore33 wrote all that stuff.
4:52:10
beach
Maybe one day I will again have time to write some sophisticated GUI application, like Clovetree.
4:55:23
loke
π
Ώπ
΄ππ
·π
°π
Ώπ π
°π
»π
» π
Όπ π
Όπ
΄πππ
°π
Άπ
΄π ππ
·π
Ύππ
»π
³ π
±π
΄ π
»π
Έπ
Ίπ
΄ ππ
·π
Έπ
4:56:05
loke
Just exploring some part of Unicode that I believe shouldn't really be part of Unicode :-)
4:58:11
loke
Anyway, I've come to the conclusion that the completion implementation in mcclim isn't very good. For example, there is no way to navigate the completion alternatives with the keyboard. You need to right-click to see them.
4:59:24
beach
I think I wrote part of the completion code, but not the part that is directly used by the end user. Maybe I wrote complete-from-possibilities and the other one the name of which I forget.
4:59:43
loke
I'm going to see if it's possible to replace the current implementation with my custom one that I currently only use in the Climaxima interacotr:
5:07:07
beach
I'll say this again: Even though I don't use Maxima (simply because I don't often use sophisticated math anymore), I think you work on Climaxima is great and that it can become one of the "killer apps" (I hate that term, but don't know any better) for showing off McCLIM.
5:07:09
beach
I had hoped Gsharp would be such a thing, but, as often happens, version 1 is full of design mistakes. That's why I hope to work on Clovetree (i.e. Gsharp v2) some day.
5:10:32
beach
But, at least I can say that McCLIM happened BECAUSE of Gsharp. I needed a GUI library, and it was unappealing to me (never considered it, really) to use a library that required FFI.
5:13:45
loke
I've written so many libraries and built so many interesting things from scratch that I would never do in other systems.
5:15:55
loke
When doing Java or whatnotm you just end up using a third-party library and stick with it even if it sucks becausise building something new is just not fun.
5:15:57
beach
I know jackdaniel disagrees with me, but I am totally convinced that we can do things like that because we have a language that makes us more productive that what is typically the case.
5:16:47
loke
The other reason is because I just don't work with _my_ code. I work with the entire system, and modifying/debugging code that is part of a library is just a M-. press away
5:18:13
loke
If I want to try a small fix in a Java library, I have to download that source spearately, figure out how to build it, make the modification, build the library, and if you're using one of the build systems such as Maven you also need to build a new repository and override the old one in your build system, do a full rebuild and hope that it all works.
5:19:42
loke
so it's not entirely the _language_ that encourages this, but also the entire infrastructure surrounding it. The fact that the language itself is nice to use is just an extra bonus.
5:22:09
loke
When I've had to make modifications to a Java library, I actually often completely circumvent this and manually extract the library, remove one of the class files inside, and replace it with a manually patched version. The way I do it is to download the original source code, make the change in the single file, and manually compile that file to a class file.
5:22:56
loke
kTHis nightmarish procedure is actually _easier_ than doing it the right way. Tells you a lot about the workflow.
5:23:38
loke
Oh and by the way, I do this when testing fixes in our application at work. This not a mess of third-party open source dependencies but a single application.
5:24:03
loke
When hacking jar files is easier than using the proper build system for a single application, you know somethign is wrong witht he ifnrastructure.
5:25:12
loke
Now, you have a large majority of developers who were raised with this, so they find it perfectly normal. Javascript, for example, is at its core very similar to Lisp in how it works, but they built an entirely ecosystem around the Java way of thinking.
5:26:54
loke
(it's not just NPM actually, npm is the package manager. then there are many more layers of crap on top)
5:27:57
beach
Several times during my career as a professor, I have considered doing an internship in industry, just so that I could write a book about the sorry state of it all.
5:29:11
beach
It almost happened once. But when I asked for a "symbolic raise" compared to my current salary, the guy basically told me that they don't pay that kind of money. That indicated to me the average level of knowledge of their developers.
5:31:59
loke
if I wanted to make extra money I could have doubled down on Java or Android, but I'm payed decently here where my development skills comes to use, but I don't actually do much in the way of development at the office. That saves my coding energy for my pet projects :-)
5:32:18
PuercoPop
loke: You are on to something regarding how easy is to modify a dependency vs the frequency one does it. (Btw specifying dependencies in Pharo is kinda confusing, at least to me so I avoid it ^_^). Another language that makes it easy to modify 3rd party code is Ruby thought due to 'open classes'.
5:33:25
loke
PuercoPop: I have contributed to so many CL projects. In total I have done more Java development than Lisp, but only contributed to a handful of projects. To me, the numbers speak for themselves.
5:33:45
beach
loke: I guess you will have ample opportunity to tell me what your work is about when we have lunch together.