freenode/lisp - IRC Chatlog
Search
7:02:14
aeth
npfaro: COERCE also works, but you generally want to use MAKE-ARRAY because the :initial-contents part can be optimized when it's a quoted list like that...
7:02:28
aeth
i.e. (coerce #(1 2 3 4) '(simple-array (unsigned-byte 8) (*))) where * is the size wildcard so you don't have to specify it (you could say (4) instead of (*))
7:05:37
aeth
In other words, use MAKE-ARRAY with a literal list as the initial-contents if you're making the array in the first place. Otherwise, if you already have a sequence and just need to convert it to another, COERCE.
10:56:20
beach
I think Feldman0 wants to implement my generic-function dispatch technique for ECL, maybe.
10:59:51
jackdaniel
currently ecl has gf dispatch mechanism operates on caches (see the file src/c/clos/gfun.d), however before the last release I've implemented class stamps
11:03:10
jackdaniel
there are internal helper functions si::instance-obsolete-p and si::instance-sig-set to work with instances (used in clos/std-slot-value.lsp) defined in src/c/clos/instance.d
11:04:01
jackdaniel
there are a few problems: a single gf dispatch mechanism does not require additional compilation at runtime, while fast gf dispatch requires you to compile the dispatch function after gathering some information
11:04:30
Feldman0
Do you think that I'll have to implement it in C or in Lisp, I'm not quite sure in what what is done in ECL
11:04:58
jackdaniel
I'm sure that it could be implemented in lisp and compiled with the compiler to c
11:05:46
Feldman0
My main struggle with reading the code base is, I'm not sure why something are in C or Lisp, is there a rule of thumb that is used or?
11:05:47
jackdaniel
so, regarding the problem -- compilation on ecl is slow, so either gf should be compiled in a separate thread, or manually triggered by i.e #'compile
11:06:31
jackdaniel
the common language runtime is implemented in c; while the rest is implemented in common lisp
11:07:02
jackdaniel
basically some low level operators needed to boostrap the language must be written in (or transpiled to) C (unless you decide to boostrap from another common lisp implementation)
11:07:45
jackdaniel
ecl also features a bytecodes compiler/interpreter (alongside native code compiler), and bytecmp is written in C
11:08:16
Feldman0
Ah right so it's like the clos-boot approach in SBCL, so my solution could be like the more fully featured clos written in CL
11:08:36
jackdaniel
you may think of the C part of the codebase as of a VM on top of which you could implement other languages (i.e common lisp)
11:09:40
jackdaniel
sure, you could think of it like that; notice that current gf dispatch machinery is written in C
11:10:43
jackdaniel
afaik sbcl and ecl clos implementations are both based on the pcl implementation
11:11:42
jackdaniel
if you have some detailed questions about ecl internals, you may join #ecl channel to not clutter the general chat with it
11:13:13
Feldman0
I think this is probably fine for now; I just need to write up a draft project proposal and submit it to potential supervisior. It's a bit early for that even, but there's really only one good supervisor for this project so I'm trying to get him early.
12:05:13
VincentVega
Trying to pick a testing framework. Currently looking at prove. The lisp cookbook says "warning: Prove has a couple limitations and will soon be obsolete. We advise to start with another test framework." What limitations? Are there other frameworks that are better in some way?
12:05:17
VincentVega
I guess what I would want from a testing framework is that it just doesn't get in the way, so to speak. I want to have testing code at the top-level (right next the code that I need to test, I don't want to create a seperate file), but I don't want it to run during the compilation, but only be tracked by the framework, so that I can run it all
12:05:17
VincentVega
later if I want to. Eval'ing a form should run it though. Do any of the frameworks support this?
12:18:52
jackdaniel
but if you want to be "the real common lisp programmer", you should write your own testing framework - it is a long lasting tradition among devs ,-)
15:02:13
jackdaniel
Bike: equal could do that too (under the hood, after realizing that both are strings)
15:02:54
jmercouris
but I think you would be writing something really complex if equal had to realize you were slicing
15:10:20
beach
And yes, string= is more specific, so it falls under the rule that one should always use the more specific construct that will have the desired effect.
15:11:21
pfdietz
One could imagine a sufficiently smart compiler that would transform (equal (subseq s ...) (subseq s2 ...)) into a call to string=, but I don't think any existing compilers do that.
15:11:32
beach
But Common Lisp is not about minimalism. It's about giving the programmer a good toolbox.
15:11:39
jmercouris
pfdietz: that's what I was hinting at with my comment that jackdaniel did not understand
15:35:17
jackdaniel
jmercouris: I've merely corrected you from implying I've said something that I did not. "sufficiently smart compilers" was a fad years before I've started working with common lisp
16:41:03
jmercouris
jackdaniel: I merely corrected you from implying that I implied that you said something which you didn’t
17:13:00
dbotton
Is there documentation / some sort of tutorial on the best way today to handle foreign C code. Seems there are a few paths when last looked.
17:13:58
jackdaniel
cffi is a usual goto answer (it also superseded uffi and provides compatibility layer with it)
17:14:44
jackdaniel
there is also cffi-groveller to generate bindings automatically (cl-autowrap seems to have a similar purpose) - I've never used grovellers though
17:15:06
jackdaniel
cffi has a documentation; when unsure I usually look at tests in the source code
17:16:54
jackdaniel
on ecl there is a special flag to make things faster (by writing inlined calls) it is disabled by default because there is no good translation between pointer types between ecl and cffi (something possible to fix with extra effort)
17:17:29
jackdaniel
basically it boils down to the fact, that modern C compilers won't accept a declaration void*(*)() to a function int*(*)()
17:18:22
dbotton
Would be good to use but don't want for this project anything that is implementation specific
17:19:16
jackdaniel
#+ecl (setf cffi::*that-flag-I-don-t-rememmber-name-of* :static) or something in this spirit
17:20:26
jackdaniel
ecl can do it three ways: dynamic ffi, dlopen ffi and static ffi - cffi implements all three