freenode/#lisp - IRC Chatlog
Search
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
16:01:00
selwyn
beach: good point. i would prefer not to touch c++, but i do find lisp and c++ integration interesting in its own right due to the myriad of issues that have to be overcome
16:08:57
p_l
it's easy topic on Windows, but that's because MS heavily invested in making all APIs accessible from anything you want