freenode/#lisp - IRC Chatlog
Search
8:48:18
beach
asdf_asdf_asdf: I am reading your questions in the channel logs, and I don't quite understand why you program in Common Lisp, given that you seem to want to treat it as just another language in the C family, where you can take the address of variables, and manipulate pointers explicitly.
8:48:18
beach
I think you would be much better off using a language in that family, rather than trying to twist Common Lisp into something it really is not in the first place.
8:49:53
beach
Perhaps you are under the impression that Common Lisp is just another language in the same family, only with a different syntax. That is not the case. It is fundamentally different with automatic memory management and uniform reference semantics.
8:52:11
beach
Well, I am afraid that asdf_asdf_asdf is wasting time because of a fundamental misunderstanding about what Common Lisp is.
8:52:45
beach
And I don't understand this desire of simultaneously using Common Lisp and treating is at something it is not.
8:55:59
asdf_asdf_asdf
Some lack me theory, so that not understand that probably reference not exists in CL.
8:57:46
beach
asdf_asdf_asdf: I understand you might not quite understand the semantics, but why are you using Common Lisp in the first place if you want to program as if you are using C, and, as I recall, also accessing C code from Common Lisp?
8:58:40
beach
asdf_asdf_asdf: If you are using Common Lisp in order to learn how to program in it, I strongly recommend you not try to interface to C in the beginning.
9:00:04
beach
asdf_asdf_asdf: If you use Common Lisp that way, the code you are going to end up with (if you succeed at all) is going to be very ugly.
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.