freenode/#lisp - IRC Chatlog
Search
5:01:11
hjek
sunshavi: no gtk in mcclim. i think it's pure X. but also there is supposedly a Cocoa back end for OS X
5:30:09
sunshavi
i have done a couple of tutorials on CommonQt. a simple frame with just a title, and a frame with three widgets label, text, button
5:38:19
jackdaniel
but you may load clim-examples, go to drawing examples and you'll have a button to generate from drawings ps / pdf
6:57:34
beach
sunshavi: And, was it compiled with threads enabled? (I am just guessing here. Normally, those examples work)
7:16:20
hjek
jackdaniel: application-frame could make sense in postscript though. https://en.wikipedia.org/wiki/Display_PostScript
7:18:54
beach
sunshavi: I am way outside my comfort zone here, but you could check whether :sb-thread is a member of the *features* list.
7:21:12
beach
hjek: A typical application for the PostScript backend (and for the PDF backend as well) would be if you have something like Gsharp (and editor for music scores). The saved PostScript document should then be a printed version of the score. The document should not contain the buttons, the interactor pane, the scroll bars, etc.
7:32:33
beach
Ukari: You export whatever names you want to use from a different package, whether they be the name of the struct, the accessors, the constructors, whatever.
7:34:24
beach
sunshavi: Check with jackdaniel first. He is the maintainer of ECL, and of McCLIM, so he would know whether that is good advice or not.
7:35:18
Ukari
i defstruct a (defstruct iterable-object (value nil) (next nil :type function)), and export by (:export #:make-iterable-object #:iterable-object-next #:iterable-object-value)
7:36:07
beach
Ukari: The Common Lisp implementation can not decide for you what functionality you want to make available to client code.
7:37:20
beach
Ukari: Like I told you, in a typical application you definitely do not want to export the names of the accessors of all the slots. That would be contrary to good software-engineering practice. And, again, the Common Lisp implementation can not decide what kind of protocol you want to suggest to client code.
7:38:12
beach
Ukari: If it so happens that you are not applying any particular modularity concerns in this case, then unfortunately, you are the exception, and you then need to export everything.
7:40:32
fourier
about having to write a lot of manual "exports" for automatically generated functions
7:42:12
beach
fourier: Only in applications that do not respect the slightest software-engineering technique would one want to export the names of all the accessors, and even less so of the slot names.
7:42:17
fourier
yes it makes sense. "I want to export all readers of this class/struct" - it is the applied modularity.
7:42:34
beach
fourier: Common Lisp was not made for people that have absolutely no concern for basic modularity.
7:43:19
beach
fourier: If you find yourself wanting to export the names of all the readers of some class, then there is very likely something wrong with your abstraction.
7:46:15
beach
There could *occasionally* be a need for that, but not often. Therefore, having to export everything is an exceptional situation. For exceptional situations, you then have to deal with the additional work of manually exporting everything. It would not make sense to have a special mechanism in the language for that, because it is, well, exceptional.
7:46:45
fourier
you put it to separate package to avoid name collisions for trivial accessors like "name" "age" etc
7:49:45
beach
Of course. But if the struct is only used as an aggregation of stuff, it would typically be in the same package as the client code. The package boundary is more likely used to define an abstract protocol that is not concerned with how things are stored.
7:50:32
beach
And, again, because they are exceptional, there is no need for a specific mechanism for exporting everything.
7:51:11
beach
So, again, yes, you would then have to manually include all the names in the package definition. Big deal.
7:58:07
Ukari
beach's option is acceptable if treat defstruct into constructors-function and slot-function. but if treat defstruct as static defination of a struct and it need to be use somewhere just like class in java or struct in c header, i thought defstruct should be more combined than spearated into divided functions
8:04:40
puchacz
hi, can salza2:deflate-compressor be passed an argument so it uses "no compression"?
8:05:35
puchacz
I want to let a user download a bunch of media files bundled together, and they are compressed already, so there is no point of wasting CPU (if there is any significant waste) on trying to compress them
8:11:30
Ukari
i use '(make-iterable-object :value nil :next nil)' with the defination '(defstruct iterable-object (value nil) (next nil :type function))', but it tells me :next is a function type and couldn't be nil
8:19:04
Ukari
if there is a system foo, with some packages syntax, util, which naming style is suitable. 'cl-foo-syntax, cl-foo-util' or 'cl-foo.syntax, cl-foo.util'
9:16:47
jackdaniel
on the other hand I will be able to debug problems on McCLIM <-> ECL line (because I know both considerably well)
16:49:02
Ukari
is cl-cont open source? i meet a wired warning which seems to tell that a argument's type is different from declared in cl-cont::lookup
16:49:26
Ukari
the message: "Derived type of CL-CONT::LOOKUP is (VALUES CONS &OPTIONAL), conflicting with its asserted type (OR FUNCTION SYMBOL)"