freenode/#clim - IRC Chatlog
Search
9:21:57
scymtym
jackdaniel: looks good. one final thing: could you change the message of the new commit to something like "with-pointer-grabbed: remove unused macro" or something else that gives a reason for the removal
9:46:52
scymtym
right. shouldn't "ports: refactor port-grab-pointer protocol" and "pointer grab removal" happen in a single commit, then
11:18:55
scymtym
jackdaniel: i'm sorry that i didn't notice this earlier, but the description text in the demo should use (format … "…line ~<newline>…") instead of (format … "…line~<newline>…"). otherwise the first word of the next is fused with the last word of the previous line
15:41:05
ck_
I'd like to see this profiled so I can get a sense of whether I'm barking up the wrong tree: https://gist.github.com/kc-/7e83e1b80e86354c5523af2b6367700b
15:45:38
scymtym
ck_: does this look ok? https://gist.github.com/scymtym/d353afc63eed0200ceb97beb6806abcd
16:52:22
ck_
scymtym: can you in any way help me understand why there's 1352 calls to draw-design in your case, and the 'proper' amount of 676 in mine?
17:07:10
ck_
scymtym: scratch that, sorry :) (or mark it under "he doesn't understand how profiling works")
17:57:00
scymtym
ck_: i looked a bit. performance is terrible because XLIB:DRAWABLE-DEPTH called in COMPUTE-RGB-IMAGE makes a roundtrip through the server for every MEDIUM-DRAW-RECTANGLE
18:37:53
jackdaniel
in dnd-comented demo tracking pointer is not reentrant, you had a similar remark somewhere else
20:03:55
krwq
when defining presentation method, are new lines allowed in the output? I think they currently are not (at least it seems like newline character gets replaced with nothing or a space) - is this intentded?
20:06:15
krwq
also seperate question: when using display-function why do present method always has to be wrapped with (let ((*standard-output* stream)) ...)?
20:10:11
scymtym
krwq: i assume you are defining a PRESENT presentation method? you should definitely be able to write newlines to the stream. the newline may not enlarge the bounding region of the presentation if not followed by more output, though. can you share your code?
20:12:27
scymtym
krwq: (let ((*standard-output* stream)) …) should not be necessary. the stream is one of the parameters of the display function. you choose a name for that parameter and then FORMAT, PRINT, etc. to the stream using that name
20:13:08
krwq
scymtym: for question 1 https://pastebin.com/69Tdd5pZ only stuff with comment `;; FOO` is relevant
20:13:29
krwq
scymtym: I'm just playing with various tutorials, right now specifically with https://common-lisp.net/project/mcclim/static/documents/mcclim.pdf
20:15:06
krwq
scymtym: for Q2: Yes but if I use (present ...) then stream doesn't get propagated into the `define-presentation-method present` and basically nothing gets displayed unless I rebind *standard-output*
20:16:58
krwq
scymtym: perhaps present should take a stream or *standard-output* should be bound already when display-function is called
20:18:12
krwq
scymtym: I mean, I think it should work by default since I'm not trying to display elsewhere
20:23:23
krwq
scymtym: also if *standard-output* was already bound I could just (format t ..) instead of passing stream everywhere - I can't see other place I'd want to print or draw when I define display function
20:24:07
krwq
if I wanted the actual *standard-output* (i.e. slime's) then I can hack it quickly myself but most of the time I don't see why
20:27:57
scymtym
krwq: i would recommend calling PRESENT like (present object (presentation-type-of object) :stream stream). it's a bit verbose but it is the most robust solution
20:28:48
jackdaniel
alternatively define a function: (present* object stream) which expand to the above if verbosity bothers you
20:28:51
krwq
scymtym: makes sense but I still think *standard-output* should be bound with stream when display function is called
20:30:17
jackdaniel
you may define your own top-level loop which does something else, in this case binding it that way should work just fine
20:30:46
krwq
jackdaniel: so *standard-output* by default will print to the first pane when display function of second pane is caled? That doesn't make any sense to me even if spec says so
20:31:25
jackdaniel
it does make sense if you think about the first application pane as the standard output and others as some helperf panes
20:32:03
krwq
jackdaniel: but all tutorials show last pane as the standard output so that still doesn't make any sense
20:33:03
krwq
jackdaniel: if it's basically bound to random pane then at that moment I'm not sure why is it bound at all
20:33:26
jackdaniel
it is not a random pane, it is a well defined pane, first application pane defined in the :panes list
20:33:31
scymtym
krwq: you can also bind special variables in the function lambda list as in (defun display (frame *standard-output*))
20:36:53
jackdaniel
wouldn't that be more random? :) I get that you don't like these defaults, but they do make sense from a frame perspective: to have one standard-output and one standard-input
20:37:24
jackdaniel
we have enough broken stuff to chase things which are not broken (and very arguably not right)
20:37:29
krwq
jackdaniel: I understand if that was configurable and first was a default but 'first' pane is random
20:37:43
scymtym
krwq: consider the new inspector which looks like this: https://github.com/scymtym/McCLIM/blob/merge-new-inspector/Documentation/Manual/Texinfo/figures/clouseau-window-screenshot.png . it has two layouts, one of which hides the interactor pane. i can still write to *standard-output* at all times. depending on the current layout the output appears in the interactor pane or the content pane. doesn't that seem useful to you?
20:40:03
jackdaniel
heck, you may define display as a generic function and bind *standard-output* from around method
20:40:26
krwq
I'd prefer the tutorials to be constructed so that it's harder to shoot yourself in the foot
20:41:32
krwq
scymtym: right now page 21: https://common-lisp.net/project/mcclim/static/documents/mcclim.pdf
20:41:50
krwq
scymtym: I prefer to stop on the tutorial and play around with stuff a bit before I keep going though
20:43:02
krwq
scymtym: and basically most of the stuff doesn't work on my first try which is kinda disappointing - I keep on having to reference previous stuff otherwise I keep on hitting weird stuff like above
20:43:38
jackdaniel
don't you think that deviating from the specification would only confuse you more because you'd have no definite resource to check things up?
20:45:10
jackdaniel
being sarcastic when I try to honestly answer your concerns is not helpful. my point is that we have to stick to something and fact that your intuition does not match the behavior is unfortunate, but understandable. it is similar when you learn anything new
20:45:57
jackdaniel
consider the moment when you have started playing with common lisp and all these dynamic interactive programming - "why can't I just compile it and run like a c program?" - you can of course, but you lose a lot and it is not a usual workflow
20:46:18
scymtym
well, the tutorial can be improved. but voicing disappointment and sarcasm won't make that happen
20:46:21
krwq
jackdaniel: I guess - just pointing out that there is a lot of stuff which newbies like myself find difficult to understand and they won't touch spec unless they got basics intuitive enough
20:46:57
jackdaniel
maybe the first tutorial should be arranged around a single (:pane :application) setting
20:47:56
krwq
jackdaniel: I'd find that much easier I think - I'd stick to buttons and simple forms with tutorial and presentations perhaps for later
20:48:02
scymtym
maybe the tutorial could just mention that T means *STANDARD-OUTPUT* and explain to which pane that variable is bound
20:48:34
jackdaniel
krwq: that would be counterproductive. while CLIM does feature "buttons and simple forms" they are just an afterthought in the system.