freenode/lisp - IRC Chatlog
Search
16:37:34
Xach
a lot of stuff depends on pngload and i worry that making it narrowly loadable will break a lot of stuff.
16:38:55
mfiano
Well, if you want to hold pngload back 1 release, I'm fine with that. We're actually in the middle of a major change that should be ready in a couple days. pngload will be close to the speed of libpng very soon
16:39:43
Xach
everyone has their own priorities, but i would rather have a pure CL library that was slower than have something that only builds if you have gcc
16:42:12
mfiano
I understand. pngload's goal has always been performance, as most of its users, myself included, use it for game development -- streaming multiple 4096x4096 or 8192x8192 RGBA images. Some trade-offs had to be made in that area.
16:43:35
mfiano
But you're not the first with such a concern, and we are already looking into it. mmap for example is a POSIX-compatible thing. Mezzano doesn't even have CFFI
16:46:05
Xach
mfiano: i may have misunderstood - i interpreted your issue as "mezzano has switched to 3bz" - but i think I should have read it as "mezzano uses pngload"?
16:46:23
mfiano
I'm sorry. We actually didn't realize the issue until it was pointed out to us after being merged into master.
16:47:35
mfiano
Point being though, McCLIM doesn't have any C layer at all, and so the mmap library or any CFFI won't work at all.
16:48:40
Xach
Ok. I'm glad that you're aware of it. In a situation like this it seems like maybe a fork with a new name for people who are happy to use ffi to get the best performance...is that feasible?
16:50:17
mfiano
Yes that is feasible. I actually wasn't aware of the issue until after it was merged. It was just pointed out to me yesterday. 3b wasn't aware either.
16:53:43
mfiano
Xach: Would a separate branch work just as well. I sort of don't want to split the trees up into separate repositories, but I will if I must.
16:54:18
Oladon_work
We could build a websockets-based browser extension that receives such notifications from Xach and displays them to everyone using the extension in real time!!
16:54:44
Xach
mfiano: I can pull from a specific branch. Are you thinking of having a branch with the old pngload and add new code to master?
16:55:24
Xach
mfiano: would you consider doing it the other way instead, where master has the old stuff and the new stuff is on a branch?
16:58:48
mfiano
slow-pngload, while speaks relatively, conveys that pngload itself is slow compared to say png-read :)
17:03:29
dlowe
If it's just the mmap, someone could theoretically make a trivial-mmap that interfaced with the OS syscalls
17:12:12
mfiano
Hmm. I think it would be a burden for me to maintain two versions. It's already a burden maintaining the one. It is pretty complex code in order to be fast. I'm considering sending pngload-legacy to sharplispers or something.
17:12:48
mfiano
Most of the changes I would make would need to be done in parallel, which is why I mentioned a branch rather than a fork, but even that is still a bit of a burden
17:13:44
Xach
It would make life easier for me and anyone else who uses pngload now if pngload remainded the same and a new fast version had a new name. (Not saying this is worth changing what you want to do.)
17:16:29
mfiano
I am juggling too many projects is all, and pngload takes a lot of brain cells when something needs to change. Sadly, I am no Shinmera
17:18:25
mfiano
Xach: For now, how about we just hold back pngload this month as to not break anything while I talk to 3b about perhaps conditionalizing 3bz and pngload to be compatible everywhere.
17:18:33
Xach
Shinmera is actually a loose collective of dozens of lisp hackers, do not compare yourself to that! It's no-win!
17:33:00
|3b|
ACTION plans to split cffi/mmap dependency of 3bz into a separate system by next month, any idea if nibbles is a problem too?
17:40:48
|3b|
looks like nibbles has portable implementations of integer functions, so might work on mezzano... don't think i would have used the float functions in 3bz
17:47:28
verisimilitude
Am I to understand there's a library for manipulating PNGs written entirely in Common Lisp, already existing?
17:48:28
verisimilitude
That's interesting; I never looked much, but only saw C bindings. I'll probably focus on some format without a pure Common Lisp solution whenever I get around to manipulating images, then.
17:50:24
verisimilitude
What I meant is, whenever I do finally get around to working with some image file format, I'd prefer to write a Common Lisp library that serves a format where that currently isn't done.
17:50:47
Shinmera
mfiano: |3b|: Xach: I would be more than fine with removing the Osicat dependency in mmap.
17:52:28
Shinmera
The only reason I used osicat was because I was too lazy to do a survey of the necessary constants and types myself.
17:53:27
verisimilitude
I see there's already an implementation of a tar format handler in Common Lisp, although that won't stop me from writing my own at some point; the name I thought of is too good to glance over.
18:02:09
mfiano
Xach: Okay, master now reflects the state before 3bz, and the fast branch is the new one.
21:31:28
ralt
is there an easy way to access an element by name, e.g.: `((:server . "nginx") (:etag . "foo"))` looping through every element looks ugly. Want to get a drakma response header.
22:06:07
ralt
never needed it until now, and now I realize there's a lot of things I could've done better
3:59:16
ck_
tourjin: you can get slime through the emacs package system, for example. Search for "Melpa packages" to set that up
4:00:39
jeosol
Is there a work around to save SBCL from slime (normally do that from the shell). Keep getting this message: "Cannot save core with multiple threads running."
4:08:15
|3b|
you could try killing all worker threads, exiting repl, and saving from *inferior-lisp*