freenode/#clim - IRC Chatlog
Search
11:07:02
scymtym
jackdaniel: the symbols related to output destinations are already exported from climb. the questions is which system should contain the code. mcclim-backend-common?
11:34:16
jackdaniel
yes, the goal is to make backends use only exported symbols (I.e without knowledge about climi package)
11:37:59
jackdaniel
mcclim-backend-common is wrong place because clim-core needs this mechanism as well
11:38:49
scymtym
from my point of view we need separate modules for 1) the backend protocol 2) code shared between backends
11:41:30
scymtym
command output destinations have two parts: 1) backend machinery 2) "user interface" in terms ACCEPT methods and whatnot
11:44:19
scymtym
also, a thing that backends implement is the definition of the backend protocol, no?
11:44:24
frgo
Hi everybody. Question to jackdaniel: Which CLX repo should I use as a base for a PR re AllegroCL ?
11:46:47
jackdaniel
hm, if output-records implement region protocol, does it mean that region protocol is output recording protocol?
11:48:30
jackdaniel
either way since it is something implemented by backend writer (i.e registering output dest) I guess you could call it backend protocol too
11:49:27
jackdaniel
my point is that this protocol on its own is not backend-specific so it should be put in clim-basic, not in backend-commons
11:50:13
jackdaniel
puting it in clim-core makes semse, yet it introduces unwanted dependency, hence my suggestion
11:51:58
scymtym
i agree that clim-core is a bad place, but i think there should be a layer (and module) "below" clim-basic that contains the backend protocol
12:03:33
jackdaniel
as I see things clim-basic was extracted as such layer "below" and contains things which are necessary for backends (minus frame-manager protocol)
12:04:33
jackdaniel
sheets are clearly needed (because that's our "window" abstraction), hence geometry. events, ports, mediums are obviously part of backend protocol.
12:05:28
jackdaniel
that leaves us with stream-input and stream-output, and they could be moved to clim-core, although we could "fix" them and make them independent wrappers over sheets for stream access (that's what I'm working on in the other PR)
12:06:44
jackdaniel
text-formatting could be moved to clim-core too, encapsulate is part of streams, so if stream-input/output go it goes with them
12:06:46
scymtym
i didn't attempt this separation practically, but it seems to me that basic currently contains things below, on and above the backend layer
12:07:42
jackdaniel
in my understanding more than 80% of clim basic the layer below you are talking about, the rest could be moved to clim-core
12:11:27
scymtym
pulling independent things likes regions out of clim-basic seems very good to me and i would like to see that for backends as well
12:11:38
jackdaniel
looking at the files now, views clearly should be moved to core; stream-*, dead-keys, encapsulation and text-formatting could be moved and then we have pointer-tracking which imho should stay
12:12:12
jackdaniel
notice, that both decls and protocol-classes does not introduce much over the general relation information between modules in a whole system
12:13:05
jackdaniel
I don't think that it is a problem (i.e region inherits from design protocol-wise and indeed design is a generalisation of region idea; it may be a bad example because they both belong to clim-basic)
12:13:24
scymtym
ideally, basic and core could go away after introducing coherent, finer-grained modules
12:13:51
jackdaniel
having protocol-classes shared between modules gives us a possibility to pull in geometry module without pulling in design module
12:15:05
jackdaniel
generally I agree about the separation, we seem to disagree about /some/ details
12:16:17
scymtym
it may be necessary to define all protocol classes early, that's true. but i see that as a technical limitation of the protocol-class approach rather than saying much about the module structure
12:17:47
jackdaniel
I find it very useful with regard to seeing, which classes /should/ implement what protocols (and what is a conceptual correspondence between them)
12:18:22
jackdaniel
i.e line is a degenerated bezier-curve, so there is no reason why it should not implement bezier-curve protocol (or, polyline protocol)
12:19:00
jackdaniel
and having line inherit from both polyline and bezier-curve gives a clear clue what you could do with lines. but that's irrelevant now\
12:20:31
scymtym
so, going back to the pull request, what should i do for now while we still have the current module structure?
12:21:40
jackdaniel
I'd put the invoke-with-standard-output in Core/clim-basic/stream-output.lisp (because it is a stream abstraction) and export methods necessary for backend registering its own output from climb package
12:22:42
scymtym
i haven't tried whether it works out technically, but seems like the best solution to attempt for now
12:23:30
jackdaniel
great; I need to get back to errands now so I'll probably answer asynchronously if something comes up
12:38:46
frgo
jackdaniel: Need your recommendation on this: With AllegroCL 10.1 the macro without-interrupts is deprecated. For all usages I need to introduce #+ conditionals - or, als an alternative, I could make a macro clx-without-interrupts somewhere and have that be dependent on AllegroCL version plus replacing all occurances of without-interrupt bz clx-without-interrupt. What do you think?
12:41:07
jackdaniel
frgo: how about: #+allegro-with-without-interrputs (defmacro without-interrupts (&body body) `(acl:without-interrupts ,@body)) #-allegro-without-without-interrupts(see-what-sbcl-does-in-dependent.lisp)
12:47:26
scymtym
jackdaniel: i just found another problem for loading basic without loading core: text-selection is in basic but uses the command machinery
13:12:37
jackdaniel
text-selection in basic is about putting markings. it calls publish-selection which is defined in Backends/common/ports.lisp which implements the selection protocol (as in copy/paste) which in turn depends on presentation-translator machinery (so indeed clim-basic has a dependency on a module which depends on core and the problem is real); function publish-selection does not call things in core module
13:14:24
jackdaniel
that makes a good case that the text-selection protocol should be move to core; then maybe standard-output-stream should not depend on text-selection-mixin in favor of clim-stream-pane depending on it
18:21:11
ck_
jackdaniel: ok. I don't understand the name change request: the function doesn't 'ensure' the value. It buffers or caches it.
18:22:27
jackdaniel
as I understand ensure-* convention it is to query the value unless it is memoized (like i.e ensure-gethash), but if you feel that the new name would be worse then leave it as is
18:23:02
ck_
I simply wasn't aware of any such convention, and was going by name alone. Is there some documentation I can look up?
18:25:07
ck_
There's ensure-generic-function in the spec, but that doesn't quite behave as this drawable-depth thing behaves. ensure-generic-function ensures that the argument becomes a globally named function. (ensure-drawable-depth drawable) would do no such thing.
18:30:46
ck_
jackdaniel: thanks for including the history in the clx pull request. Let's hope it saves someone some time, sometime in the future
19:37:42
frgo
jackdaniel: I commented on your remarks. I will commit some changes based on your comments. The def-clx-class macro issue is a mystery to me.
19:53:56
jackdaniel
frgo: I'll look into the def-clx-class thing tomorrow and we will compare notes, hm?
21:01:25
jackdaniel
frgo: it seems that the issue is already grokked: it is because allegro uses defclass not defstruct. I still think that either both options should be removed from the def-clx-class for all implementations or extension should simply use defstruct
21:02:24
jackdaniel
from the bright side changing it in this single place to defstruct should not impose any problem