freenode/#lisp - IRC Chatlog
Search
8:38:39
verisimilitude
Put simply, there are plenty of Common Lisp programs or libraries that either only work on one implementation, usually SBCL, or use the CFFI and offload all of the work onto something written in a different language, both of which I believe should be avoided.
8:41:42
verisimilitude
I was writing a program with an interactive terminal interface and did take a look at the available libraries.
8:42:44
verisimilitude
You have Common Lisp, this nice language, and yet these libraries risk memory leaks for what amounts to printing text.
8:43:25
hectorhonn
verisimilitude: that's a pragmatic decision i guess, ncurses library already exists and can interface easily with the os
8:43:25
verisimilitude
Not only that, but it's so much more bothersome to lead a Common Lisp library that wants an entire C library with it.
8:46:52
verisimilitude
As a tangent, Github is awful, hectorhonn, and you should avoid it wherever possible.
8:47:17
verisimilitude
I'd much rather a company need to bother my VPS provider than just email Github and demand something be taken down, which happens.
8:48:55
hectorhonn
verisimilitude: i see. that's good to hear. stuff taken down probably violates copyright
8:49:51
verisimilitude
https://torrentfreak.com/fuckr-developer-right-or-not-backs-down-in-fear-of-grindr-copyright-lawsuit-181014
8:50:20
verisimilitude
It would be much harder to abuse copyright for taking down things you don't like, if so many people weren't all in a centralized location.
10:43:29
pjb
verisimilitude: lists are important for abstraction, only if you use them to represent everything. If you were ready to use CLOS classes for everything (like in Smaltalk, say), then classes would become an abstraction device. Until that, they're just a representation device. It can be used to represent external objects, and thus abstract _them_, but not as an internal abstraction, since you could also have structures, vectors,
10:45:53
pjb
verisimilitude: also, there is a way to distinguish the representation from the abstraction. This week, I had to debug a bug in C (it would be the same in lisp) where I had a typedef struct { void* data; int size } buffer; with a function buffer_new(int size) and a function buffer_free. The call to free failed on invalid pointer even thought it was allocated in buffer_new.
10:46:14
pjb
verisimilitude: the reason why that some client code used &buffer->data and incremented the pointer.
10:47:29
pjb
verisimilitude: the solution was to stop using this representation (the structure) and replace it with an abstraction: typedef struct buffer; void* buffer_data(buffer* b); int buffer_size(buffer* b); Then the client code could not increment the buffer data pointer. That representation was abtracted away, code become safe and correct.
10:53:48
Inline
ebrasca: now if clim was not loaded and hence not pushed onto the *features* list then it will skip that form
10:57:18
pjb
(setf *features* (delete :+ *features*)) (read-from-string "(a #++ b c)") #| --> (a c) ; 11 |# (pushnew :+ *features*) (quote (a #++ b c)) #| --> (a b c) |#
10:58:40
pjb
To give the feature + (assuming standard readtable and packages, ie. cl:+) to #+ you would write #+cl:+
11:00:44
pjb
#+#.(cl:if (cl:= (cl-user::version) 2) '(:and) '(:or)) (new-function) calls new-function only if (version) returns 2…
11:02:17
pjb
More simply: #+sbcl x #+ccl y #-(or sbcl ccl) (error "not implemented for ~S" (lisp-implementation-type))
11:10:18
pjb
(find "LITTLE" *features* :test (lambda (x y) (search x (string y)))) #| --> :little-endian-target |# in ccl
11:11:29
pjb
in sbcl and ecl we have :LITTLE-ENDIAN, and in abcl and clisp nothing. (those works on VM that abstract away the endianness. eg. clisp always writes binary files in little endian, even on big-endian architectures, so clisp binary files can be compatible between clisp on different platforms)
11:19:19
jackdaniel
sindan: you can't, because they are not standarized and they are pushed from different places
11:19:35
jackdaniel
i.e you may find a description in the implementation manual chapter about weak references
11:20:12
jackdaniel
check out https://github.com/trivial-features/trivial-features/blob/master/SPEC.md
11:21:53
sindan
I see. So, trivial-features and starting from implementation docs if they exist. I'm guessing there will be acceptable documentation for sbcl.
11:25:58
jackdaniel
regarding mezzano, I think that such contribution would be accepted in the library, but I don't really know; ask luis
11:26:40
jackdaniel
and as of gnu hurd: is there lisp which actually works on gnu hurd as of today? and if yes, I suspect gnu hurd being a posix system, so this is explained that "sysname" information from uname is used
11:29:53
jackdaniel
if you had read the pararaph as I have suggested, you would know, that on POSIX systems the "sysname" information from uname(3) should be used
11:38:15
jackdaniel
everyone is entitled to think what they desire to think, fact remains that this works exactly as specified, sysname value is "Linux" on systems powered by linux kernel
11:43:02
jackdaniel
ACTION resigns from trying to explain why it is irrelevant given how this *features* entry is specified in the document (with a disappointment)
11:45:19
jdz
ebrasca: Not sure what you are trying to accomplish here, but this is very off-topic, so I also resign from further discussion.
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.