freenode/#lisp - IRC Chatlog
Search
9:05:06
beach
asdf_asdf_asdf: It is a *huge* mistake to think that all programming languages are fundamentally the same and that you can translate code from one to the other while preserving the overall organization of that code.
9:06:18
beach
asdf_asdf_asdf: To make things worse, C is often used in ways that the standard says is undefined behavior, but which is traditional behavior of C compilers. Such code is even less possible to translate to Common Lisp directly than conforming C code.
9:08:07
saturn2
even if you succeed, you would just end up with the same program but slower and incomprehensible to anyone but you
9:10:18
beach
asdf_asdf_asdf: So, it is highly likely that your questions such as "what is the equivalent in Common Lisp of the C construct <mumble>" will be answered by "there is no equivalent". I therefore advise you to learn Common Lisp as a language in its own right.
9:11:46
beach
asdf_asdf_asdf: You will learn more about idiomatic Common Lisp, and you will annoy people here a lot less that your current questions result in.
9:12:33
asdf_asdf_asdf
@beach; I know not must be equivalent, code in different languages another is written.
9:17:08
beach
asdf_asdf_asdf: Then quit trying to interface to C as part of your learning Common Lisp, and start using Common Lisp as a language in its own right, so that you can learn how it works, what the idioms are, and how you structure Common Lisp code.
9:20:16
aeth
The main line, I'd say, is garbage collected vs. not. But of the non GCed languages, C is about as far fron CL as you get. Even C++ has a lambda now!
9:21:23
aeth
Your code still wouldn't be idiomatic if you translated Ruby or Python or JavaScript, but at least it'd be easier to find equivalents.
9:23:21
Shinmera
You can port C code to Lisp just fine, as long as you don't try to do pointer arithmetic or other crap they like to do. In order to be able to do such a port you need a good grasp on both languages and understand how concepts translate.
9:23:50
aeth
C's all about using stuff not exposed in CL to implement stuff that practically everyone else gives you as part of the language.
9:24:22
aeth
You can translate stuff from C if it's something that can be written in any language, of course.
9:26:51
aeth
You can also do fun hacks to e.g. fake foo(&x) in CL by e.g. using 0-dimensional arrays or other fun obscure corners of the language, but as you said, you need to know both languages well first.
9:28:13
beach
My point is that I am quite convinced that asdf_asdf_asdf does not currently have the required knowledge to port C code to Common Lisp code, not to do any sophisticated emulation of the C runtime environment in Common Lisp.
10:12:38
minion
rigidus: have a look at onlisp: An advanced textbook on Common Lisp, with special focus on macros. at http://www.cliki.net/On%20Lisp
10:12:46
minion
rigidus: paip: Paradigms of Artificial Intelligence Programming. More about Common Lisp than Artificial Intelligence. Now freely available at https://github.com/norvig/paip-lisp
10:17:02
jackdaniel
like: graphics, algorithms, integrated development environments, some paticular kind of applications?
10:18:34
jackdaniel
for the last part I could recommend studying source code of cl-ppcre which implements regular expressions for Common Lisp
10:19:09
jackdaniel
regarding robots and expert systems I'm not familiar with libraries concerned with these topics
10:20:54
rigidus
jackdaniel: I was able to write the FORT in assembler 86, but I had difficulty trying to write a lisp on this FORT
11:02:51
shka__
rigidus: i made basic prolog implementation in CL, I am trying to optimize list unification right now
11:12:29
no-defun-allowed
Just saying, Hugin (with one N) is the name of an image-stitching program I've used before, but I don't think a Prolog and an image tool are easily conflatable.
11:16:46
shka__
or perhaps even better https://github.com/sirherrbatka/huginn/blob/master/src/machine/operations/unfolding.lisp
11:17:09
shka__
this is unfolding implementation with shared representation for code and data on the heap
13:21:27
dlowe
I use the one from quicklisp, since it's guaranteed to be in synch with the swank version
14:25:56
Shinmera
Dunno what you mean with out of sync either, slime from melpa bundles swank just as the one from ql does.
14:42:02
sukaeto
I think dlowe is referring to situations where you run your own Lisp image outside of Emacs and then slime-connect to that
14:42:46
shka__
i do that quite often, usually swank and slime are at most 1 version apart and so far it worked for me without a problem
14:42:53
sukaeto
in that case, if you've got the melpa SLIME package installed, you'll get a version mismatch if you're ql:quickload'ing swank from your Lisp image
14:43:36
sukaeto
you get a warning on connect that there's a version mismatch, you tell it OK, and it connects and works
14:44:51
sukaeto
fwiw, I only do it this way because when I set it up I didn't know about quicklisp-slime-helper
14:45:46
sukaeto
yeah, I mean, if you're using swank<->slime communications in a production system maybe you'd want to extensively test before doing this?
14:51:06
Shinmera
sukaeto: Even in that situation you'd have to guarantee that you're running the same QL dist version locally, too.
14:55:47
sukaeto
Shinmera: oh yes, of course. If you're juggling multiple systems all pinned to different QL dists, I can believe you'll run into this problem all the time
15:02:22
remexre
weird behavior: I'm trying to do :perform (test-op (o c) (symbol-call :fiveam '#:run! :foobar)) in an asd file I'm loading with ABCL, but I'm getting "There is no class named TEST-OP."
15:07:52
Bike
yes, and in that case you're treading in dangerous territory by using things the developer doesn't expect you to use and may change without warning
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.