freenode/lisp - IRC Chatlog
Search
5:49:10
beach
Yeah, but this practice is unfortunately incompatible with the convention of using long package names, like pjb does for instance. Package aliases would come in handy, but we don't have them yet.
5:49:54
axion
But yeah, it goes a very long way towards making your code understandable, amoung other benefits.
5:50:12
beach
Not in my world. :) I always pretend I am in a LispOS where all software is present at the same time.
5:51:52
beach
Right. In trying to clean up the code for (first) Climacs, I couldn't even figure out where most operators were defined, because it :USEd all its external packages.
5:52:24
beach
It is amazing how reading one's own code from a few years back gives quite a few surprises.
5:52:40
axion
The only thing I use now, is alexandria, because I use a handful of functions in every project, and it has almost become part of the standard for me. I really should be just using :import-from though
5:56:27
axion
What is more annoying are the surprises from reading other peoples code with many USE'd packages. I bet these developers either have a hard time naming symbols, or take the Emacs approach that lacks multiple namespaces.
6:04:25
beach
This discussion reminds me that I should probably ditch my attempt to clean up the code of (first) Climacs, and start over. My current attempt became to error prone and I fear that I will never get it to work again this way.
6:40:11
beach
1. Make sufficient progress on Second Climacs so that it can display Common Lisp code from the parse results of the incremental parser.
6:40:17
beach
2. Create a special analyzer that will highlight imported symbols without a package prefix (other than symbols from the Common Lisp package), and provide a tooltip that will show the name of the package of the symbol.
6:40:28
beach
5. Import selected parts of the cleaned up code from (first) Climacs to Second Climacs in order to make faster progress on Second Climacs.
12:03:47
myrkraverk
That has been my exerience, but I think I'm not well versed in CL yet, to know about most of the UBs (unlike C).
12:32:11
beach
myrkraverk: Common Lisp has plenty of situations where the behavior is undefined. But most Common Lisp implementations don't fail as spectacularly as most C implementations would do in such cases.
12:33:20
beach
myrkraverk: The reason is that Common Lisp implementations can (and in general do) test for these situations and signal an error then.
12:34:23
beach
myrkraverk: But the Common Lisp HyperSpec allows for undefined behavior to be as spectacular as the C standard does, so you have to choose your Common Lisp implementation wisely.
12:35:38
beach
myrkraverk: For example, I don't know a single situation where SBCL would fail silently in safe code, i.e. when the SAFETY optimize quality is equal to 3.
12:36:21
beach
myrkraverk: Now, the situation is completely different if you start using code written in a foreign language, of course (which is one reason I try to avoid that as much as I possibly can).
12:49:39
adlai
myrkraverk: you do still have to know the limitations of your machine. for example, SBCL on memory-starved linux will do the moral equivalent of a segfault if you leak memory (or don't care enough about it)
13:05:35
|3b|
one example of a place where it is easy to get C-level behavior from lisp is something like (defun foo (a) (declare (type some-type a)) (check-type a some-type)). the DECLARE tells the compiler A is SOME-TYPE, so it knows it can skip the CHECK-TYPE
13:12:13
myrkraverk
So if I start my sbcl sessions with (declare safety 3) -- at least while experimenting, I should be "safe" ?
13:25:22
Grue`
I'm getting a weird warning "Derived type of SB-C::NEW-VALUE is (VALUES EXTENDED-CHAR &OPTIONAL), conflicting with its asserted type BASE-CHAR."
13:25:42
Grue`
http://paste.lisp.org/display/339935 it happens at the line (setf (char geminated end) #\っ)
13:32:25
pjstirling
sbcl recently changed stuff to do with creating base-strings in some cases, when it can
13:36:12
|3b|
complains during compilation, but don't see anything it could validly assume about READING that would justify the warning
13:37:28
|3b|
reduced case is (defun foo (a) (setf (char (copy-seq a) 0)#\HIRAGANA_LETTER_SMALL_TU))
14:31:36
myrkraverk
http://www.myrkraverk.com/blog/2017/02/sbcl-with-timeout-is-a-nice-undocumented-feature/
14:40:01
beach
HAH! I wrote a "USE finder" that READs a file and returns all symbols that have no package prefix in the file and that have a different package from *PACKAGE* when the file is being read.
14:41:22
phoe
that's a very useful tool. you can import whole packages when developing, and find out what exactly you *need* to import when you refactor or prepare a release.
14:41:42
beach
It can't be used to automate the insertion of package prefixes, because a typical file has lexical variables for which the package does not matter, and for which one certainly would not want a package prefix.
14:42:37
beach
I plan to use it to take some of my old projects that have extensive USE clauses in defpackage, and attempt to remove those.
14:44:00
beach
The fact that such a tool was nontrivial to write says something about the difficulty a human maintainer has when reading code which :USEs many packages.
14:46:25
beach
Well, "nontrivial" should be put into perspective. I could program the SICL reader by changing how it handles symbols without any package markers in it. I just had to add a few lines in the default method, specialize it to a new stream class, and that was basically it.
14:49:13
beach
Aside from the duplicated code for token interpretation from the SICL reader, the entire thing is 50 lines or so of code.
14:52:17
malice
Hi! I tried quickloading caveman2 and I get compile-error during loading static-vectors.
15:04:28
pjb
Of course, to be garbage collected, you would have to remove all the methods and all the instances refering it
15:24:37
beach
dim: If you are in an infinite computation, you can press C-c C-c in SLIME and then use the debugger to look at the backtrace.
15:26:50
dim
or it's not done yet, or it's not handling an error properly and it's waiting for some interaction somewhere I can't see
15:29:53
phoe
there's a condition-wait somewhere, so basically, the thread is waiting for another thread to set a condition variable.
15:40:45
dim
https://github.com/dimitri/pgloader/blob/master/src/sources/common/db-methods.lisp#L316
15:40:50
dim
https://github.com/dimitri/pgloader/blob/master/src/sources/common/db-methods.lisp#L332
15:40:55
dim
https://github.com/dimitri/pgloader/blob/master/src/sources/common/db-methods.lisp#L362
15:44:27
dim
I am wondering again about the whole business of manually tracking finished tasks in a way that I can decide "table is done, continue with indexing now"
16:07:01
dim
I can't wait until the next time a colleague wants to know more about why I love Common Lisp and assert it's a modern proglang
16:07:10
fourier
after 8 years of occasional usage of cl I've finally read slime manual. it is not that bad! :) (I mainly use LW however)
16:22:23
dim
the fact that I hate auto-completion of object methods might be strongly correlated here of course...
16:47:04
dim
I'd rather read the docs from the classes and API that I am using than guesstimate which entry I might want to use
16:47:25
dim
if I don't already know the name of the method, I'm up for some reading and that's good
16:48:15
fourier
autocompletion is a way to explore what methods class have without leaving your development environment
16:54:07
dim
I'm just saying that if you don't know that, you might want to leave your dev env before it's too late ;-)
17:04:46
fourier
you can type say "(package:" and see all exported symbols from this package along with their documentation (strangely enough it doesn't show documentation for functions though)