freenode/#lisp - IRC Chatlog
Search
11:53:10
ebrasca
jdz: yea I have find it in my log. "<|3b|> ebrasca: no idea, haven't tried to run it since i stopped working on it :/"
11:58:24
pjb
sindan: for example, you can see the doc of *my* features for *this* project at: https://framagit.org/patchwork/patchwork/blob/master/notes.txt#L326
11:59:41
|3b|
cl-vulkan isn't "abandoned", but it also isn't currently being worked on, so if you want to use it, you will probably need to add to it
12:01:01
|3b|
ACTION intends to work on it more, it just isn't likely to make it to the top of my priority stack any time soon
12:01:25
pjb
You can make a CL implementation run directly on the Linux kernel. See an example with emacs: https://www.informatimago.com/linux/emacs-on-user-mode-linux.html for a CL implementation with (or new emacs with modules) FFI it would be easier, since we could do the mount directly.
12:01:41
elderK
It's like my tinkering on binary-typesy stuff has taken a backseat - past couple weeks I've been spending a ton of time learning about lisp implementation.
12:01:43
|3b|
(2 other unrelated projects ahead of it, then i probably want to work on spirv compiler some more before vulkan itself, and also get a better idea of how i want to use it)
12:02:30
|3b|
spirv is probably less important now than when i last worked on it though, since i think there are glsl extensions available that would be good enough for getting the rest working
12:03:03
|3b|
knowing how i (or anyone else for that matter) would want to use it is important though, hard to design good abstractions without knowing use cases
12:10:59
|3b|
trying to assemble a thermal camera (mostly just having trouble getting a working configuration of a 64bit arm board with all the drivers i need), and writing some simple utilities for android
12:11:23
|3b|
https://github.com/3b/cl-vulkan-samples/blob/master/initswapchain.lisp#L4 makes a vkSurfaceKHR
12:13:03
|3b|
https://github.com/3b/cl-vulkan/blob/master/vk/wrappers.lisp#L451 is the definition of the function/macro it uses, so you will need to write a linux version of that for whichever OS API you use
12:19:05
|3b|
ok, looks like glfw wants you to call its functions to create the surface, so you will have to look at bodge-glfw to figure that out
12:22:23
ebrasca
|3b|: Some years ago you helped me with cl-opengl. I like to be more like you and write good code and look like I know everiting.
12:23:26
|3b|
%glfw:create-window-surface + %vk:destroy-surface-khr should replace the vk:with-xlib-surface
12:24:30
|3b|
i'm not sure you are calling %glfw:create-window-surface correctly though, the last argument is a foreign pointer to the surface
12:24:59
|3b|
you will need to ask borodust how to call that, i'm not familiar with the wrapper generator it uses
12:28:50
jackdaniel
|3b|: new lesson learned! you look like you know everything , don't spoil it with "I'm not familiar…" talk ;-)
12:31:54
|3b|
ebrasca: #++ is my lazy way of commenting out forms. slightly shorter and easier to type than #+()
12:36:01
|3b|
and :+ on *features* seems sufficiently unusual that i'm willing to just let someone send me a patch to fix it if they come up with a good reason they need it
12:37:32
|3b|
(or remove them for that matter, though ideally most code would have pure CL fallbacks for non-bugfix cases)
12:37:41
jackdaniel
I'm taking my time to correct all #+nil 's to #+(or) when I encounter them in code I work with (for sake of correctness by default)
12:38:34
|3b|
i usually try to just remove them completely once i'm done actively working on something
12:39:22
|3b|
most of them are debugging and/or multiple attempts at something i haven't figured out yet
12:50:52
pjb
I prefer the more direct #+(and) included or #-(and) skipped. #+(or) is kind of a triple negative…
12:51:38
pfdietz
A tool that would use Eclector to produce a kind of parse tree that can be converted back to something that is character-for-character equivalent to the original file. Then, do rewrites on that representation to get rid of #+nil forms (the example above).
12:52:06
pfdietz
It would be easier if lisp files were directly equivalent to the forms after reading, but that loses comments and other reader-handled stuff.
12:53:19
|3b|
pjb: ideally it wouldn't show up much in 'released' code, unfortunately not much of my code makes it to that point :(
12:56:31
|3b|
ok, i'd probably apply that if sent, though i'd probably keep using #++ if i worked on it some more :)
12:56:38
scymtym
pfdietz: i made a very quick and dirty demo for something like this a few weeks ago (in this case replacing IF without alternative leg with WHEN): https://techfak.de/~jmoringe/refactor.png
12:59:52
pfdietz
Clone detectors? Lots of work on that in general. Dont know about for Common Lisp specifically.
13:06:37
ebrasca
|3b|: Have in mind I have done bad fat32 implementation and part of ext for mezzano.
13:18:03
pjb
I guess something like my electric-+-suppress https://pastebin.com/vYhbL47s could be achieved with abbrev too.
14:00:04
beach
Why do you care so much about specifying that? Just make sure that it does return an integer or a list of integers.
14:05:17
beach
hectorhonn: Some authors claim that statically typed languages force the programmer to supply information early on in a project; information that is then very likely to change later.
14:06:43
beach
More often than not, the information is about representation of objects, which is an implementation detail that can change later. If you want to supply type information, you should do it in terms of the abstract types of your protocol.
14:10:32
hectorhonn
beach: true. on the other hand, changing the return type of a function would require a change at all call sites, so imho its better to have that kind of information supplied early during design and set in stone. then write an wrapper as an abstraction for the function if things do change
14:36:45
scymtym
pfdietz: thank you for the idea. prototyping this revealed a few shortcomings in eclector: https://techfak.de/~jmoringe/bad-reader-conditionals.png
14:40:20
scymtym
the shortcomings were related to the fact that this reader client does not use host symbols or packages
16:20:41
jcowan
beach: that definition doesn't seem to be particularly CL-centric; I think it could apply to almost any language with (dynamic) types.
17:09:43
pjb
MoziM: however, Univac were nice computers. It would be fun to implement (or find) an emulator, and run this lisp.
17:10:49
pjb
Also, the compiler is written in lisp, so you could easily write a driver to run it in CL…
17:19:48
MoziM
is this an accurate way to summarize the "LISP" way of thinking? still trying to get my head around it https://i.imgur.com/m2BmyGa.png
18:16:41
drmeister
Hey folks - bordeaux-threads *default-special-bindings* is confusing me - in what thread are the forms supposed to be evaluated?
18:17:08
drmeister
It says in the documentation for *default-special-bindings*: "Forms are evaluated in the new thread or in the calling thread? Standard contents of this list: print/reader control, etc. Can borrow the Franz equivalent?"
18:19:53
drmeister
It makes more sense to me to evaluate the forms in the parent thread because then bindings like ( ('*print-pretty* . *print-pretty*)) will get the value of the *print-pretty* binding of the parent. If you evaluate *print-pretty* in the child thread - then you will get the global value.
18:59:14
beach
MoziM: No, that looks totally wrong. And we don't write it "LISP" anymore. We write it "Lisp".
19:00:23
beach
MoziM: Common Lisp allows both assignments and sequences of forms (expressions to evaluate).
19:01:43
beach
MoziM: And the "value of a symbol" thing is wrong. Common Lisp uses eager evaluation.
19:03:15
beach
MoziM: But if you do (SETQ X (+ A B)), then the addition is computed once and the result is stored as the value of X.
19:11:27
jcowan
interestingly, Univac Lisp is a Lisp-1; that seems to be a common change for people reinventing Lisp from scratch
19:14:17
pjb
So, for who searched for a non-emacs editor, here is one, in univac lisp: http://www.frobenius.com/source.htm
19:14:30
pjb
So, for who searched for a non-emacs editor, here is one, in univac lisp: http://www.frobenius.com/editor.htm
19:20:59
jcowan
interestingly, it has a non-closed function constructor spelled LAMBDA, and an otherwise identical closure constructor spelled LAMDA (which is how it is spelled in Modern Greek)
19:34:54
phoe
What is the function that does the inverse of REMOVE? I want to keep all the elements instead of removing them.
19:35:27
phoe
I can do it via (remove-if-not (curry #'eql thing) list) but I wonder if there's a shorter way.
20:10:35
phoe
I have a class object. I want to remove it from the Lisp system altogether. No live instances of that class remain. Is it enough to call REMOVE-DIRECT-SUBCLASS on all of the direct superclasses of that class and remove all methods that specialize on that class?
20:14:16
LdBeth
phoe: for you question, I think the class is kept somewhere that FIND-CLASS can get it by it's name
20:14:58
phoe
I want to ensure that the class object itself is inaccessible. This means removing everything that links to it from CLOS.
20:40:04
LdBeth
interesting, so seems (setf find-class) to nil is sufficient, all the other things are mop specific, https://groups.google.com/forum/#!topic/comp.lang.lisp/hzQ7RRTK4Lg
20:46:38
flip214
phoe: alternatively just replace your class with one that has no slots - then all the accessors should become invalid at once
20:50:11
phoe
I don't think so. X is then a direct subclass of EMPTY, so there still is a strong reference.
20:51:14
flip214
why should it become a subclass? the (CHANGE-CLASS (FIND-CLASS 'X) 'empty) replaces the _class_ object with (an incompatible) object
20:55:02
phoe
(c2mop:class-direct-subclasses (find-class 'standard-object)) still has a reference to it.
20:55:57
phoe
try it out yourself: (defclass empty () ()) (defclass foo () ()) (change-class (find-class 'foo) 'empty) (c2mop:class-direct-subclasses (find-class 'standard-object))
21:02:53
flip214
my guess is the best we can do is some hack with CHANGE-CLASS - replace the class object with an empty one
21:05:05
phoe
Removing STANDARD-OBJECT as its direct superclass and SETF FIND-CLASS NIL are not enough.
21:08:28
flip214
well, with that SETF you should make it inaccessible. and if there are no more references, it should (might?) be gone at some later time