freenode/#clim - IRC Chatlog
Search
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.
20:50:09
jackdaniel
if you look for "traditional" toolkits like this I think that ltk is better suited, I've written a few projects in it and it matches the common gui practices
20:50:37
jackdaniel
writing tutorial in clim which does not teach clim doesn't sound very useful. either way, once again, good night
20:50:51
krwq
jackdaniel: I do want to use presentations and all stuff clim provides but it's easier to start with something which I know how it works vs something completely new not found in other toolkits
20:54:27
krwq
it's not only about what I can do with stuff, it's also about how quickly I can productively use clim
20:55:51
krwq
so file selection, button, message box (or some other alernative solution) etc would be a better start than presentations and other stuff which I don't know what to do with until I read it all
20:57:30
scymtym
i think a tutorial focusing on such things would put newcomers on a suboptimal trajectory
21:00:04
krwq
I just don't particularly find text based list with `*` showing current element controllable with manually typed commands too appealing
21:00:34
krwq
also the commands for some reason don't match the names I've used, they just somehow got some magically generated nicer names
21:02:42
krwq
I get that it probably might be better path if you want to become an expert but I don't think it's best example for newbies
21:02:53
scymtym
if you command name is com-do-something, the user will see "Do Something" unless you supply a name with the :name option
21:04:05
krwq
scymtym: https://common-lisp.net/project/mcclim/static/documents/mcclim.pdf page 18 of pdf (or page 13 printed in the right top corner)
21:04:07
scymtym
:name nil -> not invocable by name, :name t -> invocable via auto generated name, :name STRING -> invocable via STRING
21:04:49
krwq
scymtym: when I C-c C-d C-d on the define-superapp-command I don't see any doc so it's not particularly easy to know what to even search for in the spec
21:05:27
krwq
scymtym: might be worth to either improve this or at least show newbies how to use the spec with macros generating macros
21:06:53
scymtym
the alternative would be (clim:define-command (com-foo :name WHATEVER :command-table superapp) …)
21:09:25
krwq
also this part of the tutorial is WTF: (format *standard-input* "~a" argument) - no clue how that even works
21:16:13
scymtym
no, if the value of *standard-input* is an interactor-pane, it is a bidirectional stream
21:17:14
krwq
scymtym: can you instead write to *standard-output* then? If it's bi-directional then presumably it will be bound to the same value?
21:17:59
scymtym
you can write to *STANDARD-OUTPUT*, but as we discussed earlier, that is bound according to a different rule: http://bauhh.dyndns.org:8000/clim-spec/28-3.html#_1496
21:18:49
scymtym
if your frame has an application-pane and an interactor-pane, *STANDARD-OUTPUT* is bound to the former, *STANDARD-INPUT* is bound to the latter (by default, you can customize this)
21:20:27
krwq
scymtym: makes sense after you explained it but when I read the tutorial I was scratching my head when I saw that and eventually I just kept going hoping it will be explained
21:26:52
scymtym
krwq: mostly by looking at the example, i think. i don't remember exactly. but i wasn't in a hurry
21:28:00
krwq
I'm having motivational issues because I came for "UI which works everywhere and is easy to plug in everywhere" and so far cannot make any UI which is reasonably easy to use (i.e. like menus where I need to hold the mouse button etc: yes I know fix is pending but still)
21:29:21
krwq
scymtym: fortunatelly I'm not super in a hurry but will be disappointed if I spend longer period of time and won't be able to plug that into the website
21:31:08
scymtym
i see. gtk has the same capability, is a traditional toolkit and has CL bindings. maybe that would be a better fit?
21:31:10
krwq
scymtym: that's my end goal - just want to write UI which works natively in the browser - but not meant for being public (so basically ignore all security problems)
21:31:50
krwq
scymtym: for now I'm fine with native GUI but ultimately I'd like the HTML to be generated
21:32:14
scymtym
in-browser clim will not involve any web frameworks. it will server a single static HTML file and a bit of javascript once, then only talk trough a websocket
21:32:26
krwq
scymtym: btw is there a way to pass pane size (or :geometry) as :max or something? I work with stumpwm and don't necessarily want to pass size all the time
21:34:53
krwq
scymtym: when I work with stumpwm it currently shows for a second as 640x480 and then after a second it auto-resizes correctly
21:36:01
krwq
scymtym: basically what I want is to be able to pass (:geometry :width :max :height :max) in my app instead (:geometry :width 640 :height 480)
21:40:36
krwq
scymtym: actually that would be a cool tutorial to explain how to even write such extension
21:42:30
krwq
scymtym: will need to create github account for that as my employer is not supper happy with me doing non work related stuff on github
21:47:15
krwq
scymtym: I'd prefer that - thank you! I'm trying to recall credentials for the account I made specifically for this purpose long time ago
22:02:20
krwq
scymtym: whichever will do - sounds pretty cool, any chance you could share how that extensibility model works?
22:04:47
krwq
basically if you have any diff or code I can add to my app to have that I'll be happier
22:05:11
scymtym
that just means the function is not in the CLIM standard. i gave you the full name so you can look at it
22:08:57
scymtym
you could add (:geometry :width (clim:graft-width (clim:find-graft)) :height (clim:graft-height (clim:find-graft))) to your application frame definition
22:09:50
krwq
scymtym: way simpler - when you said extension I was thinking that you will need to provide implementation specific way of getting that value first
22:15:43
krwq
scymtym: I see, I think that makes it way more usabe. Btw I think the current version is the easiest to use and perhaps the version with units would work too but :max makes most sense - :maximum would be a bit too verbose IMO for no good reason
22:19:12
krwq
scymtym: everything works as intended. Btw for my first question about the newline character not showing up
22:20:19
krwq
scymtym: so should the bounding region be extended automatically or not? Even when it's not extended it should still be showing up in the example I gavew
22:22:23
scymtym
i think the bounding rectangle of the presentation only includes actual, visible output. but i'm not sure
22:22:54
krwq
scymtym: that makes sense, but what doesn't is that output is currently showing as numbers in one line space separated
22:23:28
krwq
I can see how "~%" can be a bit ambigious or opinionated on how it should behave though
22:24:40
krwq
scymtym: one way or another though I think the new line should be there - unless spec explains this in some more details then I'm interested in the reading
22:24:44
scymtym
change the final command definition to (define-views-command (com-show-person :name t) ((person 'person :gesture :select)) …) to make person presentations clickable
22:29:48
scymtym
the one on page 23 of https://common-lisp.net/project/mcclim/static/documents/mcclim.pdf
22:38:13
krwq
scymtym: the question is not about incremental display - I extended that code so that numbers are presentations of integers
22:39:28
krwq
and was expecting enters to be visible but presentations spanning across the line but saw one liner with all numbers and ~% being ignored for some reason
22:46:42
krwq
scymtym: also prevents people from giving me answers 7h after I already figured out an issue and forgot about it
22:57:41
scymtym
you can do (define-presentation-type my-integer) and use that in the method definition and the PRESENT call
23:08:00
scymtym
did you write (define-presentation-TYPE my-integer ()) and not (define-presentation-METHOD my-integer ())?
23:09:54
scymtym
(define-presentation-method my-integer (object (type integer)) …) -> (define-presentation-method present (object (type my-integer)) …)
23:11:22
scymtym
your example already has PRESENT presentation methods. copy of those but change the specializer of the TYPE parameter to MY-INTEGER
23:12:33
scymtym
did you change (present (car current-element)) -> (present (car current-element) 'my-integer)?
23:21:57
krwq
Per http://www.jucs.org/jucs_14_20/an_implementation_of_clim/jucs_14_20_3358_3369_moore.pdf I should use (defmethod presentation-type-of ((object integer)) 'integer) ?
23:24:13
krwq
nvm, just don't know how can I make my-integer be accepted from places which ask for 'integer
23:31:43
krwq
scymtym: ok works, there is only an issue that the integer is displayed weirdly in the input field
23:32:29
krwq
so presumably 1 arg will need to be specified more in the method - I'll try to figure it out myself