freenode/#lisp - IRC Chatlog
Search
16:35:19
Josh_2
http://paste.lisp.org/display/358222#1 Now I'm more than happy to talk about everything else that sucks.
16:42:06
_death
now you can rename your RETURN-8008 restart to USE-VALUE, have it take one parameter and set I to it.. then you can (use-value 8008 condition) in your HANDLER-BIND
16:43:09
_death
and then you should have another loop, calling the predicate with the new I until a valid value is used
17:02:21
emaczen`
I'm trying to inspect a foreign array by using #'cffi:foreign-array-to-lisp but I have no idea what to do with the array-type argument
17:09:10
_death
Josh_2: cool.. usually you define a function that invokes the restart, for example (defun use-value (new-value &optional condition) (let ((restart (find-restart 'use-value condition))) (when restart (invoke-restart restart new-value)))) .. in the case of use-value, CL already defines such a function
17:10:17
emaczen`
has anyone used CFFI with opencv before? It is a bit difficult because the C API is deprecated in favor of the C++ API
17:10:50
_death
emaczen: I wrote some opencv bindings years ago, when the C API was not yet deprecated..
17:12:42
emaczen`
_death: I don't know who would remember particulars about cvEncodeImage... Only in the C API the documenatation says that it returns a single-row matrix that contains the encoded image as an array of bytes
17:13:58
Josh_2
hmm well I can't actually define a function called (use-value). I'm going out now so I'll fiddle when I get back. Thanks for all the help everyone.
17:14:15
emaczen`
In the newer APIs it looks like you pass a vector<uchar> and it gets filled with your bytes...
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