freenode/#lisp - IRC Chatlog
Search
18:14:11
attila_lendvai
emaczen``: pass it something like '(:pointer (:structure my-foo-that-has-been-cffi-defstruct-ed)
18:21:40
emaczen``
attila_lendvai: I'll try it in a second, I thought I was getting a byte array from C but I'm actually getting a CvMat* which has a single row, so I have to defcstruct CvMat* and get that single row byte array first...
19:08:27
emaczen``
dlowe: yep, unless someone else has already tied into C and wrote a wrapping API, then you have to
19:12:40
fourier
emaczen``: in difficult cases I typically write the short C/C++ program which does exactly what I expect from Lisp program to do towards the library I'm dealing with and literally translate all back to lisp
19:20:00
emaczen``
fourier: I'm dealing with images and I think I'm going to have a hard time determining if I'm even getting what I expect
19:21:22
paule32
i search for quantum computer programming by doing lisp - have anyone links, infos ?
21:58:46
drmeister
Let's say I compile a minimal version of Clasp that has a compiler compiled into it.
21:59:34
drmeister
Can I expect to be able to compile-file all of the Common Lisp source code (including CLOS) and then link and load that together.
22:00:09
dim
https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf --- you might already be familiar with it
22:00:25
drmeister
I realize this is not a well formed question and there are implementation dependent stuff here.
22:00:43
Bike
the trick is to make sure that anything the compiler uses is properly defind in the compiler context
22:02:12
Shinmera
fasls that only contain compile-time side-effects, such that you can load this minimal part to compile-file the rest without having to do a full load.
22:02:49
Bike
(eval-when (:load-toplevel) ...this goes in the fasl...) (eval-when (:execute) ...this is only executed when loading as source...) (eval-when (:compile-toplevel) ...in the cfasl...)
22:08:15
drmeister
The slow part of building clasp has been bclasp LOADing and JITting all of Cleavir and clasp's extensions to Cleavir, (~10 min) and then running that code to build all of cclasp (~50 min).
23:34:23
anticrisis
it's not evident from clhs: check-type that it can't be used for structs, or did i miss something?
0:08:17
antoszka
jmercouris: did you try compiling rust to object code/libraries and calling that the same way you'd call C (via cffi)?
0:08:41
antoszka
jmercouris: that's how I'd approach the problem, though I've honestly have zero experience with rust ;)
0:17:11
jmercouris
antoszka: I didn't try that, at any rate, I found out the project I want to use is too immature any way, so I'll just use C++ and I'll be fine :D
1:50:57
emaczen
I also can't figure anything out with #'cffi:foreign-array-to-lisp to try to see what's going on
1:58:19
Zhivago
And can you access the fields of what cvencodeimage provides a pointer to, and find expected values?
1:59:07
emaczen
that's my problem, when I evaluate that cffi:foreign-slot-value form, I just get another foreign pointer
3:48:21
emaczen
I can relate to the CCL cocoa-bridge and I have only just toyed with ABCL's java integration
3:48:45
beach
drmeister seems to come here to #lisp only when he has a general Common Lisp question to ask.
3:49:18
beach
emaczen: No I don't. But Clasp uses the Cleavir compiler framework for its main compiler. And I am working on Cleavir.
3:51:23
emaczen
jmercouris: I wish they had it integrated with OpenStep so I could use it elsewhere and not just on OSX
3:52:08
jmercouris
I guess you can make different bindings for different platforms that are abstracted somehow
3:53:52
emaczen
That's what I have now haha, but I need something fast. I keep freezing my mini becuase I use so much memory.
3:54:30
emaczen
I stopped starting SBCL with --dyanamic-space-size 4096 because I learned my lesson eventually... ha
3:55:38
emaczen
Right now, I want the bridge for capturing video. I'm working with the CFFI and I just don't know that much about C and there isn't much to inspect either...
4:01:48
jmercouris
Not as far as I know, though every so often someone makes a controversial blog post about why we should start using it
4:04:23
beach
I use Emacs right now. I am working on Second Climacs, which I hope will be much better than Emacs for Common Lisp development.
4:05:58
beach
I am working on an incremental parser for Common Lisp code. It will be able to do things that can not be done with Emacs or SLIME.
4:06:47
jmercouris
Like pausing on an error during compilation and allowing you to change the offending line and then continuing compiling?
4:07:24
beach
I am planning to compile at typing speed so that errors can be visible without hitting C-c C-c or equivalent.
4:08:59
beach
It can already indicate names of packages that don't exist, names of symbols that are not exported from a particular package, names of symbols that do not exist in a particular package.
4:10:47
beach
jmercouris: I am also planning things like the ability to hover the mouse over a variable and see the places where it is defined or assigned to.
4:11:11
jmercouris
Ah yes, that is a feature that I am sorely missing from other languages in lisp, it only works some small percentage of the time in emacs
4:12:10
jmercouris
beach: for example, you might be able to see that there's a divide by 0 situation based on some assignment, stuff like that, things you'd have to run the program to get an error for
4:13:02
beach
I am not planning anything like that. But, I am planning a tight integration with SICL, so that run-time errors can be indicated by highlighting the offending place in the source code.
4:13:25
jmercouris
beach: Do you expect that SICL will ever be as performant as other lisp implementations?
4:13:48
jmercouris
If not, what would you suggest to developers? Use SICL/Climacs for dev, and then deploy your apps with SBCL for example?
4:15:07
beach
I hope so. But, the goal is very different. I see Common Lisp as a safe language, so safety is my first goal. Other people work hard (using FFI) to turn Common Lisp into a clone of any old unsafe language out there. So there might be performance issues like that, that I am not willing to cater to in SICL.
4:15:30
beach
Otherwise, I am planning to use the latest research in compiler technology to make things as fast as I possibly can.
4:17:05
jmercouris
Are you saying that anytime FFI is used, there is some degree of uncertainty due to the inability to properly test a C program for all unexpected behavior?
4:17:27
jmercouris
That is, because of the nature of the lisp interpreter, you can recover from any error, but the moment you introduce FFI, this net is lost?
4:19:02
beach
First of all, many implementations, including SBCL, can be unsafe as it is. If you declare (safety 0), or just declare something to be dynamic extent that really isn't , then SBCL is unsafe. Also, any library installed with (say) Quicklisp can alter the compiler and install a virus.
4:20:01
jmercouris
Are you planning on usage in embedded systems or something? Why is safety so important?
4:20:03
beach
But yes, most C compilers rely on undefined behavior in the C standard in order to favor fast but unsafe code. So using FFI makes Common Lisp just as unsafe as the C compiler that is used that way.
4:21:45
emaczen
If someone can install a virus on your computer because you are using unsafe code, that sounds like a pretty big intrusion if you ask me!
4:21:58
beach
jmercouris: I think computing is in a rut. We are using operating systems and programming languages that are by nature unsafe, which dire consequences. Then we try to patch things up with stuff like ASLR, making life harder for the developers. I would like to try something else.
4:22:10
jmercouris
emaczen: There are many many vectors, quicklisp is probably one of the least likely
4:22:47
vtomole
Speaking about unsafe, today i learned that garbage collectors can have memory leaks.
4:23:17
jmercouris
beach: Yeah, I hear you, ASLR blows my mind that it even works, let alone that it doesn't have massive consequences on perofrmance
4:23:31
beach
vtomole: Not typically. But code that relies on GC can, if you don't make big data structures inaccessible.
4:23:53
jmercouris
I think one of the big issues here is legacy systems, and the inertia from that, nobody wants to pay for the retooling of all systems, despite all of the knowledge we've gained about best practices
4:24:13
jmercouris
beach: no definitely not, there are quite a few good strategies that work on probability models to defeat them
4:24:37
emaczen
beach: the computing world is pathetic, case in point: HTML, CSS, Javascript, server-language, database-language -- a typical dev environment, and it can be worse.
4:24:43
beach
jmercouris: I am a researcher, so I don't care about legacy. I don't care if I am the only person using Second Climacs, SICL, or whatever. I am satisfied showing that it can work.
4:25:55
jmercouris
It feels like javascript has become this terrible monstrosity, why would you ever run applications in the browser??? That is NOT the purpose of HTML or the web...
4:26:19
vtomole
What about forking emacs and rewriting small parts of it in cl, work inside out. Instead of starting afresh.
4:27:29
vtomole
Why guile and not cl though. It seems like they are doing it intentionally just to spite cl haha
4:29:06
emaczen
I'm working with my first CFFI project and I'm trying to get a byte array from a CvMat*
4:30:05
jmercouris
vtomole: oh, it's most definitely intentional, common lisp makes way more sense than some arbitrary gnu definition of lisp
4:32:03
beach
jmercouris: So, in summary, the plan is to work on Cleavir and SICL to create a safe Common Lisp system, to work on Second Climacs to get an order-of-magnitude improvement in development tools, ...
4:32:04
beach
to work on Clordane (http://metamodular.com/clordane.pdf) which will probably require SICL, to get an order-of-magnitude better debugger,, and to then work on LispOS (http://metamodular.com/clordane.pdf) using SICL as a basis.
4:32:14
vtomole
beach: But he's currently not working on emacs. So that shouldn't matter, right? So emacs devs also hate CL
4:35:05
vtomole
beah: I didnt know about this clordane paper. Looks like ive got some reading to do.
4:35:49
beach
vtomole: None of that stuff exists yet, but it will be easier to create when SICL and Second Climacs exist.
4:36:21
beach
vtomole: It should also be seen as a statement of how I think existing Common Lisp systems should evolve (i.e., to be able to support such a thing).
4:39:30
vtomole
beach: About Second Climacs, if the editor is compiling the expressions while you are entering them. Is there a way to make it also check for type errors?
4:40:41
beach
vtomole: Yes, that might be possible to a certain extent. As you probably know, whether a Common Lisp program is correctly typed is undecidable. But there is a subset of common situations that we can check.
4:41:53
beach
Well, it will run the first few passes of the Cleavir compiler, and Cleavir has a type inferencer.
4:44:31
pillton
You are better off using (eval-when (:compile-toplevel :load-toplevel :execute) (asdf:load-system "cffi")).
4:45:29
emaczen
but I actually don't need to since in my package.lisp file I have :cffi in the use-list
4:48:32
emaczen
is an example, where "cvNamedWindow is the name of the foreign function with return type int, and two function parameters
4:48:34
beach
jmercouris: Yes, that's the one. It is not as hard as most people think. SICL has first-class global environments which is the bases of it. McCLIM already exists for the graphics stuff.
4:48:57
paule32
https://z0ltan.wordpress.com/2016/09/16/interop-mini-series-calling-c-and-c-code-from-common-lisp-using-cffi-part-1/
4:55:35
beach
emaczen: You may be wasting your time. My experience is that paule32 asks a lot of basic questions, but then doesn't follow the advice that is being offered.
4:59:31
emaczen
beach: can you look at http://paste.lisp.org/display/358268 and let me know what you think *bytes* is and how I can get a common-lisp array?
5:02:15
jmercouris
beach: Maybe the messages are abit out of order here, what code are you talking about?
5:03:23
beach
jmercouris: I am just saying that if you have a Common Lisp system that compiles to native code, like most high-performance Common Lisp systems do, then turning that into something bootable is not very hard.
5:03:27
jmercouris
beach: speaking of following advice offered, I made 99% of the changes to my code base from your suggestion
5:03:36
emaczen
can anyone with CFFI experience tell me how to get a common-lisp array from *bytes* all I can get is different foreign pointers
5:04:18
jmercouris
beach: I still left some things global though, like the minibuffer access vars (for simplicity sake) and I didn't change my object accessors, they are verbose, but I think I prefer it that way
5:05:08
jmercouris
It's all kind of irrelevant though, I have to do some major rewrites soon, after the next minor version
5:05:27
beach
jmercouris: Contrary to common belief, most modern high-performance Common Lisp systems are not based on an interpreter, but on a compiler that generates native binary code. The common belief is based on the (wrong) idea that something interactive must be interpreted, and something compiled must generate a binary file.
5:07:00
jmercouris
beach: You know that is interesting, I bet this belief stems from other languages that are interpreted but don't offer a compiler
5:07:15
jmercouris
If I had to guess, I would say most interpreted langauges do NOT offer a compiler
5:07:25
paule32
emaczen: as example: the string: "Hello" has 5 chars - with a postleading 0 so you can define a string of chars like in C "char buffer[100];" and you have a "static" string buffer
5:08:06
beach
jmercouris: A language is a specification of what is acceptable. Whether things are compiled or interpreted is up to the implementation.
5:08:48
jmercouris
"whether there exists a compiler depends on who is deciding to do the implementation"
5:08:56
emaczen
paule32: I know, my question is about using the CFFI to convert from the foreign pointer to a common-lisp array
5:09:47
beach
jmercouris: Interpretation/compilation is a concept that is orthogonal to batch/interactive.
5:10:41
beach
jmercouris: The (wrong) belief is based on the fact that most languages that are typically implemented with a compiler (like C) are also batch languages, and most languages that are interactive (like Python) are implemented with an interpreter.
5:11:29
jmercouris
beach: I guess that is how I have always thought of it, thank you for clearing up that misconception in my head