freenode/#lisp - IRC Chatlog
Search
8:14:42
shka
schweers: https://common-lisp.net/project/cffi/manual/html_node/Tutorial_002dCallbacks.html
8:15:16
beach
schweers: yes, but look, this is freenode. We are into free software. When you "duplicate" some existing C code in Common Lisp, you make it safer, and more available to other Lispers.
8:16:40
ZombieChicken
I doubt it will always be 'safer'. Well-tested encryption algorithms in C would be preferable to a relatively untested version in CL
8:16:55
schweers
beach: I’m not sure how things will turn out exactly, but I might need a library callable from lisp and other languages, possibly gauche scheme (written in C, can call C functions)
8:17:48
beach
ZombieChicken: So you are saying, we should just throw in the towel for every case, and abandon the goal of writing Common Lisp code?
8:19:43
shka
schweers: writing bindings sucks for everything that was not designed explicitly to support bindings
8:20:23
beach
ZombieChicken: I am genuinely concerned about the way software is produced today. I think many people, including most of the industry, is doing the wrong thing, wasting a lot of effort using the wrong language, and producing unreliable code.
8:20:49
ecraven
beach: many would agree with you, but start arguing on what actually *is* the right language
8:21:07
edgar-rft
We could write a new earth in Commom Lisp, we'd only be willing to invest 4.5 billion years of work.
8:21:49
loke
Thankfully, RabbitMQ exists, and it's very good, and arguably written in a safe, acceptable language
8:22:03
beach
ecraven: I am totally convinced that Common Lisp, while perhaps not THE RIGHT language (especially not for EVERY situation), is a huge step in the right direction compared to most commonly used languages. And that includes using C or C++ for applications.
8:22:18
shrdlu68
beach: For an industry/profession/trade that automates things, we're doing a poor job of automating ourselves away. That, for me, is the first sign that something is wrong with the way software is produced today.
8:22:54
ecraven
not disputing this, just saying that *that* is where people'so opinions probably differ ;)
8:22:56
schweers
beach: I share your sentiment, and in general agree with what you told me earlier, that I should rather be writing in lisp than in C. That being said, I may be forced to have parts of the code in a way that accepts a C function. I hope I can avoid this, but I wanted to know the state of things beforehand.
8:23:31
loke
beach: I've used it a bit (mostly using Elixir), and it does have many of the same benefits as Lisp.
8:23:34
ZombieChicken
beach: Perhaps, but there are practical concerns in the mean time. I'd rather see someone call known good C in some cases (mainly encryption) than reimplement the code in CL and potentially break something important. Of course, this doesn't apply to people who do know how to write such code and verify that it is indeed right.
8:24:15
beach
schweers: I understand. Though I am always skeptical when it comes to phrases such as "have to", or "forced to". It is a choice after all. In fact it's a choice to even write software in the first place.
8:25:10
shrdlu68
It's a myth - an illusion - that there are some wizards out there who know how to implement crypto correctly.
8:25:45
loke
shka: I'm curious as to what your use case is? For me, as soon as I wanted to do anything beyond the absolute simplest use-case where I was sending simple messages from one place to another, it simply wasn't able to provide the necessary functionality.
8:26:18
beach
ZombieChicken: Sure. I am merely pointing out that we are in #lisp and that I feel that I should encourage people to put in a little extra effort so that we can increase the collectively available amount of Common Lisp code, rather than to solve their own problem that is much harder to share.
8:27:30
loke
beach: You have no idea how many poeople in the Maxima community have adviced me to “just use qxmaxima” or “put your effort in jyupiter for Maxima instead”. Luckily, I'm stubborn and refuse. :-)
8:28:17
beach
ZombieChicken: I am also saddened by the proportion of the traffic in this channel that is dedicated to questions, answers, and discussions about how to use other languages that Common Lisp.
8:28:39
shka
loke: i built distributed system with it, i used zeromq for messeging between machines, monitoring processes and so one
8:28:41
loke
beach: At some point I resign myself to the fact that all needed software won't ever be rewritten in Lisp. Hence by choice to use CFFI to call out to Freetype and Harfbuzz. (I know JD doesn't like that)
8:29:05
loke
shka: My biggest issue with zeromq was that it has no subscription or selection features.
8:30:03
loke
beach: I think that's as close as we're going to get to the proverbial “I hust/have to use C code”.
8:30:20
beach
loke: Maybe propose another project here: http://metamodular.com/Common-Lisp/suggested-projects.html
8:32:04
loke
beach: I think reimplementing harfbuzz is going to be a very complicated project, and also a very tankless one.
8:33:00
ecraven
loke: I'd love to implement harfbuzz, but I don't think a single person can usefully do that :-/
8:34:12
ecraven
also, it has to be rather performant too, there's a lot of hot paths in the font engine
8:34:30
ZombieChicken
Perhaps a silly question, but if it's more complicated than it needs to be, why reimplement it in any language?
8:34:46
shka
loke: i can't find example in acceptable language, but just use pub-sub and setsockopt to subscribe
8:35:19
ecraven
ZombieChicken: I don't think it is more complicated than it needs to be, writing systems are just amazingly complex
8:36:30
loke
shka: I don't think that's enough... My requirements (what I use in Rabbit, and what made me switch) is that I need to be able to include metadata to messages which are broadcast to various channels. The listeners use selectors to pick messages based this metadata (Rabbit calls them “routing keys”)
8:36:58
loke
Another thing I need is the ability to have expiring messgaes, that disappear if they are not picked up in a certain amopunt of time.
8:37:22
ecraven
beach: I understand that, but writing systems are kind of a hobby of mine, and I really do think that people vastly underestimate the complexity to deal with *any* writing system (not just a few specific ones)
8:37:59
loke
shka: Another feature I use is queue timeouts, where a receiver queue (bound to a broadcast source) times out if a client hasn't touched it in some amouint of time.
8:38:39
loke
shka: There is also the concept of a “dead letter” queue where unprocessed messages are routed.
8:39:32
shka
loke: so ok: zmq has subscriptions, but as for the rest of the stuff: it is socket library
8:40:07
loke
shka: Right. That was my point really. I discovered that while it had “MQ” in its name, it's not really a message queue. It's a fancy socket library.
8:40:27
loke
I would have much less issue with it if it was called something without mq in the name :-)
8:40:47
ecraven
beach: I'm no expert on opentype, but there as a reason for most of the complexity. not saying it couldn't be done better, but it is the de-facto standard font format, it would be hard to replace it
8:41:00
ecraven
same for unicode, some very bad decisions were made, but there's no easy way to remedy that
8:41:46
loke
C++ is always a good reason for rewriting something. Unfortiunately he went to something that is only marginally batter, no? (C)
8:44:55
loke
shka: for your next project, why don't you give Rabbit a try? If you need anything slightly more capable. It's really a wonderlfy system. :-)
8:45:19
beach
ZombieChicken: Seems like a good fit for some problems. I have also seen people use it as a general-purpose language, but I am more doubtful about that kind of use.
8:47:44
loke
ACTION stares at his rendering of square roopts... That line... Tha aliasing. it makes my eyes hurt.
8:48:05
dmiles
ACTION uses Prolog for general perpose language.. Though many times i'll use it as a glue to FFI
8:48:12
loke
I may have to implement that line-join algorithm I found just so that I can make line-drawing use Xrender.
8:59:32
fm4d_
Hello, is there any way to have a string that spans across multiple lines (most programming language supports it via \ etc.) in common lisp? I've only found a way to do it in format control string. Thanks :)
9:05:05
fm4d_
Sorry, I've forgot to add that I would like that multiline string to be without newlines.
9:06:41
fm4d_
I can of course concatenate the two strings or remove the newline afterwards, but that feels dirty
9:09:48
loke
fm4d_: With the FORMAT trick, you can even have space at the beginning of the second line to line things up, FORMAT will strip those off. If you don't like that behaviour you can terminate each line with ~: instead of ~
9:10:41
ecraven
loke: any idea why elisp chose % instead of ~? doesn't ~ have precedent in earlier lisps?
9:11:21
loke
That said, Maclisp had FORMAT with pretty much the same syntax as CL and it is contemporary with Emacs.
9:12:42
loke
fm4d_: If you want to be really fancy, you could create a reader macro to provide custom syntax for that. :-)
9:15:44
fm4d_
For now I am happy to be able to solve some real world problems in clisp without constantly searching in books and frantically googling :D
9:32:50
loke
ym: you want to type CL code in emacs and have it run in the CL? Or you want to run a CL comamnd from within Lisp and have it pass Emlisp code for execution in Emacs?
9:36:47
ecraven
look in contrib/slime-repl.el, around line 1710 (defun slime-repl-event-hook-function ..)
9:39:01
ym
I want to use emacs as UI-frontend to my CL program, but everything points me out that it isn't the way.
9:59:57
ecraven
shka: depending on what you want to interface with, slime/swank might get in the way more than it helps
10:14:44
ym
I'd be fine with CL-implementation-independent Emacs-frontend, and seems like just digging into slime/swank is exactly what I need. Reading it's docs. Thanks for help.
10:31:41
dim
mm, I just discovered today that in SLIME C-c C-c is more like C-M-x than like C-c C-e, and that I like C-c C-c a lot, when I used to only use C-M-x
11:12:32
dim
I know I prefer C-c C-l to C-c C-k for whole files, in order to avoid having fasl files around, but for defun forms it seems not to do that
12:55:06
dim
mmm, not quite there yet with taming SBCL, or rather understanding what parts of the code are consing, I guess
13:45:58
dim
in that case though I think I can use a streaming API instead of packing things in-memory in a batch, with the ZS3 stream support
13:52:22
dim
the code already does (sb-ext:gc :full t) each time it gets rid of a batch, to hint SBCL
16:09:02
oleo
loke: i just used :plot 2d (expression) sin(x) (variable) x (lower bound) -5 (upper bound) 5 to get a plot
16:23:59
oleo
just not sure why output-translations are not defined in quicklisp for the local-projects stuff by default....
19:23:43
dim
the run includes parsing a command language, which returns a lambda form, that is then compiled
19:26:25
scymtym
if you call COMPILE at runtime, some amount of compiler stuff is going to be in the profile (disregarding what PCL might add)
19:26:40
dim
pgloader in that profiled run loaded 121746 rows (36.3 MB) in 2m23.802s, so the compiling shouldn't be leading the profile, that said it's a multi-threaded program, does the profiler knows how to profile multiple threads?
19:28:23
dim
retrying with options (:max-samples 10000 :mode :alloc :report :flat :threads :all :reset t), that should help, maybe
19:30:57
scymtym
dim: if you are adventurous (and your SBCL version is recent enough), you could try https://github.com/scymtym/clim.flamegraph/tree/future to get a more nuanced view
19:33:27
aeth
I notice a lot of things in sprof not directly related to my program. sb-profile seems a lot more useful
19:37:02
dim
though I see calls in the trace that don't seem to belong to the pgloader main thread at all, so I'm quite confused
20:13:46
jeosol
dim: sometimes it pays to leave it for a while and come back, allowing the brain to relax