freenode/#lisp - IRC Chatlog
Search
5:32:29
jmercouris
pjb: Some people install one billion packages, and then complain when their nyan cat rainbow modeline slows down their system
5:32:54
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.
5:33:59
aeth
It wouldn't be hard at all to write something more reliable than Emacs. Just keep safety above 0.
5:37:42
fiddlerwoaroof
Hmm, should give circe a whirl: using trim-buffers, erc seems to be fairly fine for me
5:38:25
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.
5:38:51
jmercouris
aeth: All ram is lost, like tears in rain, do not fight against electron.js, embrace it
5:39:20
jmercouris
Ram is like sand, the harder we try to hold it, the quicker it runs through our hands
5:39:24
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
5:40:27
p_l
jmercouris: I fight hard against RAM waste because I already lost the fight on web front
5:41:26
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.
5:42:03
fiddlerwoaroof
I find that system reponsiveness is more affected by ram usage than cpu usage these days
5:42:26
fiddlerwoaroof
e.g. if my desktop starts feeling laggy, I close all my tabs and everything is snappy again :)
5:42:38
aeth
freshly started up (and my OS is not on a recent SBCL!) 49 MB in a terminal, 51 MB in SLIME
5:43:39
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 :|
5:45:30
parjanya
if I create a stream with (process-output (run-program "/usr/bin/ls" '() :output :stream)) , how can I read it?
5:45:44
aeth
Basically the only thing that uses unjustified amounts of RAM are web browsers or things that use web browsers like Electron apps
5:46:17
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.
5:46:41
p_l
aeth: and then there applications that take "electron" and put "even more unjustified resource usage", like Slack
5:47:14
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.
5:48:15
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
7:11:44
eviltofu
If I want to make a GUI app in common-lisp that runs under macOS, what should I use?
7:12:52
pjb
You can add my Objective-CL reader macros if you want to have an Objective-C -like syntax.
7:14:17
jackdaniel
so it is certainly possible to run it on macos, but it doesn't have this "native" feel
7:14:19
pjb
If you don't want to make a Cocoa Application, then you can use any implementation with CLIM.
7:25:04
aeth
eviltofu: There's also another kind of graphical application that's possible, too. e.g. https://github.com/vydd/sketch#sketch
7:25:21
aeth
These other things all use OpenGL, so you're definitely not going to get a native feel.
7:29:18
aeth
Some people have built entire GUIs on top of OpenGL, though, e.g. the Blender 3D modeling application.
7:30:26
aeth
Also McCLIM used to have an OpenGL backend, but it was removed here, probably because it was over a decade out of date. https://github.com/robert-strandh/McCLIM/commit/d1bc1e222b36adffa5a76e4c664d1b365d2144e4#diff-b81146e6af95bf6e22cf57459890216f
7:31:01
eviltofu
Sketch is interesting, I was looking at Processing a few weeks back for some coding fun!
8:03:25
jdz
Which OpenGL? On which platform is that specific OpenGL supported, and FFI available for CL?
8:04:41
jdz
I bet OpenGL will be obsolete soon enough, with different vendors moving in different directions: MicroSoft -> DirectX, Apple -> Metal, Others -> Vulkan.
8:06:05
earl-ducaine
Clutter is a good example of modern, full feature graphic toolkit built on top of open GL.
8:08:57
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.
8:11:21
Shinmera
If anything, OpenGL has been gaining massive traction in recent years thanks to the web and mobile tech
8:13:28
earl-ducaine
Wing 3d is an interesting 3d modeler. GUI and canvas are both implemented in open GL.
8:13:34
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.
8:17:26
jdz
Also relevant to this discussion: http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trainwreck-2016-edition/
8:31:16
whoman
ACTION is only concerned about HDD lag from swap for general desktop useage. dev tools should be hyperspeed negative latency
8:34:33
aeth
In the world where Electron apps are commonplace, even SBCL is absolutely lightweight in RAM.
8:38:44
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
8:45:38
loke
jdz: That article dismissed GTK for adding 20 MB to the code size. That's a bit silly, IMHO
8:46:01
loke
His requirements are not only that he wants to graw graphics and stuff, he also wants it really small.
8:48:58
aeth
jackdaniel: But, on the other hand, it's a lot easier to avoid allocation in SBCL through profiling and disassembly, at least ime.
8:49:14
aeth
When I want to write some large thing that doesn't allocate, I'm only sure that it doesn't allocate in SBCL.
8:50:58
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
8:51:36
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.
8:54:53
jdz
Even if the conclusion is not useful the article still includes more data points than "Blender uses OpenGL for GUI".
8:57:20
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.
8:57:23
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
8:58:23
beach
jackdaniel: Sure, but that elegance comes at a cost. And I rarely see that cost evaluated against the gain in memory.
8:59:05
beach
jackdaniel: Plus, someone who is obsessed with memory size probably makes other elegance compromises instead.
8:59:59
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.
9:00:11
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)
9:01:50
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!)
9:02:09
loke
By looking at the Nom web site, it seems to me that the users have similar values as the Go crowd.
9:02:43
loke
(I'm old enough to remember Unixes without dynamic linking support at all, and it was not fun)
9:04:45
aeth
loke: A potential counterargument: we have a lot more space now. Even 1 TB SSDs are very affordable.
9:06:04
jackdaniel
dynamic linking goes beyond that - updating library requires updating only one shared object
9:08:13
jackdaniel
sure, did you ever use gentoo? if you don't have dynamic linking it gets even more messy
9:09:38
aeth
I think the future is probably going to be sandboxing all over the place, which could be the death of dynamic linking.
9:09:56
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.
9:10:53
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.
9:12:17
jackdaniel
OK, I get it better now, yet sometimes it's not very obvious from the context for me (probably fault in my understanding)
9:20:42
loke
aeth: Let me tell you, they are doing something interesting, but man is the approach flawed.
9:48:07
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.
11:20:48
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?
11:22:17
Shinmera
Because then you'd create an indefinite extent reference and prevent it from being GCd.
11:22:55
phoe
Shinmera: exactly, (lambda () (free-static-vector (static-vector instance))) would be a mistake.
11:23:54
Shinmera
What I like to do is this kind of scheme: https://github.com/Shirakumo/cl-mixed/blob/master/c-object.lisp
11:25:13
phoe
CL-LZMA will get a pretty big update, including an API change that makes use of static vectors.
11:25:15
Shinmera
Point being a generic function that returns a closure that "knows" how to finalise that object's resources.
11:25:55
phoe
Since right now it's 95% CL overhead coming from coercing vectors from (UNSIGNED-BYTE 8) to T and the other way around
12:31:31
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
12:32:37
jdz
Have a thread that sleeps most of the time, or have a main loop that periodically checks the schedule.
12:33:24
jdz
There might be platform-specific ways to also schedule a signal (alert) for the process.
12:34:05
Shinmera
Just sleep like half of the time you need to the next event until you're within a certain range of acceptability.
12:34:32
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
12:34:54
Shinmera
(loop for diff = (- (get-universal-time) target-time) until (< diff 60) do (sleep (/ diff 2))
12:39:28
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.
12:40:38
phoe
osune_: there was a thing with minion where you could ask him to remind you to do something in 140380 seconds or something (:
12:41:30
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)
12:43:00
osune_
phoe: I assume I should look at the code for minion. Or are you suggesting I should make requests against minion via IRC ? ;)
12:43:32
Shinmera
Alternatively you can just sleep for a second in a thread and then check all events.
12:44:28
Shinmera
osune_: Then just loop sleep a second and check each event, with events sorted by target time to short-circuit.
12:45:06
Xach
When I had the same problem I made a heap data structure and slept until the next minimum item.
12:49:41
osune_
phoe: minion doesn't have the command anymore, looking at the help-text in this repository https://github.com/stassats/lisp-bots/blob/c39f7e793ef96c3a0715413af404a16faf4f47f8/minion/minion.lisp#L340
12:50:08
phoe
osune_: ow. Well then, obviously you need to write your own IRC bot in order for your thread to be able to sleep. ;)
12:57:03
osune_
jdz: it's posix.1-2001. Even if posix.1-2008 supersedes it, it seems to be the way to go for now
12:59:25
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.
13:01:12
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?
13:04:13
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?
13:05:36
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?
13:09:03
jdz
I knew about alert(), then just learned about {set,get}itimer, and upon learning about them they got immediately deprecated.
13:31:22
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"
13:32:09
p_l
osune_: syscall is not equall to syscall, though. Normally-callable functions count as system calls for purposes of POSIX
13:32:36
p_l
in fact, on most recent Unices, timer-related syscalls are actually library calls often to kernel-managed space
13:39:28
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.
13:47:01
Shinmera
|3b|: If you could review https://github.com/3b/3bmd/pull/36 I'd appreciate it a lot
13:48:03
osune_
p_l: just to a be borderline nitpicking: `man 2 syscalls` lists setitimer as syscall http://man7.org/linux/man-pages/man2/syscalls.2.html ;)
14:05:34
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 ;)
14:07:03
osune_
jdz: doesn't matter, even setitimer(2) says it's deprecated so you are good or something like that :)
14:21:45
jdz
Xach: the project is not linked from https://www.xach.com/lisp/ (probably intentionally; just letting you know).
14:51:13
sigjuice
anyone know offhand approximately how much disk space it would be if I downloaded all quicklisp releases for offline use? Thanks!
14:58:55
Xach
sigjuice: to install it all, you can use ql-dist::(map nil 'ensure-installed (provided-releases (dist "quicklisp")))
15:01:40
makomo
Xach: what kind of syntax is that? does it evaluate the form as if it was in the package ql-dist?
15:10:07
Xach
allegroserve uses foo:: a few places and it really puts a crimp in porting to clozure cl.
15:10:48
Xach
mfiano: fwiw http://report.quicklisp.org/2018-01-02/failure-report/gamebox-grids.html#gamebox-grids
15:13:02
mfiano
Xach: Please remove that library from Quicklisp. It has no users and the math is wrong on closer inspection.
15:43:23
phoe
Shinmera: no, COERCE'ing arrays from (unsigned-byte 8) to T and then from T to (unsigned-byte 8).
15:43:52
phoe
So working on 600kB worth of tiny archives consed up about half a gigabyte of memory in total.
15:44:16
phoe
It's easy to achieve 40000% speedups, you just need to fuck up *really* bad in the first place.
15:45:02
phoe
Or, to be more specific, coercing raw CFFI memory into simple-vector into (vector (unsigned-byte 8)).
15:45:11
Shinmera
Reminds me of the stories of people intentionally making products slower so that they had an insurance on future releases being faster.
15:46:26
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
15:48:32
phoe
Unrelated: I just found a way to run threaded ECL on my Android phone, via termux. I'll blogpost about it later today.
16:19:16
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".
16:19:52
whoman
i dont think one dude has enough capacity or perspective or time or energy for anything made by many people. crowd wins
16:24:27
beach
I recall a paper by Xof, explaining good and bad ways of using reader conditionals. Does anyone remember where to find it?
16:25:28
whoman
web tech is not an "invention" - its layers and layers of progressive changes and things from the whole world
16:25:51
whoman
like public transpotation. we can blame cars or roads or whatever but yeah we still got to get around
16:27:07
LexLeoGryfon
casual symposyim of lisp programmers https://www.pornhub.com/view_video.php?viewkey=1221903074
16:34:15
Xach
the person is trying to disrupt the global productivity of lispers. let us not help them succeed by discussing it further!