freenode/#lisp - IRC Chatlog
Search
18:12:25
Bike
thorondor[m]: the trivial-garbage documentation states that finalize returns the object. if it doesn't on ecl, that's a bug in trivial garbage, not cairo2.
18:14:46
Bike
https://github.com/trivial-garbage/trivial-garbage/blob/master/trivial-garbage.lisp#L307-L313 ext:set-finalizer doesn't return the object i guess, so all you'd have to do is have the let return object
18:14:48
phoe
https://common-lisp.net/project/ecl/static/manual/re89.html does not say anything about the return value
18:16:02
thorondor[m]
it is trivial to implement in trivial-garbage anyway. just return the passed object, regardless of the implementation specific finalizer implementation
18:26:53
ealfonso
I was using one package (via (:use :lib1)) and decided to change to a different library lib2, so I removed lib1 from the :use list. now I'm getting a warning: "MY-PACKAGE also uses the following packages: lib1". how can I "un-use" a package?
18:27:09
ealfonso
I tried (unexport nil (FIND-PACKAGE 'lib1)) (unexport 'lib1), etc, which didn't work
19:09:59
phoe
gosh, I wrote over a thousand lines of markdown over the course of the last three days
19:54:24
ealfonso
anyone familiar with stefil know how to clear/delete previously defined tests in a suite?
21:34:46
PuercoPop
ealfonso: following ensure-test points to the *TESTS* variable. Also FIND-TEST is SETFable. So (setf (find-test 'my-test) nil) should work
21:37:11
pfdietz_
Is there a CL test framework for property-based testing? That is, it allows descriptions of properties that some piece of software must have, and (separately) ways of generating inputs for the software.
22:13:13
ealfonso
when I saw an array returned from drakma:http-request, I thought it had interpreted the application/json content type and automatically parsed response JSON to an array... I was wrong. apparently I have to add the hack: (push (cons "application" "json") drakma:*text-content-types*) suggested here https://sites.google.com/site/sabraonthehill/home/json-libraries
23:03:24
pierpa
I like CL's punning. The problem only occurs when interfacing with a format that chose a different set of punnings.
23:28:11
antoszka
Is there a reader macro out there for ingesting/operating on IP addresses written in decimal notation? (and keeping them internally as 32-bit integers as they are?)
23:29:58
Bike
not that i'm aware of. i think socket libraries tend to use vectors as addresses, but i could be wrong
23:32:58
antoszka
Bike: oh, okay, any particular socket library you have in mind? Do you think it'd be useful to write a macro like this?
23:34:07
Bike
e.g. (sb-bsd-sockets:host-ent-address (sb-bsd-sockets:get-host-by-name "google.com")) => #(172 217 3 110)
23:34:47
Bike
as for a reader macro, id on't know, i don't deal with that kind of stuff much, but i thought hardcoded ip addresses weren't common
23:53:50
pierpa
There's only a finite number of characters, and very few of them are usable easily. I wouldn't waste one for this macro. And the convenience would be infinitesimal anyway.
0:01:50
pjb
pierpa: notice that with emacs, you can easily bind any unicode character to an easy key or key-chord.
0:04:20
pjb
pierpa: of course, with emacs, you can also have the convenience the other way: display a long-name as a single unicode character (with the compose operator, see eg. https://www.emacswiki.org/emacs/PrettyLambda
0:08:59
Josh_2
It's listed in the SBCL 1.4.6 manual but it isn't being recognized by the SBCL I'm using atm
0:18:59
antoszka
pierpa: guess I can see one piece missing, there are make-inet{,6}-address functions for parsing the string, but there are no equivalent print functions, maybe that could use some work.
0:55:14
ealfonso
I have N long-running threads performing some work. occasionally I'd like to peek into the current state of the work from an event-driven thread. I've thought about having each thread write to a global hash table but is there a better way?
0:58:34
ealfonso
the event requires the long-running thread to stop, compute an serializable state object, then continue altering the state
5:29:59
phoe
Hm. FIVEAM:MAKE-FIXTURE and FIVEAM:MAKE-TEST are exported symbols but have no definition.
6:02:58
blurgh
Would Lisp being tree-based instead of list-based remove the need for CDR coding and other tricks to get it to run on bare metal?
6:05:41
beach
blurgh: Modern processors are perfectly capable of running Common Lisp perfectly well.
6:07:12
blurgh
beach: True, but they're not designed for it. Technically, you could run a truely foreign language like Clean or something based on cellular automata, but would that yield appreciable speed? (OK, maybe Clean would be fast on bare metal given how fast it is already)
6:07:50
beach
blurgh: SBCL is capable of generating very fast native code. I don't know where you get the idea that this is not possible.
6:08:18
phoe
They aren't designed for running Java either which doesn't prevent it from flourishing on x86_64 and more and more optimizations making its way into the JVM all the time
6:08:30
beach
blurgh: Furthermore, there is nothing special about running on bare metal. The same code generator can be used, with only minor modifications.
6:09:27
beach
blurgh: Or, perhaps by "bare metal" you don't mean "without any operating system", and instead you mean "running native code"?
6:10:02
beach
blurgh: If so, then it is already done, and has been for decades. Most modern Common Lisp system generate native code on the fly.
6:10:23
blurgh
phoe: C maps 1-to-1 to a Von Neumann architecture computer with a single core. Even if it's a lie now (multiple cores, parallel stuff, etc), it's still faster than any other language. Lisp can come close to C's speed, but can match it only with judicious use of "call 'dissasemble', optimize by hand".