<phoe>
but to my defense, back when I wrote this wrapper, I didn't know about STATIC-VECTORS.
EvW has joined #lisp
<_death>
I just wrote some terrible lisp as well ;)
<aeth>
I need to look into moving over to static-vectors
<phoe>
...
<phoe>
CFFI's FOREIGN-ARRAY-TO-LISP allocates vectors of element type T
<phoe>
it completely ignores element types
<phoe>
where it could specialize for octets for example
t0adst00l has quit [Ping timeout: 272 seconds]
<phoe>
this sucks curly braces
<_death>
this would break backwards compatibility
<phoe>
yes, yes, I know.
<phoe>
but using static-vectors gives me foreign octet vectors.
<phoe>
and I don't need to COERCE, which probably causes all the insane consing.
<phoe>
I'll switch over to them.
<aeth>
What I try to do is convert while doing a useful operation. So, e.g. I can multiply two CL-native matrices *into* a foreign C matrix rather than having a translation step.
<aeth>
Whether or not that can work for you depends on your specific problem.
Amplituhedron has quit [Ping timeout: 264 seconds]
<_death>
ugh, performing computation on a 512M RAM droplet's live image isn't such a good idea.. unless you like meeting the oomkiller
<pagnol>
type-check doesn't let me say that something may also be nil, does it?
<_death>
pagnol: (or something null)
<pagnol>
terrific, thank you
<aeth>
_death: Sounds like a good use case for preallocating literally everything. It's hard, though.
t0adst00l has joined #lisp
<p_l>
_death: that's when swap becomes your friend :D
<_death>
in this case it's as simple as running it on my machine and pushing the resulting database
<phoe>
aeth: my case is dead simple, I have a wrapper around a LZMA library that does (de)compression. It needs raw chunks of uchars to operate on. I need to provide these chunks to it in the cheapest way possible.
<phoe>
No matrix multiplication here or anything.
<phoe>
Anyway - see you tomorrow. Good night, #parentheses.
nirved has quit [Quit: Leaving]
damke_ has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
damke has quit [Ping timeout: 264 seconds]
smurfrobot has joined #lisp
conceivably has joined #lisp
smurfrobot has quit [Ping timeout: 264 seconds]
DeadTrickster has quit [Read error: Connection reset by peer]
DeadTrickster has joined #lisp
randomstrangerb has quit [Ping timeout: 248 seconds]
<jmercouris>
yeah, that seemed to fix it, thank you
<jmercouris>
at least part of the problem
DeadTrickster has quit [Read error: Connection reset by peer]
DeadTrickster has joined #lisp
Oladon has joined #lisp
<whoman>
^_^ what else?
<jmercouris>
It is a GTK type of issue, basically I can't add things to a GTK list store (model part of mvc for gtk tree view) that are not strings, therefore I have to maintain two lists, one of my actual objects in my model, and one of their string representation
<jmercouris>
So I know what I need to do, it's just kinda a dumb limitation to the way GTK works, I never thought I'd be glad for cocoa delegate model
<p_l>
is there no way to subclass whatever it accepts?
<jmercouris>
p_l: Not that I am aware of, I'm using cl-cffi-gtk, which seems to be a very thin layer over C
megalography has joined #lisp
<jmercouris>
It is okay though, it's just for the first release of GTK, I'm sure when some GTK users use it, they'll submit some PRs, at least I hope :D
djinni` has quit [Read error: Connection reset by peer]
djinni` has joined #lisp
<jmercouris>
p_l: Correct, but it has to be a GObject, can't be a Lisp object
<jmercouris>
and You can't write your own like "value_for_row" method
<p_l>
jmercouris: yes, and the library provides you with an interface to subclass something that acts as GObject
<jmercouris>
p_l: I didn't see that actually, but the issue is that I need to display any kind of arbitrary object within the tree view
<jmercouris>
p_l: It is for my minibuffer completions, they are just the lisp objects passed to the view to be rendered, in cocoa I do (write-to-string object) and it'll show that object representation for any arbitrary object I add into the model
<p_l>
jmercouris: I'd honestly just try subclassing the list-store class
<p_l>
or subclass tree-model and implement the iteration methods, actually
<jmercouris>
p_l: that makes a lot of sense, but do I know which methdos I need to implement?
<jmercouris>
rather, how do I know which methods I need to implement
<p_l>
hard to say, but I suspect it might just as well be possible to subclass and override the list-store one
<jmercouris>
Hmm yeah, that way is definitely possible
<jmercouris>
but I don't want to alter the completions by having to make them be a subclass of GObjects, because it has to work for both Cocoa and GTK
<p_l>
no, no
<jmercouris>
Am I misunderstanding? Can you dynamically subclass in CL or something?
<jmercouris>
At any rate, the completion will eventually pass back the original object to the c
<jmercouris>
completion handler, sorry pressed return instead of delete
<pagnol>
I just found it that it's possible to define macros inside macros
<pagnol>
how awesome
<pagnol>
*found out
<aeth>
That's probably the wrong approach.
<pagnol>
aeth, do you mean me?
<jmercouris>
aeth: What do you mean?
fikka has quit [Ping timeout: 256 seconds]
<aeth>
pagnol: You probably want to use helper functions within an eval-when when macros get really complicated.
<p_l>
jmercouris: you could probably subclass a GtkLabel or something like that, as a wrapper around any random CL object, then put it into list-model
laurus has left #lisp ["Part"]
<jmercouris>
p_l: That's a creative approach, make like a subclassed gobject container object?
<jmercouris>
Why not just something like gojbect-container-object with a slot for a lisp object
<jmercouris>
and of course gobject-container-object would subclass gobject
<p_l>
jmercouris: yeah, subclass gtk-label, adding an extra slot (reference to CL object) and applying an afer method on initialize-instance that sets up the label to be stringified form of the passed in object
<jmercouris>
But why subclass gtk-label instead of gojbect directly?
<pagnol>
aeth, I have set up a macro that defines a class and would like to have another macro that lets me operate on instances of the class defined by the first macro
<jmercouris>
s/gojbect/gobject
<pagnol>
the second macro would like some knowledge that the first macro had... so I'm wondering if I can store something globally for the second macro to pick up?
<pagnol>
*would need some knowledge
<aeth>
pagnol: You could create functions instead of macros, and ideally put that knowledge within the defun you're generating. The general advice in this channel is "Does that have to be a macro or can an inline function work?"
<p_l>
jmercouris: hmm, it looks like you can't just put a widget reference in TreeModel, but you can put in any random crap and write your own renderer
<aeth>
pagnol: Although I'm not sure about your exact details
<pagnol>
it's probably possible... probably since I just learned how to use macros I'm trying to apply them a bit overzealously
d4ryus1 has joined #lisp
<jmercouris>
p_l: I think I'll do things the hacky way for now, I don't really care to become a GTK expert, it'll take time anyway for me to learn it
<aeth>
You could even put a closure around the function instead of making that information global, e.g. `(let ((foo ,vital-information)) (defun ,generated-function-name (x) (some-function-call foo 42)))
<jmercouris>
head my is full of cocoa stuff right now anyway :D
<p_l>
jmercouris: well, if you're willing to go a bit crazy, there's always the option of using cocoa on other platforms
<p_l>
(yes, it works)
<jmercouris>
p_l: I'm already using Cocoa :)
<jmercouris>
This is me working on the GTK port of my software
<p_l>
jmercouris: yeah, but I mean on *other* platforms so you don't have to deal with GTK :P
<jmercouris>
Ah yes, that is a whole different challenge :D
<jmercouris>
if I ever get some money I'll hire someone who knows GTK
<jmercouris>
and someone who knows Cocoa, and I'll only write the Lisp part
<p_l>
jmercouris: People have, afaik, succesfully used GNUstep and Cocotron with CCL
<jmercouris>
p_l: Oh yeah, definitely, I've seen +cocotron inside the CCL sources, but I wouldn't get any benefits of cocoa, because I don't believe cocoa webkit is ported to Linux :P
d4ryus has quit [Ping timeout: 256 seconds]
<jmercouris>
I'll actually eventually even have to change the completion model because I would like to make the interface effectively like a server
<jmercouris>
where the Lisp code is the client/model, and the GUI is the server, and just contains EXTREMELY minimal code
<jmercouris>
my GTK port right now is just 214 lines, the Cocoa one is 285
<jmercouris>
so, writing a port is quite trivial
<p_l>
hmmm
<jmercouris>
beach gave me some good advice in this respect early on, which helped a ton
<p_l>
I think the easiest webkit wrapper was with beach
<p_l>
s/beach/commonqt/
<p_l>
brainfart
<jmercouris>
lol
<jmercouris>
yes, but commonqt is extremely far behind upstream
<jmercouris>
this means if servo comes out tomorrow, I could adapt nEXT to use servo, with basically one or two weeks worth of work
<jmercouris>
I didn't want to be strongly beholden to one system
<aeth>
pagnol: Just as a rule of thumb: macros deal with bindings and places (I hope I'm using the correct terminology). So: define-foo, let-foo, do-foo, with-foo, etc., or any use of define-modify-macro such as inc-foo-f.
<aeth>
Even a lot of those macros can be written as thin wrappers over functions.
<p_l>
jmercouris: I expect Servo to be a hard thing to integrate
smurfrobot has joined #lisp
pagnol has quit [Ping timeout: 260 seconds]
conceivably has quit [Remote host closed the connection]
smurfrobot has quit [Ping timeout: 248 seconds]
Kaisyu7 has joined #lisp
Vicfred has quit [Ping timeout: 248 seconds]
makomo has quit [Ping timeout: 260 seconds]
orivej has joined #lisp
jmercouris has quit [Ping timeout: 264 seconds]
igemnace has quit [Read error: Connection reset by peer]
igemnace has joined #lisp
jmercouris has joined #lisp
<jmercouris>
p_l: You're not wrong, in general, but the API is extremely small, and IPC can happen over sockets in the worst case scenario
damke has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
dddddd has quit [Remote host closed the connection]
igemnace has quit [Read error: Connection reset by peer]
dieggsy has joined #lisp
<jmercouris>
pjb: I've read that a few times now, not able to follow it anymore
igemnace has joined #lisp
orivej has joined #lisp
<jmercouris>
What does #| mean?
JonSmith has quit [Ping timeout: 256 seconds]
<pjb>
STRING takes a string designator, which is either a character, a string or a symbol, and returns the corresponding string.
<pjb>
#| is a comment #| and a comment inside a comment |# that ends here |#
<pjb>
INTERN takes a string and returns a symbol.
<jmercouris>
ah okay, I just had a momentary lapse of reason :D
<pjb>
SYMBOL-NAME takes a symbol and returns a string (naming the symbol).
Vicfred has joined #lisp
<pjb>
CHARACTER takes a character designator (which is a character, a string with 1 character or a symbol whose name is a string with 1 character) and returns the corresponding character.
<jmercouris>
yeah, I saw those mentioned in the cl cookbook as well
<pjb>
So those functions let you go between character, string (of 1 character) and symbols (whose names are string of 1 character).
Karl_Dscc has quit [Ping timeout: 272 seconds]
nika has joined #lisp
jack_rabbit has joined #lisp
z3t0 has joined #lisp
KarlDscc has quit [Remote host closed the connection]
asarch has quit [Quit: Leaving]
<jmercouris>
pjb: Do these kinds of functions exist for all built-in data types?
Andrew_ has joined #lisp
Andrew_ is now known as OS-26949
<jmercouris>
is there something like (INTEGER) as well? or do we have to use parse-integer?
<jmercouris>
just tested in a repl, oh well :(
<jmercouris>
I guess characters and strings have a much more intimate relationship
turkja has joined #lisp
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 248 seconds]
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 272 seconds]
<fiddlerwoaroof>
The most annoying thing to me about the CL standard, is there isn't anything in it besides READ-FROM-STRING and PARSE-INTEGER for converting strings to numbers
schoppenhauer has quit [Ping timeout: 264 seconds]
<fiddlerwoaroof>
So, you have to use something like the PARSE-NUMBER package to parse arbitrary numbers
<aeth>
There are many annoying things about the CL standard.
schoppenhauer has joined #lisp
z3t0 has quit [Remote host closed the connection]
<beach>
I don't understand this argument. So many people are using languages that don't even have a standard. Why is it a disadvantage to have at least SOME features standardized?
<fiddlerwoaroof>
I'm not making that argument
<beach>
It sounded like you did.
<fiddlerwoaroof>
I'm just saying that it's a bit awkward to have PARSE-INTEGER but not PARSE-FLOAT or similar
<beach>
But you don't have to. Use something that is not in the standard.
<p_l>
I think it's more like my usual argument, that CL standardized too little
<beach>
You are not forced to use the stuff in the standard.
<aeth>
fiddlerwoaroof: We should keep a list of things that should be added to the standard one day.
<Bike>
but it would be nice if it was in the standard, since the implementation has to have it anyway
<beach>
All those people who use non-standardized languages use features that are not standardized all the time.
<aeth>
beach: I think the general argument is that there should be additions to the standard, not that there should be no standard.
<p_l>
well, by now, we have an unofficial living standards as well, could be nice if it was somehow codified
<beach>
Bike: Yes, but that's pointless wishing because it aint gonna happen.
<fiddlerwoaroof>
Yeah, I'm actually happy with the CL standard as-is
<Bike>
how pessimistic
<p_l>
beach: well, maybe not ANSI standard
shka has joined #lisp
<p_l>
but an, let's say, "Open Common Lisp Standard - 2018" could be written ;)
<fiddlerwoaroof>
It's more a matter of aesthetics: there seem to be a couple lacunae in the standard that are a bit surprising
<fiddlerwoaroof>
I'm perfectly happy, though, with the way, say, threadings and sockets are standardized.
<aeth>
p_l: A good starting point would probably be de facto minimum sizes. The size minimums (e.g. for maximum array lengths or fixnum bit sizes) in the standard are tiny and afaik 16-bit-friendly. It would be enlightening to see what the actual minimum sizes are for actual 32-bit and 64-bit implementations, especially if there is a de facto standard that most follow.
<fiddlerwoaroof>
s/threadings/threading/
<aeth>
p_l: e.g. A de facto minimum fixnum size for 64-bit implementations should be 60-bit, since that afaik safely covers all of them except clisp.
<Bike>
that doesn't seem that good
<aeth>
If non-conforming implementations can be patched to obey de facto minimums, library authors can make more assumptions.
<aeth>
Bike: Right now, any string longer than 1024 might not run on a conforming CL implementation.
<beach>
I personally think that there are more urgent things to do than to attempt to improve the standard. We need programming tools and libraries.
<p_l>
aeth: fossilizing ASDF a bit and including it in said standard would cover a pretty big hole left by politics and even worse reasons
djeis has joined #lisp
<Bike>
the whole idea of things being declared fixnum instead of unsigned-byte whatever is kind of unfortunate imo
<p_l>
beach: I sometimes think we also need plain old discoverability
<p_l>
beach: Just today I learned what's the real state of cl-cffi-gtk, and I was blown away
<fiddlerwoaroof>
In a good or bad way?
<p_l>
in VERY good way
<aeth>
Bike: If nothing else, it would be nice to know what array-total-size-limit's actual practical minimums are in 32-bit and 64-bit
<fiddlerwoaroof>
Ah
smurfrobot has joined #lisp
<fiddlerwoaroof>
I used that at one point, but it's a bit annoying because I gather that the GTK developers are a bit inconsiderate of non-Gnome users of GTK
<Bike>
i don't see why you can't query the implementation for that
<Bike>
but, sleep
Bike has quit [Quit: leaving]
<p_l>
"where's the gui library" is veeeery common question ultimately, and the answers were always full of problems...
<p_l>
fiddlerwoaroof: true :<
<fiddlerwoaroof>
CAPI is also really nice
<p_l>
fiddlerwoaroof: yeah, but CAPI is LW-only
igemnace has quit [Ping timeout: 260 seconds]
<fiddlerwoaroof>
I wish LispWorks would just open it up so someone could port it cross-implementations
<fiddlerwoaroof>
of course, it's probably their main selling point, so....
<fiddlerwoaroof>
I would commit to mcclim a lot more, if I could make it run on all my platforms :)
jack_rabbit has quit [Ping timeout: 248 seconds]
<aeth>
fiddlerwoaroof: Imo Gnome 3 killed GTK, it's just taking a long time for the slow death to happen
igemnace has joined #lisp
<p_l>
as for programming tools and libraries - I'd love a HTTP/2 lib, better crypto libs (ironclad isn't), Grpc lib, convenience libraries for writing servers/clients, REST-style
<fiddlerwoaroof>
So, right now, I'm mucking about with a cross-implementation objc/lisp bridge to fix the mac side
<aeth>
GTK apps just look ugly and non-native everywhere except for Gnome 3.
<p_l>
aeth: unfortunately they poisoned everything else through Wayland
<fiddlerwoaroof>
Hmm, my experience has generally been that GTK is better than Qt as far as cross-platform gui libraries go
<p_l>
(fun fact: Wayland + a ton of custom behaviours is the only really supported GTK3 platform)
<fiddlerwoaroof>
Another project I've been thinking about is an entirely-lisp graphics stack
<djeis>
Mezzano? :p
<fiddlerwoaroof>
But, it's a pain to setup a development environment for such a thing on a laptop that's always on the brink of running out of disk space
<aeth>
Mezzano is imo approaching things the wrong way.
<fiddlerwoaroof>
djeis: no, more like a lisp replacement for X on top of linux
<aeth>
Start at the highest level, replace things on your way down.
<fiddlerwoaroof>
Mezzano is, however, extremely impressive
<aeth>
It is.
<aeth>
I just don't think it will ever have users.
<djeis>
fiddlerwoaroof: an X replacement in Lisp would be neat. Oh! Ulubis.
<aeth>
If you replace a Unix piece by piece, you might get some users, at least of pieces.
<fiddlerwoaroof>
aeth: I think you need both approaches, there's so much between distance the top and the bottom that it would take forever
<fiddlerwoaroof>
Yeah, my vision is to wrap the linux kernel with a bunch of lisp :)
<fiddlerwoaroof>
e.g. a lisp-init, a lisp-display server, etc.
<aeth>
fiddlerwoaroof: Emacs is almost there with Emacs Lisp, too bad Emacs Lisp is essentially stepping in a time machine back 30 years.
<fiddlerwoaroof>
But, I'm fairly unlikely to actually do this
<aeth>
Emacs Lisp is, at least, further along than CL is. You have e.g. eshell
<aeth>
You can almost live entirely in Emacs. CL just has stumpwm afaik.
smurfrobot has quit [Ping timeout: 256 seconds]
<djeis>
You can actually build a half-decent DE in emacs
<fiddlerwoaroof>
stumpwm is pretty nice
<aeth>
The main applications I run in stumpwm are emacs, lxterminal (with zsh), and firefox, though.
<aeth>
None of those use CL
<aeth>
So it only replaces one tiny slice of the system.
<fiddlerwoaroof>
Yeah, I use emacs, roxterm, chrome
<fiddlerwoaroof>
But, I have commands that allow for some interesting workflows
<fiddlerwoaroof>
Like, highlight some text, hit <C-/><RET> and open a google search for the text
<fiddlerwoaroof>
Hmm, on that note, does lem have a graphical mode now?
<fiddlerwoaroof>
Yeah, via electron
smurfrobot has joined #lisp
pierpa has quit [Quit: Page closed]
<aeth>
CL needs an editor (with replacements for slime and magit), a terminal, multiple shells (standard sh, extended sh like bash or zsh, and sh mixed with CL like eshell), and a web browser. Then, running on stumpwm, you get a much larger percentage of your time actually in the CL ecosystem.
<fiddlerwoaroof>
lem seems to be coming along nicely as an editor
<aeth>
Of these, only the multiple shells one sounds even remotely doable because it's not graphical
<aeth>
fiddlerwoaroof: The problem with editors is that you have to compete with Emacs.
<aeth>
You can probably beat Emacs in code quality and performance, but not in features.
<fiddlerwoaroof>
If lem had an evil-mode, I would seriously give it a try
djeis has joined #lisp
<fiddlerwoaroof>
Maybe there's another project for me to put off
<aeth>
fiddlerwoaroof: well, vim lost the CL community a while ago :-p
<aeth>
You would need something like evil though, yes
smurfrobot has quit [Ping timeout: 240 seconds]
<fiddlerwoaroof>
I tell my coworkers that the best implementation of vi is written in emacs lisp
ryanbw has quit [Remote host closed the connection]
<aeth>
You'd need equivalents for (at least) paredit (and its numerous competition), magit, evil, and slime
<fiddlerwoaroof>
lem has slime
<aeth>
You'd also probably need modes for other languages because usually people don't program exclusively in CL, which complicates things
<fiddlerwoaroof>
including a mode where it connects to its own lisp impl
<aeth>
SLIME is probably the easiest to get
<fiddlerwoaroof>
There's actually a pure-lisp implementation of a swank client
smurfrobot has joined #lisp
<aeth>
right, SLIME is really about swank
<fiddlerwoaroof>
Which I've found useful occasionally
djeis has quit [Client Quit]
<fiddlerwoaroof>
lem also has a vi-mode
<fiddlerwoaroof>
interesting, this could be really cool...
<jmercouris>
aeth: You'll have a web browser REALLY soon
<aeth>
A CL editor would probably have to support C, C++, Python, Perl (although that's increasingly irrelevant), Scheme (at least Guile and Chicken), Racket, and Clojure.
<jmercouris>
aeth: I think tomorrow I'll release an alpha, and then maybe make an official release sometime this week, if I can get cl-webkit to run on my machine
jack_rabbit has joined #lisp
<aeth>
oops, I left out shell and configuration files, those are important, too
<fiddlerwoaroof>
I'm sort of in the "lisp-only" bandwagon
<fiddlerwoaroof>
It's not really a problem that DrRacket only supports racket, for example
<jmercouris>
What are some reasons for rewriting emacs in cl?
<aeth>
jmercouris: Performance. Better code quality. Better interoperability with the CL ecosystem.
<pjb>
Because we prefer to write and debug Common Lisp code, rather than C code.
<pjb>
jmercouris: emacs core is written in C!
<aeth>
jmercouris: Emacs is a terminal application that glued on a GUI later, so it has really ugly internals afaik.
<aeth>
(Of course, many people here would consider any C ugly internals.)
<jmercouris>
Hmm, I guess performance hasn't really been an issue for me in emacs
<jmercouris>
my use case of course doesn't represent everyones
<jmercouris>
Also yeah, I would help with emacs if it were not written in C
<aeth>
fiddlerwoaroof: I was just thinking about things that one might have to edit in a Unix environment. That will include C, C++, Python, Perl, shell, and even possibly Ruby in some distros.
<jmercouris>
like "core" emacs, whatever that means
<pjb>
jmercouris: try it with: emacs -Q
<jmercouris>
pjb: doesn't make a huge performance impact the packages I'm using
<jmercouris>
or at least, I'm unable to discern any lag
<aeth>
jmercouris: Just being able to run the Lisp portion of an editor in a fast lisp like SBCL instead of a slow lisp like Emacs Lisp would be a huge win, without much changed.
<pjb>
jmercouris: you don't have any package when you run emacs -Q !
<pjb>
jmercouris: you only get the core emacs, only the C code.
<pjb>
no emacs lisp.
Oladon has quit [Quit: Leaving.]
<jmercouris>
Right, that's what I'm saying
<jmercouris>
if I run emacs or emacs -Q I cannot notice a speed difference
<pjb>
of course. Why would you?
<fiddlerwoaroof>
I have performance issues in certain modes
<fiddlerwoaroof>
I couldn't use ERC for a while because it was eating all my memory
<jmercouris>
pjb: Some people install one billion packages, and then complain when their nyan cat rainbow modeline slows down their system
<jmercouris>
fiddlerwoaroof: I highly reccommend Circe
<jmercouris>
in place of ERC
<aeth>
Emacs is a horrible application. I don't use ERC because I persist my IRC, and I don't persist my Emacs. I restart my Emacs as often as possible. Helps with memory.
<jmercouris>
I've been running emacs for like 2 weeks, and I'm at 268 MB of ram
<p_l>
a multithreaded, concurrent emacs in CL... one can dream
<jmercouris>
pjb: I've got 25.3.1 and it seems that emacs-uptime comes with it
<pjb>
I've been using emacs since 18.
<jmercouris>
pjb: Maybe time to clean up your init file then ;)
smurfrobot has quit [Ping timeout: 263 seconds]
<pjb>
You never know when you have to use them with old systems…
<fiddlerwoaroof>
I use a bouncer to persist my irc session.
* jmercouris
turns on the club music
<fiddlerwoaroof>
Hmm, should give circe a whirl: using trim-buffers, erc seems to be fairly fine for me
<jmercouris>
goodnight everyone
<aeth>
jmercouris: I have 16 GB of RAM on my desktop (although I run IRC on a machine with 512 MB, where memory usage is very important), but even when I have 64 GB of RAM, I'll still hate when RAM gets wasted.
<jmercouris>
aeth: All ram is lost, like tears in rain, do not fight against electron.js, embrace it
<jmercouris>
Ram is like sand, the harder we try to hold it, the quicker it runs through our hands
<aeth>
I aggressively fight RAM waste and I'm still at 1.66 GB before I do anything interesting with it. If I didn't fight it, I'd probably start at 3 GB or more
<jmercouris>
I was totally joking :D
<aeth>
well, 1.66 GB right now...
<fiddlerwoaroof>
Hmm, erc right now is holding onto 11% of my system's memory
<jmercouris>
fiddlerwoaroof: Get a dedicated ERC machine
<aeth>
This entire machine that hosts my IRC is usually between 60-70 MB of RAM usage.
<p_l>
jmercouris: I fight hard against RAM waste because I already lost the fight on web front
fikka has quit [Ping timeout: 256 seconds]
<p_l>
16G is not enough
<aeth>
I don't like wasted RAM, but I do prefer CPU performance over RAM efficiency, e.g. I prefer SBCL over alternative CLs even though SBCL starts around 40-60 MB before doing anything.
<aeth>
Interestingly, SBCL apparently keeps getting more efficient.
<aeth>
There was a time when SBCL was comparable to Emacs afaik.
<fiddlerwoaroof>
I find that system reponsiveness is more affected by ram usage than cpu usage these days
<p_l>
aeth: yeah, but with SBCL I see that I'm getting my money's worth :D
<fiddlerwoaroof>
e.g. if my desktop starts feeling laggy, I close all my tabs and everything is snappy again :)
<p_l>
meanwhile Slack will happily gobble tons of RAM
<aeth>
freshly started up (and my OS is not on a recent SBCL!) 49 MB in a terminal, 51 MB in SLIME
<aeth>
roswell's recent slime+sbcl is... 95?
<aeth>
well, something's up there
<p_l>
top three apps on my system: Chrome using 4GB (surprisingly little, I suspect shenanigans), VMware using 2GB (for a 2GB VM, expected) ... Slack = 1.2GB :|
jmercouris has quit [Ping timeout: 252 seconds]
<parjanya>
if I create a stream with (process-output (run-program "/usr/bin/ls" '() :output :stream)) , how can I read it?
<aeth>
Basically the only thing that uses unjustified amounts of RAM are web browsers or things that use web browsers like Electron apps
<aeth>
The good news is this: If people can tolerate Electron adding 1 GB per Electron app, they can probably tolerate SBCL adding 100 MB per CL app.
<p_l>
aeth: and then there applications that take "electron" and put "even more unjustified resource usage", like Slack
<aeth>
If anyone has (64-bit) Electron, it would be interesting to see how much RAM a hello world takes. It would probably take too long for me to download just to test that.
<aeth>
And it would be interesting to compare this to the worst case of a graphical CL hello world app, which is probably going to be 90-120 MB counting the base CL
<aeth>
s/CL hello world/SBCL hello world/
<aeth>
SBCL probably uses the most RAM.
smurfrobot has joined #lisp
<aeth>
The CL one is probably going to be 3x-5x C, though.
<fiddlerwoaroof>
But slack has custom emojis...
smurfrobot has quit [Ping timeout: 272 seconds]
mlau has quit [Ping timeout: 240 seconds]
karswell_ has quit [Remote host closed the connection]
karswell_ has joined #lisp
smurfrobot has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
smurfrobot has quit [Ping timeout: 256 seconds]
panji has quit [Ping timeout: 240 seconds]
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 264 seconds]
glamas has joined #lisp
glamas has quit [Client Quit]
smurfrobot has joined #lisp
rippa has joined #lisp
panji has joined #lisp
smurfrobot has quit [Ping timeout: 260 seconds]
smurfrobot has joined #lisp
fikka has joined #lisp
smurfrobot has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 256 seconds]
add^_ has quit [Ping timeout: 268 seconds]
damke has joined #lisp
add^_ has joined #lisp
t0adst00l has quit [Ping timeout: 272 seconds]
OS-26949 has quit [Quit: Leaving]
eviltofu has joined #lisp
dieggsy has quit [Ping timeout: 268 seconds]
t0adst00l has joined #lisp
dec0n has joined #lisp
<eviltofu>
If I want to make a GUI app in common-lisp that runs under macOS, what should I use?
<pjb>
eviltofu: the easiest is to use Clozure CL (ccl) and its Objective-C bridge.
<pjb>
You can add my Objective-CL reader macros if you want to have an Objective-C -like syntax.
panji has quit [Ping timeout: 248 seconds]
<pjb>
you can also get it from the AppStore (Clozure CL.app).
<eviltofu>
ok thanks! What about CLIM?
<jackdaniel>
it does work only with Xserver at the moment
<jackdaniel>
so it is certainly possible to run it on macos, but it doesn't have this "native" feel
<pjb>
If you don't want to make a Cocoa Application, then you can use any implementation with CLIM.
<pjb>
There's X11.app on macOS.
<eviltofu>
I'm just putting around exploring CL
<eviltofu>
ok thanks
dddddd has joined #lisp
damke_ has joined #lisp
damke has quit [Ping timeout: 264 seconds]
bugrum has quit []
damke_ has quit [Ping timeout: 264 seconds]
safe has quit [Read error: Connection reset by peer]
<eviltofu>
Sketch is interesting, I was looking at Processing a few weeks back for some coding fun!
shka has quit [Ping timeout: 260 seconds]
lemoinem has quit [Ping timeout: 248 seconds]
lemoinem has joined #lisp
eviltofu has quit [Quit: Page closed]
smurfrobot has joined #lisp
brendyn has quit [Ping timeout: 248 seconds]
damke_ has joined #lisp
smurfrobot has quit [Ping timeout: 248 seconds]
DeadTrickster has quit [Read error: Connection reset by peer]
DeadTrickster has joined #lisp
damke has joined #lisp
jack_rabbit has quit [Quit: Leaving]
damke_ has quit [Ping timeout: 264 seconds]
damke has quit [Ping timeout: 264 seconds]
jack_rabbit has joined #lisp
randomstrangerb has quit [Ping timeout: 248 seconds]
earl-ducaine has quit [Remote host closed the connection]
damke has joined #lisp
earl-ducaine has joined #lisp
randomstrangerb has joined #lisp
damke has quit [Read error: Connection reset by peer]
Cymew has joined #lisp
<whoman>
aeth, whoa. GL CLIM is a nice thought
<aeth>
GL CLIM would run on every platform.
`420 has left #lisp [#lisp]
orivej has quit [Ping timeout: 268 seconds]
<jdz>
What's this magic GL you're talking about is?
<aeth>
jdz: OpenGL, i.e. render 2D things using that 3D graphics API.
<fiddlerwoaroof>
eviltofu: qtools is also a fairly good way to write gui applications for osx
<jdz>
Which OpenGL? On which platform is that specific OpenGL supported, and FFI available for CL?
damke has joined #lisp
<fiddlerwoaroof>
sketch uses OpenGL 3.3
<fiddlerwoaroof>
Looks like it runs on all the major implementations
<jdz>
I bet OpenGL will be obsolete soon enough, with different vendors moving in different directions: MicroSoft -> DirectX, Apple -> Metal, Others -> Vulkan.
<fiddlerwoaroof>
I have prototype-quality objective-c/cffi interaction going on locallly
<earl-ducaine>
Clutter is a good example of modern, full feature graphic toolkit built on top of open GL.
<jdz>
It sure is an example, not sure about the "good" part.
DeadTrickster has quit [Read error: Connection reset by peer]
<fiddlerwoaroof>
What are the reader macros that ccl uses for objective-c?
DeadTrickster has joined #lisp
<fiddlerwoaroof>
I sort of recall #[] and #_ and a couple others, but it's been a while
<jdz>
It may make sense to use Clutter instead of OpenGL directly.
vlatkoB has joined #lisp
<aeth>
jdz: OpenGL will be supported for a long time
<pjb>
fiddlerwoaroof: ccl doesn't define any objective-c specific reader macro; they're reader macros used for the FFI in general. I wrote my own Objective-CL reader macros to provide the Objective-C syntax to CL.
<whoman>
jdz, webgl, opengl es, opengl .. there is an overlap
<Shinmera>
jdz: OpenGL isn't going anywhere and Vulkan isn't replacing it.
<jdz>
OK.
<Shinmera>
If anything, OpenGL has been gaining massive traction in recent years thanks to the web and mobile tech
<jdz>
Thanks to OpenGL ES.
<whoman>
clutter looks interesting, seems dead
knobo has joined #lisp
<jdz>
Huh?
<jdz>
GNOME is built on top of it.
<knobo>
Is there a way to get the argument list for a function?
<aeth>
The point of using OpenGL would be portable, like Blender.
<whoman>
dead might be a wrong word. solid? my house is built on top of solid rock
<earl-ducaine>
Wing 3d is an interesting 3d modeler. GUI and canvas are both implemented in open GL.
<earl-ducaine>
What's interersting from a CL perspective is that it's a clone of Nendo which is a stripped down version of Mirai, which is what Symbolics' S-World suite eventually became after being purchased by Nichimen.
<whoman>
touch clim is an interest to me as well
<jdz>
earl-ducaine: it's also interesting that it is written in Erlang.
<aeth>
It's also the most RAM-intensive way to make a GUI
<aeth>
That's... actually the prior topic here.
<aeth>
1+ GB RAM. An SBCL solution would be 10% that. Other CLs even less.
<whoman>
yeah =( i only have 2gb so i am doing opengl instead of web.
<whoman>
sorry or text ui*
<whoman>
including mcclim, x11, freetype etc ?
<whoman>
(ram usage)
Sauvin has quit [Read error: Connection reset by peer]
LocaMocha has joined #lisp
scymtym has quit [Ping timeout: 264 seconds]
fikka has quit [Ping timeout: 268 seconds]
Arcaelyx has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<whoman>
web does not take too much ram on mobile
<aeth>
whoman: I think it would be hard to get a GUI + SBCL above 150 MB RAM.
<whoman>
cool
<aeth>
For a hello world, I mean.
<aeth>
Obviously the GUI app could be a virtual machine and take up gigs of RAM or whatever.
<whoman>
yeah ~ but the layers down to the OS, including fonts and all that
<whoman>
and X11 etc. like if one were to "tree-shake" a snapshot of hello world gui
d4ryus1 is now known as d4ryus
<jackdaniel>
if you are concerned about ram usage, you should try CCL
<jackdaniel>
if that's not enough, you should try ECL
* whoman
is only concerned about HDD lag from swap for general desktop useage. dev tools should be hyperspeed negative latency
<aeth>
jackdaniel: I'm using SBCL as a worst case example of RAM usage.
<aeth>
I personally don't care as long as it's < 100 MB.
<aeth>
And it is.
<aeth>
In the world where Electron apps are commonplace, even SBCL is absolutely lightweight in RAM.
nowhere_man has quit [Remote host closed the connection]
nowhere_man has joined #lisp
<jackdaniel>
for some of thigns I try SBCL heaps blows above 8GB while CCL fits nicely in 2GB (during compilation), so that's a valid concern for me
Kevslinger has quit [Quit: Connection closed for inactivity]
smurfrobot has joined #lisp
<loke>
jdz: That article dismissed GTK for adding 20 MB to the code size. That's a bit silly, IMHO
smurfrobot has quit [Ping timeout: 256 seconds]
<loke>
His requirements are not only that he wants to graw graphics and stuff, he also wants it really small.
<jackdaniel>
I agree that this is silly
<aeth>
jackdaniel: But, on the other hand, it's a lot easier to avoid allocation in SBCL through profiling and disassembly, at least ime.
<aeth>
When I want to write some large thing that doesn't allocate, I'm only sure that it doesn't allocate in SBCL.
jack_rabbit has quit [Ping timeout: 248 seconds]
<jdz>
loke: Yes, seems like people (male?) are obsessed with size.
<jdz>
Or maybe just measuring "things".
<jackdaniel>
and the whole article seems to be written in purpose to justify creating yet another toolkit (this time in NIM), what is even more silly. If he feels he want to make one, then he should do it, but making excuses is not something I'm going to appreciate
<loke>
Right
<beach>
I think there is a serious lack of back-of-envelope calculations. Instead, what I observe is typical Kahneman stuff; the fast brain module is lousy with math, and the slow module is lazy so it believes the fast one.
t0adst00l has quit [Ping timeout: 272 seconds]
randomstrangerb has quit [Ping timeout: 264 seconds]
randomstrangerb has joined #lisp
<jdz>
Even if the conclusion is not useful the article still includes more data points than "Blender uses OpenGL for GUI".
<aeth>
jdz: IRC isn't a good medium for data
jack_rabbit has joined #lisp
<jdz>
Text/font rendering is very important for me.
<jdz>
OpenGL has nothing for text rendering, as far as I know.
<aeth>
jdz: The section on Blender seems very favorable to me
<aeth>
jdz: Using OpenGL means, afaik, consistent font rendering on all platforms that consistently looks different from what every other application does. But, yes, you'd have to write it yourself or use a library.
<jackdaniel>
beach: on the other hand (regarding memory use) I totally get why someone could want to have small memory footprint *even if he knows* that memory is cheap. If you may have exactly same functionality in 10KB vs 10MB (given that both are coded reasonably well), the former solution is more elegant by some metrics
<aeth>
jdz: There are some interesting ways to render fonts using 3D APIs these days.
<jackdaniel>
so this argument shifts from practical point of view int aesthetic one
<beach>
jackdaniel: Sure, but that elegance comes at a cost. And I rarely see that cost evaluated against the gain in memory.
<beach>
jackdaniel: Plus, someone who is obsessed with memory size probably makes other elegance compromises instead.
<aeth>
Focusing on a small amount of memory makes perfect sense for a server (especially a home server, which should be quiet and low-power). It's probably not as important for graphical applications since that server will be running without X.
damke_ has joined #lisp
<jackdaniel>
right, that's why I agree that saying that "it is 20MB, so it's bad" is a silly argument, yet I acknowledge that sometimes this argument may be very valid one (and can't be debunked with saying, that someone forgot to do his math, or was lazy)
<jackdaniel>
not in this case though
randomstrangerb has quit [Ping timeout: 252 seconds]
jack_rabbit has quit [Ping timeout: 260 seconds]
<aeth>
Personally, I'm a bit selfish. I usually am very wasteful of RAM when I program, but I don't like other applications using it up (less RAM for me!)
<aeth>
I wonder if anyone else is like that.
randomstrangerb has joined #lisp
damke has quit [Ping timeout: 264 seconds]
<loke>
By looking at the Nom web site, it seems to me that the users have similar values as the Go crowd.
<loke>
Somehow they think that statically linked binaries is a great thing.
<loke>
(I'm old enough to remember Unixes without dynamic linking support at all, and it was not fun)
scymtym has joined #lisp
<aeth>
loke: A potential counterargument: we have a lot more space now. Even 1 TB SSDs are very affordable.
<jackdaniel>
dynamic linking goes beyond that - updating library requires updating only one shared object
<jackdaniel>
if there is no dynamic linking, you have to recompile each module
<jackdaniel>
so you have to be more aware of your software dependency tree
<aeth>
jackdaniel: There are probably tools to do that now, though
Tobbi has joined #lisp
<jackdaniel>
sure, did you ever use gentoo? if you don't have dynamic linking it gets even more messy
<aeth>
I think the future is probably going to be sandboxing all over the place, which could be the death of dynamic linking.
<beach>
jackdaniel: It is not a matter of debunking, but of getting the full picture. I am perfectly happy to see an argument such as "yes, it is going to take me a year of full-time work to save a small amount of memory, but I think it will be a lot of fun to try", instead of seeing just half the argument.
<beach>
jackdaniel: I would hate for people to tell me what to put work into, so I certainly do not try to tell others what they would be doing.
<beach>
SHOULD be doing, rather.
t0adst00l has joined #lisp
jack_rabbit has joined #lisp
manualcrank has quit [Quit: WeeChat 2.0.1]
<jackdaniel>
OK, I get it better now, yet sometimes it's not very obvious from the context for me (probably fault in my understanding)
<beach>
Nah, probably a result of the medium (IRC) that requires me to be brief.
<loke>
aeth: I'm just now trying to use Nixos, which is essentially that
<loke>
aeth: Let me tell you, they are doing something interesting, but man is the approach flawed.
EvW has joined #lisp
fikka has joined #lisp
_cosmonaut_ has joined #lisp
Murii has joined #lisp
Tobbi has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
smurfrobot has joined #lisp
<p_l>
whoman: Web is also probably the worst stack to make GUI in, no matter the platform
smurfrobot has quit [Ping timeout: 248 seconds]
<loke>
p_l: I was about to counter with some worse toolkits... However... Now that I think about it, I do think you're right.
damke has joined #lisp
<aeth>
loke: I agree.
<aeth>
With both of your recent statements, actually.
Tobbi has joined #lisp
damke_ has quit [Ping timeout: 264 seconds]
<loke>
:-)
random-nick has joined #lisp
jack_rabbit has quit [Ping timeout: 264 seconds]
random-nickname has joined #lisp
Tobbi has quit [Remote host closed the connection]
random-nick has quit [Ping timeout: 252 seconds]
Tobbi has joined #lisp
random-nickname is now known as random-nick
jack_rabbit has joined #lisp
Firedancer_ is now known as Firedancer
dddddd has quit [Remote host closed the connection]
brendyn has joined #lisp
smurfrobot has joined #lisp
makomo has joined #lisp
t0adst00l has quit [Remote host closed the connection]
t0adst00l has joined #lisp
smurfrobot has quit [Ping timeout: 256 seconds]
Tobbi has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hhdave has joined #lisp
t0adst00l has quit [Remote host closed the connection]
t0adst00l has joined #lisp
m00natic has joined #lisp
DeadTrickster has quit [Read error: Connection reset by peer]
DeadTrickster has joined #lisp
fikka has quit [Ping timeout: 272 seconds]
whoman has quit [Ping timeout: 252 seconds]
fourier has joined #lisp
nika has quit []
wxie has joined #lisp
fikka has joined #lisp
whoman has joined #lisp
raynold has quit [Quit: Connection closed for inactivity]
EvW has quit [Ping timeout: 265 seconds]
whoman has quit [Ping timeout: 260 seconds]
whoman has joined #lisp
jstypo has quit [Ping timeout: 264 seconds]
damke_ has joined #lisp
osune_ has joined #lisp
smurfrobot has joined #lisp
mlau has joined #lisp
damke has quit [Ping timeout: 264 seconds]
jstypo has joined #lisp
smurfrobot has quit [Ping timeout: 248 seconds]
nowhere_man has quit [Ping timeout: 256 seconds]
mishoo has joined #lisp
oleo has quit [Remote host closed the connection]
<phoe>
I have a class whose slot contains a STATIC-VECTOR. If I understand this correctly, I can use TRIVIAL-GARBAGE:FINALIZE that closes over this static vector to make this memory reclaimable by the garbage collector, like, (let ((vector (static-vector instance))) (lambda () (free-static-vector vector))). Do I understand it right?
<jackdaniel>
yes
<Shinmera>
As long as you don't close over the thing you're finalizing.
<Shinmera>
Because then you'd create an indefinite extent reference and prevent it from being GCd.
nirved has joined #lisp
<phoe>
Shinmera: exactly, (lambda () (free-static-vector (static-vector instance))) would be a mistake.
<Shinmera>
Or, well, that doesn't clearly illustrate it
<phoe>
I get the general idea.
<phoe>
CL-LZMA will get a pretty big update, including an API change that makes use of static vectors.
<Shinmera>
Point being a generic function that returns a closure that "knows" how to finalise that object's resources.
<phoe>
Since right now it's 95% CL overhead coming from coercing vectors from (UNSIGNED-BYTE 8) to T and the other way around
fourier has quit [Ping timeout: 250 seconds]
oleo has joined #lisp
nowhere_man has joined #lisp
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 240 seconds]
theBlackDragon has quit [Ping timeout: 264 seconds]
wxie has quit [Read error: Connection reset by peer]
milanj has joined #lisp
wxie has joined #lisp
Karl_Dscc has joined #lisp
gravicappa has joined #lisp
randomstrangerb has quit [Ping timeout: 255 seconds]
randomstrangerb has joined #lisp
DeadTrickster has quit [Read error: Connection reset by peer]
DeadTrickster has joined #lisp
EvW has joined #lisp
smurfrobot has joined #lisp
varjag has joined #lisp
smurfrob_ has joined #lisp
smurfrobot has quit [Read error: Connection reset by peer]
randomstrangerb has quit [Ping timeout: 248 seconds]
randomstrangerb has joined #lisp
smurfrob_ has quit [Ping timeout: 248 seconds]
smurfrobot has joined #lisp
makomo_ has joined #lisp
fikka has quit [Quit: leaving]
fikka has joined #lisp
smurfrobot has quit [Ping timeout: 268 seconds]
<osune_>
I have (soon) a long running CL application. I want to execute a function with arguments at a specific date and time. This date can be even years in the future. There will be many dates when this function should execute, with different arguments. I feel uncomfortable to use a normal timer for such use case. A workaround would be to use CRON and let it talk to the the CL App via sockets which can be selected. But what are possible
<osune_>
solutions inside of CL ?
t0adst00l has quit [Ping timeout: 272 seconds]
<jdz>
Have a thread that sleeps most of the time, or have a main loop that periodically checks the schedule.
makomo has quit [Ping timeout: 272 seconds]
<jdz>
There might be platform-specific ways to also schedule a signal (alert) for the process.
<Shinmera>
Just sleep like half of the time you need to the next event until you're within a certain range of acceptability.
<Shinmera>
As in, do that in a loop
<osune_>
jdz: my problem with the "check shedule periodically" approach would be what my "Nyquist Frequncy" for sampling would be. But platform specific solutions are ok
<osune_>
*frequency
<Shinmera>
(loop for diff = (- (get-universal-time) target-time) until (< diff 60) do (sleep (/ diff 2))
<osune_>
Shinmera: thx, the easiest solutions seem always to escape my mind
<jdz>
osune_: there's the alarm() function if you're on a Posix system.
<phoe>
osune_: there exist even simpler solution
<osune_>
I'm listening ?
<tfb>
osune_: what's the problem with just checking when the next event is and then sleeping until then? The repeatedly-wake-and-sleep thing seems like ... hard work.
<osune_>
tfb: new events can be sheduled any time for any time in the future
<jdz>
Also let's not forget that systems may sleep (especially if running on a laptop).
<phoe>
osune_: there was a thing with minion where you could ask him to remind you to do something in 140380 seconds or something (:
<phoe>
but I forgot the syntax right now
<jdz>
And time may be running faster or slower depending on different factors.
<tfb>
osune_: every time the schedule changes you need to wake the sleeping thread in any case (same if the whole system is asleep or is restarted which it will be since you're talking about years)
<osune_>
phoe: I assume I should look at the code for minion. Or are you suggesting I should make requests against minion via IRC ? ;)
<Shinmera>
Depending on how many events you have you can just launch a thread for each
<phoe>
osune_: via IRC, exactly (:
<Shinmera>
Alternatively you can just sleep for a second in a thread and then check all events.
<Shinmera>
phoe: Colleen could do that too but I removed it
<Shinmera>
cause it wasn't used
<osune_>
Shinmera: its a pet project, but lets assume there are "millions"
<osune_>
phoe: sounds like a solid approach :)
<Shinmera>
osune_: Then just loop sleep a second and check each event, with events sorted by target time to short-circuit.
t0adst00l has joined #lisp
<jdz>
osune_: just have a sorted sequence of times, and check the head every second.
<jdz>
Oh, what Shinmera said.
<Xach>
When I had the same problem I made a heap data structure and slept until the next minimum item.
<Xach>
That wound up in SBCL as its SB-TIMER facility.
<osune_>
Shinmera: jdz: yep that was in the back of my head to.
<phoe>
osune_: ow. Well then, obviously you need to write your own IRC bot in order for your thread to be able to sleep. ;)
DeadTrickster has quit [Read error: Connection reset by peer]
<osune_>
that would be another point on my bucketlist I could check ;)
DeadTrickster has joined #lisp
<osune_>
thx everyone for your suggestions and help
<jdz>
Apparently SBCL uses setitimer, which is obsolete already...
t0adst00l has quit [Ping timeout: 272 seconds]
<osune_>
jdz: it's posix.1-2001. Even if posix.1-2008 supersedes it, it seems to be the way to go for now
fikka has quit [Ping timeout: 268 seconds]
mariari has joined #lisp
<jdz>
osune_: my man page says «Applications should use the timer_gettime() and timer_settime() functions instead of the obsolescent getitimer() and setitimer() functions, respectively.», POSIX.1-2008.
AndChat-153225 has quit [Ping timeout: 265 seconds]
<osune_>
jdz: mine says basically the same. But as the kernel 'never' brakes userspace this is a bit ugly but somewhat a non-issue, no?
<jdz>
This has nothing to do with kernel (or so it seems to me).
mariari has quit [Ping timeout: 252 seconds]
fortitude has quit [Ping timeout: 272 seconds]
<phoe>
I have a function which accepts a stream as a parameter. What is the canonical way of checking if this stream outputs (unsigned-byte 8)s?
<jdz>
Xach: nice, the code in SBCL is from 2005. Time flies...
<osune_>
I would assume that the interface is bound to the kernel, as these are systemcalls which expose timer functionality of the kernel to the user. So deprication warnings for posix interfaces are ugly. But apart from that i don't see a problem using sb-ext:timer?
sz0 has joined #lisp
<jdz>
I was not complaining or pointing at a problem, more like expressing my puzzlement.
<osune_>
ah got it .
<phoe>
oldie but goldie
<jdz>
I knew about alert(), then just learned about {set,get}itimer, and upon learning about them they got immediately deprecated.
<osune_>
unfortunate
<jdz>
Nah, I just rear UNIX-HATERS Handbook recently, minor things like this only amuse me.
<osune_>
I worked with the timerfd interface (in C) which was very nice to use
randomstrangerb has quit [Ping timeout: 260 seconds]
randomstrangerb has joined #lisp
theBlackDragon has joined #lisp
<p_l>
osune_: POSIX doesn't cover any syscalls
Jarwin has joined #lisp
Tobbi has joined #lisp
smurfrobot has joined #lisp
gabot has quit [Ping timeout: 268 seconds]
EvW has quit [Ping timeout: 246 seconds]
gabot has joined #lisp
<osune_>
p_l: you are right POSIX are not syscalls. But they work on system calls. And even the manpage is ambiguous about the usage of the term as it says "These system calls provide access to interval timers"
<p_l>
osune_: syscall is not equall to syscall, though. Normally-callable functions count as system calls for purposes of POSIX
smurfrobot has quit [Ping timeout: 248 seconds]
<p_l>
in fact, on most recent Unices, timer-related syscalls are actually library calls often to kernel-managed space
smurfrobot has joined #lisp
ykoda has joined #lisp
wxie has quit [Remote host closed the connection]
ykoda has quit [Client Quit]
ykoda has joined #lisp
smurfrobot has quit [Ping timeout: 265 seconds]
<osune_>
p_l: aye. I used the term "systemcall" incorrect. What I wanted to say is: It won't break with the next kernel update nor will the interface vanish soon. I assume I used it, as the manpage for setitimer missuses the term and the setitimer interface depends on the kernel timer facility. Thanks for the correction though and the added information about recent timer-related calls.
smurfrobot has joined #lisp
fikka has joined #lisp
Jarwin has quit [Ping timeout: 248 seconds]
smurfrobot has quit [Ping timeout: 265 seconds]
Sigyn has quit [Quit: People always have such a hard time believing that robots could do bad things.]
<osune_>
and I realized I did not write a real sentence. sorry
smurfrobot has quit [Ping timeout: 264 seconds]
brendyn has quit [Ping timeout: 272 seconds]
<p_l>
osune_: is it linux manpage, or POSIX manpage?
<p_l>
there's a difference ;)
<p_l>
like POSIX manpages not having section 2
<osune_>
p_l: man 2 setitimer and man 2 syscalls ; so just linux manpages
<jdz>
Oh, I was reading POSIX manpages.
<p_l>
osune_: linux ones will obviously talk about actual Linux behaviour
<osune_>
getitimer(3p) (which is refered to from setitimer(3p) doesn't use the word "syscall / system call". So of course I don't cite it. It would undermine my argument ;)
ngqrl has quit [Read error: Connection reset by peer]
FreeBird_ has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
<mfiano>
Xach: Please remove that library from Quicklisp. It has no users and the math is wrong on closer inspection.
<Xach>
ok
FreeBirdLjj has quit [Read error: Connection reset by peer]
FreeBird_ has joined #lisp
lclark has joined #lisp
<mfiano>
Thanks. I'll have to rewrite it someday when I have need for it again
FreeBird_ has quit [Remote host closed the connection]
smurfrobot has joined #lisp
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 240 seconds]
Kevslinger has joined #lisp
asarch has joined #lisp
hexfive has joined #lisp
smurfrobot has quit [Ping timeout: 264 seconds]
Cymew has quit [Remote host closed the connection]
Cymew has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
nika has joined #lisp
Cymew has quit [Ping timeout: 265 seconds]
<phoe>
Heck yeah, I fixed CL-LZMA.
<phoe>
Its decompression should be 40000% faster now.
Cymew has joined #lisp
<Shinmera>
What was it doing before? SLEEP?
<Shinmera>
Wait for the bits to align?
<phoe>
Shinmera: no, COERCE'ing arrays from (unsigned-byte 8) to T and then from T to (unsigned-byte 8).
<phoe>
So working on 600kB worth of tiny archives consed up about half a gigabyte of memory in total.
<phoe>
It's easy to achieve 40000% speedups, you just need to fuck up *really* bad in the first place.
<phoe>
Or, to be more specific, coercing raw CFFI memory into simple-vector into (vector (unsigned-byte 8)).
<Shinmera>
Reminds me of the stories of people intentionally making products slower so that they had an insurance on future releases being faster.
<phoe>
I'll keep this in mind.
turkja has quit [Ping timeout: 264 seconds]
<Shinmera>
Other ways to provide job (and product) insurance: write very obscure code that only you can read, or add in details that nobody but you will notice
Cymew has quit [Ping timeout: 248 seconds]
<phoe>
> write very obscure code that only you can read
<phoe>
do you mean Lisp?
<Shinmera>
No I mean Java
<phoe>
Hm. I write Java for a living.
<phoe>
I must consider this.
Cymew has joined #lisp
<phoe>
Unrelated: I just found a way to run threaded ECL on my Android phone, via termux. I'll blogpost about it later today.
Cymew has quit [Ping timeout: 248 seconds]
Cymew has joined #lisp
dec0n has quit [Read error: Connection reset by peer]
vlatkoB has quit [Remote host closed the connection]
Cymew has quit [Ping timeout: 264 seconds]
Cymew has joined #lisp
vlatkoB has joined #lisp
SaganMan has joined #lisp
Cymew has quit [Ping timeout: 240 seconds]
Cymew has joined #lisp
__rumbler31 has joined #lisp
scymtym has quit [Ping timeout: 240 seconds]
milanj has joined #lisp
Cymew has quit [Ping timeout: 240 seconds]
Walex has joined #lisp
yeticry has quit [Ping timeout: 248 seconds]
Cymew has joined #lisp
yeticry has joined #lisp
Cymew has quit [Ping timeout: 240 seconds]
Cymew has joined #lisp
<whoman>
p_l, "worst" , "best", well you know
<whoman>
as for "stacks" well it doesnt matter. CSS and html5 are nonprogramming ways to make a lot of things. there are so many teams and individuals and groups and standards and companies and gov'ts and so on that is behind "web tech".
_cosmonaut_ has quit [Ping timeout: 264 seconds]
<whoman>
i dont think one dude has enough capacity or perspective or time or energy for anything made by many people. crowd wins
Sigyn has left #lisp ["Leaving the channel (no spam or action taken for 3 days.) /invite Sigyn #lisp again if needed"]
<TMA>
whoman: there are cases that can prove you wrong.
Cymew has quit [Ping timeout: 252 seconds]
<TMA>
whoman: Fabrice Bellard comes to mind...
<beach>
I recall a paper by Xof, explaining good and bad ways of using reader conditionals. Does anyone remember where to find it?
<whoman>
TMA, is that a person's name... ? i cant imagine how that would relate =)
fortitude has joined #lisp
smurfrobot has joined #lisp
<whoman>
web tech is not an "invention" - its layers and layers of progressive changes and things from the whole world
<rpg>
I feel like this should be a FAQ, but I'm not finding it -- is there an easy way to print an s-expression without package qualifiers, no matter what the value of *package* is and what the home packages of the symbols are ?
kajo has quit [Ping timeout: 240 seconds]
<phoe>
rpg: #'PRINC
<Bike>
usually i'd just bind *package* to the keyword package
<Bike>
er, sorry, "without", nevermind
<rpg>
phoe: PRINC isn't doing it for me.
<phoe>
you want all the other symbols printed with ~S, huh?
<phoe>
s/symbols/things/
<phoe>
hmmm. let me think for a moment.
<rpg>
actually, looking at this, the s-expression is entirely made up of symbols, but probably that'
<rpg>
s not a safe assumption
<phoe>
What I did once, was:
<phoe>
I copied the whole expression via COPY-TREE, then destructively traversed the copy to replace all symbols with gensyms of the same name.
<phoe>
And then I bound *PRINT-GENSYM* and printed.
<rpg>
phoe: I guess we do that, but avoid NIL, right?
<phoe>
rpg: why?
<rpg>
phoe: I guess it's ok....
<phoe>
#:NIL will get printed as NIL anyway
<phoe>
since NIL might get printed as CL:NIL if you are in some crazy package
<phoe>
so I guess it's even slightly safer to gensym it.
<rpg>
phoe: Are you sure you did this with GENSYM instead of MAKE-SYMBOL?
knobo1 has joined #lisp
<phoe>
rpg: MAKE-SYMBOL, correct
<phoe>
(make-symbol (symbol-name x))
<Bike>
there's actually a copy-symbol function
<rpg>
that makes sense. Question: why do (make-symbol (symbol-name x)) instead of just collecting SYMBOL-NAME (and printing strings w/o quotes)?
<Bike>
you could be the first one to use it!
<phoe>
Bike: woah
<phoe>
rpg: printing strings without quotes? how?
<rpg>
Bike: Thanks!
<phoe>
PRINT will print them with quotes, and if you could print items with ~A selectively to print strings without quotes, then you would be able to print symbols without package prefixes.
<phoe>
Bike: the standard keeps on surprising
knobo has quit [Ping timeout: 248 seconds]
Tobbi has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<phoe>
Could I ask for a code review? I'm submitting a PR to CFFI that makes it possible to return specialized arrays from FOREIGN-ARRAY-TO-LISP. https://github.com/cffi/cffi/pull/128
<Bike>
drop the "holy standard" thing
<Bike>
and i guess you could put in a compiler macro on foreign-array-to-lisp to avoid apply, but it's probably not super important
<rpg>
Bike: ?
aeth has joined #lisp
Jarwin has quit [Quit: moritus de saluto]
<phoe>
Bike: dropped the thing, and hm. The compiler would probably be smart enough to notice whenever MAKE-ARRAY-ARGS is NIL, since (apply #'foo bar baz '()) seems like a very simple optimization.
<phoe>
Bike: thanks for the review!
smurfrobot has quit [Remote host closed the connection]
<asarch>
Can you "overload" functions in Lisp?
LocaMocha has quit [Read error: Connection reset by peer]
<asarch>
Or just define a function with a big list of all available arguments it could handle: (defun foo (list(a 0 a-p) list(b 1/2 b-p) list(c "Hello, world!" c-p)) ... )
fikka has joined #lisp
<Xach>
asarch: no
<phoe>
asarch: you mean some kind of pattern matching?
<Bike>
you can define generic functions, which do different things based on the classes of their arguments. you can't write definitions with different numbers of arguments of which only one is picked by the compiler, like in C++, though you can have a function that takes a variable number of arguments and does different things depending on the number.
<phoe>
Bike: oi
<phoe>
methods can also be EQL-specialized
<dlowe>
asarch: not sensibly. You could just define all your functions with a &rest parameter and do your argument parsing in the function body. It would be annoying and slow, though.
<phoe>
but then again, I wonder if EQL-specializing is what asarch wants...
<phoe>
asarch: what kind of mechanism are you trying to achieve?
smurfrobot has joined #lisp
dieggsy has quit [Ping timeout: 252 seconds]
<__rumbler31>
phoe: do you have a commit published where you made your changes that resulted in the speedup? How did you figure out that the coercing was the cause, and what did you change to alleviate that?
DeadTrickster has quit [Read error: Connection reset by peer]
broccolistem has joined #lisp
DeadTrickster has joined #lisp
<phoe>
__rumbler31: yes, one second.
<phoe>
I used SB-PROFILE:PROFILE to profile a few functions - the decompression function itself, the LZMA-DECODE function (CFFI callback), and then I extracted the COERCE into a separate function that was profiled as well.
<pjb>
asarch: you can define anything you want in lisp.
<phoe>
The coercion consed up to half a gigabyte of memory and took almost all execution time.
<phoe>
What I did was, I removed both converting from C into simple-vector, and then from simple-vector into octet-vector, by using a static vector.
broccolistem has quit [Client Quit]
<phoe>
I gave the C callbacks pointers into raw memory that is the storage of the static vector. This way, the C function can operate straight on the memory that is used by the static vector, and I can then use this inside Lisp code without any conversions or copying.
<phoe>
__rumbler31: I'll actually write a blogpost about it. Thanks for the idea.
broccolistem has joined #lisp
broccolistem has quit [Client Quit]
broccolistem has joined #lisp
broccolistem has quit [Client Quit]
<fe[nl]ix>
phoe: use static-vectors and avoid copying
vlatkoB has quit [Remote host closed the connection]
<phoe>
the implementation needs to support it
<phoe>
since you are creating an object that is a valid Lisp array and also contains a valid C array
<asarch>
I see
broccolistem has quit [Client Quit]
<asarch>
Thank you guys
smurfrobot has quit [Remote host closed the connection]
broccolistem has joined #lisp
smurfrobot has joined #lisp
broccoli_ has quit [Ping timeout: 240 seconds]
broccolistem has quit [Client Quit]
damke_ has joined #lisp
broccolistem has joined #lisp
damke has quit [Ping timeout: 264 seconds]
broccolistem has quit [Client Quit]
broccolistem has joined #lisp
EvW has joined #lisp
broccolistem has quit [Client Quit]
broccolistem has joined #lisp
broccolistem has quit [Client Quit]
orivej has joined #lisp
shifty has joined #lisp
t0adst00l has joined #lisp
broccolistem has joined #lisp
broccolistem has quit [Client Quit]
fourier has left #lisp ["ERC (IRC client for Emacs 25.3.1)"]
smurfrobot has quit [Remote host closed the connection]
broccolistem has joined #lisp
broccolistem has quit [Client Quit]
smurfrobot has joined #lisp
smurfrobot has quit [Ping timeout: 256 seconds]
warweasle has quit [Quit: later]
Cymew has joined #lisp
ykoda has quit [Remote host closed the connection]
Cymew has quit [Ping timeout: 252 seconds]
makomo has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 260 seconds]
makomo has joined #lisp
fikka has joined #lisp
jmercouris has joined #lisp
<jmercouris>
anyone willing to help test nEXT on Linux?
fikka has quit [Ping timeout: 260 seconds]
<jmercouris>
I only have a VM, so I'm not sure how quick things are, and I'm getting some extremely strange GTK errors, not sure how much is my code or VM
<jasom>
jmercouris: what do you want me to do?
<jmercouris>
jasom: Just run it, and see if it explodes/works on your machine
<jmercouris>
jasom: If you're curious about the source code, it's all available for you to look at
<jasom>
e.g. changing it from #' to ' makes it work
<jasom>
well not complain, haven't tried it for working yet
<jmercouris>
jasom: Huh, maybe mine only works because I've alredy compiled
<phoe>
I'd like to ask for a proofreading in case I screwed up somewhere.
<jmercouris>
phoe: number 5 makes no sense
<jmercouris>
"Run apt install emacs for installing vim. Install spacemacs or download your favorite emacs configuration."
<jmercouris>
phoe: Pretty impressive technology
<phoe>
jmercouris: fixed.
<jmercouris>
jasom: Does it start or no?
<jasom>
jmercouris: ah, I think I needed to load "next/gtk"
<phoe>
jmercouris: technology? what do you mean?
<jmercouris>
jasom: That would make sense, gotta ql it first
<jasom>
jmercouris: I was not aware that the "next" system was insufficient
<jmercouris>
phoe: I mean, it is impressive that it's possible to run this on android at all
<jmercouris>
jasom: Yeah, "next" is just the core
<jmercouris>
jasom: Sorry about that!
<phoe>
jmercouris: the rule is simple
* jasom
is installing newer libwebkit2
<phoe>
1) get a C compiler there, 2) run everything
randomstrangerb has quit [Ping timeout: 256 seconds]
<jmercouris>
phoe: simple != easy
<jasom>
jmercouris: I'll get back to you tomorrow on this; I'm running gentoo, and currently not at my faster machine, so it will take a couple of hours to build webkit
<jmercouris>
jasom: You have to literally build it :D?
randomstrangerb has joined #lisp
<jasom>
jmercouris: yup
<jmercouris>
jasom: Okay, I look forward to it, thanks!
<jasom>
I can build webkit in 65 minutes on my faster machine, but I'm on a 4 year old xeon right now, so it will take maybe 3 hours to build
<jmercouris>
Lol, that's hilarious, doesn't portage provide binaries?
<jmercouris>
It is portage right?
<jasom>
jmercouris: it only provides binaries for select items
<p_l>
jmercouris: no, it doesn't, then webkit is just a PITA
broccolistem has joined #lisp
<jmercouris>
How should I package my application for distribution on Linux?
<jasom>
jmercouris: make a deb that works on ubuntu and force everyone else to build from source; that's the Linux way :)
<jasom>
(substitute "rpm" for deb and "Red Hat" for ubuntu if it's 10 years ago)
broccolistem has quit [Client Quit]
drcode has joined #lisp
<jmercouris>
jasom: How do I make a deb file for SBCL or CCL?
<jasom>
jmercouris: they already exist
drcode has quit [Remote host closed the connection]
no_bobby has joined #lisp
<jmercouris>
So I run the app, save the image, and pop into an existing deb file and ship?
<Shinmera>
jmercouris: You might have luck with AppImage. Alternatively you can wait for me to get around to turning Portacle into a platform
<jmercouris>
How do I ensure that the user has the webkit libraries for example?
<jasom>
jmercouris: that should work. If you want it to get upstreamed you'll have to do more (the author of pgloader did this)
<jasom>
jmercouris: you specify dependencies
<jasom>
jmercouris: easiest way to check your deps are right is to use an lxc or vm image of a fresh install and see if it works there.
<jmercouris>
Shinmera: AppImage looks pretty cool
<jmercouris>
jasom: I am running on a completely barebones vm right now
<jasom>
for actually getting it upstreamed, the author of pgloader has a blog article about it
<jmercouris>
jasom: I wish I had a linux machine that didn't suck
<jmercouris>
jasom: you mean dim?
<jmercouris>
or is it demetri, it's d+ something
<Shinmera>
It's dim
<jasom>
jmercouris: I'm really bad with names, so don't ask me
drcode has joined #lisp
smurfrobot has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
smurfrobot has quit [Ping timeout: 248 seconds]
EvW has quit [Ping timeout: 246 seconds]
no_bobby has quit [Ping timeout: 256 seconds]
jmercouris has quit [Remote host closed the connection]
jmercouris has joined #lisp
fikka has joined #lisp
<aeth>
AppImage is probably the least popular of the three options (the other two are Flatpak and Snappy, with the third being Canonical's NIH)
<aeth>
And, yes, it's Linux, there's always at least three options.
<aeth>
GNOME is backing Flatpak and Ubuntu is backing Snappy, which is why they're probably more popular.
<jmercouris>
Sometimes more choice is less good
<jmercouris>
I'm sure that's an unpopular opinion, but I don't feel like packaging my app in 20 different ways
<Shinmera>
aeth: Don't forget about Docker...
<aeth>
I'd personally go with Flatpak, then. It seems to be extremely available, e.g. Fedora installs it by default.
<aeth>
(And it's not just because Fedora is a GNOME distro, I install the KDE spin.)
<jmercouris>
I'm mentally going to just making a deb file and letting everybody else figure it out
<aeth>
That's probably the worst option. debs aren't portable at all.
<jmercouris>
debian + ubuntu should cover most users I think, and anyone who doesn't use those distros should be used to installing from source
<aeth>
Actually, no
<aeth>
As a Fedora user, I'm used to there being a Fedora/SUSE RPM option as well.
<aeth>
Arch is where people who are used to source installs go
<Shinmera>
And even then I like having an AUR build script ready for me
<jmercouris>
As a BSD user, I'm used to things not being available
<aeth>
(Although it's common that the RPM is third party)
mishoo has quit [Ping timeout: 240 seconds]
igemnace has quit [Quit: WeeChat 2.0.1]
<jmercouris>
aeth: Will you be my third party ;)?
no_bobby has joined #lisp
<aeth>
Personally, if I released packages, I'd just do a Flatpak and if someone wants to make distro-specific packages the community can do it themselves.
<aeth>
The old portable method was a shell script, usually installing things to ~ or ~/foo/ with an option to install them to /usr/local/
<aeth>
I've encountered that a lot more than providing a package at all.
broccolistem has joined #lisp
<aeth>
In checking, I just found out that I have a /usr/@DATADIRNAME@/ so that shows you how reliable such scripts are.
selwyn has quit [Read error: Connection reset by peer]
frob has joined #lisp
frob has left #lisp [#lisp]
no_bobby has quit [Ping timeout: 248 seconds]
<aeth>
Cool, specialization-store supports ECL now
<pillton>
I added it before it got added to quicklisp.
smurfrobot has joined #lisp
<aeth>
I guess it's just missing ABCL and CLISP support (fairly common due to how those implementations work) and Clasp support (also fairly common, due to Clasp not being complete yet)
<aeth>
Also, Mezzano (is it its own implementation?) and MKCL (probably the least supported implementation for libraries)
shifty has quit [Ping timeout: 260 seconds]
wxie has joined #lisp
<pillton>
Well, I am only one person. It took nearly four years for SS to get where it is now.
<aeth>
Afaik, SBCL+CCL+ECL+CMUCL covers most people outside of the commerical Lisp world, and any large application will already have some dependency that doesn't support the rest.
smurfrobot has quit [Ping timeout: 268 seconds]
<pillton>
ECL doesn't implement the environment API of CLtL2. The compile time functionality of SS requires it.
EvW1 has joined #lisp
__rumbler31 has quit [Ping timeout: 268 seconds]
<aeth>
pillton: So how do you handle support on implementations that don't support it at compile time?
<pillton>
Implementing that and updating introspect-environment is a good project for someone.
<aeth>
And I agree.
<pillton>
All of the compile time support is delegated to introspect-environment.
<pillton>
I think it just returns T.
<aeth>
oh
<aeth>
hmm
<Bike>
ecl has an environment api now?
<pillton>
Not that I know of.
<pillton>
I thought it would be a good project for someone.
<aeth>
pillton: Would specialization store work for an inline function that takes either three arguments or one argument, where the one argument variant is actually based on the three argument version? I have two vector representations (multiple value and actual vector) and I implement all of my vector math as multiple value math, currently using %foo as the multiple-value name
<pillton>
aeth: Yes. The link about rest arguments shows how to do that.
<pillton>
aeth: SS is smart enough to interpret THE forms.
<aeth>
pillton: Currently, I have (vec+ v1 v2) and (vec+-into! result-v v1 v2) that are both implemented based on an inline (%vec+ v1-x v1-y v1-z v2-x v2-y v2-z) and I do this for everything (vectors and quaternions) except matrices, where the multiple value approach is too inelegant
<aeth>
So e.g. there's also a %quaternion+ that takes in 8 values used as the basis of quaternion+ and quaternion+-into!
<pillton>
I have no general advice for mathematical problems. It is probably the hardest domain to design for.
<aeth>
The "%" is a bit of a misnomer because I actually mostly use them directly because I put a lot of my vectors in 2D arrays, where the row represents the actual value and I retrieve multiple values
jstypo has quit [Remote host closed the connection]
<aeth>
pillton: Well, there are definitely higher-performance ways to do what I'm doing. I do the multiple-values approach because it gives me pure functions that do not cons. It makes the API really messy, though.
<pillton>
I do the same thing (except they are called vec+ and nvec+).
<pillton>
In my experience, the BLAS/LAPACK API is by far the easiest to work with.
<aeth>
A naive-consing vector API will have 1/3 the functions that I have (naive consing, -into, and multiple-values)
<aeth>
Using the -into API winds up making everything look not very mathematical and more like a machine
<pillton>
You get used to it after a while.
<pillton>
The problem with the mathematical way is understanding what happens underneath.
<pillton>
I've tried doing all the analysis and it is ..... hard.
<aeth>
I only use the -into method for matrices
<aeth>
I don't even call them -into
<aeth>
e.g. it's (matrix* destination m1 m2)
QualityAddict has quit [Ping timeout: 265 seconds]
<pillton>
I do a similar thing.
<aeth>
Unless I move to SBCL-only SIMD, there isn't really a disadvantage to using the multiple value approach directly. It actually beats writing for the vectors themselves because it essentially is a loop unrolling via macro.
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
<aeth>
I think it adds one instruction over doing it manually.
QualityAddict has joined #lisp
<aeth>
I'd like to make the whole thing cleaner, though. Having three versions that do the same thing with different tradeoffs is messy.
<pillton>
You always have that trade off. It is even worse with matrices since they can be row-major, column major or some general stride setup.
kupad has quit [Ping timeout: 240 seconds]
<Shinmera>
Wait until you get to sparse matrices.
<Shinmera>
That's where the real "fun" begins.
<Shinmera>
(Don't implement your own sparse matrix stuff. It's not worth it.)
Bike has quit [Ping timeout: 260 seconds]
smurfrobot has joined #lisp
<pillton>
You can say the same thing for diagonal matrices or Toeplitz.
<Shinmera>
Or any matrix stuff, really
<Shinmera>
In general, don't implement your own linear algebra
<pillton>
That isn't a satisfactory position to advocate. How will things improve?
moei has quit [Quit: Leaving...]
<Shinmera>
Things improve if you tackle domains that you have a good shot at improving. Linear algebra is highly likely not one of those.
wxie has quit [Remote host closed the connection]
Tobbi has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nirved has quit [Quit: Leaving]
asarch has quit [Quit: Leaving]
damke_ has joined #lisp
Tko has quit [Ping timeout: 264 seconds]
damke has quit [Ping timeout: 264 seconds]
ski has quit [Quit: Lost terminal]
kupad has joined #lisp
smurfrobot has quit [Remote host closed the connection]
LiamH has quit [Quit: Leaving.]
Xach has joined #lisp
kajo has joined #lisp
Murii has quit [Quit: WeeChat 1.4]
whoman has quit [Read error: Connection reset by peer]
random-nick has quit [Remote host closed the connection]
smurfrobot has joined #lisp
<aeth>
Afaik, you can't really get very high performance vector stuff in CL
<pillton>
SBCL is pretty good considering the assembly doesn't use SIMD.
<aeth>
At least for game linear algebra, it looks like the optimal data structure (e.g. if I were implementing it in x86-64 asm directly) would be a buffer of what SBCL calls simd-packs.
makomo has quit [Ping timeout: 248 seconds]
<aeth>
if that's even possible
jamtho_ has joined #lisp
<aeth>
i.e. instead of an array of 32000 (sb-ext:%make-simd-pack-single)s, you do SIMD on offsets into a buffer that can hold the equivalent amount of data.
<aeth>
It could be kept compact by e.g. swapping the last valid element in the buffer with the one you're removing and then removing the last valid element in the buffer
<aeth>
(in this case, the element would be the simd, not one float)
damke has joined #lisp
<aeth>
If this scheme could work and the GC could skip over this chunk of memory, too, that would be amazing.
smurfrobot has quit [Remote host closed the connection]
damke_ has quit [Ping timeout: 264 seconds]
<JonSmith>
could probably done with some of the ffi stuff
<aeth>
To be really worth it in a library one would have to (1) make it portable to at least CCL and ECL even if the portable part is a slower fallback in native CL and (2) add no foreign library dependencies
<JonSmith>
you'd use cffi / uffi / whatever is in vogue now to fix the memory mostly
<aeth>
Oh, and the holy grail would be (3) if it was as usable as static-vectors
<aeth>
#3 is probably impossible
<pillton>
You could also consider adopting an API similar to LDB and DPB but for chunks of an array.
<pillton>
... and BOOLE.
<JonSmith>
alternately it would be cool for someone to hack SIMD vector stuff into sbcl
antonv has joined #lisp
<pillton>
What would it look like?
smurfrobot has joined #lisp
Tko has joined #lisp
safe has joined #lisp
<JonSmith>
probably a set of VOPs and some sort of logic to trigger them when you're doing *special vector stuff*, its been a long time since i looked at the sbcl internals so i can't remember how the optimizer/emitter works
<pillton>
I mean, what would a user write to perform a dot product of two vectors?
<JonSmith>
that would be a couple levels of abstraction up from what i'm suggesting, so presumably lisp code that does a dot product of two vectors that have type declarations
<JonSmith>
it would be cool, but that doesn't mean it is particularly feasible
<JonSmith>
and i think they'd be typed 1d arrays rather than vectors, technically
<JonSmith>
or 2d
makomo has joined #lisp
JonSmith has quit [Remote host closed the connection]
DeadTrickster_ has joined #lisp
smurfrobot has quit [Remote host closed the connection]
DeadTrickster has quit [Ping timeout: 248 seconds]
<stylewarning>
pillton: aeth: within a couple weeks we will be releasing our linear algebra library. It could use lots of work for the high level API, but the BLAS/LAPACK bindings are solid.
DeadTrickster has joined #lisp
Kaisyu has joined #lisp
DeadTrickster_ has quit [Ping timeout: 256 seconds]
<pillton>
stylewarning: Great. I look forward to it.