libera/#commonlisp - IRC Chatlog
Search
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.