freenode/#lisp - IRC Chatlog
Search
3:46:13
saturn2
you need to close it first https://common-lisp.net/project/cffi/manual/cffi-manual.html#close_002dforeign_002dlibrary
4:18:41
beach
I wonder whether some of the people who insist on using foreign code are converted Pythonista who therefore think that calling C code is the only way to get good performance from their Common Lisp code.
4:27:14
beach
Oh, wait, it's the prisoner's dilemma all over again. If everyone who needs a library that exists only as foreign code instead wrote an equivalent in Common Lisp, then everybody would benefit from everybody's code. But using foreign code is faster for each individual, so, like the prisoners, each individual chooses what benefits him/her. The result is that everybody suffers.
4:29:11
remexre
beach: OpenGL requires interfacing with the hardware directly, in ways not documented by most vendors
4:30:27
beach
I have no answer for you. Personally, I would then do something other than accelerated 3d graphics.
4:31:22
beach
remexre: My observation was not about you. It was about all the suffering I see here in #lisp by people using foreign code.
4:37:03
aeth
beach, remexre: Technically speaking, cl-opengl is mandatory. The rest of the stack (e.g. glfw or sdl), however, is not, but it would require a lot of work to write directly to WinAPI, xlib, etc., for all of the windowing code related to a 3D application.
4:37:26
aeth
(Okay, you could use something like cl-vulkan instead of cl-opengl, but you do need to use a graphics API because it's at the driver level... i.e. it's what the hardware speaks)
4:38:07
remexre
aeth: I mean, I've heard stories whispered in huddled corners of writing directly to the memory-mapped region of the GPU
4:38:51
remexre
so in theory (stretching the bounds of plausibility), you could reimplement all the libGL.so's in CL
4:42:34
aeth
And technically speaking, an implementation could build in OpenGL or Vulkan functionality as well as SDL-like/GLFW-like functionality
4:43:29
remexre
fair, though I feel like there's a difference between implementing GLFW bindings in the implementation and reimplementing a GLFW-like on top of "plain syscalls"
4:44:16
remexre
Sure, but mmap() is a C function in libc, and afaik there's not a nice library for doing "raw syscalls," so in practice you're gonna be calling the C one
4:45:10
beach
remexre: In fact, I started such a project, and it would be great to have an implementation-independent way of making Unix system calls.
4:45:56
remexre
saturn2: as in existing implementations expose something like https://golang.org/pkg/syscall/#Syscall6 ?
4:45:57
saturn2
i've used sbcl's sb-unix::int-syscall and just looked up the syscall number manually
4:46:29
aeth
remexre: In SBCL, you should be able to do raw syscalls without using C because Linux has a stable ABI and SBCL allows you to do "inline asm" (not really "inline" because that's not how Lisp works, but the phrase is from other high level languages).
4:46:56
aeth
For Windows and macOS, the syscalls are an internal interface and you're expected to use the C libraries.
4:47:36
remexre
yeah, it shocked me when a normal windows update actually changed the syscall numbers, breaking an asm program I was writing
4:48:20
aeth
remexre: probably not a normal one... Windows 10 is supposed to be the "last" Windows and they have fairly major updates every 6 months or so, not unlike a distro like Ubuntu or Fedora
4:54:44
remexre
I dunno, if I were MS, I'd change the syscall numbers every update to force people not to depend on them :P
4:55:36
aeth
meanwhile, Linux's tables are, well, simpler, e.g. https://filippo.io/linux-syscall-table/
4:56:36
remexre
idk, I'm kinda trying to go the Oberon route and build my own lang+OS; rn I'm going with s-exprs and image-based, but strongly typed and with hot code loading only at the "thread" level
4:57:27
no-defun-allowed
Just to check, is that statically typed (like Haskell) or strongly typed (like Common Lisp)?
5:03:02
remexre
probably going to have CL-style macros, though I'm not implementing this rn; it looks like most of what I'd want macros for, I could get with some sort of &block (like Ruby blocks)
7:35:22
refusenick
How do I set the axes and labels in wxplot2d and wxplot3d to be white? I'm running Imaxima in Emacs with a dark background, and the default black labels look bad unless I go to a light background.
9:53:15
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=c29a8e5b will be valid until 10:00 UTC.
10:49:15
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=5363ce94 will be valid until 11:00 UTC.
10:50:56
lxbarbosa
someone @ reddit said that Paul Graham 'needs to learn how to code in Lisp, instead of creating new lisp languages(bel)'
10:55:43
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=5363ce94 will be valid until 11:00 UTC.
14:13:15
g_o
Hey I'm trying to deref an sb-alien array and get the following warning: https://pastebin.com/3HdKirHe. Any ideas?
14:28:49
p_l
where possible, we try to recommend implementation-independent approaches, because they lead to healthier community
14:32:13
Ober
just given the history here, almost always sbcl is recommended as the implementation, rarely an alternative
14:32:22
p_l
beach: I figured that at low traffic explaining that might be good, and assumed good faith
14:32:28
beach
ACTION adds g_o as another data point to the statistics of suffering that was mentioned some 10 hours ago.
14:33:37
p_l
SBCL has significant list of cons (pun intended), including long compilation times and being pretty memory hungry (it generates fast but big on memory code)
14:33:39
Ober
sure, I should have rephrased it, but endless effort fighting issues on other implementations tends to lead to the general advice to new folks to use sbcl outright.
14:34:37
p_l
on some platforms I would actually recommend ECL, but not many people can claim to be "new" on those platforms
14:34:57
p_l
Ober: I'm also still pretty sure it's slower in following yet-another-brammage from Apple than CCL
14:37:09
Ober
as fare says adsf has a long tail of implementations supported. but I would not be recommending any of them.
14:37:35
p_l
selwyn: z/OS (with USS/OMVS), random platforms that accept mostly ANSI/C99 code with bits of posixish APIs, etc.
14:38:04
p_l
in case of ASDF, the long-tail stretched back to platforms that didn't see serious updates since 1994
14:39:08
p_l
and there's small chance Corman might creep back, though updating it for 64bits would be a challenge afaik
14:41:18
p_l
I personally believe that keeping to cross-platform by default is going to be good for community
14:42:12
White_Flame
which either is or should be getting to general usage for C++ integrated scenarios
14:45:28
p_l
At the moment I'd be just happy to maybe use it as CL's equivalent of SIP, since I'm really not in the mood to write C++ to interrogate Clang about vtable layouts
14:46:10
p_l
(and proper exception handling is something that actually gave me waking nightmares when I tried to implement it in ~2010)
14:48:37
p_l
and as my recent experience with CommonQT shows, we need to update tooling because Qt4 is actually unbuildable/unrunnable in some cases
14:52:57
selwyn
i wonder if having potentially large c++ libraries available in CL (via clasp without C wrappers) would significantly affect the lisp community
14:56:26
p_l
selwyn: unfortunately C++ is used heavily enough in some cases that it is unavoidable in *current* state of the world
14:57:00
p_l
especially since the ways to actually have multi-language interoperability are reviled by people outside of MS
14:59:05
p_l
And I want CL used more in general, not just in rather closed off pockets that can deal with just reimplementing around C++
15:10:29
selwyn
beach: there are some fields such as professional game development in which one cannot do without making use of large existing c++ libraries. having these libraries available in lisp all of a sudden certainly makes the space of lisp applications much bigger. having said that, i doubt that having a lisp game published would have significant positive effect on, say, the lisp library ecosystem
15:12:36
p_l
certain ML areas are full of C++, sometimes so bad C++ you can barely use it as C++ (I'm looking at tensorflow specifically)
15:17:38
beach
p_l: I understand that there is a huge amount of C++ out there. I was wondering about selwyn's own thoughts about whether the availability of that software to Common Lisp programmers would influence the Common Lisp community.
15:23:23
beach
selwyn: There is also the possibility of a negative impact. If large amounts of bad and unsafe C++ code is available, it might discourage the use of safe, native Common Lisp code.
15:34:48
p_l
beach: I think C++ is bad enough that if you're using it from anything not-C++ you are already looking for better alternatives