Copenhagen_Bram has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 245 seconds]
Copenhagen_Bram has joined #lisp
fikka has joined #lisp
<makomo>
Bike: on a second thought, WITH-RESOLVED-PLACES isn't exactly like ONCE-ONLY. the typical use case would be wanting to avoid multiple evaluation of subforms of a place within a macro -- for that you would use WITH-RESOLVED-PLACES within the expansion but with a gensym'd name for the binding
<makomo>
a place version of ONCE-ONLY would use WITH-RESOLVED-PLACES for you so you don't have to. in essence, WITH-RESOLVED-PLACES is like the LET within the final expansion -- the one that does the evaluation
<makomo>
(...) like the LET at the beginning of the final expansion of a macro that uses ONCE-ONLY*
<makomo>
AeroNotix: you might find this interesting as well ^
fikka has quit [Ping timeout: 272 seconds]
<makomo>
PLACE-ONLY and ONCE-ONLY have a lot in common. perhaps another higher-order macro should be made to avoid code duplication -- triple backquotes? :^)
<makomo>
WITH-RESOLVED-PLACES and SETF-EXPANDERLET are damn cool
<AeroNotix>
I'm surprised a lot of these weren't included in the standard. Especially things like updatef/applyf
pierpa has quit [Quit: Page closed]
<makomo>
true. it's also amazing how the setf expander machinery even allows you to design stuff like this today, a couple of decades afterwards
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Bike>
define modify macro is supposed to do updatef, since usually the function is fixed
pierpal has joined #lisp
it3ration has quit [Ping timeout: 240 seconds]
<makomo>
UPDATEF is almost like FUNCALLF, except that it doesn't take any extra arguments but allows multiple place-function pairs instead
fikka has joined #lisp
lnostdal has joined #lisp
fikka has quit [Ping timeout: 252 seconds]
ealfonso has quit [Disconnected by services]
ealfonso has joined #lisp
<makomo>
why doesn't EVERY have :start and :end keys ;__;
<no-defun-allowed>
cause it wouldn't be every then
<makomo>
hah
<no-defun-allowed>
it'd be, er, partly
fikka has joined #lisp
<Bike>
because ti takes an arbitreary number of sequences and then it's messy
jinkies has quit [Read error: Connection reset by peer]
<makomo>
Bike: ohh, good point
fikka has quit [Ping timeout: 252 seconds]
fikka has joined #lisp
smokeink has quit [Remote host closed the connection]
jinkies has joined #lisp
fikka has quit [Ping timeout: 246 seconds]
Oladon has joined #lisp
FreeBirdLjj has quit [Ping timeout: 252 seconds]
<makomo>
are there any tricks to COND-like macros that would allow me to reuse certain variables from a COND clause's test-form?
<makomo>
for example, in order to test for a case i need to do an exepensive computation but also reuse it later on within the body of the clause
<makomo>
s/to/or/
fikka has joined #lisp
<makomo>
hm, i guess there's ACOND but it's not really what i want
<makomo>
basically i want a clause-wide LET
it3ration has joined #lisp
fikka has quit [Ping timeout: 245 seconds]
<loli>
makomo: you could just let lazy variables that get evaluated in the cond test case
pjb has quit [Remote host closed the connection]
<makomo>
that would work too, but it's a bit ugly :c
<makomo>
but i'll try to implement a macro over it :D
<loli>
I've done something similar to save (if (let (if (let into (let (cond
pjb has joined #lisp
schjetne has quit [Ping timeout: 268 seconds]
fikka has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
it3ration has quit [Ping timeout: 252 seconds]
fikka has quit [Ping timeout: 272 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 246 seconds]
rumbler31 has joined #lisp
Lycurgus has joined #lisp
<PuercoPop>
makomo: there is cond-let
housel has joined #lisp
it3ration has joined #lisp
rumbler31 has quit [Ping timeout: 246 seconds]
<makomo>
PuercoPop: unfortunately that introduces bindings which are visible to all of the clauses
fikka has joined #lisp
fikka has quit [Read error: Connection reset by peer]
<aeth>
Bike: but now it's time for a second-order pun, i.e. utility library for Common Lisp named after an ancient city because alexandria is
<makomo>
but anything related to alexandria will do :D
<aeth>
Bike: so even though there is no notable great library of Carthage, the name Carthage would be a fitting name for a utility library because alexandria is so notable
k-hos has quit [Ping timeout: 240 seconds]
<Bike>
alexandria is still like, around
<Bike>
is carthage? i guess it would be in tunisia
<Bike>
modern municipality has a population on the order of that of my hometown
<Bike>
so nah
<aeth>
It actually got rebuilt and was one of the major cities of the Roman Empire. It would make a good name for a utility library because both Alexandria and Carthage were major Roman cities in Africa
it3ration has quit [Ping timeout: 272 seconds]
Copenhagen_Bram has quit [Ping timeout: 272 seconds]
jinkies has quit [Remote host closed the connection]
<aeth>
Rome, Antioch, Carthage, Constantinople, etc. would make good names for CL utility libraries because Alexandria exists. Except, of course, if you called your library Rome it better be the best utility library in history.
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Copenhagen_Bram has joined #lisp
<makomo>
hm, i'm wondering whether it's possible to create a "conditional place". it would be named IFF and would be used like (IFF cond then-place else-place)
<makomo>
it would delegate to one of the two places depending on the truthness of cond
fikka has joined #lisp
<makomo>
the expander for IFF can do some merging of the expansions for the two places, but i'm not sure how to avoid multiple evaluations of cond
<makomo>
because i don't know where i would put that evaluation
<makomo>
it would have to happen outside all of the expressions produced by the setf expander :^(
fikka has quit [Ping timeout: 240 seconds]
dale has joined #lisp
it3ration has joined #lisp
kajo has quit [Ping timeout: 252 seconds]
joni has joined #lisp
fikka has joined #lisp
buffergn0me has joined #lisp
fikka has quit [Ping timeout: 246 seconds]
fikka has joined #lisp
dddddd has quit [Remote host closed the connection]
dented42 has joined #lisp
fikka has quit [Ping timeout: 246 seconds]
fikka has joined #lisp
emaczen has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 240 seconds]
emaczen has joined #lisp
Copenhagen_Bram has quit [Ping timeout: 252 seconds]
emaczen has quit [Read error: Connection reset by peer]
emaczen has joined #lisp
Copenhagen_Bram has joined #lisp
fikka has joined #lisp
Roy_Fokker has quit [Read error: Connection reset by peer]
Denommus` has quit [Ping timeout: 246 seconds]
fikka has quit [Ping timeout: 240 seconds]
Xof has quit [Ping timeout: 272 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
rpg has joined #lisp
emaczen has quit [Read error: Connection reset by peer]
Copenhagen_Bram has quit [Ping timeout: 250 seconds]
aindilis has quit [Remote host closed the connection]
Copenhagen_Bram has joined #lisp
quazimodo has quit [Ping timeout: 245 seconds]
quazimodo has joined #lisp
emaczen has joined #lisp
fikka has joined #lisp
FreeBirdLjj has joined #lisp
fikka has quit [Ping timeout: 245 seconds]
<beach>
Good morning everyone!
joni has quit [Ping timeout: 272 seconds]
<sabrac>
Morning beach
bradcomp has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
Oddity has quit [Ping timeout: 244 seconds]
<no-defun-allowed>
hi beach
ealfonso has quit [Disconnected by services]
ealfonso has joined #lisp
Oddity has joined #lisp
<p_l>
beach: 'morning
<Fare>
'night
<Fare>
Hello from the land of strong static types.
<beach>
Don't worry, you won't be lost forever.
<no-defun-allowed>
that doesn't sound like a fun place to live
<aeth>
Fare: the land of sb-ext:*derive-function-types*?
FreeBirdLjj has quit [Remote host closed the connection]
fikka has joined #lisp
<p_l>
is it maybe the land of strong static types and dynamic scope for all practical purpose?
Lycurgus has quit [Quit: Exeunt]
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fikka has quit [Ping timeout: 246 seconds]
bradcomp has quit [Ping timeout: 244 seconds]
Oddity has quit [Ping timeout: 252 seconds]
makomo has quit [Ping timeout: 244 seconds]
fikka has joined #lisp
Oddity has joined #lisp
fikka has quit [Ping timeout: 252 seconds]
bradcomp has joined #lisp
<Fare>
I miss dynamic scope A LOT in OCaml.
<Fare>
The types are often a big burden, but they do come with nice benefits when you learn to go with them.
<Fare>
Like, large refactorings that just work.
ealfonso has quit [Disconnected by services]
ealfonso has joined #lisp
ealfonso` has joined #lisp
fikka has joined #lisp
<ealfonso`>
what is a recommended resource for CL best practices, like how to organize a project into packages, formatting conventions, linter?
fikka has quit [Ping timeout: 245 seconds]
<SaganMan>
Morning Peeps
<p_l>
Fare: heh, I had thought of Nix with that comment
<SaganMan>
ealfonso`: what kind of project are you working on?
<ealfonso`>
I wanted to factor out a youtube data api client library currently embedded into another project
fikka has joined #lisp
<ealfonso`>
I just want to learn and follow best practices if there is a convention
<beach>
ealfonso`: I don't think there are any general guidelines. I use an ASDF file and a package file for each "module".
<beach>
ealfonso`: Then I use a global ASDF file for the entire project.
housel has quit [Remote host closed the connection]
<beach>
ealfonso`: I stick each "module" in a separate directory in the file hierarchy.
<beach>
ealfonso`: It also contains tests using my favorite testing technique (random test against a reference implementation), and documentation.
fikka has joined #lisp
<aeth>
ealfonso`: the three styles are generally one-package-per-file (sometimes combined with package inferred system), one-package-per-directory, and one-package and everything top level. The latter two are the more popular styles.
<ealfonso`>
beach aeth thanks
<aeth>
ealfonso`: The compiler usually fills the role of the linter. Indentation is usually enforced by the editor, which is usually Emacs.
fikka has quit [Ping timeout: 246 seconds]
<aeth>
(Some compilers, like SBCL, give style warnings.)
<ealfonso`>
I can look at a project like hunchentoot or beach's recommendation Cluffer as guidance. aeth that makes sense
<ealfonso`>
I probably just need to understand the packaging conventions and testing
<loke>
ealfonso: there are multiple packages conventions. My recommendation is that you create a single package for your project, and never IMPORT (or :USE) any packages. Always refer to symbols in other packages by a full PACKAGE:SYMBOL name. THat will reduce any problems.
igemnace has joined #lisp
<buffergn0me>
Random tests against reference implementation is such an awesome thing to do whenever you can
<beach>
loke: Why a single package? I think that depends on the size of the project. Even for a modest-size project like Cluffer, I have 8 packages so that each "module" only exports its protocol.
Lycurgus has joined #lisp
<buffergn0me>
One thing I would advise is to make your package names long and unambiguous
<beach>
buffergn0me: It is very powerful, yes, and it saves a lot of time trying to enumerate all test cases manually.
<buffergn0me>
Short package names should be left available to end users
quazimodo has quit [Ping timeout: 252 seconds]
<beach>
Right. I always prefix my package names and ASDF system definitions. Like in SICL, they are all named sicl-* and in Cluffer, they are all named cluffer-*
fikka has joined #lisp
<aeth>
Iirc the style ASDF/UIOP prefers is foo/bar rather than foo-bar. So if the package represents the directory bar for the project foo, it would be foo/bar.
<buffergn0me>
Parenscript had a package named "JS" for a long time. Well of course JavaScript came out and also had a package named "JS"
<loke>
beach: Because one has to have a reasonably deep understanding of packages to make that work. Packages are actually quite difficult to understand for beginners, even though the concept is actually remarkably simple.
<beach>
loke: Who was talking about beginners?
quazimodo has joined #lisp
<buffergn0me>
Glad I got rid of "JS" from Parenscript, still feeling bad about having a "PS" package though
<aeth>
it's fine until someone writes a way to generate postscript
<loke>
beach: It seemed ealfonso is a beginner, based on the questions he asked.
<beach>
Ah.
<buffergn0me>
aeth: Are there not any CL Postscript libraries?
<buffergn0me>
Anyway, "PS" is getting removed in two releases
fikka has quit [Ping timeout: 240 seconds]
<buffergn0me>
Also don't forget about the Java-style naming convention for packages. Another option
<loke>
buffergn0me: without package nicknames (not supported by all implementations) java-style packages are horrible.
<beach>
One neat trick is to do what Common Lisp itself does and also CLIM. There is one package that contains only the symbols that are exported. Then there are potentially several "implementation packages" that provide the real definitions of those symbols. But any symbols naming helper functions, helper classes, etc., are strictly private to the implementation packages.
<no-defun-allowed>
indeed
<beach>
That way, the "implementation packages" are totally independent and can be maintained separately without any risk of stepping on helper symbols in other implementation packages.
<beach>
So in SICL, to name an example, I have packages like sicl-clos, sicl-boot sicl-reader, sicl-printer, sicl-loop, sicl-format, etc.
<loke>
beach: with multiple backend “private” packages there is the question about which “private” sumbols should be exported though
<beach>
Sometimes they should.
<loke>
Because there is no way you can make a private package, well, “private”. That means that any exported symbols from a private package becomes candidates in code completion.
<loke>
I have resorted to using :: when having cross-package references between private packages. It's not ideal.
<loke>
CLIM works around it by having almost everything stuffed intop a single clim-itnernals package.
<beach>
There is no rule against exporting some symbols from those implementation packages.
<beach>
Like in sicl-loop, I export symbols that allow for customization of the LOOP expansion.
<loke>
beach: True, no rule. but... once they are exported, they end up being proposed in the symbol-completion of SLIME
<beach>
Sure, that's no problem.
<beach>
If they are exported, they are meant to be used.
<loke>
beach: But what if I have two private packages, let'
<loke>
beach: But what if I have two private packages, let's call then FOO and BAR... Now I have some functions in FOO that BAR should see, but they should never be exposed to regular users.
<beach>
The CLIM solution with a single implementation package is not ideal, because it defeats the independence I was referring to.
<loke>
I'd like those functions to remain completely non-exported
<beach>
loke: Then it is questionable whether you should have two packages.
<beach>
loke: What you need for that situation is first-class global environments.
<loke>
beach: Exactly. That's my point.
<beach>
Sure the package system does not solve all problems.
<beach>
... which is why I invented first-class global environments.
<loke>
beach: right. that's pretty much the point I was trying to make; the package system could be better.
<loke>
beach: It's the right solution.
<beach>
loke: Oh, please don't go there.
<loke>
If only the implementations I use supported it... That's currently SBCL, ABCL and ECL (and sometimes CCL)
<beach>
"<bla> is not good in Common Lisp. We need an improved standard! Why did the creators of Common Lisp not think about that?"
<loke>
at least that's teh im,plementations I care about.
<beach>
loke: I have no influence over those.
<beach>
All I can hope for is that, once SICL exists, some of the techniques I use will be also be used by other implementations.
<loke>
beach: I know. I was just lamenting the fact that implementations are not following your lead here.
caltelt_ has joined #lisp
<beach>
loke: It would require some significant work, so I can understand why they would be reluctant.
<beach>
loke: Using my fast generic dispatch might make it more practical to use generic functions, so that the implementation is more modular. That, too, will require a lot of work in existing implementations.
bradcomp has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
Inline has quit [Quit: Leaving]
<beach>
The fundamental problem is that existing implementations are not very modular. Fundamental implementation decisions are scattered all over the code, as opposed to being isolated in separate modules. Therefore, changing one of those decisions requires looking at a large part of the code.
gpiero has quit [Remote host closed the connection]
<beach>
Plus, for bootstrapping reasons, some code might be written in a subset of Common Lisp, like the compiler not using generic functions, for instance. Such restrictions make it very hard to work on the internals.
fikka has quit [Ping timeout: 244 seconds]
Lycurgus has quit [Quit: Exeunt]
ebzzry has joined #lisp
it3ration has quit [Ping timeout: 246 seconds]
existential1 has left #lisp [#lisp]
steiner has joined #lisp
nirved has joined #lisp
fikka has joined #lisp
doubledup has joined #lisp
steiner has quit [Ping timeout: 252 seconds]
fikka has quit [Ping timeout: 252 seconds]
_whitelogger has joined #lisp
quazimodo has quit [Ping timeout: 246 seconds]
quazimodo has joined #lisp
eddof13 has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 244 seconds]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vlatkoB has joined #lisp
<jackdaniel>
recently on cl-pro mailing list there was a suggestion, that dividing software into multiple packages gets in a way of the programmer
<jackdaniel>
I don't have a strong opinion on that topic, but there certainly is a merit in a claim, that juggling packages may be tedious and confusing (i.e answering the question "what is where?")
<jackdaniel>
loke: chaotic development (i.e without a centralized "lead") has some profound qualities, i.e it is more reisistant for mistakes and it grows in many different (competing) directions
<jackdaniel>
then you are able to "pick" something what suits you best, or there may raise a consensus what is "the right choice"
razzy has joined #lisp
Arcaelyx has quit [Ping timeout: 240 seconds]
fikka has joined #lisp
orivej has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
it3ration has joined #lisp
Bike has quit [Quit: Lost terminal]
<loke>
jackdaniel: I find it hard enough to juggle when I'm doing personal projects.
<buffergn0me>
Another thing to consider is breaking up packages along domain specific language boundaries.
scymtym has quit [Ping timeout: 240 seconds]
trittweiler has quit [Ping timeout: 244 seconds]
aindilis has joined #lisp
it3ration has quit [Ping timeout: 272 seconds]
ludston has joined #lisp
fikka has joined #lisp
emaczen has quit [Read error: Connection reset by peer]
fikka has quit [Ping timeout: 252 seconds]
nika_ has joined #lisp
crsc has joined #lisp
Copenhagen_Bram has quit [Ping timeout: 252 seconds]
ludston has quit [Read error: Connection reset by peer]
emaczen has joined #lisp
<aeth>
jackdaniel: I :USE internally even though USE in general is discouraged, so that gets around the major inconvenience of separate packages.
Copenhagen_Bram has joined #lisp
<aeth>
i.e. my style rule is "USE" only "CL" and any internal package for the same project
<aeth>
Then the only inconvenience is what to export
<aeth>
I have some macros that greatly cut down on exports. It's mostly just the one macro for defining with-foo-accessors. (with-foo-accessors ((foo foo) (bar bar)) ...) behaves like with-accessors, except it will intern and prefix the accessor, so it's really (with-accessors ((foo foobar::my-foo-foo) (bar foobar::my-foo-bar)) ...)
trittweiler has joined #lisp
fikka has joined #lisp
fikka has quit [Ping timeout: 272 seconds]
<_death>
this misses the point of packages, as can be seen by use of ::
emaczen has quit [Read error: Connection reset by peer]
shrdlu68 has joined #lisp
Copenhagen_Bram has quit [Ping timeout: 252 seconds]
scymtym has joined #lisp
trittweiler has quit [Ping timeout: 244 seconds]
emaczen has joined #lisp
Copenhagen_Bram has joined #lisp
<_death>
also, I find that with-accessors is a bad idea on several counts.. it's meant to lessen verbosity, but is itself verbose.. it's an under-the-carpet macro since the verbosity is a symptom of bad interface
<aeth>
_death: You don't see the ::
<_death>
or cramming too much code into the function's body
fikka has joined #lisp
<aeth>
_death: having foo::bar internally in a macro is perfectly okay as long as it doesn't fit in any of the cases that makes (gensym) necessary
shka_ has joined #lisp
<_death>
aeth: yes, but it means the user doesn't distinguish between external and internal symbols.. so no point in packages
<aeth>
_death: the only public way to access these symbols is through the macro
<_death>
it loses the idea of symbol identity, since the second symbol in the "binding" is used only for its name in another context.. this makes it difficult to distinguish internal and external, and to extend as well
emaczen has quit [Read error: Connection reset by peer]
fikka has joined #lisp
shrdlu68 has quit [Ping timeout: 240 seconds]
<aeth>
_death: Extensibility is a valid criticism of this sort of approach, but these aren't really meant for outside use. This gets around exporting issues when using many *internal* packages.
Copenhagen_Bram has quit [Ping timeout: 252 seconds]
<aeth>
Extending these internal structure-objects and standard-objects will almost certainly break something.
<_death>
what are the exporting issues?
<aeth>
_death: make a package for every file and you soon find yourself writing packages with literally dozens of exported symbols
<aeth>
Most of these will be accessors needed in multiple files.
fikka has quit [Ping timeout: 245 seconds]
<_death>
I would say that this is a sign that you need to change your design
astalla has joined #lisp
<aeth>
The alternative is dozens of function arguments :-)
<_death>
why do you have dozens of accessors
Copenhagen_Bram has joined #lisp
<aeth>
_death: you only need a few large objects for something like that
<_death>
this leads to the obvious "why do you need large objects"
<aeth>
I mean, I could probably split that into (for example) three objects, but that just means I either pass in 3 objects instead of 1 or I have one object-of-objects and now have 3 more accessors!
<_death>
separation of concerns
<aeth>
I think most Lispers just would use a dozen global special variables, which is even more problematic
<_death>
or a plist
<aeth>
Notice that each element in the struct has a :type argument. This is checked reliably in some implementations. The plist approach would require a CHECK-TYPE at moment of access from the plist, in a different part of the program.
<aeth>
There's just a ton of complexity in a game engine, no matter how you choose to arrange it.
<_death>
if you want to deemphasize symbol identity, you can use keywords which is very easy to see the pros and cons of.. a macro like with-foo-accessors lets you "feel with but go without" (not sure about the english idiom for this..)
<_death>
*which make it very easy to see
emaczen has joined #lisp
flamebeard has joined #lisp
<aeth>
If I used keywords to abstract over struct and standard-object accessors, I would have to write a considerably more complicated macro than with-foo-accessors, and without the benefit of the reader basically seeing what I mean just by the name of it.
<aeth>
I mean, I do use keywords in other places. But that's basically as a part of a DSL.
<_death>
but the point is that you don't access your settings by having an accessor for each one
<_death>
and a Lisper could just use one special variable for holding them, by the way..
<_death>
you don't need to do type checking at each access.. you can do it when you create or modify the object
<aeth>
Do you want zombie-raptor/core/settings:settings-title, an explicit import-from for the 5 settings you happen to access in that package, the package to :USE that package, etc? Pretty much every way to access is messy.
<_death>
(setting :title)
<aeth>
And I use zero special variables (besides redefinitions of *standard-output*/etc.) because they don't play nice with threads.
lavaflow has quit [Ping timeout: 252 seconds]
<aeth>
I can't even temporarily use them for temporary hacks because of the threading.
<shka_>
aeth: that's why you want to have minimal number of special variables
<shka_>
but for settings, one will do
<Shinmera>
???? special variables work just fine with threads
<_death>
once again we see that we have different design values ;) luckily lisp allows both
<aeth>
Shinmera: afaik, only if you yourself are making the call to bordeaux-threads
<Shinmera>
what
<shka_>
aeth: you are having troubles rebinding special variables?
<aeth>
I had weird things happen with special variables and threads. Now I just take the extra few minutes to pass objects around and get better performance and a clearer idea with what's going on.
<aeth>
It actually isn't that big of a deal to pass a variable 6 levels down a call-stack as special variable proponents claim.
<Shinmera>
if that's what you believe
<aeth>
Special variables are very useful for I/O though
<aeth>
standard-output is essentially irrelvant 95% of the time, so it would just pollute the API
<_death>
I think settings is also a classic use case for special variables
<_death>
it is a big deal from the point of view of interactive development
<_death>
in addition to the fact that it's just clutter
<aeth>
That means that I would have to write my application with the assumption that the settings could change at any moment to anything.
<_death>
you are right that this is something to think about.. you can tell the user not to do that (this isn't java after all :).. or you could actually handle it correctly.. think Cells :)
<_death>
but I don't see how with-foo-accessors solve it
<_death>
or are you saying that you just won't pass a settings object there.. which then make it troublesome to inspect settings
<vsync>
aeth, _death: yes always consider vsync
<aeth>
_death: the easiest way to inspect this is to recompile a function to insert a (break) in the middle of it ime
<aeth>
otherwise there would be dozens of objects (not just settings) that would need to be saved into debug globals
<_death>
I mean for the function to inspect a setting
mange has quit [Remote host closed the connection]
<aeth>
with-settings-accessors means that you just pass settings in.
<aeth>
it also means that it's very clear when something is accessing one
<_death>
in short you choose not to use the mechanism of special variables for something they are quite useful for (context).. many programmers do that, usually because they lack that mechanism.. and then there are programmers that make a conscious choice.. I think we can put Schemers in that category
<aeth>
_death: Special variables means that the whole program and all outsiders access settings. A settings object means only the functions that are passed the object (and, obviously, the programmer if debugging or whatever from the REPL) access it.
<aeth>
The whole world doesn't need access to vsync
<aeth>
*standard-output*, on the other hand, is useful for the whole world to have access to
<Shinmera>
? special variables are still bound to a symbol, just like your macro
doubledup has quit [Quit: Leaving]
<aeth>
Shinmera: I'm assuming _death wants it to be an exported symbol
<_death>
this is a familiar argument (protect the programmer from himself) and we can agree to disagree about it.. there is a small technical point that the special variable has a name like *settings* which may be imported or not and so there's a way to indicate use or not use
* vsync
is available to everyone!
<vsync>
equal opportunity
<aeth>
vsync: you shouldn't be. You don't have earmuffs
* vsync
LOLs, dies
<aeth>
vsync: there's actually a correct response
* aeth
*
<no-defun-allowed>
Oh no, vsync died! My monitor's not syncing up now.
<aeth>
no-defun-allowed: now I have scanlines!
<vsync>
aeth: oh nice heh
<aeth>
_death: The programmer can do whatever they want in the CL environment, including access private things. This makes tests a lot easier to write, for instance. It also helps with REPL-based debugging, even though it might be annoying to write out a full package followed by ::
<vsync>
anyway +vsync+ because it must always be 60Hz which is the correct refresh rate
<_death>
we always used the term "vertical retrace" :)
<aeth>
vsync: the human eye can't see more than 30 Hz
<vsync>
pah false
<vsync>
_death: I think of vsync vblank vtrace as different aspects of the same thing
<no-defun-allowed>
Compare these two pictures.
<aeth>
vsync: a trinity of sorts
<vsync>
different avatars of the divine
<vsync>
heh beat me to it
<_death>
aeth: right.. and a special variable is transparent.. things that don't use it don't need to pass it around.. unlike a settings object where you need some non-users to pass it around to users
<aeth>
_death: nothing's stopping the user from saving it into cl-user::*settings*
<_death>
*settings parameter
<_death>
aeth: right.. but then he needs to pass it on his own to the "roots"
<_death>
aeth: and internally, there's also the need to pass it around.. like I said, this hurts interactive development
<aeth>
_death: in my architecture, everything's passed into the init. The programmer owns the data. I don't even support reading in textures. I might eventually but in all of my tests that needed it, I just load in a PNG myself.
<aeth>
_death: Since the programmer passes everything in, the programmer can save it into a special variable first
<aeth>
(I actually prefer saving it into a LET, though)
<aeth>
_death: That's also why I prefer structs with typed-slots or standard-objects with a metaclass that ensures that preconditions are held. I want errors to happen before passing the data in.
<_death>
vsync: does the number #x3DA says anything to you.. (maybe a more indicative notation, &H3DA)
Fare has quit [Ping timeout: 246 seconds]
trittweiler has joined #lisp
<vsync>
no :-(
<p_l>
aeth: human eye doesn't have fixed refresh rate or anything like that
<aeth>
p_l: but 24 is cinematic!
<p_l>
aeth: yes, and it involves being *trained* for it
<p_l>
it also involves the issue of uncanny valley of 2D display looking *too* real
<vsync>
well that but also it's effectively 48Hz/2 in its proper form
<vsync>
each frame displays twice with a shutter flicker in the middle
<vsync>
the flashing tricks your brain into interpolating motion in the interim
<vsync>
wonder if you could get ultimate frame rate by inserting a tiny flicker at some frequency
<p_l>
vsync: ultimate in what sense? which data channel are you even targeting?
<aeth>
p_l: I was joking about 30 Hz btw
<p_l>
aeth: Poe's law
<vsync>
real ultimate power
* p_l
notes that all of the data channels in visual path are continuous wave with various levels latency involved in processing them
<aeth>
continuous? So the ultimate is infinite?
<_death>
vsync: it was the port of the VGA status word register.. to wait for vertical retrace you'd wait for the 3rd bit to be set there
<p_l>
the fastest (pure motion matrix) had been recognized at 255 fps if not more
<_death>
vsync: many basic programs had a "wait &h3da, 8" statement :)
<vsync>
_death: oh cool, think the code I saw just hooked the interrupt
<vsync>
whatever Andre LaMothe told me to do
<_death>
(fourth bit, obviously)
SenasOzys has quit [Remote host closed the connection]
it3ration has joined #lisp
SenasOzys has joined #lisp
fikka has joined #lisp
SenasOzys has joined #lisp
it3ration has quit [Ping timeout: 244 seconds]
SenasOzys has quit [Remote host closed the connection]
SenasOzys has joined #lisp
lavaflow has joined #lisp
zfree has joined #lisp
shrdlu68 has joined #lisp
<shrdlu68>
Running `sh make.sh` in the latest SBCL tarball from github says it can't run `git describe`.
lavaflow has quit [Ping timeout: 245 seconds]
<Shinmera>
>>#sbcl
fikka has quit [Ping timeout: 252 seconds]
<no-defun-allowed>
The variable |>>#SBCL| is undefined.
<shrdlu68>
I have some code that runs in 14s in SBCL, and way too long in other implementations. It heavily (ab)uses a hashtable, I'm fairly certain that's the biggest factor in the difference. Now I'm curious what exactly makes SBCL's hash table faster.
<shrdlu68>
Probably their #'sxhash
<Shinmera>
sxhash is not actually used for hash tables
<shrdlu68>
Really?
<Shinmera>
and hash-tables with test equal or equalp are probably not tables at all, but trees.
<Shinmera>
yes
<shrdlu68>
I defined a custom hash table test and used sxhash with virtually indistinguishible results from :test #'equal
<Shinmera>
For one, the result of sxhash can change for some objects over time.
<Shinmera>
notably objects whose equivalence is not covered by equal
<Shinmera>
So standard-objects and so on
igemnace has quit [Quit: WeeChat 2.2]
<Shinmera>
or rather, whose content-equivalence
<shka_>
sxhash is pointless in sbcl if eq is used
<shrdlu68>
I wonder where this massive difference stems from, then. In ECL, it runs for over 2m, I had to interrupt it. Similarly dismal on CCL.
<Shinmera>
profile it
<jackdaniel>
ecl is espcially bad with generic function dispatch, I would be suprised if hashtable were that much subpar
astalla has quit [Ping timeout: 245 seconds]
<_death>
CL hash tables are complicated creatures.. several times I saw advice to implement your own hash tables and see resulting performance
<shrdlu68>
jackdaniel: Would or would not?
<shrdlu68>
Shinmera: I think I need a primer to profiling CL code.
fikka has joined #lisp
jochens has joined #lisp
<shrdlu68>
Ah, think I'll use Slime's profiling.
<Shinmera>
on sbcl the statistical profiler is very nice
<shka_>
yes
<shka_>
it is very useful
<jackdaniel>
shrdlu68: would be suprised, hash tables are optimized on ecl to a reasonable degree
ealfonso` has quit [Ping timeout: 252 seconds]
sz0 has joined #lisp
it3ration has joined #lisp
<shrdlu68>
Now I'm even more curious.
it3ration has quit [Ping timeout: 246 seconds]
emaczen has quit [Read error: Connection reset by peer]
emaczen has joined #lisp
Copenhagen_Bram has quit [Ping timeout: 272 seconds]
emaczen has quit [Read error: Connection reset by peer]
emaczen has joined #lisp
Copenhagen_Bram has joined #lisp
trocado has quit [Ping timeout: 252 seconds]
Oladon has quit [Quit: Leaving.]
DataLinkDroid has joined #lisp
<vsync>
humph, gonna be lazy (did look for 30sec though)
<vsync>
signaling an error in primary method prevents after-methods from running correct?
<vsync>
and, 1 after-method to another?
<trittweiler>
The signaling not per se, but the handling will most likely involve a transfer of control - so yeah.
<makomo>
but you can do the same for "iff" just by writing that macro
<Bike>
i figured (iff a b c) would expand into (let* ((#:1 a) (#:2 (when #:1 b)) (#:3 (unless #:1 c))) (if #:1 #:2 #:3)) which is obviously just a more complicated (if a b c)
<makomo>
yeah, that should be it
<shka_>
shrdlu68: it does not look like it chookes on hash-table
Lycurgus has joined #lisp
<makomo>
Bike: hm, i think i don't even need to rely on READF and the expander of IFF for the IFF macro
<makomo>
i can just expand into (if ,cond ,then ,else)
<Bike>
i'm not sure what readf is for, except i guess writing a complicated setf expander with complicated get, and wanting to not duplicate it
<makomo>
yeah, just a small utility. it's also used within SETF-EXPANDERLET i think
<phoe>
a portable Common Lisp interface to the WordNet database
<phoe>
I've been refurbishing it since yesterday and got satisfying results; now I'm trying to get an official license on it
kajo has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
<jackdaniel>
commendable effort
<shka_>
what is the origin of sxhash name?
<shka_>
sx prefix to be specific
<Bike>
it makes a hash of- oh.
<Bike>
well, it's in maclisp
schjetne has joined #lisp
adam_erc has quit [Remote host closed the connection]
rumbler31 has joined #lisp
Roy_Fokker has joined #lisp
SaganMan has joined #lisp
joni has joined #lisp
rippa has joined #lisp
<beach>
shka_: I am here now. No progress on the book.
<shka_>
beach: thanks for info
<beach>
I am hoping my favorite coauthor will have time to set up the infrastructure for testing the algorithms this year. Last year, she was on an all-research year, so she was buy doing that.
<makomo>
since the variable is used during macroexpansion
<Bike>
only if it's used within that file
<Bike>
doesn't look like it is
<makomo>
oh, right, forgot about that again...
<makomo>
right, nothing is actually using the macro
SenasOzys has joined #lisp
steiner has joined #lisp
rpg has joined #lisp
pierpal has quit [Ping timeout: 240 seconds]
igemnace has quit [Quit: WeeChat 2.2]
gravicappa has joined #lisp
rumbler31 has joined #lisp
nowhere_man has quit [Remote host closed the connection]
<beach>
So let's say that METHOD-COMBINATION is a class. Then presumably STANDARD, AND, PROGN, etc., would be instances of that class, right? But then, method combinations take options, so it would appear that a method combination metaobject is an instance of an instance of a class.
nowhere_man has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
Khisanth has quit [Ping timeout: 240 seconds]
montxero has quit [Ping timeout: 246 seconds]
<beach>
Let's call the last thing a "variant". FIND-METHOD-COMBINATION would check whether the name and the options describe and already existing variant and return it. DEFINE-METHOD-COMBINATION, on the other hand, would define an instance of METHOD-COMBINATION. Does this seem reasonable?
fikka has joined #lisp
DataLinkDroid2 has joined #lisp
<Bike>
you remember the els talk, right?
<beach>
I am reading the paper.
<beach>
And he sweeps a certain number of things under the rug.
<beach>
But he does not allow lambda lists in long method combinations, so no "use time" options.
<Bike>
i think he mentioned it, but find-method-combination makes more sense if it's called compute-method-combination
rumbler31 has quit [Ping timeout: 245 seconds]
<beach>
I agree.
eddof13 has joined #lisp
<beach>
Or ensure-method-combination perhaps.
<Bike>
is there any reason to have the "same" method combination use in two different generics be the actual same object, besides maybe saving some memory?
<beach>
There might be. Currently that is how it is done in SBCL according to Didier's paper.
<beach>
It is unappealing, for one thing.
<Bike>
unappealing to not cache?
<beach>
Yes.
<Bike>
how so?
DataLinkDroid has quit [Ping timeout: 256 seconds]
FreeBirdLjj has joined #lisp
<beach>
I have no strong argument to give.
<Bike>
mm
<beach>
Apparently, it works without a cache. The proof is that SBCL is doing it.
<beach>
But I think that's a minor detail.
<beach>
The main question is what kind of animal is the result of DEFINE-METHOD-COMBINATION and what kind of animal is returned by FIND-METHOD-COMBINATION.
<beach>
And I think DEFINE-METHOD-COMBINATION might make an instance of the class METHOD-COMBINATION.
<beach>
And, like I said, FIND-METHOD-COMBINATION might create a "variant" which is some kind of instance of the instance that was created by DEFINE-METHOD-COMBINATION.
<beach>
Whether that last thing is cached or not might be less important.
<Bike>
The way I think of it is that define-method-combination defines a kind of method combination, but the actual method combination objects have to be computed and have all the argument information. so they are "variants" so to speak.
<beach>
Yeah.
varjag has joined #lisp
<beach>
The other possibility is for DEFINE-METHOD-COMBINATION to create a subclass of METHOD-COMBINATION rather than an instance.
<beach>
Then FIND-METHOD-COMBINATION would instantiate the class.
<Bike>
in ECL and Clasp's implementation, the things like "standard" and "progn" don't really exist as objects, there's mostly just a hash table that stores the expansion function and stuff, and then the actual method combination object is equipped with that when it's created.
<beach>
I see.
<beach>
Either way, there has to be some kind of dictionary to look things up given the name.
<beach>
So a hash table seems reasonable.
<beach>
I would obviously stick that table in a first-class global environment.
<Bike>
yeah, it's more the lack of objects I'm thinking about
<beach>
Sure.
<beach>
But that would not be very SICL-like, now would it? :)
<Bike>
I think the "general" things are different from the specific "variants"- classes is one way I guess
<Bike>
yeah, just throwing functions in there is obviously not what you're going to go with
housel has joined #lisp
<Bike>
there's other information like the documentation
<beach>
Yeah.
Khisanth has joined #lisp
<dim>
beach: you're contemplating making every function (operator?) a generic function the same way that any data type is usable as an object?
<beach>
I am not considering making every Common Lisp function generic, no. I am not sure what it means for any data type to be usable as an object. I can't see how (integer 2 3) would be an object, other than in the trivial sense that it is a list of 3 elements.
pierpal has joined #lisp
<beach>
There are plenty of functions that can't really be generic.
<dim>
my vocabulary on those concepts is lacking, maybe I should consider reading the mop someday…
<beach>
Like +, *, list
<dim>
why can + not be generic?
<beach>
Because it can take 0 arguments.
<beach>
There would be no required parameters.
<dim>
oh.
<beach>
So there would be no way to specialize a method.
zfree has quit [Quit: zfree]
<beach>
Dylan handled it by making + a function and then binary-+ generic
<dim>
in math the zero-argument result of the + function would be named the neutral element in the group, right?
<beach>
Right.
<dim>
(N, +, 0) would be such a group
<Bike>
but it's not clear what the group is. fixnums and floats are different groups (i don't think floats actually form a group, but w/e)
<dim>
so maybe that's the missing piece that would allow for a generic +, where your specification would allow for a “neutral element” to be defined for any data type (integer, defclass instance, etc)?
<beach>
I am still interested in getting good performance, and I don't know how to do that without inlining and I don't know how to inline generic functions.
<dim>
I don't know, throwing ideas at you
<Bike>
dim: even if that was defined, there'd be no way to tell what data type is in use
<dim>
Bike: true that
<beach>
dim: I will make things like SYMBOL-NAME and SYMBOL-PACKAGE generic though, simply because it is easier to do that than to make them non-generic in SICL. Plus, the generic function would not do any more work than an ordinary function would do.
<beach>
Same with accessors on packages.
<makomo>
beach: what do you think about Fare's LIL? is it a feasible approach? i think i remember watching part of his 2-3 hour stream about LIL
<beach>
makomo: But I think Fare's goals are very different from mine.
shka_ has joined #lisp
<shka_>
good evening
<beach>
makomo: I would have watched it if I knew about its existence.
<beach>
Hey shka_.
<pjb>
The 0-ary CL:+ doesn't prevent to define a generic function SI:+ taking 1 or more arguments, with (defun cl:+ (&rest args) (if (zerop (length args)) 0 (apply (function si:+) args))) and to document it. If enough implementation do that, we could even standardize it!
<dim>
stylewarning: what would be the invert of an element in ℕ?
<makomo>
beach: but i'm not sure anymore whether i heard your voice or not, maybe i confused you for someone else :-)
emaczen has joined #lisp
<stylewarning>
dim: with respect to +, it would be the negative
<stylewarning>
Whatever x satisfies n + x = 0
Copenhagen_Bram has quit [Ping timeout: 246 seconds]
<dim>
so the invert would then be what is named usually the opposite in there, interesting
<beach>
makomo: It doesn't seem plausible.
<beach>
makomo: If it turns out to be true, I will go seek professional help for my bad memory.
<stylewarning>
makomo: beach sounds like a professor and someone who thinks about compilers sometimes
<makomo>
beach: haha :-)
<makomo>
stylewarning: :-)
<makomo>
stylewarning: oh, since you mentioned abstract algebra, i want to ask: what do you think is the relation (or is there any) between Lisp and abstract lagebra/category theory/etc., compared to the same thing but with Haskell for example?
Copenhagen_Bram has joined #lisp
<makomo>
the question is probably vague but maybe you can understand/guess what i'm getting at
ebrasca has quit [Remote host closed the connection]
<stylewarning>
makomo: I think there’s no intrinsic relationship, except that Lisp being dynamically typed allows you to get away with implementing broader protocols for algebraic structures
ebrasca has joined #lisp
doubledup has joined #lisp
<Bike>
haskell has a pretty specific relation through curry howard correspondence
<stylewarning>
makomo: Haskell type classes are limiting because they force you to choose one implementation that you want to be polymorphic over (in other words, you can only create one Group over Integer as a type class, even though integers have many such group operations)
<makomo>
stylewarning: do you say that because nobody ever formalized Lisp in those terms or? and would you say that Haskell does have such a relationship?
<stylewarning>
makomo: I say it because Lisp lets you implement things that arent adhering to a strict static type system
<makomo>
Bike: mhm
<stylewarning>
Standard ML lets you get a bit further than Haskell on this front by having “parameterizable signatures” called “functors”
m00natic has quit [Remote host closed the connection]
arbv has joined #lisp
fikka has quit [Ping timeout: 272 seconds]
DataLinkDroid3 has joined #lisp
random-nick has joined #lisp
DataLinkDroid2 has quit [Ping timeout: 256 seconds]
<flip214>
when interrupting QL during download of packages, and later on retrying (ql:update-all-dists), it just says "already updated" - and not-yet-downloaded packages are kept in the old version.
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
mkolenda has joined #lisp
pjb has quit [Read error: Connection reset by peer]
pjb has joined #lisp
FreeBirdLjj has quit [Ping timeout: 245 seconds]
cage_ has quit [Quit: Leaving]
fikka has joined #lisp
nowhere_man has quit [Ping timeout: 252 seconds]
housel has quit [Read error: Connection reset by peer]
SenasOzys has quit [Quit: Leaving]
<AeroNotix>
^confirmed this behaviour
<AeroNotix>
flip214: I doubt it's intended. It's a bug
pierpal has quit [Quit: Poof]
fikka has quit [Ping timeout: 244 seconds]
pierpal has joined #lisp
nika has quit [Quit: Leaving...]
<AeroNotix>
aaand now I've broke my quicklisp :)
<AeroNotix>
Xach: you might be interested in this^
rumbler31 has joined #lisp
rpg has joined #lisp
scymtym has joined #lisp
rumbler31 has quit [Ping timeout: 272 seconds]
fikka has joined #lisp
Oladon has joined #lisp
SaganMan has quit [Quit: WeeChat 1.6]
<aeth>
do not attempt to update Quicklisp?
<aeth>
Is it a bad bug?
iskander has joined #lisp
<phoe>
well
<phoe>
I think, in the worst case, delete parts of the quicklisp directory
<phoe>
it should try regenerating them
<phoe>
...or backup your local-projects and reinstall QL altogether
azimut has joined #lisp
<shka_>
gosh
<AeroNotix>
phoe: that's what I did to fix it
<shka_>
cowards
kristof has quit [Ping timeout: 246 seconds]
<shka_>
be brave!
<AeroNotix>
aeth: nah updating is "fine" as long as it doesn't crash part way through :)
<shka_>
update boldly when no man updated before!
jessup has joined #lisp
azimut has quit [Ping timeout: 272 seconds]
<phoe>
Xach: does quicklisp have any option to invalidate all archives and force-redownload everything?
azimut has joined #lisp
igemnace has joined #lisp
<shka_>
phoe: you can manually nuke your files
<shka_>
which is easy
<Xach>
phoe: not built-in. i delete stuff.
<Xach>
from the dist dir, rm -rf installed software archives
<phoe>
Xach: I suggest that to be added to the client, just for usability sake
<phoe>
(ql:nuke-archives :really t) would be enough I think
<shka_>
i don't think it is a good idea
<dim>
Xach: is it intentional that the directories in this order read like proper English? ;-)
<dim>
shka_: it could be protected to only do that when there's no diff known to the downloaded version
<shka_>
eh
<shka_>
dim: complicated
<shka_>
i think that you should do what you must, and do it perfectly
<shka_>
and this is just not critical
rpg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azimut has quit [Ping timeout: 272 seconds]
<dim>
refreshing a cache or force-download as an option would be contrary to your principle?
azimut has joined #lisp
jinkies has joined #lisp
<shka_>
dim: if it is just about deleting few files here and there: yes
<jeosol>
morning guys
j`ey has left #lisp [#lisp]
<jeosol>
Some of you are aware of my work on an optimization challenge using CL. I am presenting on Friday in Spain. Some of the complexity of the work is possible with the image-based development in CL and other CLOS features
<jeosol>
enabled layered complex functionality
<jeosol>
I will meet with other (larger service companies) who will be asking questions about how I did so and so. How have you guys dealt with such questions
<jeosol>
do you tend to hide your toolkit (e.g., choice of language) -- think Graham mentioned something about this.
<phoe>
why hide?
<jeosol>
haha
<phoe>
no, seriously
<jeosol>
good point phoe. CL is not remotely used at all
<phoe>
if your code is fast, it doesn't matter what code you've written it in
<phoe>
(though you do get bonus points if it's readable, factored and documented)
<phoe>
s/what code/what language/
<jeosol>
A company may be interested in the code and may want to get it on or convert to C++.
<phoe>
that's the perspective of a lot of people I've seen, and it's scary
<jeosol>
I did document the function interfaces and using long names where necessary
<phoe>
converting code from Lisp to C++ is doable, provided that you do all of the heavy lifting and debugging in CL before the translation (;
<jeosol>
I had one a few weeks ago to code up similar functionality in C/C++, after thinking about it (refreshing OOP in C++) I realized I can't replicated many things from CLOS or the ease, so I backed out.
<jeosol>
phoe: yes, it will be translating the CL code.
<jeosol>
I use a lot of around, :before and :after modifies in the CLOS parts to keep things clean and organized
<jeosol>
their concern will be I am the only one that knows the code very well, and CL not being common.
<phoe>
> and CL not being common
<jeosol>
phoe: thanks for the inputs btw
<phoe>
I laughed
<jeosol>
phoe: not from me. I have being using it for years since grad school
<phoe>
jeosol: one thing I'd do is actually prepare "why I can't easily translate this into C++"
<jeosol>
I mean from their perspective.
<shka_>
jeosol: well, i hope you will succeed
<jeosol>
phoe: good point
<phoe>
and start talking about the :before :after :around methods
<jeosol>
I have actually gather some info from lispworks webiste and all.
<phoe>
talk about the interactive debugger, livepatching etc (which aren't required but are extremely nice)
<phoe>
if you're using the metaobject protocol, you can mention it as well.
<jeosol>
phoe: yes, the debugging was a big plus, enabling interactive development.
<phoe>
that's why I said that moving from CL to C++ is doable once you have everything figured out in CL
<jeosol>
with write-compile-link cycle in the other languages, it won't be a pain
<phoe>
the debugging is amazing
<phoe>
and the interactivity enables instant feedback
<jeosol>
phoe: the reason for moving will be, "you are the only one that knows the code"
<dim>
jeosol: the only reason why CL would not be popular/common is that not enough people are using it, so the only cure is that more people would use it?
voidlily has quit [*.net *.split]
stylewarning has quit [*.net *.split]
thekolb has quit [*.net *.split]
Ziemas has quit [*.net *.split]
cpt_nemo has quit [*.net *.split]
tobel has quit [*.net *.split]
danlentz has quit [*.net *.split]
convexferret has quit [*.net *.split]
rme has quit [*.net *.split]
CEnnis91 has quit [*.net *.split]
jhei has quit [*.net *.split]
p_l has quit [*.net *.split]
drmeister has quit [*.net *.split]
splittist has quit [*.net *.split]
stux|RC-only has quit [*.net *.split]
<jeosol>
not like I can get insane speeds
zooey has quit [*.net *.split]
kushal has quit [*.net *.split]
<jeosol>
dim: thanks dim
<phoe>
dim: correct, except "it won't be our company that pays people to learn this alien language" mentality
<jeosol>
I actually tried to start a small meet up group in my area to teach CL
<dim>
jeosol: what's your goal in that presentation?
<dim>
land a job, show CL is awesome, win a challenge, something else?
<jeosol>
the goal is the application to a problem, not CL per se.
Ziemas has joined #lisp
<jeosol>
but there will be vendors who may be interested in how I was able to organize the code and achieve some of the things I am claiming ...
<dim>
yeah yeah but yourself, what do you expect out of your presentation?
<aeth>
AeroNotix: That's not QL-specific. I've had Linux package manager issues if I lose power during an update/upgrade in the past.
<jeosol>
dim: I see.
<aeth>
(Unless QL is crashing.)
random-nick has quit [Read error: Connection reset by peer]
<jeosol>
dim: I guess I would say, to garner interest from the larger companies who may be trying to get into the space and would need a large code base to pick up.
<dim>
jeosol: without that I can't help you decide how to organize the presentation, if you don't care for yourself just explain why you picked CL and then how it helped, but only as an appendix — always begin with the result, the take away
<jeosol>
dim: this is where I think the issue of "only you can work this code will come up".
<jeosol>
dim: thanks
<dim>
gardner interest into what?
<jeosol>
dim: software
stux|RC-only has joined #lisp
<phoe>
jeosol: "well, translating this code to C++ will surely make it worse and you'll lose a lot of the tactics that aren't possible with C++ - why don't you teach your people better languages instead?"
<dim>
I'm sorry jeosol it seems I can't read/think tonigh
voidlily has joined #lisp
kushal has joined #lisp
zooey has joined #lisp
<jeosol>
dim: I am proposing some new features and how to solve an existing problem, and CL really enabled this. but the initial focus for the presentation is not CL per se. It's domain area specific."
<dim>
you want them to be interested into the software you wrote, is that right?
<jeosol>
The vendors are the ones that my want to follow up later.
<dim>
I'd just spend about 0 time on CL then
<phoe>
^
<phoe>
only tell them if they're curious about the "how"
<jeosol>
dim: yes, it's 0 time on CL. No CL on my slide at all
<phoe>
truly the secret sauce
<dim>
just explain how your solution is better than the other ones, show what “technology lock” you managed to break through
<jeosol>
I am talking of follow up conversations later, when issues of conversation or sticking with CL (with me running things)
<dim>
if they want your thing they won't care
<dim>
if they don't want your thing they won't care
<dim>
ok course that's simplifying a lot, but well
<aeth>
If they are pg they will care.
<jeosol>
dim: I was thinking they complain about the choice of language. I get your point.
<dim>
of course they will
dale has joined #lisp
<dim>
it's because it represent a change that they didn't decide nor anticipate
Pixel_Outlaw has joined #lisp
<dim>
so your only possible course of action is saying “yes it's in CL”
<dim>
they will go through the usual change phases: deny, anger, bargain
<jeosol>
The reason I am concerned on how to spin it (continue CL with me, or we convert) is that,
<dim>
“no it can't be” “yes it is”
<dim>
“WHY?“ “CL is fine, it's the best, it's done is CL”
<jeosol>
dim: I see. thanks
<dim>
“can we do it in C++ instead?” “I don't think I could have done it in C++, that's why I've done it in CL”
<AeroNotix>
aeth: QL can do something better in this situation
<dim>
and then when they begin to ask what's so good about CL, then you can begin to answer, slowly
<dim>
before that, you loose your time and energy
<dim>
it's just human people and change really
<jeosol>
as phoe mentioned above, interactive enabled rapid feedback. it's a big plus in my development. Some of the load times (without saving image) is around 10 minutes to re/load the problem.
<jeosol>
dim: thanks
<dim>
jeosol: search for the change curve and https://en.wikipedia.org/wiki/Kübler-Ross_model applied to politics/management/change
<jeosol>
dim: thanks. I would like to lead an internal effort to use CL somewhat, but be able to have that discussion in the beginning and explain why CL was better.
<jeosol>
dim: btw, are you with citusdata now?
<dim>
I am, yes
<jeosol>
dim: that's a useful link. I will study it as I start locking horns with these guys.
<dim>
jeosol: before you can lead that effort, people in power must have understood why CL is good for them, and you have two options: drive the change, or make them drive the change by allowing them to pretend it's their own idea
housel has joined #lisp
<dim>
or you can also take power, usually that's more complex
gpiero has joined #lisp
<jeosol>
dim: thanks, I would like to drive that change, like lead the effort, and find CL developers, or teach or sth.
<dim>
they need to accept the change then, and there's nothing much technical or CL specific in that approach, I believe
<jeosol>
I feel it is easier to continue in CL, code is cleaner, and after questions here and at comp.lang.lisp, I was able to get it to run for weeks with no issues.
<dim>
I know beach has some very good content to help approach choosing a programming language and CL in particular, though, and that might help you there
<jeosol>
dim: yes, that is example of materials I am trying to gather to make very solid arguments
<dim>
I believe it only helps when they have reached a certain point in the acceptance curve though, before that all you can say is “yes it's Common Lisp”
<jeosol>
conversion will be a pain, I came from C/C++
<dim>
refrain from using your arguments early
<jeosol>
dim: thanks for that info
<dim>
early they want to show why change is not necessary, and remember to spot the steps denial/anger/bargain, only make your move after that
<jeosol>
dim: thanks. The kubler-ross model thingy will be useful. I anticipate a lot of why CL and not some other language, e.g., Java,C/C++. Like you said, it is not so much like gathering the benefits of CL but I guess how you sell it.
<jeosol>
I remember reading some document here why JPL stopped using CL
<russellw>
I read the NASA one awhile back. In a nutshell, they needed C aboard their spacecraft because when you are programming embedded real-time control software, C always comes into the picture, and then it turned out to be awkward to integrate two completely different programming languages in a tiny spacecraft control computer when there was no room for error
akovalenko has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
<trittweiler>
jeosol: Ravenpack.com is based in Marbella, Spain, and uses Common Lisp. May be interesting to you, for the upcoming presentation and perhaps personally in case you can consider relocation :)
<russellw>
Then they made an excuse about lisp being too slow, so someone spent a couple of years making it run faster, but it was a waste of time because this was not the real reason in the first place. Moral of that story: be careful of the difference between reasons and excuses. In programming, 'too slow' is more often an excuse than a reason
dale has quit [Quit: dale]
<jeosol>
trittweiler: Thanks for that. I will be in Barcelona, not sure how close. But I will try to reach out if they still/use CL heavily.
it3ration has quit [Ping timeout: 240 seconds]
<dim>
they presented their use at the ELS 2018 (conference in Marbella) and I think they are still heavy users of CL yes
<jeosol>
dim: hmm, interesting about google flights, if they are still using the ITA software in CL
<trittweiler>
jeosol: not close; I thought you may be spaniard yourself :)
<aeth>
jeosol: Here's how you say it imo: There's the right tool for every job to get the problem solved in the simplest way. These days, that means being multilingual.
<Xof>
google are most definitely still using the CL version in Google Flights
<jeosol>
aeth: I agree with that. Being multilingual
<jeosol>
for some of the ML/AI related tasks, I am making calls to python libraries from CL. Didn't have much success with the clml lib but will go back to it later.
stylewarning has joined #lisp
<jeosol>
I think for the overall layering and organization, debugging, interactive development, CL helped a lot.
<jeosol>
a former colleague saw my screen and wondered why I was working with parentheses all the screen. It was jarring for him.
Inline has joined #lisp
<jeosol>
all: I appreciate the feedback you guys have given. very useful with the links also.
<trittweiler>
Maybe you want to use a reader-macro that turns #\( to #\< and #\) to #\>, so it will look like xml
<dim>
parens... it took me about one week before I didn't take, and a couple months before every other programming language would look weird to my eyes
<dim>
in C/Java parens translate to (){}[]; and then you realise that mostly lisp code uses less parens than C/Java
Inline has quit [Read error: Connection reset by peer]
<jeosol>
dim: good point dim
Inline has joined #lisp
<jeosol>
one of the benefits of CL too, I don't have to remember too my language syntax
<jeosol>
that reduces mental burden a lot
josemanuel has joined #lisp
<oystewh>
(defun make-func (x) (lambda () (+ x 10)))
<oystewh>
((make-func 10))
<oystewh>
doesn't work -- why?
<Bike>
(funcall (make-func 10))
<AeroNotix>
oystewh: lisp 1 vs lisp 2
<oystewh>
but ((lambda () (+ 10 10))) works
asarch has quit [Ping timeout: 245 seconds]
<oystewh>
it's a closure - aha
<pjb>
oystewh: nope.
<pjb>
oystewh: the only operator that can create closures is cl:function. In ((lambda () (+ 10 10))), no cl:function occurs, therefore no closure.
<oystewh>
i mean, make-func returns a closure
<pjb>
Ah, above.
<pjb>
oystewh: notice that in make-func, lambda is a macro that expands to (cl:function (cl:lambda () (+ x 10))) ; so it returns a closure.
gpiero has quit [Ping timeout: 252 seconds]
<pjb>
(let ((x 24)) ((lambda (y) (+ x y)) 18)) may look like a closure, but it's actually equivalent to (let ((x 24)) (let ((y 18)) (+ x y))).
<phoe>
pjb: uh, only cl:function can create closures?
<phoe>
oh right
<phoe>
you're correct
<pjb>
granted, an implementation could also compile (let ((x 24)) ((lambda (y) (+ x y)) 18)) as: (let ((x 24)) (funcall (lambda (y) (+ x y)) 18)) and here a closure would be created. But it would be anti-optimizing. (pessimising).
<Bike>
oystewh: it's a syntax thing. Function calls can be either (function-name ...) or ((lambda ...) ...). You can't compute the function like in scheme.
<oystewh>
ah ok
<oystewh>
i was working with the substitution model that i think i got from SICP
oni-on-ion has joined #lisp
<Bike>
if you want to call a function you compute you just use the funcall function like i indicated.
<oystewh>
yup thanks
gpiero has joined #lisp
rumbler31 has joined #lisp
akovalenko has joined #lisp
rumbler31 has quit [Ping timeout: 252 seconds]
oni-on-ion has quit [Quit: WeeChat 1.9.1]
zooey_ has joined #lisp
zooey has quit [Remote host closed the connection]
rpg has joined #lisp
kuwze has quit [Ping timeout: 252 seconds]
vlatkoB has quit [Remote host closed the connection]
thekolb has joined #lisp
Lycurgus has quit [Quit: Exeunt]
oni-on-ion has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
Roy_Fokker has joined #lisp
ealfonso has quit [Disconnected by services]
ealfonso has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
fikka has joined #lisp
shka_ has quit [Ping timeout: 272 seconds]
fikka has quit [Ping timeout: 245 seconds]
gravicappa has quit [Remote host closed the connection]
bigfondue has quit [Ping timeout: 252 seconds]
CEnnis91 has joined #lisp
v0|d has joined #lisp
papachan has quit [Ping timeout: 245 seconds]
nirved has quit [Ping timeout: 240 seconds]
nirved has joined #lisp
housel has quit [Read error: Connection reset by peer]
housel has joined #lisp
mrcom has quit [Ping timeout: 272 seconds]
<AeroNotix>
Is there a library for lexing assembly?
nckx has quit [Quit: Updating my GNU GuixSD server — gnu.org/s/guix]
<AeroNotix>
I know it's quite a trivial thing to parse but wanted to know if something was already out there.
bigfondue has joined #lisp
nirved has quit [Ping timeout: 240 seconds]
it3ration has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
papachan has joined #lisp
it3ration has quit [Ping timeout: 246 seconds]
nckx has joined #lisp
mrcom has joined #lisp
Denommus has quit [Ping timeout: 240 seconds]
it3ration has joined #lisp
pierpa has joined #lisp
it3ration has quit [Remote host closed the connection]
it3ration has joined #lisp
<no-defun-allowed>
There's a lot of kinds of assembly syntax. What kind?
fikka has joined #lisp
<no-defun-allowed>
(nasm vs gas, arm vs x86, etc)
<dim>
disassemble output varies from an implementation to another, too
<dim>
CCL outputs "forms" I believe
fikka has quit [Ping timeout: 244 seconds]
lumm has quit [Read error: Connection reset by peer]