freenode/lisp - IRC Chatlog
Search
13:03:31
pve
beach: I've also read the paper, very interesting.. at some point I may want to think about how the dispatch is done in this little language I'm working on
13:05:21
pve
it's a bit simpler, in that methods "belong to classes" like in smalltalk, and they only specialize on the recipient of the message (i.e. "self")
13:05:42
phoe
one option is to defer dispatch to the host CLOS and wait for that host CLOS to become good/fast enough
13:07:31
beach
So, I have a theory that C++ dispatch could be made faster if it used my technique. Currently, they try very hard to use a table-driven approach using so-called VTABLEs.
13:08:25
beach
And I think when they have multiple inheritance, the tables must be nested, so that should result in several memory accesses.
13:12:10
jackdaniel
it is. this approach makes writing c++ class extensions as dynamically loaded libraries not feasible at all
13:14:08
dlowe
they're "v"tables only to support so-called virtual methods. Non-virtual methods are resolved according to declared type, ignoring the type of the object
13:17:25
jackdaniel
ldb: but C and C++ make use of it, and they are fairly popular. only dispatch in C++ is crooked with this regard
15:51:46
fwoaroof[m]
(It's been a long time, and I see C++ developers complain about virtual methods all the time these days)
15:53:11
fwoaroof[m]
I think it's a combination of dynamic dispatch being slow and dynamic dispatch makes control flow confusing
15:54:06
beach
Yeah, me neither. But given the table-driven dispatch, it might be slow in the eyes of a C++ programmer.
15:55:06
beach
But it was my impression that virtual methods and dynamic dispatch (which some people here say doesn't exist anymore) was one of the mechanisms required for the OO style that C++ recommends.
16:11:53
beach
I don't believe it, but this is not the right forum to discuss C++ and its implementations, so I did not protest too much.
16:15:28
jackdaniel
"Since C++ does not support late binding, the virtual table in a C++ object cannot be modified at run-time, which limits the potential set of dispatch targets to a finite set chosen at compile time. "
16:16:14
jackdaniel
(taken from wikipedia, but it matches my prior knowledge) -- https://en.wikipedia.org/wiki/Dynamic_dispatch#C++_implementation
16:16:59
beach
Limiting it to a finite set sounds different from "all resolution is done at compile time"
16:17:27
dra
So it's instruction cache vs. branch prediction. Not that it generally matters much anyway.
16:17:54
beach
But I am not going to participate any further in this discussion. It is off topic, and I need to go start dinner anyway.
16:17:54
jackdaniel
uhm, at least this "finite set" is what I've meant when I said that it is indeed sad and that you can't extend it by loading .so libraries
17:01:27
sjl_
This should work and return (1 nil 2 nil) right? (loop :with (a b) = '(1) :for (c d) = '(2) :do (return (list a b c d)))
17:01:33
sjl_
> During loop expansion, each variable in the variable list is matched with the values in the values list. If there are more variables in the variable list than there are values in the values list, the remaining variables are given a value of nil.
17:01:57
sjl_
It works like I expect in SBCL and CCL, but signals an error in ECL and ABCL. Am I misreading the spec?
17:05:45
scymtym
jackdaniel: quick, check SICL loop. maybe it behaves like ECL and ABCL. you can still get a majority
17:07:48
jackdaniel
I've reported the issue: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/605
17:08:05
easye
sjl_: According to the CLHS paragraph you quoted, the references should clearly by NIL.
17:08:49
jackdaniel
ACTION walks away while pretending that he does not hurry to be faster than easye with the fix
17:08:58
sjl_
easye: yeah that was my reading. But two unrelated implementations having the same behavior made me second guess myself
17:10:13
sjl_
It would be convenient if it destructured like destructuring-bind, but that would complicate the (loop for (a b c) of-type (integer integer float) in ...) type declaration syntax I guess
17:14:16
jackdaniel
easye: "just" using sicl's loop is buying into a strategy, where you bootstrap from fully-features common lisp - that is a fine strategy, but not something automatically agreeable. I think that sicl's loop implementation requires working loop implementation
17:15:13
jackdaniel
you may always replace abcl's loop /after/ everything is built, so you have your old loop for building abcl, and this new loop for users
17:15:53
jackdaniel
adopting first class global environments will allow even switching loop implementation by the user without breaking the implementation internals
17:16:42
jackdaniel
but still doing all that is not the most obvious thing to do where it comes to fixing a bug ;)
17:18:01
sjl_
jackdaniel: for 100% clarity, in the issue you linked, it should work for both WITH and FOR
17:19:06
sjl_
No idea if with/for are implemented by the same code or not, so might be worth checking both.
17:22:02
fwoaroof[m]
I tend to care about this sort of issue, because it's the sort of thing that prevents me from using the libraries I like in LispWorks
17:26:00
ferada
hiya, anyone worked with commonqt/qtools/... and possibly has an example of subclassing/delegates usage (e.g. for custom listview elements)?
17:30:49
fwoaroof[m]
Depending what you need, maybe this? https://github.com/Shinmera/qtools/blob/master/examples/melody/melody.lisp
17:32:11
fwoaroof[m]
I believe this also used qtools extensively: https://github.com/Shinmera/parasol
17:37:40
fwoaroof[m]
https://lisp-journey.gitlab.io/blog/gui-programming-in-common-lisp-part-1-of-5-tk/
17:40:16
fwoaroof[m]
https://gitlab.com/eql/EQL5 maybe too, it's embedding strategy seems more stable to me than attempts to FFI
17:43:10
fwoaroof[m]
There's some valiant efforts to maintain GUI toolkits in the various programming language communities, but there's little money or thanks in that effort
17:45:46
fwoaroof[m]
And the big toolkits that do exist (Cocoa, Gtk, QT, Flutter) are actively hostile to using non-approved languages
17:46:08
ferada
well i'd wish to have more resources to dedicate to native ui, but time's limited isn't it
17:46:39
fwoaroof[m]
(I believe the Gtk developers, for example, explicitly have said something like "we don't care about non-Gnome use cases"
18:04:32
luna_is_here
Yeah... It is the decline of the desktop application. 10 years ago every language had bindings to all major GUI toolkits.
18:05:07
luna_is_here
The good news is: People are now used to Web-Apps and do not care soooo much about native apps anymore.
18:06:30
jackdaniel
it is not good news that you need a program bigger than your operating system (resource-wise) to run an hello world application
18:07:59
luna_is_here
Thus, having a modern theme for McCLIM might get you 95% of the way of a modern GUI in lisp, IMHO.
18:10:17
jackdaniel
it is not about electron, I'm more concerned that my computer which is many times faster than my computer in 2000 feels actually slower ^_^
18:10:18
fwoaroof[m]
I got a lot of compliments about a CAPI app I wrote on the side for some stuff at work
18:10:45
fwoaroof[m]
Out of the box, native apps on a Mac look good and work mostly as users expect them too
18:14:15
luna_is_here
Depends on the expectations... I usually find MacOS apps quite ill-behaving. But, that is a matter of taste, I guess.
18:16:25
luna_is_here
I know. But there is also a certain consistency between web-apps and people these days are used to that.
18:17:12
luna_is_here
Anyways, I know what you mean. I also prefer applications that are well integrated into my desktop.
18:19:00
luna_is_here
The question, however, is. Is it worth the extra effort, for example, for a language community to maintain bindings to all native GUIs and maybe a cross-platfrom toolkit on top.
18:24:31
luna_is_here
That they ask for any GUI toolkit does not mean that they care for a native one.
18:25:27
luna_is_here
And that this question pops up so frequently, probably means that there is currently no satisfying answer in all of these languages.
18:25:28
fwoaroof[m]
Depends on what you mean by "native", but they often explicitly don't want a web frontend
18:26:22
jasom
11:05:07 luna_is_here | The good news is: People are now used to Web-Apps and do not care soooo much about native apps anymore.
18:27:33
Xach
hmm, I didn't know about Integrated Inference Machines - http://pt.withington.org/publications/LispM.pdf
18:28:16
luna_is_here
[19:58:55] <luna_is_here> Thus, having a modern theme for McCLIM might get you 95% of the way of a modern GUI in lisp, IMHO.
18:29:15
jasom
you also need it to work on something other than X11 though; last I checked McCLIM didn't have a great story there.
18:30:24
Xach
anyway, i stumbled across that because P.T. Withington worked for Laszlo Systems, and they had a GUI system designed around declarative constraints that I always found very interesting, but it petered out in the market.
18:30:43
Xach
and i can remember "P.T. Withington" but not "OpenLaszlo" the product, so looking it up is always an adventure...
18:45:19
luna_is_here
The arrangement of a set of native widgets might look good on one platform, while the same arrangement can look terribel on another.
18:46:19
fwoaroof[m]
Yeah, that's hard to avoid, though: you basically just have to separate view/logic and pick the view based on the platform
18:51:53
jasom
separating view from logic can become complicated what happens when you hit the "up" arrow on a spinner that has a logical maximum value? Is the maximum value told to the view by the logic, or does the logic intercept the "up" event and decline to increment? Different GUI toolkits may prefer one way over the other
18:53:14
luna_is_here
Now it depends on your audience, whether the audience cares for a native app. ;)
18:53:32
fwoaroof[m]
But, there isn't really a good option here: electron/OpenGL GUIs just look wrong and often break OS features, multiple frontends is a maintenance burden and picking a platform restricts your audience
18:54:19
fwoaroof[m]
But, I'd pay LispWorks for access to a CI environment for building my apps for distribution on Linux/Windows
18:56:03
jasom
I don't currently own a mac, but when I did, ltk made "not terrible" apps and tk was pre-installed on macs. Not sure if either/both of those are true anymore. Now that multiplatform implies at least iOS, I'm not certain there is any CL solution for GUIs anymore.
23:38:36
Bike
markasoftware: they can have the same name, but the symbol in the environment can only refer to one class, i.e. find-class returns only one thing.
0:03:50
jasom
right you could do (setf class-name) to change the name of one class to be the same as another.
0:09:28
jasom
The main takeaway is that the following does not necessarily hold (eq X (class-name (find-class X)))
0:23:40
Bike
the clhs uses "proper name" to mean a class's name if the environment has that class under that name as well