libera/#commonlisp - IRC Chatlog
Search
10:18:42
pjb
beach: there are arguments to deprecate prog2. For example, there's no multiple-value-prog2, only a multiple-value-prog1 :-)
11:15:16
scymtym
deprecate all three and generalize to MULTIPLE-VALUE-PROG-NTH N FORM* where N is evaluated. i'm sure there will be no negative impact in terms of ergonomics or performance
11:40:33
scymtym
that's hard to answer in general. GTK has gpu acceleration, more complete text and font support, more supported platforms and probably looks more appealing to many users. McCLIM works without foreign libraries, has the presentation and command sub-systems, is easy to extend due to the stratified design and has a specification. but again, advantages and disadvantages will depend on the use-case
12:16:45
lotuseater
a friend of mine said McCLIM looks old but I more tend to use the term "baroque"
12:25:32
beach
lotuseater: So here is what bugs me. People would rather spend a lot of time and energy debugging FFI solutions that serve only their own projects, and complain about the looks of McCLIM, rather than spending a small amount of time making McCLIM look the way they would like it to, thereby providing a better solution for the entire community.
12:50:02
contrapunctus
lotuseater: there's been some lovely art from the Baroque era, is that a compliment? 😏
14:28:41
beach
The grammatical structure of the sentence makes that clear to a native speaker. Sorry about that shka.
14:30:50
beach
I am not sure what the message is here. The initial creators of McCLIM didn't take into account the necessity for everything to be just bitmaps, so therefore, since coding is required to make it look the way we want, we should all give up and use gtk instead?
14:33:53
pjb
Also, it's an impossible task. Apple is not in the computing business, it's in the fashion business. The look WILL change every year! If you try to follow, you are only wasting resources that would be better spent elsewhere.
14:35:34
pjb
The more bland the look anyways, the faster and the better. We can compete on other things, such as ergonomics and smarts.
14:36:39
lisp123
is it possible to build a bridge between any Lisp GUI system and the default GUI tools of each OS?
14:39:26
lisp123
shka: thanks, I guess its too time consuming so hasn't really happened. Its very hard to go up against Apple (in particular) due the amount of money & time they spend on design - and anything that doesn't follow the native look on MacOS will look off to some degree
14:39:35
beach
lisp123: There are great advantages to a GUI toolkit written entirely in Common Lisp.
14:40:46
lisp123
beach: I was more thinking if its possible to keep everything but using the end visual components of a native system
14:42:54
lisp123
beach: oh I see, I misread his comment as I thought it mean its not enough to only reuse bitmaps, but required more
14:43:35
beach
Exactly, you can't just plug in new bitmaps into McCLIM the way it is now structured.
14:44:08
beach
So, in order to reuse the native look without FFI, all you can do is copy their bitmaps, but that's not currently enough.
14:45:11
beach
I think the people complaining about McCLIM looks haven't really seen the great advantages that presentations and a dynamic programming language give in a toolkit.
14:45:37
lisp123
(p.s. not complaining :-) ) - out of curiousity, why not just go down the FFI route
14:46:16
beach
lisp123: Because it always results in a debugging nightmare, as you can see from the numerous cries for help here, when people are lost.
14:46:45
shka
beach: the problem is that no matter how cool is to program applications using McCLIM, there is distinction between nerd software and normal people software
14:48:10
beach
Oh, and commercial mass software is what all the #commonlisp participants who complain about McCLIM are into?
14:49:09
beach
But Common Lisp is totally useless for commercial software anyway, as I understand it. So I don't see the problem.
14:51:48
shka
well, that's how it is, i can write prototype in McClim, and it will be fun, but there is no way in hell that boss would allow it go to the user with the company logo slapped on
14:53:30
beach
My message is that there is A LOT of collective energy spent in debugging FFI solutions. I think the effort to make McCLIM look like the native toolkit would be WAY LESS than the collective wasted effort we witness here on a regular basis.
14:54:22
beach
Yet, people choose FFI all the time, complain about McCLIM, and then come here and cry because they can't figure out the FFI stuff, thereby wasting other people's time too.
14:55:41
shka
well, from my point of view, making mcclim look and feel exactly like native toolkit is not exactly required
14:57:36
beach
shka: Let me make that very clear. I was not addressing you here. I don't consider you one of the complainers.
15:12:34
beach
I suspect I am the one responsible for the initial McCLIM scroll bars, and if so, I very likely used code to draw it, as a function of the size.
15:14:52
eta
ACTION played around with the clim-listener once and found the experience generally quite janky
15:15:05
_death
in DOS days everyone wrote their own GUI libraries.. you'd deal with the myriad of drivers or VESA etc.. each would have different look and feel, kind of like today's websites
15:15:32
eta
I also suspect it's an acquired taste, as in you have to familiarize yourself with the paradigm (which isn't what your OS GUI looks or feels like either)
15:15:46
pjb
But nowdays, they'll use vertorial images for the various resolutions. Possibly shadowed by "optimized" bitmaps for the most common resolutions.
15:16:12
_death
many great tools from that era had look and feel tuned to match the tool's functionality
15:17:29
beach
eta: Part of the problem with the listener is the input editor, which is DREI and which was extracted from (first) Climacs. We are (slowly) working on Second Climacs that we hope will be much better.
15:20:03
_death
the listener could've been more extensible, so that people could independently write their own command tables and they could all be used by the listener's user without much effort
15:20:16
eta
beach, I'm trying to provide a bit more nuance to your opinions on the GTK+ "complainers" being terrible and no good :p
15:22:48
_death
eta: when you get used to a listener pane being available, you find more and more uses for it.. essentially it gives you the best of both worlds (GUI and command line)
15:24:28
_death
I wouldn't use clim for everything, of course, but it seems more underused than overused
15:33:37
lisp123
beach: nice, I will search for it (the main reason I ask is context switching, the dream is to have everything in one window and Emacs does that a lot but cannot handle GUI well)
15:34:29
beach
lisp123: My plan is to make Second Climacs so much better than Emacs for editing Common Lisp code that it will be irresistible to Common Lisp programmers.
15:36:13
lisp123
Nice :D A good text editor is very important IMO - there's a lot of applications for text manipulation, now I'm using a lot of Emacs APIs to do some funky stuff
15:37:44
lisp123
But (to play devils advocate), is that a limitation of Emacs or of features not in SLIME?
15:38:50
lisp123
unless all the global variables and how Emacs does things, makes it too cumbersome to control it via slime
15:38:52
beach
Oh, sure, you can accomplish anything you want, but the fact that everything has to be encoded in a wire protocol makes it very hard to write and maintain such a thing.
15:39:37
lisp123
Ok, fair enough - I see from that perspective. Plus its a very large dependency one would *ideally* avoid in a pure CL environment
15:41:53
lisp123
_death: whats 'bret victorish'? google came up with a school board trustee's home page, so probably something else :D
15:45:58
_death
a while ago I looked into using cells with clim.. it basically worked, but all I remember now is that it needs further exploration
15:56:32
_death
e.g., when you move a slider you don't necessarily get notified until mouse button up (iirc).. also, clim needs a sensible way to do debouncing
15:58:26
_death
beach: it basically means setting a timer to do the action, rather than doing it immediately, and readjusting if necessary (the user is not yet idle)
15:58:55
_death
beach: this could alleviate obvious problems like "jumpy" highlighting because of nested presentations
16:07:21
lisp123
I instaleld it on a linux within a VM, but the rendering of fonts by the VM wasn't good enough (since I have a largish screen), then tried Macports & Home brew, but wasn't so easy
16:07:59
lisp123
Best would be App Store, but I'm sure many have mentioned that already :-) I think you will find a lot of love from the MacOS community
16:21:19
jmercouris
I know, I was a macOS user myself, it’s just so frustrating dealing with the APIs
16:26:19
lisp123
Yeah its annoying how macOS is similar to linux but still the gap is far and many things don't port over nicely
16:48:50
lotuseater
jmercouris: are there plans for also bringing nyxt to ARM (I mean eg raspberry pi)? and I can imagine it has a smaller footprint in memory than firefox or chromium
16:50:52
lotuseater
but this is one excellent example for me how to deploy such a big application to various platforms
16:52:06
lotuseater
the thing is the SBCL on pi is just vesion 1.4.6 or so o_O even in apt, but I installed nix package manager so this oldish debian pkgs is not my problem where i need newer software releases
18:01:23
ecraven
hm.. I remember looking at an article that talked about how to implement compile-time unit (as in m, s, m/s, ...) checking in Common Lisp, but can't find it any longer :-/ does anyone happen to know it?
18:04:00
_death
possibly https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-3-scientific-units-8e41d8a727ca
19:12:27
JeromeLon
I have a (declaim (optimize ...)) at the top of each file in my asdf system. This is suboptimal, I would like a shared directive (in package.lisp for example). I couldn't find what the compile-time semantics are for declaim when using multiple files: declaim stuff should be global, but the compiler focuses on a single file that is not even loaded. What is the right way to share a declaim between multiple files?
19:19:32
JeromeLon
lotuseater: that sounds perfect! the doc for around-compile even mentions "proclaiming consistent optimization settings"
19:20:45
pjb
JeromeLon: you should not declare optimization in library (or published application) code.
19:24:52
JeromeLon
pjb: so, what is the right way to do it? declaim something and then call load-system? will my declaim be used (assuming nobody did what you are guarding me against)?
19:28:12
pjb
JeromeLon: put your optimization declaration in your rc file. Change it depending on what you want to do (eg. if you want to generate a fast executable, you can rais speed, by default, you will be debugging).
19:29:14
aeth
imo... if what you're doing isn't math, you probably don't want to optimize it at all; if it is math, I'd optimize per-function (perhaps with a macro to automate it)
19:29:50
aeth
pjb: It's not a universal, though. There are cases where you absolutely want to have optimizations in the source files, directly. But essentially only for math libraries.
19:30:22
aeth
i.e .You don't want to have the user force (near-)universal optimizations just to get efficient math
19:30:35
pjb
you would have to wrap them in a lot of checks. Most of the time, that would defeat the purpose.
19:32:08
JeromeLon
ok, let me reformulate my question: I am writing a system that consists of a lot of files. What do I have to do to have all the debug capabilities at all time while developping?
19:34:37
JeromeLon
pjb: just to be clear: I eval this on the repl just before load-system, and all the compiling will use it from that point on?
19:54:22
pjb
Note however that there's no conforming API to inspect the optimize declaration, and not all implementations provide one.
19:54:45
pjb
So it would be hard to do an around-compile function that would save and restore the optimizations.
20:04:28
jcowan
fwiw I think that skinnability has become an important part of UI design. But that can wait for OClim rather than McCLIM, I suppose.
20:33:33
jcowan
Yes. Mac/Mc is a prefix to Irish and Scottish surnames originally meaning "son of", whereas "O" means "grandson/descendant of".
20:34:47
jcowan
My own surname is a clipped form of Irish "Mac Eoghain", son of "Eoghan", "Owen", or "John", though my father was Thomas and not John.
20:36:10
jcowan
His father, however, wrote his name "John Cowan" but pronounced it more like "Shawn a-Cawn".
20:37:51
lotuseater
here in germany the most common surnames are something like "Müller" or "Meier" for also historical reasons
20:43:43
jcowan
Yes. Germans didn't go in for patronymics for whatever reason, unlike Jews, Scandinavians, the English, and the Welsh.
20:50:31
lotuseater
I fond it interesting that some jewish surnames are very german but one can predict they're more used in jewish families
20:51:24
lotuseater
nice waleee you're from sweden :) a friend of mine is travelling atm there with a camper
20:52:02
waleee
the rest of the surnames would sound jewish in German I guess (heavily nature-inspired)
20:52:33
jcowan
Invented by Austro-Hungarian bureaucrats, who could be paid to give you better ones.
20:53:43
jcowan
"So what name did you get?" "Schweisshund." "Whaaat? Didn't you pay him enough?" "My friend, you have no idea how much I had to pay for that W!"
20:59:54
lotuseater
my surname is that of a german town without the last two chars, has nothing to do with each other, but sometimes useful to say for one to write it down correctly :D and also not so often which is good
21:03:59
lotuseater
like Fickmühlen, Luschendorf, Afrika, Knoblauch, Amerika, Texas, Poppel, Lederhose, Aua, Hanf, Kothausen, Drogen
21:04:46
lotuseater
so coming back ontopic, they should have used a CL tool for figuring out that those names are silly
21:50:56
lotuseater
are then the double colon not exposed symbols package::symbol the childrens the world shall not know about? ^^