freenode/#lisp - IRC Chatlog
Search
23:07:14
specbot
Pretty Print Dispatch Tables: http://www.lispworks.com/reference/HyperSpec/Body/22_bad.htm
23:09:00
pillton
It won't tell you what object is printed on a fresh line, but you could possibly use a custom stream and an entry in the dispatch table to get that information.
23:19:03
stacksmith
pillton: a browser/debugger of sorts. I would love to not reinvent the wheel with layout/indentation but have some idea about where things wind up.
3:16:48
blep-on-external
how do i get all the class slots of a class? i've tried sb-mop:class-slots but it doesn't have applicable methods for the symbol or an instance of the class
4:11:43
beach
blep-on-external: Either you have TABs in your code that pastebin can not handle, or you line starting with COLLECT is incorrectly indented.
6:51:29
shrdlu68
"In general, Common Lisp is a type-safe language. A Common Lisp compiler is responsible for inserting dynamic checks for operations whose type safety cannot be proven statically. However, a programmer may indicate that a program should be compiled with a lower level of dynamic type-checking." -- What does (safety 0) do?
6:54:40
specbot
The ``Arguments and Values'' Section of a Dictionary Entry: http://www.lispworks.com/reference/HyperSpec/Body/01_ddc.htm
6:54:53
pillton
"Except as explicitly specified otherwise, the consequences are undefined if these type restrictions are violated."
6:56:59
White_Flame
also, a big ol' "In general," in the beginning of shrdlu68's quote leaves leeway there, too
6:57:34
pillton
"Should signal an error of type type-error if index is not a valid sequence index for sequence. "
6:58:52
shrdlu68
I should pay closer attention to exception types, never noticed array out of bounds exception was not standard.
6:59:35
White_Flame
sanity is relative to time frames. Pathnames, for instance, are kind of insane nowadays
6:59:41
beach
The purpose of WSCL is to clarify many such situations, like requiring errors to be signaled in safe code.
7:00:23
pillton
I must admit. I have never really understood the definition of safe code given clhs 1.4.4.3.
7:23:54
beach
Hard to quantify of course, but it is probably worse than most people think after a casual read of the Common Lisp HyperSpec. But I am guessing it is not as bad as some languages like C.
7:43:59
jackdaniel
what is awesome lisp? also, that is pretty dumb advice, unless provided as a simplified instruction for a real newbies.
7:44:25
jackdaniel
if we didn't care about portability, but "just write" for sbcl there wouldn't be a need for a standard and we'd be in a similar situation python or clojure are
8:08:40
beach
jackdaniel: The concept of a standard that is independent of implementations and of the organizations that supply implementations is pretty hard to grasp, especially these days, when single-implementation languages and benevolent-dictator languages are not only commonplace, but also used by industry projects that think of themselves as being serious.
8:17:51
jackdaniel
I can imagine our civilization getting doomed; only printed standards and programs survived
8:18:40
jackdaniel
of course I'm half-joking here, but looking at standards this way may help making the topic a little easier to grasp
8:21:24
beach
But, and I know I have said this before, for any industry project that thinks of itself as being serious, using a language with an independent standard is a must, or else they must take precautions and figure out what to do if the "language" they have chosen should disappear, quit being maintained, or be altered in some major way.
8:21:46
beach
They might have to hire compiler experts then. And they probably don't even know where to find one, nor what to pay such a person.
8:28:00
dim
beach: what about companies using their own home-grown and home-steered projects/language, such as Google with Go or Mozilla with Rust (I think), or Oracle with Java?
8:30:53
beach
dim: That's fine because they will then have hired people who are capable of maintaining that stuff.
8:40:29
aeth
akkad, jackdaniel: I find a good compromise between painful portability and no portability is to write for one implementation and then test it on one or two supported others. Technically, they could all violate the standard in the same way, but at least you're not tied to *one*
8:42:49
aeth
It's pretty easy to run on both SBCL and CCL. On the other hand, ABCL and CLISP are probably the hardest to support.
8:43:43
aeth
CLISP is... unusual. I think its fixnum is 48 bits. Its long float is arbitrary precision. etc.
8:44:44
Cymew
beach: If that is the old implementation I'm thinking of, I think it is such a corner case that it can be disregarded for compatibility reasons.
8:45:24
dim
as soon as that's possible, I'll have a look at having pgloader.jar and also using JDBC on that platform, that'd be great really for supporting some commercial databases and other niche ones
8:45:43
aeth
Cymew: CLISP is the interpreted implementation that's semi-active (no new release in a long time, but not dead), but tons of resources from 2000-2010 recommended it so it'll live for a long time.
8:47:01
White_Flame
the 3 major things is that it's slower than native compiled implementations, it has fast bigmath, and it's easy to get running on new/unsupported platforms
8:47:05
Cymew
White_Flame: I have read descriptions of its implementation of CLOS to be very peculiar.
8:47:26
beach
Cymew: karlosz is in fact writing a Cleavir-based compiler for CLISP as a GSoC project.
8:50:03
aeth
I'd say that the most annoying thing about CLISP is that it doesn't support single-float and double-float specialized arrays. When a specialized array isn't supported, you just get T arrays instead. *Tons* of libraries assume float arrays (or byte arrays) even though the standard only requires bit and character arrays. Those libraries will (slowly) run in CLISP, but without any sort of benefit in the type system.
8:51:23
aeth
Implementations with long-float (not just CLISP) also have an interesting issue with pi. pi is technically long-float, but in most implementations that's also a double-float so some people erronously assume pi is a double-float. So CLISP has the opposite issue there, where it supports something (long-float) that most popular implementations don't.
8:55:39
aeth
(CLISP does support byte arrays, so I might have been unclear there. I was just saying that that's another thing libraries assume.)
8:57:17
White_Flame
that's a problem I keep hitting. Half the libs want specialized VECTOR, the other half want specialized SIMPLE-ARRAY
8:59:06
_death
when I started learning lisp I used clisp on windows (and sbcl on linux) .. it was slow, but usable for many tasks.. it also has a small image size
8:59:19
aeth
White_Flame: a (simple-array single-float (*)) is a (vector single-float *) afaik (but not the other way around afaik)
8:59:49
aeth
_death: And there's the right answer for what you do NOT want to use SBCL for. When you need a small image size!
9:00:38
White_Flame
yeah, flexi-streams will build a vector for me, then I need to convert to simple-array to give it to the websocket lib
9:02:09
_death
flexi-streams has many faults.. some of them can be fixed without creating backwards compatibility issues, but that particular one I'm not sure
9:02:16
aeth
A simple-array is usually what you want if you even remotely care about performance (assuming you're not using one of the features that a nonsimple array has). It gives more guarantees as to the structure of the thing.
9:04:34
White_Flame
yep, I think a real failing of the spec is that simple-vector cannot be specialized
9:05:28
White_Flame
however, when you think about it, when you're dynamically building up a buffer from a stream, the backing data can't be simple
9:08:17
aeth
You would need some way to communicate that it's only meaningful up to a certain index. A general library should probably just use the 2nd return value to do it, but I'd personally put it in a struct to store the value.
9:09:07
aeth
Obviously this is probably going to waste space (but also risk running out of space), but make things faster.