libera/#commonlisp - IRC Chatlog
Search
15:10:28
Shinmera
luis: Well it makes it impossible to use on linux if you have a directory that's not lowercase
15:22:02
p_l
Also, I wonder how much code would break if I made a lisp implementation faithfully represent full NT pathnames...
15:46:49
didi
Using SLIME and a fresh SBLC instance, why does C-c C-l work for loading a file with `require' forms but C-c C-k complain about non designated packages?
15:58:34
_death
the require is evaluated during load time, but not during compile-time (you could use eval-when to make it work)
17:47:35
didi
So I read <https://mstmetent.blogspot.com/2020/02/block-compilation-fresh-in-sbcl-202.html> and wondered: Is CMUCL still around?
18:12:11
phoe
https://gitlab.common-lisp.net/cmucl/cmucl/blob/master/src/general-info/release-21e.md
19:50:01
Cymew
It used to be my main lisp, and I liked it quite a bit. Kind of fun to hear it mentioned again.
19:52:07
jackdaniel
nerverless many libraries work without any changes on mezzano, unless they depend on ffi
19:52:42
jackdaniel
(as an example of benefits from using "pure" common lisp -- I personaly have no problem with well written bindings)
19:53:05
dlowe
I can imagine if a mezzano backend were written for iolib, libfixposix wouldn't be an issue :p
20:05:16
p_l
we could also encourage implementations to provide better own abstractions to be used by things like IOlib
20:23:46
fe[nl]ix
Shinmera: the C library is pretty much necessary, unless you can convince implementors to include POSIX FFI bindings
20:25:48
Shinmera
I am suggesting not using a library that requires C stuff for something that's just a new pathname implementation.
20:26:43
fe[nl]ix
including some function-like accessors which are allowed by POSIX to be defined as C macros
20:28:32
p_l
as all interface libraries are explicitly language-agnostic (and even if they use C internally, it's fully hidden from you, including lack of linkage to C runtime)
20:36:39
jackdaniel
given that these operating systems all have libc which gives you necessary functionality, and that it is possible o have an uniform interface to it, I'd say that it is saner to have such interface
20:37:08
p_l
jackdaniel: the problem is that the libc might not be first class API on some platforms
20:38:05
pjb
p_l: even amongst C programmers, there's a movement to avoid libc, and use linux syscalls directly!
20:38:34
pjb
p_l: it's more fun, since it's not a unix system, under, but a Mach OS. So you don't syscall, you send messages to the microkernel :-)
20:39:59
Odin-
"Going the easy way around isn't pure enough, so let's do tons of difficult work to try and keep up with outside systems that are often a very swiftly moving target!"
20:40:19
pjb
So, basically CL implementations would have to support 3 kernels, Mach, MS-Windows-NT, and Linux.
20:40:39
fe[nl]ix
BSD developers consider libc as the ABI so they have in the past removed syscalls and reimplementing libc functions
20:40:55
p_l
though I'm pretty sure POSIX specifies a libc that contains certain interfaces (mostly compatible with ANSI/ISO), another set of "syscalls" which might be actually implemented by another library (passing to message passing interfaces)
20:41:34
p_l
fe[nl]ix: from my understanding, POSIX spec doesn't require that various low-level interfaces are "syscalls", it can be a library
20:42:01
p_l
and I'm pretty sure someone even made one for linux (or maybe some other OS) in the form of "libsyscall" or something like that
20:42:56
p_l
anyway, going through libc on Windows means you are relegated to second class citizen, and in fact might actually mean a more moving target
20:42:57
jackdaniel
in other words, supporting posix is a matter of having ffi wrapper, what's precisely what IOlib does ;) I'd file a bug on Windows bugtracker and call it a day, i.e "[bug][critical] Windows is not a real POSIX" ;)
20:43:30
pjb
On the other hand, this is what makes the success of unix (POSIX) systems, the command line user interface. Other systems were way more inconvenient to use. You couldn't compile and run programs like that, willy-nilly…
20:44:09
pjb
It was more like iOS, where you needed sysadmins to install the commands for you, with authorisations, etc (not code signatures at the time, but it was as inconvenient).
20:44:16
p_l
jackdaniel: if you actually managed to get deep enough to put a bug on internal bugtracker, and someone with a grey enough beard read it, you might end up with a long rant on why POSIX interfaces sucks :P
20:44:30
Odin-
pjb, p_l: Dunno, at least some of the relevant standards include C header snippets as the definitive material.
20:44:56
jackdaniel
p_l: that's not my point. either way, since we talk about outstanding operating systems, here is windows93: http://www.windows93.net/ and I'll stop offtopic on my part
20:47:13
pjb
Odin-: we can have lisp implementations targetting POSIX systems indeed. ecl is more like that than other implementations. We could have CL implementation to produce DLLs and shared libraries usable from C.
20:52:36
fe[nl]ix
that said, if SBCL used LLVM, you could have wrappers for C macros that get inlined in Lisp code
20:52:37
copec
I like the unix processor model with C. I think it is the lowest common denominator to have totally separate software systems share
20:54:07
copec
It would be nice if there were some type of standard low level data structures that could work between different languages without conversion
20:55:10
p_l
well, WinNT is much more C-like, but a) the interfaces are designed mostly so that you don't need C b) for complex interfaces there's COM
20:56:37
fe[nl]ix
I look forward for a libc whose API is defined in some IDL language, which is then translated to various languages (including C headers)
20:57:31
p_l
fe[nl]ix: WinNT is... getting close there? I mean, there's a bunch of stuff which will remain defined through C headers, but all the advanced complex APIs are in IDL (including DirectX, WPF, etc.)
20:57:32
Odin-
jackdaniel: I'd be fine with a subset. There's an interpreter for a slightly-off subset that can run on an ATmega328, which is an interesting toy.
21:00:18
p_l
across architectures, yes. But even then not much, afaik (due to rather specific typing approach in MS source code)
21:00:52
jackdaniel
fe[nl]ix: scymtym wrote C preprocessor https://github.com/scymtym/language.c on top a grammer I have written in esrap
21:00:57
fe[nl]ix
and put the burden of doing that on whoever wanted to port Go to their OS/arch combo
21:03:04
Odin-
fe[nl]ix: Yeah, but Go seems to have a manpower problem on the opposite end of the scale.
21:05:20
fe[nl]ix
libfixposix can be an annoying requirement but it works very well and it's easy to maintain
21:06:50
p_l
Go, most importantly, started with an already ported custom runtime before they wrote first line of compiler
21:09:20
p_l
6c wasn't, but I don't remember if they published a version of it, but then, 6c differences from 8c were... minor
21:14:28
p_l
fe[nl]ix: anyway, they way I see it, perhaps iolib should promote better interfaces to be packaged as part of the implementation, so that libfixposix is needed less (or might be, in fact, embedded in the implementation)
21:16:42
dlowe
Now using those C parts to expose a full posix interface sounds like a worthy project.
21:18:49
dlowe
that's where it would go, sure. But I mean taking the bits from libfixposix and integrating them so that libfixposix isn't needed.
21:21:59
dlowe
If the implementation were in the C runtime instead, it wouldn't need to be high-level or slow