kevingal_ has quit [Remote host closed the connection]
nature has quit [Ping timeout: 256 seconds]
triffid has quit [Remote host closed the connection]
Guest491241242 has quit [Quit: Client closed]
orestarod has quit [Ping timeout: 256 seconds]
random-nick has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
<dbotton>
Guest74 CLOG uses change-class as part of object factories all the time, it is my favorite feature of CLOS. Example in builder you design your "panel" (a div used as a container), the code generated creates a DIV, adds your content, then specializes it using change-class to the user defined class and attaches the slots to whatever controls you have assigned names for.
* moon-child
puts up smalltalk posters
<moon-child>
'If you liked CHANGE-CLASS, you'll _love_ become:!'
<dbotton>
become:?
<dbotton>
looked up, I think change-class more powerful
<dbotton>
and less dangerous
s-liao has quit [Ping timeout: 256 seconds]
zachel has joined #commonlisp
jealousmonk has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
morganw has quit [Remote host closed the connection]
s-liao has joined #commonlisp
<jcowan>
White_Flame: ABCL boxes fixnums, but it also preallocates a few: {-1, 0, 1, 2, 3}.
pranavats has joined #commonlisp
waleee has quit [Ping timeout: 260 seconds]
eugercek has joined #commonlisp
Catie has quit [Remote host closed the connection]
Catie has joined #commonlisp
orestarod has joined #commonlisp
eugercek has quit [Ping timeout: 272 seconds]
raeda_ has joined #commonlisp
orestarod has quit [Ping timeout: 250 seconds]
raeda has quit [Ping timeout: 256 seconds]
<dbotton>
A method when called executes with the namespace of the package it was defined in or the one that it is active when called?
<White_Flame>
jcowan: yeah I was going to say before in the conversation that singleton values are equivalent to immediate values
<dbotton>
sorry macro
<White_Flame>
when it's called
<White_Flame>
then *package* is the same as whoever called it
<White_Flame>
just like functions & special vars, too ;)
<White_Flame>
now, when the macro is _read_, its symbols are going to be in its file's in-package
<White_Flame>
when the macro body executes, and runs things like INTERN, then it is coming from its caller
<dbotton>
got it
pranavats has left #commonlisp [Error from remote client]
<dbotton>
so I can call a method defined in one package that receives an object and a slot name as a string, have it call a macro that will use intern on slot name and then set the slot-value and the intern will be in the callers package
<moon-child>
yes
<moon-child>
I did that once
<moon-child>
people don't like it, but
zachel has quit [Quit: Quit: Leaving!]
pranavats has joined #commonlisp
zachel has joined #commonlisp
<dbotton>
it seems to be smarter that using MOP
<dbotton>
to spend time doing introspection to get the symbol etc
<dbotton>
like this I can also use the accessor
Krystof has quit [Ping timeout: 252 seconds]
<dbotton>
and so trigger :before and :after
<dbotton>
so seems much smarter
<dbotton>
although just realized based on what white_flame said, that namespace when calling even a function and I assume method same, is the callers
<dbotton>
so maybe don't need the macro
<dbotton>
OO in lisp not encapsulating the namespaces with the object is a negative for clos
pranavats has left #commonlisp [Error from remote client]
azimut has quit [Remote host closed the connection]
<beach>
dbotton: On the contrary, the fact that encapsulation is orthogonal to object representation makes CLOS much more flexible. It is possible that this confusion in traditional object-oriented languages is what makes those programs so much more complicated for not much functionality.
azimut has joined #commonlisp
<beach>
dbotton: Encapsulation is the business of the package system in CLOS.
<dbotton>
Have use Ada since 95 which is same boat it is more of a hindrance than a help
<jcowan>
beach: I can't agree there. :: means that packages don't actually encapsulate anything.
<beach>
jcowan: Of course.
<moon-child>
jcowan: it is not strong encapsulation
<moon-child>
but it is still encapsulation
<jcowan>
Mmmm.
<beach>
I mean "of course you can't agree with that".
<jcowan>
In any case, inheritance breaks encapsulation too.
<White_Flame>
the "real" hiding encapsulation is closures :-P
<jcowan>
1
<jcowan>
s/1/+1
<beach>
dbotton: In what way is it a hindrance to use the Common Lisp package system?
<dbotton>
Probably should have designed a way to add inheritance to closures
<aeth>
right, lexical closures are the only "true" encapsulation in Common Lisp
<dbotton>
The other way around
<dbotton>
It is a hindrance to the objects
<aeth>
The variable might not even exist at runtime with the debugger open
<beach>
dbotton: I think you need to explain that.
s-liao has quit [Quit: Client closed]
<beach>
jcowan: In your opinion, what is required for a feature to be called encapsulation?
<dbotton>
It means that you have to fully qualify your symbols used to represent accessors and slots it many situations that if the symbol was associated with the class wouldn't. Yes I know that is more limiting
<beach>
dbotton: What utterance are you responding to here?
<dbotton>
explaining in my poor way the hindrance to the object
<dbotton>
it is a syntactic issue only
<dbotton>
I am not per se saying there is a better alternative and still keep CL as it is
<beach>
dbotton: Slots are implementation details and should not be used by client code. Accessors may or may not be part of the protocol.
<jcowan>
A situation in which state inside a capsule can only be changed by operations provided by the capsule.
<beach>
dbotton: I thought that was exactly what you were saying.
<beach>
jcowan: Sounds like the way the package system works.
<jcowan>
Obviously you can get "encapsulation" by just providing getters and setters for the state.
<jcowan>
No, it's the way closures work. Indeed, objects (in the OOP sense) are the duals of closures.
<beach>
jcowan: In what way does the package system not provide the functionality you are looking for?
<dbotton>
I think that an introduction to CLOS should describe the use of packages as part of defining an object
<dbotton>
or rather a class
<jcowan>
We've already talked about that: packages are incomplete capsules
<beach>
dbotton: That I can agree with. But not "OO in lisp not encapsulating the namespaces with the object is a negative for clos".
<char[m]>
dbotton: how would you have close treat namespaces differently?
<beach>
jcowan: So you are not going to tell me. Fair enought.
<beach>
enough
Oladon has quit [Quit: Leaving.]
<jcowan>
I thought we already agreed on that point: packages are not complete capsules in the senses closures are. A closure *prevents* access to its local state variables from outside the closure; thus they are complete capsules providing complete encapsulation.
<dbotton>
negative in CLOS in the eyes of someone wanted OO like in other languages, Same issue happened with "tagged types" we added to Ada in 95. The encapsulation was separate from the OO type
<jcowan>
s/senses/sense
<dbotton>
It creates difficulty in understanding the OO model were OO is a means of encapsulation
<beach>
jcowan: If you don't trust your programmers not to use ::, then you should replace them.
<dbotton>
and it CL and Ada isnot
<jcowan>
Eh. OOP jargon comes from peope whose base position is "No programmers can be trusted to do anything correctly", to which they then carve out as few exceptions as possible.
<beach>
That is probably why OO is now considered a failure.
<dbotton>
<char[m]> I wouldn't change anything
<dbotton>
I would though change how CLOS is presented to people
<char[m]>
I see you were presenting a different perspective
<dbotton>
I only after using it for some time figures out that beach meant by protocols what most think of as interfaces
<dbotton>
So teaching people to use packages like part of the class definition would lead them to something they could relate to
<dbotton>
after you can show the flexability
<jcowan>
"Let's face it: software is crap. Feature-laden and bloated, written under tremendous time-pressure, often by incapable coders, using dangerous languages and inadequate tools, trying to connect to heaps of broken or obsolete protocols, implemented equally insufficiently, running on unpredictable hardware -- we are all more than used to brokenness."
<jcowan>
--Felix Winkelmann (author of Chicken Scheme)
<jcowan>
Of course this is not a position that people who teach CS can afford to hold, or they would hang themselves.
<dbotton>
So teaching a class is = defclass + package and interfaces are your public protocols is a better model for most to get clos
<beach>
jcowan: So that's the level of the discussion now?
<dbotton>
if I am making sense and understand what beach meant by protocols
<beach>
It's in several documents that use Common Lisp.
<jcowan>
Eh, it's 2325 here now and I need to go to bed very soon. I'm normally more optimistic than this.
<beach>
Yeah, go to bed.
<dbotton>
beach thanks, would have helped more a year ago :)
<beach>
I can't fix that.
<dbotton>
I know and is ok, part of learning the lingo
<dbotton>
Still trying to get my 10k hours in on a new language
<dbotton>
where is that chapter from beach?
<beach>
From a book I am working on. But it is stalled because of other things I feel I have to do.
<dbotton>
I look forward to it
semz_ has joined #commonlisp
<qhong>
is there a good portable way to test if a symbol is a valid type specifier?
<qhong>
I could (typep nil interesting-symbol) and see if it gives an error, but it looks kinda ugly
semz has quit [Ping timeout: 256 seconds]
<moon-child>
beach: section 5.6 of your 'protocols' chapter seems somewhat inconsistent. First it refers to a 'minimal protocol' (implying that there are protocols which are not minimal). Then it says that something which is not minimal is not a protocol. Then it says that a set of operations which is not minimal is an extended protocol (a reader might be forgiven for thinking that an extended protocol
<moon-child>
is a type of protocol)
<moon-child>
(or, rather than inconsistent, I should perhaps say unclear)
thomaslewis has left #commonlisp [#commonlisp]
tyson2 has quit [Remote host closed the connection]
<beach>
moon-child: Thanks. I should be more consistent with the terminology.
<beach>
The CLIM II specification seems to use API for "extended protocol", and I probably meant to use a different word initially. But I prefer "extended protocol" to API here, and I should make sure to use it consistently.
<dbotton>
is there a way to check if a symbol exists by string that won't intern the symbol?
jealousmonk has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 27.1)]
Guest74 has joined #commonlisp
aartaka has joined #commonlisp
opcode has quit [Quit: we freebsd now]
s-liao has joined #commonlisp
s-liao has quit [Client Quit]
Oladon has quit [Quit: Leaving.]
<dbotton>
beach "weakly connected" is the same as loosely coupled? (going over more carefully your protocol doc)
<beach>
Let me check...
<beach>
I guess so, yes.
<dbotton>
why us concept of larger vs smaller here? that may not be the case
<dbotton>
consumer and provider better no/
<beach>
For the two parts of a module you mean?
<dbotton>
for the two different modules one with interface and one with implementation
<beach>
Not two different modules. Two parts of each module.
<dbotton>
ok, so spec and body in ada lang
<beach>
I don't know Ada. Sorry.
<dbotton>
specification and implementation
<beach>
Most of the literature on software engineering uses "interface" and "implementation" I think.
<dbotton>
yes but you used smaller and larger
<dbotton>
which is not always the case
<beach>
The implementation is typically large and the interface typically small.
<beach>
The larger the interface part is compared to the implementation, the more code is concerned with coupling with other modules, so the overall coupling in the code base increases.
<beach>
But sure, I can add a "typically" there.
<dbotton>
modules are the same as packages?
<beach>
In Common Lisp? No, not quite. A module can have several packages.
<beach>
But the interface part of a module is typically in one package.
<dbotton>
if not mentioned before in book probably should
<beach>
OK, thanks.
<beach>
My preferred way of organizing a module is to have a package that contains ONLY the symbols that are exported, and thus meant to be used by client code.
Oladon has joined #commonlisp
<beach>
Then, other packages contain the symbols that make up the implementation of the exported features.
<beach>
This organization is the exact opposite of what typical object-oriented languages require, and it is made possible by the package system.
<beach>
Well, not ONLY those symbols, but those symbols and the ones in the COMMON-LISP package.
<beach>
Well, I take that back. That's not necessary.
<dbotton>
you probably should look ada as this is how everything is laid out
<beach>
Sounds good.
<dbotton>
you are setting up a layer on top of CL for good engineering :)
<dbotton>
Ada excels in that regard, you can't produce something that compiles with out it
<beach>
So, the interface is just (defpackage #:interface (:use) (:export ...)) and contains no definitions.
<dbotton>
you mention the interface contains functions and generic functions
<dbotton>
how is that so?
<beach>
It contains the symbols that name those items.
<dbotton>
what does that look like?
<dbotton>
same for that you mention the interface contains the return values
<beach>
Then an implementation has (defclass interface:class-name-1 ..) (defgeneric interface:function-1 (...))
<dbotton>
that doesn't show a return value for function or generic function?
<beach>
Not all protocol elements can be encoded in the language.
<beach>
Some of it is in the documentation.
<dbotton>
I actually asked a few weeks ago if someone had a convention for that
<dbotton>
do you?
kotshie has joined #commonlisp
<beach>
For what?
<dbotton>
return values in the doc string
<dbotton>
how to record it or relate it
<dbotton>
ie put it in to the interface
<beach>
I tend to write separate documentation rather than documentation strings. I find that documentation that is created as documentation strings is lacking a lot of information.
<dbotton>
I use mgl-pax to sort of reverse engineer my docs from the code it works well
<dbotton>
I wish though I had real "interfaces" like in ada for the docs
<beach>
I find that there is no good place for things like concepts and overall philosophy.
<moon-child>
I find such 'documentation generators' generally have rather poor results
<moon-child>
vs purpose-written documentation
<moon-child>
(even aside from beach's complaint)
<dbotton>
I feel a good interface that is compiled is better than al
<dbotton>
the pax docs does decent middle of the road
<dbotton>
as I can add docs as well beyond the doc strings
<beach>
That's good.
<dbotton>
That is the one thing I miss in CL the lack of a compiled spec/interface
<beach>
I don't understand what it is that you are missing.
<beach>
I mean, every file is typically compiled in a modern Common Lisp implementation.
<moon-child>
I assume 'compile' in the traditional sense (as similar to 'collate'), not as in 'translate from one programming language to another'
<beach>
Ah.
<dbotton>
I can compile all my specs in ada and leave out the bodies (implementations)
<dbotton>
the compiler checks for consistency, errors etc
<dbotton>
but obviously doesn't produce code in such a run
<dbotton>
on larger project very helpful
<dbotton>
it is a different model, but not that much
<dbotton>
as the older compilers used a "library" that sort of is like the lisp image you build up before dumping to an executable
<dbotton>
in 5.3 probably should compare protocols to abstract classes not classes
<dbotton>
The truth is (as you taught me early in my lisp journey) comparisons are failures for means of teaching/learning Lisp
<dbotton>
My observation is that since lisp is more abstract, ie you are essentially manipulating references to closures, it is a different than other languages in a fundamental way
<dbotton>
other languages the program is more fixed to the code itself
<dbotton>
the code can be changed or rewritten by some macro etc
<dbotton>
you have to pay attention to what is behind the code all the time
<dbotton>
(sorry if I am not being concrete enough)
<neominimum>
Hey, beach would you forward declare an ordinary function definition as part of the protocol like this: `(defun foo (arg) (declare (ignorable arg)) (error "No concrete implementation exists for FOO"))` and then redefine it later as part of the implementation?
<beach>
dbotton: That sounds like a description of the essence of a dynamic programming language like Common Lisp.
<beach>
neominimum: Probably not. I wish there were a good way of doing that. But then, my interface functions tend to be all generic anyway.
<dbotton>
it seems there are two branches of programming, concrete (ada,c, etc) and abstract (lisp)
<beach>
The usual distinction is static (= batch) vs dynamic (= interactive).
<dbotton>
(someone once said that eventually everything will be programmed in Ada or Lisp but they didn't know about the third branch - marketing)
<moon-child>
beach: there are many dynamic languages which are not interactive (or which permit limited interactivity); and I can imagine an interactive static language
<beach>
As long as the software industry is run by insufficiently trained and incompetent people, people are going to adopt the latest fad rather than understanding the essentials.
<beach>
moon-child: My definition is dynamic = interactive = a language with semantics defined by a sequence of interactions.
<moon-child>
I see
<moon-child>
I think most people interpret the terms 'static' and 'dynamic' in context as referring to typing
<neominimum>
dbotton: as far as I'm aware there is nothing inhibiting the use of lisp for the type of programming that I imagine you mean by concrete.
<beach>
I said nothing about types.
<beach>
Then I would have said "statically typed" and "dynamically typed".
<dbotton>
<neominimum> you can statically type lisp
<moon-child>
All I am just saying is that, in context of programming language classification, I think the terms 'static' and 'dynamic' are generally used to refer to types
<dbotton>
First thing I did was work that out and create some macros
<dbotton>
I think concrete vs abstract is acurate
<neominimum>
dbotton: oh I see
<dbotton>
it is just not something talked about in most courses and books
pve has joined #commonlisp
<dbotton>
Lisp is very abstract and Ada is very concrete
<beach>
moon-child: I am sorry to hear that.
<dbotton>
Trace analysis is possible in Ada not sure even possible in Lisp
<dbotton>
where you trace every line of code to the compiled output
<dbotton>
and then prove its correctness etc
<dbotton>
used for commercial air craft
<dbotton>
Ada you program the compiler, lisp you program the program
<dbotton>
or program the computer, and program the program that programs the computer better
<SR-71>
It's recursive.
<dbotton>
lisp is a derivative (math term) of programming
<dbotton>
5.7 beach is that not exactly what an abstract class is
<dbotton>
maybe should mention that prallel
<dbotton>
parallel
<dbotton>
done with doc. You really should look in to Ada specs, in particular the 2012 standard that introduces contracts.
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
Oladon has quit [Quit: Leaving.]
<beach>
dbotton: Neither term exists in the standard, but "protocol class" is what is used in the CLOS literature.
<beach>
dbotton: At the moment, I need to be more careful about additional tasks that I take on, so it shall have to wait.
treflip has joined #commonlisp
davep has joined #commonlisp
semz_ is now known as semz
mon_aaraj has quit [Ping timeout: 272 seconds]
qiduo has quit [Read error: Connection reset by peer]
qiduo has joined #commonlisp
s-liao has joined #commonlisp
mon_aaraj has joined #commonlisp
rgherdt has joined #commonlisp
mepy_ has quit [Quit: Leaving]
cosimone has joined #commonlisp
kotshie has quit [Ping timeout: 272 seconds]
shka has joined #commonlisp
aartaka has quit [Ping timeout: 272 seconds]
aartaka has joined #commonlisp
<mfiano>
Is there a "prepend FOO to list BAR iff FOO is not nil" operator?
<moon-child>
(append foo bar)? Or you want the equivalent of (if foo (cons foo bar) bar)?
<beach>
(setf bar (append foo bar))
<mfiano>
doesn't need to be destructive, just the idea without writing the conditionalization myself is fine. I know the standard has a lot of obscure list manipulation functions I can't ever remember
<mfiano>
beach: PREpend, without manual conditionals.
<moon-child>
yes, that prepends foo to bar
<moon-child>
by appending bar to foo
<beach>
Exactly.
<mfiano>
Oh I see what you did
<mfiano>
You would still need to conditionalize though
* beach
sees a change of specification coming up.
<mfiano>
if FOO is not NIL
<mfiano>
Since it must be a list
<beach>
NIL is a list.
<mfiano>
I could use alexandria:ensure-list I suppose
<beach>
The empty list in fact.
<mfiano>
Right
<mfiano>
The original question specified something you overlooked
<beach>
So then the APPEND return the second element.
<moon-child>
mfiano: I will note I asked if that was what you want, a second before beach did at that (by my clock) :)
<mfiano>
The element should be prepended, whether it is an atom or a cons, if it is not nil
<mfiano>
I never said it must be a cons!
<moon-child>
(i.e. (if foo (cons foo bar) bar), as I said earlier)
<beach>
The word PREPEND would not apply to an atom.
<mfiano>
That's overthinking it. In English terms, prepending an element to a list, is done whether a new cons has to be constructed and then linked or not.
<mfiano>
Since PREPEND is not a glossary term.
<jackdaniel>
even if there is such operatir I would not look to hard - adding an utility doing the right thing is trivial while looking for exotic operators is not
<mfiano>
I do like discussing it anyway. THat's how I was able to be reminded of an elegant ADJOIN solution instead of REMOVE-DUPLICATES yesterday.
<mfiano>
jackdaniel: Oh sorry to see you leave #clprojects
s-liao has quit [Quit: Client closed]
<jackdaniel>
I have too many channels opened anyway :)
<moon-child>
I think I have about 50 at the moment
<mfiano>
I have about 50 as well, but I set highlights only for pretty much non-CL channels (and lispcafe) :)
<SR-71>
lol, I have just 2.
treflip has quit [Remote host closed the connection]
<mfiano>
Well I've been on IRC since before the Web was even conceived :)
<SR-71>
You must have sweet memories with mIRC.
s-liao has joined #commonlisp
<mfiano>
Nope, I never was into Windows.
<SR-71>
Do you remember when people were whacking with a wet trout everywhere?
Krystof has joined #commonlisp
<mfiano>
It was a large trout
<SR-71>
Yeah a "Large" one.
<moon-child>
it was smacked, not whacked
* moon-child
smacks SR-71 around a bit with a large trout
<qhong>
Do we have head specializer (like those in Emacs Lisp's CLOS) in real CLOS?
abrantesasf has quit [Read error: Connection reset by peer]
abrantesasf has joined #commonlisp
cage has joined #commonlisp
nature has joined #commonlisp
abrantesasf has quit [Ping timeout: 256 seconds]
Guest74 has quit [Quit: Connection closed]
Guest74 has joined #commonlisp
random-nick has joined #commonlisp
nature has quit [Ping timeout: 256 seconds]
abrante32 has joined #commonlisp
eugercek has joined #commonlisp
tyson2 has joined #commonlisp
<McParen>
hello, is there a way to avoid initialize-instance called on objects made with make-instance? I have objects with missing initargs, so they cant really be initialized. I'd like to fill in those missing slots, and only then manually call initialize-instance on them, is such a thing even possible?
<phoe>
no
<phoe>
if you want to do something like that, call ALLOCATE-INSTANCE directly
<phoe>
that will give you an uninitialized object that you can then call INITIALIZE-INSTANCE on with all the initargs you want
<yitzi>
Or maybe `initliate-instance :after` and just initialize the slots you want?
<Guest74>
couldn't you just set them using :before?
<yitzi>
Or :before also ^
notzmv has joined #commonlisp
<McParen>
yitzi: I dont think :before would work here, because I would have several uninitialized objects, check what is missing and calculate that, then initialize them all. I have to read about phoes suggestion allocate-instance, but it sounds exactly like what i was looking for.
<McParen>
"The generic function allocate-instance creates and returns a new instance of the class, without initializing it."
cage has quit [Ping timeout: 240 seconds]
<beach>
McParen: MAKE-INSTANCE is essentially ALLOCATE-INSTANCE + INITIALIZE-INSTANCE.
<Guest74>
this sounds interesting. What are you doing that has interdependent objects for initialization?
<yitzi>
McParen: Ok, I usually use :after for late binding initialization of slots. I would be curious to see an example for which this isn't sufficient.
<rotateq>
or maybe when some slot-values depend on each other so the slots without initargs get computed with the others and stored via `initialize-instance :after` (just one of many possibilities of course)
<McParen>
yitzi: i am not sure whether it isnt sufficient. my current initialize-instance uses :after to call out cffi, so I need all the params before :after is called.
orestarod has joined #commonlisp
<McParen>
Guest74: I am trying to layout rectangles on a ncurses screen, and some of them are missing a geometry, so I have to calculate that before fully initializing the object, but I also need an object to find out what is missing.
<McParen>
so I guess it has to be a two-step process.
<Guest74>
ah, someone around here had a tui that handled windows.
<Guest74>
oh, but they didn't use any ffi
<McParen>
Guest74: yes, the problem is basically how to delay the cffi call until all the params are provided.
cage has joined #commonlisp
<rotateq>
McParen: shouldn't the pipeline separate this anyway? first instantiation, then recalculations and only then (re)rendering
<yitzi>
McParen: Maybe use :around for the cffi stuff?
<McParen>
rotateq: ideally it would, but I have not anticipated the need to recalculate the init parameters.
<McParen>
yitzi: I think :around would still not allow checking other objects and then finish the initialization of the current object.
s-liao has joined #commonlisp
<rotateq>
and via another metaclass inheriting from standard-class maybe?
<rotateq>
okay no forget that :D
<McParen>
the cleanest way would be to calc all the geometries first, then initialize all the objects.
abrantesasf has joined #commonlisp
abrante32 has quit [Ping timeout: 240 seconds]
<McParen>
but it would require a second set of non-cffi objects just to hold the geometries, which is why i want to avoid that.
<Guest74>
can't you just set some geom and then resize?
<McParen>
of course, but that would be too easy. ;)
<Guest74>
I don't think you'd really need an object just to hold a layout. My layouts are just a tree.
<Guest74>
I believe they were talking about clos objects. I could be wrong.
<beach>
There is no such thing as a "CLOS object". All objects have a class and classes are a CLOS feature.
<McParen>
Guest74: The nodes in the layout tree I have are clos objects, not cons cells.
<beach>
McParen: There is no such thing as a "CLOS object".
<beach>
Guest74: Do you take remarks on your layout.lisp?
<Guest74>
sure.
<beach>
Guest74: LOOP keywords should be first on a line, and your LOOP clauses are not indented correctly.
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
<yitzi>
LET isn't either, so that could be a tab/GitHub issue.
<beach>
Guest74: And you have mysterious multiple spaces between forms in various places.
<Guest74>
yeah, it's pretty old. Before I learned to stop emacs from inserting tabs.
<beach>
Normally, you would have one blank line between top-level forms.
notzmv has quit [Ping timeout: 256 seconds]
<beach>
(loop for i below num...) can be expressed as (loop repeat num ...) if you don't use the loop variable.
<beach>
Sometimes you have NO space between forms.
<Guest74>
what's the command to show whitespace in emacs again?
<McParen>
setq show-trailing-whitespace t
<Guest74>
though it seems just using replace works.
<Guest74>
Now, I mean there's a highlight mode, I don't think it was that.
<Guest74>
aptly named whitespace-mode
<Guest74>
tabs as far as the eye can see.
<Guest74>
stopping emacs from inserting tabs really should be in all beginner tutorials.
<Guest74>
beach: any thoughts besides layout?
<beach>
I don't know what the code does or is supposed to do. That would be a lot more work.
<Guest74>
So the readme isn't sufficient? It's the first thing you see.
<beach>
CALC-BOX should probably be split into several smaller functions.
<Guest74>
probably needs better wording.
<beach>
I didn't read the README.
<Guest74>
it's got pictures.
<Guest74>
I think I've settled on cutlist for what calculating a layout produces.
<McParen>
Guest74: the library looks nice.
<Guest74>
thanks, though I think it might be a little terse for human construction. Seems to work well for generating layouts.
<Guest74>
at some point of thinking of adding things :horizontal and :vertical like all the big kids.
<Guest74>
apparently I can't type.
<Guest74>
My window manager uses it, so there's also main-and-stack and main-and-grid, which seems to work nice at 4k. grid also better distributes windows instead of having a huge stack on the left.
wacki has quit [Quit: Leaving.]
<McParen>
I've looked into allocate-instance and it does not seem to do what I hoped. I can not have some initargs, calculate the missing ones, then call initialize-instance.
abrantesasf has quit [Read error: Connection reset by peer]
<McParen>
Guest74: It makes sense to calculate every geometry in the tree first, then make the objects based on that.
<yitzi>
McParen: I really think you can do this with :after and :around. Probably need more concrete code examples, though.
<Guest74>
and depending on what your end goal is, having resizable/moveable windows might be a good thing. So starting geometry wouldn't be an issue then.
dec0d3r has quit [Quit: Leaving]
<Guest74>
this may be why systems like X11 have creation and mapping/display as separate.
s-liao has quit [Quit: Client closed]
yewscion has joined #commonlisp
<McParen>
yitzi: I also know that it is possible, but it would currently require a lot of refactoring of what I already have, so I hoped i could avoid that.
<yitzi>
Ok.
<Guest74>
meanwhile, does anybody here know an easy way to populate an sb-alien:array from a lisp array?
abrantesasf has joined #commonlisp
<McParen>
Guest74: If that is what CFFI abstracts away, I'd look into examples for cffi:mem-aref
<_death>
for some specialized arrays, there could (should) be an operator to perform a fast copy.. if it's a static vector, you can just use memmove yourself
<Guest74>
I'm guessing I should at some point move this to cffi, I'm just more familiar with sbcl stuff.
<Guest74>
the array also lives in a struct, but I guess that doesn't change the fact I'd have to get the address of the array I guess?
<Guest74>
_death: yeah, they're mirrors of c arrays, so I was hoping there was a fast copy path.
yewscion has quit [Ping timeout: 256 seconds]
psf has quit [Ping timeout: 256 seconds]
psf has joined #commonlisp
<_death>
unfortunately the relevant cffi operators (lisp-array-to-foreign and its counterpart) have naive implementation
<Guest74>
for reference, what I'm doing is writing a macro used to define foreign structs that defines the foreign struct, defines a lisp struct with same type declarations, and creates a reader/writer.
<Guest74>
_death: thanks. I would have forgotten to increment the pointer by the element size.
<Guest74>
though I was just thinking of setf'ing the deref'd index.
mepy has joined #commonlisp
kevingal has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
<dbotton>
Is there a term for referring to a CLOS object vs a general object in lisp? Would that term be clos object?
<dbotton>
I've seen mixed impressions if the term CLOS should even be used today
<McParen>
i refer to objects produced by make-instance as clos objects and objects for everything else
<random-nick>
I think the usual term for objects of subclasses of standard-object is standard instance
<yitzi>
^ Yes. Object is any Lisp datum. If someone says "instance" I assume they mean as random-nick has said.
<yitzi>
If "CLOS object" was the correct term the method would be `make-clos-object` not `make-instance`. ;)
jealousmonk has joined #commonlisp
<beach>
dbotton: There is the concept of a standard object. And there is another concept of an instance of a standard class.
<_death>
if precision is required, just (deftype object-of-interest () '(or standard-object structure-object))
<beach>
McParen: There is no such thing as a clos object.
<beach>
random-nick: What is wrong with "standard object" I mean, an instance of the class C is usually referred to as "a C".
<beach>
So if it is an instance of a subclass of the class STANDARD-OBJECT it is "a standard object".
mon_aaraj has quit [Ping timeout: 272 seconds]
<beach>
And let me see if I get this right: A subset of standard objects may be instances of a standard class, i.e., instances of an instance of STANDARD-CLASS.
<Guest74>
don't you usually refer to an instance of class by the class and not its supers?
<beach>
That would be a "direct instance".
<Guest74>
just going by what you said.
<beach>
What part?
mon_aaraj has joined #commonlisp
<Guest74>
an instance of the class C is usually referred to as "a C
<beach>
I am not sure whether you are correcting something I said or not.
<random-nick>
from the clhs glossary: instance n. 1. a direct instance. 2. a generalized instance. 3. an indirect instance.
<beach>
Yes. An instance of the class PERSON is "a person".
<random-nick>
instance apparently means both of those
<random-nick>
and yeah I don't see anything wrong in referring to (generalised) instances of STANDARD-OBJECT as standard objects
<beach>
I believe the term "standard instance" is used in the MOP, and there is a function named STANDARD-INSTANCE-ACCESS, but then the MOP wasn't as carefully worded as the Common Lisp standard.
<McParen>
beach: I know that, as I said, I refer that way to objects initialized by make-instance. when a name got stuck, it is difficult getting rid of it.
<beach>
Guest74: And that works for instances of subclasses too. If EUROPEAN is a subclass of PERSON, then "a European" is also "a person".
<Guest74>
but we usually say he's european, not a person.
<Guest74>
if we go by english that is, usually using the more specific term.
<rotateq>
McParen: but when you try calling MAKE-INSTANCE on a subclass of BUILT-IN-CLASS it will signal an error
<_death>
there are many axes where you can get much more specific.. people usually just go for a "good enough to get my message across"
<rotateq>
_death: I like using 'this human/person' or 'this entity' when I'm not sure.
<Guest74>
just refer to everything as T and you'll be fine.
<rotateq>
yes, ⊤ and ⊥ :)
perrierjouet has joined #commonlisp
<rotateq>
⊤ with the supertype ⊤
notzmv has joined #commonlisp
<Guest74>
I guess we also stop at a superclass that differentiates at the level we want to differentiate.
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
abrante17 has joined #commonlisp
SR-71 has quit [Remote host closed the connection]
abrantesasf has quit [Ping timeout: 272 seconds]
amb007 has quit [Read error: Connection reset by peer]
Catie has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
Oladon has joined #commonlisp
treflip has quit [Remote host closed the connection]
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
treflip has joined #commonlisp
Posterdati has quit [Ping timeout: 256 seconds]
Posterdati has joined #commonlisp
Guest491241242 has joined #commonlisp
pranavats has left #commonlisp [#commonlisp]
abrante17 has quit [Quit: -a- Connection Timed Out]
<utis>
thought i would give seibel's id3-parsing chapter another try, but all my mp3s seem to have version 2.3; does anyone know where i could find some with 2.2?
pranavats has joined #commonlisp
<Guest74>
the versions are backwards compatible, so stuff should work.
<Guest74>
unless he borks on reading a version different than 2.2, but that should be a simple change.
<_death>
maybe instead of finding old mp3s you can extend the code to support it.. https://id3.org/id3v2.3.0
abrantesasf has joined #commonlisp
abrantesasf has quit [Read error: Connection reset by peer]
<Guest74>
looks like he talks about supporting 2.3
abrantesasf has joined #commonlisp
waleee has joined #commonlisp
thomaslewis has joined #commonlisp
abrantesasf has quit [Ping timeout: 240 seconds]
<Guest74>
is there a way to evaluate a code snippet, submitted as an arg to a function, in the lexical environment of the function? Or I need to change my function to a macro?
tane has joined #commonlisp
<_death>
not really.. but you can construct a lexical environment in the code passed to eval
<Guest74>
that references some lexical var in the function?
<Guest74>
maybe I should just add an option to return the object and keep the function as is.
<Guest74>
I wonder if I should add support for writing polygon points. Is there any use case that they'd be better than just using path?
<Guest491241242>
Hello all, currently at the repl I have to refer to the function with "(PACKAGE:FUNCTION PARAM1 PARAM2). What should I do to be able to write just the function name to make the function call. Like so: "(FUNCTION PARAM1 PARAM2)"
<jackdaniel>
you know, this whole opengl thing and xrender extension that accepts triangles
<Xach>
Guest491241242: there are a number of options! one easy one is (use-package :package). you can make that part of your defpackage. you can also import individual symbols into your current package to avoid package prefixes.
thomaslewis has left #commonlisp [#commonlisp]
<Guest491241242>
Ok, thanks Xach!
<Guest74>
jackdaniel: wondering just svg. If I draw to a render surface I use triangles if appropriate.
<jackdaniel>
ah, you see this is for educational purposes
<jackdaniel>
I'm writing a tutorial for creating "draw-only" backends
rotateq has quit [Remote host closed the connection]
<tane>
jackdaniel, where will you publish that? :)
IPmonger has joined #commonlisp
<jackdaniel>
and McCLIM core methods have a fallbacks so it is enough to implement "only" medium-draw-polygon*
<Guest74>
Do you decimate into triangles?
IPmonger has quit [Remote host closed the connection]
<jackdaniel>
not in this backend, but I've implemented triangulation for internal purposes (xrender here we come in other words)
<Guest74>
heh, mine only needs draw:pixel. But that's not very optimized.
<Guest74>
i wish there was an external library for the triangle thing. hint hint.
<jackdaniel>
tane: on my blog
<jackdaniel>
and later, when appropriately adjusted, in the manual
wacki has joined #commonlisp
<jackdaniel>
(I have also an early draft on my patreon)
azimut has joined #commonlisp
anticomputer has joined #commonlisp
wyrd has joined #commonlisp
ec has joined #commonlisp
gxt has joined #commonlisp
abrantesasf has joined #commonlisp
jeffrey has joined #commonlisp
jealousmonk has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 27.1)]
treflip has quit [Quit: good night]
abrantesasf has quit [Remote host closed the connection]