freenode/#clim - IRC Chatlog
Search
9:30:07
ikrabbe
Good morning, today I found a strange behaviour: I wrote a present function for some type. That present function simply prints the object in bold type. Now, in the listener it tries to present the object, but the stream (some drei editor thing) is a string-output-stream, but no extended one, that can be styled in any way, so it breaks. Is that intended?
9:38:06
beach
That sounds strange. I mean, the listener can display any object including graphics. Are you sure you presented it to the right stream.
9:39:11
beach
I can believe that the stream associated with Drei is a string input stream, but I can't see how that would be the stream that the listener uses to display things.
9:48:47
lukego
This is looking like a pleasant day of CLIM'ery for me :-). That's assuming CLIM is the tool for the job I have in mind, which is to use drawing operations like draw-rectangle/with-translation/with-scaling, and output not actual graphics but rather geometry information such as the list of drawn rectangles/polygons with their absolute positions. Am I on the right track? Use output recording and inspect the output records?
9:51:45
beach
I can't think of any. But there are two variables that control drawing and recording. If you set them to NIL and T respectively, you should get the desired effect.
9:52:21
beach
And the stream has an output history which is the root of the tree that contains the output records.
9:52:43
lukego
Is there an easy way to do this such that it doesn't need e.g. X11? (I mean since I don't need to render graphics anywhere but only do the geometry operationS)
9:56:20
ikrabbe
beach, I found that error, in the present method for my type, which changes text-styles. I now have a type switch for the stream that is given to the present function. Possibly I should try to trace it.
9:57:09
beach
Because I just tried in the listener to do (with-text-style (*standard-output* (make-text-style nil :bold nil)) (format t "hello"))
9:57:11
lukego
Thanks. I see also that with-output-recording-options seems to let you say if you want to actually draw or not. I'll dig a bit.
9:57:40
ikrabbe
But with the type switch the record now displays without text-styles in the listener window
9:58:23
beach
The "listener window" is *standard-output* and, my test shows that it can display bold text.
9:59:00
ikrabbe
I will try to choose the text styles from *standard-output* and not from the stream given to the present function, but still this sounds like the start of a bug report.
10:21:05
lukego
Sorry to be dense but is there an easy way, e.g. at the listener, to get an output record representing a draw-rectangle* call? I'm trying stuff but it's erroring e.g. (with-recording-options (t :draw nil :record t) (draw-rectangle* t 0 0 1 1)) errors probably because the latter t should be something else..?
10:28:03
lukego
yeah I'm reading through the docs but I don't get how to create/acquire a suitable medium
10:29:30
lukego
Is the sheet something that I create, or something that already exists that I need to reference, or is that a very context-dependent question? Just now I'm working in the clim listener but ideally I'd be typing expressions into Emacs and seeing results in CLIM instead
10:32:59
lukego
I'm having a hard time because the streams/sheets/etc are being created somewhere deep in CLIM via e.g. run-frame-top-level so I don't really understand e.g. how I could create a throw-away dummy one for these purposes
10:33:05
jackdaniel
lukego: writing to clim stream from the emacs repl is very likely to break - you access stream output history from outside its thread
10:34:08
lukego
so is that idea that I should "live" in the clim listener while experimenting with clim?
10:34:33
jackdaniel
not necessarily, you may execute commands on other application frames (and that is thread safe now)
10:34:48
jackdaniel
another option is to queue an event and handle it on the clim side (also thread safe)
10:35:59
jackdaniel
that said, if you want to implement thread-safe stream operations, I can provide some insight and an idea how that coould be done ;; I'm doing too many things right now to start that task though
10:36:11
lukego
I'm not sure if that's what I want... I don't actually want any graphics at all, I just want to call e.g. draw-rectangle* and get an output record to extract geometry data from. I'm using the listener because that seems like the easiest way to get a medium to draw on
10:37:14
lukego
I did replace t with *standard-output* above ^^ which got rid of the error but didn't actually give me an output record
10:37:22
jackdaniel
alternatives are using the render port, or (even better) the null port; but they are less tested
10:37:33
jackdaniel
if you just want to get the output record, you want to use (with-new-output-record …)
10:38:27
jackdaniel
I have (somewhere) a hack where I've created a *null-stream* that works with with-new-output-record
10:39:19
jackdaniel
ikrabbe: with interactive streams (like drei) it is important to have the text-view specialization that works only with text (for sake of parsing/unparsing results)
10:39:47
jackdaniel
so the easy way out for you would be defining two present methods: one specialized on (view text-view), and second not specialized on it (or specialized on some other view)
10:40:39
jackdaniel
example of interactive stream present use: autocompletion after tab -- if you put there arbitrary output, you could have a command line filled with circles, not really something you could rescan (as in parsing)
10:41:04
jackdaniel
perhaps that would make a nice extension, but I hope that gives you an intuition why it is required to be a string
10:58:16
jackdaniel
(let ((clim:*default-server-path* :null)) (defparameter *stream* (clim:open-window-stream)))
11:00:27
lukego
I really appreciate this. I have a problem where I really don't have a "global" view of CLIM and can get lost on really basic things. Helps immensely to have an example to start from
11:01:22
lukego
This seems to immediately DWIM with with-translation/with-scaling too i.e. the output record contains the final transformed coordinates
11:02:06
jackdaniel
but since it is a null medium, you may have problems if you probe i.e a bounding rectangle of a text output record
11:02:42
jackdaniel
mind, that this is not thread safe either, but since null backend does not generate any events - the "proper" thread doesn't do anything
11:03:05
jackdaniel
so there is no risk of a race condition unless you start multiple threads accessing the stream yourself
11:04:05
jackdaniel
probably a cleaner soultion would be creating an instance of the standard-output-recording-stream and use that as the macro argument, but I haven't tested it
11:12:00
lukego
re: thread-safety, would a simple hack be to just inject a closure into a clim thread to do anything clim-related?
11:12:36
jackdaniel
yes, that's the gist of the solution I have in mind. send a continuation wrapped in an event
11:12:40
lukego
IIRC that's how Java finally resolved their thread safety problems in Swing i.e. just decided that one thread has to own the whole GUI because otherwise it's a nightmare
11:13:52
lukego
*nod* don't let me distract you. hopefully I can help out a bit with stuff if I get my own CLIM application in the air