freenode/#lisp - IRC Chatlog
Search
0:04:32
lerax
There is a portable way to use threads with Common Lisp? Currently I'm using the sb-thread: package from sbcl, but this is not a nice solution because is SBCL only.
0:06:48
lerax
This is the official docs https://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation right?
0:12:18
billitch
now i'm stuck rewriting stream classes because evented io is not supported by ansi cl streams
3:08:26
lerax
I have a asdf system on my quicklisp, but I have the same at ~/lisp-chat/lisp-chat.asd. There is a simple way to load it by the current path on sbcl repl instead of loading the global installed by quicklisp? (lisp-chat it's provided by the quicklisp dist)
3:11:21
pjb
Or, of course, you can just (push #P"~/lisp-chat/" asdf:*central-registry*) ; nothing hacky in it.
3:11:49
lerax
yes, I did that... but seems that in some way the quicklisp gives preference to the version from quicklisp (ql:quickload 'lisp-chat)
3:14:44
lerax
Just for curiosity, this function search for .asd files and register at system-index.txt?
3:20:38
Bike
asdf has a deep api for specifying how it searches for systems, but hardly anyone understands it so we just use central registry and a text file list and so forth
5:59:38
borei
with 4 cores and hope that there is no overheade (there will be some) i should get 10Gflops (double-float), it's getting more or less ok
6:06:07
borei
basically i'd like to say that r-lane (and c-lane) has the type (simple-array double-float (4))
6:07:03
|3b|
(though if you are running at safety 0, you probably should verify they actually contain that type first)
6:08:01
White_Flame
you could put the LET inside the LOOP, making the declarations valid & properly scoped, as that's where the variable is actaully used
6:08:02
|3b|
though they could easily be a literal or constant or something instead of allocating every time
6:09:00
White_Flame
a definite shift from C-style languages to Lisp is that you scope variables much tighter, instead of just declaring them all up at the top of the function
6:10:37
White_Flame
and yeah, LOOP itself migh tbe able to iterate the arrays for you, instead of dealing with indexes manually
6:11:31
|3b|
actually yeah, missed that they were just directly iterating a vector, was thinking FOR = rather than FOR ACROSS
6:15:43
|3b|
ACTION would just do the whole thing on a GPU though, even with the horribly crippled double precision on consumer nvidia cards, recent midrange stuff does 50-100gflops :)
6:21:38
|3b|
CL as specified doesn't have anything like that, but most implementations have some sort of lower-level APIs that would for example let you write asm or extend the compilers
6:24:38
|3b|
https://www.pvk.ca/Blog/2013/06/05/fresh-in-sbcl-1-dot-1-8-sse-intrinsics/ talks about some features in sbcl for example, still fairly low-level though
6:25:31
|3b|
(in the "write asm/extend the compiler" range, but with some of the supporting parts already done)
6:28:50
|3b|
there is also the option of using something like opencl on CPU... not sure if it would be any easier, but would at least be different problems :p
6:33:01
|3b|
also, at that scale of matrix multiplies, you might want to start looking at algorithms that take better advantage of memory access patterns
6:36:25
White_Flame
borei: there's some game engine stuff out there in Lisp which does on-the-fly shader interactive coding while the program runs
10:46:54
jmercouris
not looking for something as full blown as curses, but just like a way to make and print menus
10:47:06
jmercouris
of course I could roll my own rather easily, but just wondering if something already exists
10:47:28
jackdaniel
I've written cl-charms tutorial lately: http://turtleware.eu/posts/cl-charms-crash-course.html
10:48:16
jackdaniel
https://asciinema.org/a/KNDnnycLc2uHMsmi7YvFMUpau ← here is tutorial final effect
10:49:19
jmercouris
I just fully appreciate the fact that it is possible for clim to be loaded into a terminal, blows my mind
10:51:18
jackdaniel
loke: depends on use - displaying images or non-rectangular shapes won't be pretty for sure
10:53:48
jmercouris
jackdaniel: not sure if you are interested, but I found a small grammatical issue in your article
10:55:35
beach
jmercouris: The reason McCLIM uses CLX is that, when I wanted a GUI library for Gsharp (score editor), I wanted to have as little foreign code as possible, and CLX is mostly written in Common Lisp. That is also the reason why McCLIM exists at all. I was not willing to use any GUI library written in some other language.
10:56:41
beach
jmercouris: So, I would be very unhappy, if the CLX backend was dropped in favor of a single SDL-based solution, since SDL is not Common Lisp code.
11:00:44
|3b|
ACTION suspects a lot of the work involved in a SDL backend could be shared with a glop backend... not sure a glop backend would be all that good of an idea either though :)
11:03:00
|3b|
arguable whether it is as "pure cl" than CLX, since it does FFI on the user side rather than hidden behind implementation-specific networking APIs
11:03:05
beach
That actually looks appealing if what it states is true, i.e., that system functions are used directly.
11:04:25
|3b|
ACTION doesn't have any OSX though, so all my knowledge of that is second hand at best
11:04:35
beach
Well, if system functions are used directly, they could be hidden behind an abstraction layer that would allow someone to replace the FFI layer by some native implementation of the system functions.
11:09:04
beach
ACTION should be quiet since we are entering a territory of which he knows very little.
11:09:05
|3b|
i'm guessing that none of the options (glop or either of the sdl bindings) was particularly designed with that in mind though
11:28:31
jmercouris
beach: Ultimately CLX must have some non-lisp code if only to interface with the OS
11:38:20
|3b|
X programs tend to mix with 'native' things on windows even worse than GTK or whatever :p
11:39:18
|3b|
also hard to get good GL performance out of things using CLX (admittedly not something everyone cares about)