libera/#commonlisp - IRC Chatlog
Search
15:38:03
beach
Didier Verna is looking for people to teach object-oriented programming (using CLOS) at four different EPITA sites in France (Lyon, Rennes, Strasbourg, Toulouse), with 6x2 hours per site. If I understand things right, he is teaching the first 2 hour session, and the second session is between March 6 and April 3, with more flexibility for the remaining ones.
15:39:07
beach
I think it is great that there are still universities in France that teach Common Lisp, and CLOS in particular.
15:41:25
beach
He asked me to announce this information here, and you should contact him if you are interested, available, and qualified.
16:08:24
Demosthenex
i'm pleased to reach day 6 of AOC in CL! woo! boy my code is ugly compared to some of the reddit posts though
16:10:13
pjb
utis: a-priori, I would say that (defcffi foo …) (function foo) should give you what you want in lisp. Now it may not be possible to pass that back as a int(*) parameter to a C function. To pass a lisp function to C we use defcallback and (callback foo).
16:11:36
nij-
Anyone using sly? In the default setting from doomemacs all of the texts printed to standard output has a certain color. How do I change that color?
16:13:03
pjb
utis: you can also use dlsym to get a pointer to a C function, if it's in the symbol table.
16:16:50
pjb
utis: from the sources, it seems you can use foreign-symbol-pointer to get a pointer to the C function, and you can call it with foreign-funcall. Try it.
16:19:38
nij-
Grep changes the matched texts in terminal programatically. I wonder if I can replicate that in sly, pjb.
16:36:17
VincentVega
It's an ecosystem aiming to displace Emacs, terminal emulators, contemporary Lisp IDEs, git, interactive notebooks (ala Jupyter), and all and any note-taking applications. And not just /displace/, but do so with /verve and panache/. It's a lofty goal, but I believe I can do a basic working system in 5 years:
16:36:17
VincentVega
*Fern*: A tree-fiddling GUI toolkit w/ prototypes & constraints (already half-way there for the fundamentals; based on Garnet) -- 1 year.
16:36:23
VincentVega
All form a homogeneous power-user environment with a high degree of flexibility and composition. Majorly, there will be a specification for working with text /seamlessly/ -- *Rune*. That's a major differentiating aspect for the project.
16:36:27
VincentVega
Some of you may wonder why I am not using McCLIM for GUI: many reasons. I have written a review here:
16:36:33
VincentVega
(beach, jackdaniel: if you find it misrepresents the state of things, I don't want to spread misinfo, so don't hesitate to tell me I am wrong)
16:36:41
VincentVega
I am not going to mince words: I need funding for me to be able to work on this. So, if you think you could use this, please, support the project. For a quick overview, see: https://patreon.com/projectmage
16:36:44
VincentVega
And my apologies for the dump of text. I will stick around in this chat for a few days, so feel free to ask or criticize anything.
16:40:33
jackdaniel
VincentVega: your paraphrasing mcclim manual actually misrepresents the intention; it is not that the user is stupid - beating estabilished conventions is simply hard, and clim approaches building graphical applications from a different direction than widgets and callbacks
16:41:08
jackdaniel
it is like trying to understand common lisp references after learning about C, pointers, copy by value, copy by something etc
16:41:48
jackdaniel
I will read the article in more detail later, always happy to read critical remarks; I've just wanted to address that part since I've read it first :)
16:45:12
VincentVega
jackdaniel: I understand, but I still find it an insincere way of putting it, because it's still not the reason why they have a hard time with it ¯\_(ツ)_/¯. I talk about it more down the line, though. And yeh, clim doesn't have callbacks?
16:47:18
jackdaniel
I read it as an sincere admitting, that CLIM is unusual and if you don't understand it then don't feel stupid, quite contrary to what you have summarized but oh well
16:48:02
jackdaniel
regarding callbacks, some gadgets define callbacks because clim 2 spec tries to cater to traditional gui expectations too, but that's somewhat glued to the clim as it is
16:54:03
VincentVega
Alright, I understand. I referred this to as an ambition to subsume native toolkitry, which it itself a mess. I think this is a fundamental flexibility problem, where the backends don
16:57:07
VincentVega
Toolkitry, of course. But due to the ambition, the effect ripples down the consuming system, e.g. callbacks jackdaniel just mentioned. But I give an example of that in the article.
16:59:28
jackdaniel
I think that backend can customize plenty of things, especially because a backend may define both the port and the frame manager
16:59:59
jackdaniel
(including core abstractions that is), but I'll comment more after reading the thing
17:03:27
VincentVega
Sure, it can. What I refer to is mostly the problem of CLOS, where you can't add/remove slots/beaviours of the existing objects/classes at runtime, dynamically. I think CLOS is the biggest downside of CLIM, for many aspects.
17:08:04
VincentVega
Or, you know, screw that review, if you want to see where I am coming from, just read the Fern section here:
17:09:16
nij-
It's been many times. While I load a library that requires some dynamic lib, usually the program looks at the wrong place for *dylib files. https://bpa.st/RC4EE
17:10:02
nij-
I know where the dylib it wants is located. But I don't want to hack that specific library (in this case it's cl-lib). Is there a better way to tell my lisp about the default dirs to look for dylibs?
17:14:03
nij-
In the manual of CFFI (https://cffi.common-lisp.dev/manual/html_node/Tutorial_002dLoading.html#Tutorial_002dLoading), there doesn't seem to be a way to assign load path for it.
18:43:57
jackdaniel
VincentVega: I agree with remarks about poor humor (which is mine:) and that clim is quite complex and hard to bite (partially because it tries to cover a big scope going beyond guis)
18:45:23
jackdaniel
for example when you criticize output records and say that they duplicate what a tree widget would do, you miss the fact that output records create such a tree - easily composable at that
18:46:09
jackdaniel
and when you criticize inks, you completely miss the concept of an indirect ink which achives precisely what you ask for
18:48:35
VincentVega
I wasn't talking a "tree widget", though, but a tree of widgets. And my point is precisely that you don't need the second tree, you don't need to generate it. One tree is enough.
18:48:58
nij-
pjb Thanks! cffi:*FOREIGN-LIBRARY-DIRECTORIES* cffi:*DARWIN-FRAMEWORK-DIRECTORIES* were indeed the things to look at.
18:50:54
jackdaniel
I know that you mean a tree of widgets. I'm saying that a tree of output records is not a duplicate, it realizes the concept of a tree of objects (at a more composable level), I don't see how that's a duplication
18:53:48
VincentVega
Then I don't see why you have to have a concept of capture and output records in the first place, if all they are but the augmentations of the tree node they belong to. You see, my problem is with the homogeneity and with the seperation of concepts, where I see no good reason for it to be there. It's kind of the same problem with panes/vs/widgets/vs/application-pane. I just don't get why you need that many concepts to represent one
18:56:16
jackdaniel
application frame represents the state of the application, it ties together the model, its semantics and visual representation (i.e a tree of panes), the application frame may live even when it is not an interactive object on a screen
18:56:39
jackdaniel
as of gadgets, they are specialized version of panes - all "clim" windows are panes
18:57:10
nij-
It launch a process `cc ..` without including the paths from either cffi:*FOREIGN-LIBRARY-DIRECTORIES* or another.
18:58:07
nij-
According to the call stack, the error happens when calling #'process-grovel-file, which is not documented in the manual. https://cffi.common-lisp.dev/manual/cffi-manual.html
18:58:12
VincentVega
That implies that a tree node may not live even when it's not an interactive object on the screen.
18:58:12
jackdaniel
and regarding capturing output - it is captured to construct a tree of objects inside a specialized version of panes - to allow pointer sensitivity, object identity (presentations) and generally to construct a tree of objects inside a pane
18:59:53
VincentVega
So, why can't a tree node have pointer sensitivity, object identity? Can't the programmer construct that tree by himself and attach it to the current node?
19:00:54
jackdaniel
practically you have layout panes (to organized sub-windows), gadget panes that have states like armed, active, disabled etc and stream panes - general purpose clim abstractions
19:01:21
jackdaniel
gadgets are provided to allow people used to "traditional" toolkits write applications the way they are used to
19:01:45
jackdaniel
output record hierarchy is the abstraction that constructs such tree, that's precisely my point
19:01:58
jackdaniel
and yes, you may create your own output record hierarchy without capturing any output
19:03:01
jackdaniel
and replaying your not-drawn-tree will produce a graphical result as you desire (via replay-output-record), with pointer sensitivity, highlighting and all that jazz. you may call it a widget tree if you like really
19:05:01
VincentVega
Well, you see, in all these I see an overabundance of concepts which do similar things, but which don't need to have seperate names, or be differentiated. I don't know how else to put it. And the reason I am criticizing it, and the reason why you say it needs to be that way, is because of CLOS, which forces you into this type of seperation decisions. Do you see my point?
19:07:44
jackdaniel
I don't, sorry. CLIM has its own issues, but I don't think that they are "because of CLOS"
19:07:52
VincentVega
E.g. from a draw method, you can't just create two branchings in your node: you can't just put two new slots.
19:09:31
jackdaniel
well, if you are so certain of it then there is no point in arguing. sure, we are building a tree
19:13:58
VincentVega
Because it can be very convenient for graphical applications, because if you can do that, you don't need to have 3 different concepts for what's just an object in a tree of objects.
19:14:33
jackdaniel
as I see it a tree in clos terms could be simplistically defined as (defclass node () (parent children))
19:15:04
VincentVega
yitzi: yes, and that's what I am going to be using, and that's what I argue is unavoidable in a GUI application
19:15:54
yitzi
VincentVega: Lot's of GUI applications don't use prototype OO, so the argument that is unavoidable is not true.
19:16:14
jackdaniel
that's fine, but I don't understand the grudge with clos in this context; doing it with prototypes may be fun - why not, I'm trying to understand though why a dynamic tree in clim can't be done
19:16:27
VincentVega
yitzi: I mean lots of people use windows. If you are a power user who respects himself, using linux these days is unavoidable.
19:16:52
fluentpwn
Hello, is there a shorter way to index list by another list(i.e (? (1 2) (1 2 3 4)) -> (nth 1 (1 2 3 4)) (nth 2 (1 2 3 4))) than to just map?
19:16:53
jackdaniel
but you've clamied that clos forces something and makes something impossible, what that something was a tree
19:17:18
VincentVega
jackdaniel: Alright, but you did see my examples in the article, that are due to CLOS, right?
19:17:49
jackdaniel
I've read only the part about CLIM becasuse I've believed that I will be able to provide some constructive feedback
19:20:16
jackdaniel
you quote a 'guide tour to clim', but I don't see any examples (with counterexamples) of things that are not possible
19:20:16
yitzi
It is just my personal opinion...but prototype OO is hot mess. I've built large systems with both prototype OO and CLOS. Large prototype based systems usually end up becoming a shambling ball of spaghetti.
19:20:39
VincentVega
jackdaniel: My CLOS grudge isn't exactly about the ability to build a tree, but about the ability to have similar concepts with different names, which you then use to build a tree. My position is very simple: where you claim that gadget+pane+frame+output-record+representation are all a necessity, what I am saying is that you just need one concept: a tree object, and prototype OO lets you do that, but not CLOS
19:21:00
VincentVega
jackdaniel: I have quoted these exactly within the section, I have copypasted them.
19:21:22
VincentVega
mfiano: of course. You have to create a seperate class to use them. That's a problem.
19:21:50
jackdaniel
VincentVega: you may also use a list, that's even more uniform; I don't see the issue with naming different things differently
19:22:17
mfiano
But a tree is very typically represented as 2 slots - a reference to the parent node, and a collection (list, hash table, etc) of children nodes.
19:22:44
VincentVega
but you do see an issue with complexity? well that's what you get if you don't see a problem with giving 10 names to a variation of the same concept.
19:23:43
jackdaniel
I think that some of the complexity is intrinsic in gui systems and is not a result of being sloppy with names
19:25:39
VincentVega
mfiano: well, then you get prototype OO (or a very shallow version of it), which is what the argument is about
19:26:09
VincentVega
can you get a reasonable prototype OO system with CLOS? Maybe. BUt I haven't seen one.
19:26:10
jackdaniel
I see. either way my feedback ends here - I don't find your criticism of clim very insightful
19:27:41
VincentVega
mfiano: you are just going to say something is a disaster and just leave? That's evil.
19:28:39
paulapatience
I'm confused about the dynamic extent of streams bound in WITH-OPEN-FILE, WITH-OPEN-STREAM, WITH-INPUT-FROM-STRING and WITH-OUTPUT-TO-STRING.
19:28:40
paulapatience
CLHS says they have dynamic extent, and indeed SBCL gives dynamic extent to the stream in WITH-INPUT-FROM-STRING, but SBCL does not give dynamic extent to the stream in WITH-OPEN-FILE.
19:28:40
paulapatience
But supposing a STREAM-ERROR is signaled from within any of those forms, if you don't handle it before the stream's dynamic extent ends, then it should no longer be accessible via STREAM-ERROR-STREAM, no?
19:29:54
jackdaniel
the hang was out of the blue, so I don't think that a report would be any helpful
19:30:44
Shinmera
You can type cheats at any time, the cheat menu is just there to avoid accidentally pressing or activating other things while typing
19:35:45
Shinmera
It might be an input issue, we've seen other reports of that happening, but so far no indication of why or how to reproduce it.
19:36:42
jackdaniel
probably when someone plays too well the game gets confused - now wonder it is rarely reproducible ,)
19:43:25
jackdaniel
ah, and a log of already provided hints, because the first time I've missed the instructions ;p
19:44:12
jackdaniel
I did not see the control saying: "go to the safe point to save", but I'll read over the list again!
20:31:47
paulapatience
SB-KERNEL:ALLOCATE-CONDITION checks if the error is a STREAM-ERROR and further checks if the stream is stack allocated, and if it is (which in SBCL's case can be only for string input and output streams), makes a stub stream, with SB-IMPL::MAKE-STUB-STREAM, which contains enough information to report via STREAM-ERROR-STREAM.
20:31:47
paulapatience
I don't know what other implementations do, but I suppose it's only possibly a problem when dynamic-extent declarations actually do something.