freenode/#lisp - IRC Chatlog
Search
21:11:58
verisimilitude
Yes, Josh_2; say, has anyone else had issues with CCL being unable to find its queer little database it uses; I've been unable to do some work under it and, using GuixSD, am reluctant to directly modify anything related to it.
21:13:11
verisimilitude
I'm also having issues conditionally loading this code, because CLISP whines about the #$ reader macro.
21:15:05
phoe
Yes, it is over - though people are staying for longer since Marbella is just that pretty
21:15:53
jcowan
Am I right to think that whereas block names have both lexical scope and dynamic extent, catch tags have indefinite scope and dynamic extent?
21:16:32
rme
ccl expects to find the interface db (darwin-x86-headers64/ or whatever) in the #p"ccl:" directory. By default, that's the same directory as the heap image file. You should be able to set the environment variable CCL_DEFAULT_DIRECTORY if that is not right.
21:17:13
jackdaniel
trying to call return-from from to non-existing block (i.e from escaped function) signals a condition
21:19:09
Xof
and I didn't even manage to tell didier that I have a fix for all his method-combination issues
21:20:19
theemacsshibe[m]
Are there any interesting lisp shows in Melbourne Australia? Not the Florida one.
21:26:35
verisimilitude
There's a /lib/ there, but no x86-headers/, no libc/, and not a single cdb file.
2:25:13
verisimilitude
The test is separate; sure, it only runs once, but then you're caught in the idea that you can write perfect tests to test imperfect code.
2:25:45
verisimilitude
That recursion needs to be broken somewhere and the easiest place is before it starts.
2:26:55
verisimilitude
It seems strange to talk about performance like that for several reasons; firstly, it's clearly more important that the program is correct; secondly, this is Lisp and, if only performance mattered, Lisp wouldn't be chosen.
2:27:35
verisimilitude
With the ASSERT, you can even use restarts and continue; you can't do that with a test, but what if your test is wrong and fails to cover something that would only show up during actual execution over a long period of time?
3:05:28
pfdietz
Absent formal verification, testing is indispensible. And you might as well package up the tests so anyone can run them.
3:09:49
pfdietz
Delivering software of any complexity that works is very hard, and testing is not an optional part of that process.
3:13:02
verisimilitude
There's a difference between using a program to see if it works and writing however many test cases that check if something continues performing identically according to the test.
3:13:18
verisimilitude
Using a program to truly see if it works is necessary, but not this testing fad.
3:15:18
pfdietz
Casual execution of a program to "see if it works" will do f-all in a program of any complexity.
3:16:59
verisimilitude
``Beware of bugs in the above code; I have only proved it correct, not tried it.''
3:17:41
verisimilitude
Now, the funny aspect of all of these things that supposedly aren't optional is that they really are optional.
3:18:45
verisimilitude
Give a man a test and he'll know his program works. Give a man many tests and he'll never be quite certain.
3:19:16
pfdietz
Give me your code that you haven't tested, and I can be quite certain it will be shit.
3:19:59
verisimilitude
I tested this by actually running it and making sure it produced proper output in a few different cases.
3:20:14
verisimilitude
I don't need some fancy test suite to make certain a macro compiles a description correctly.
3:20:24
smokeink
check this out guys: https://www.youtube.com/watch?v=iavSKtqjVNA IOHK | Runtime Verification; Prof. Grigore Roșu CEO.
3:21:35
smokeink
"The 50 years of research and development work on K made possible what many thought couldn't be done. We can automatically generate a correct-by-structure virtual machine from it's formal specification, which is fast enough to run real programs." this is the tool in action https://www.youtube.com/watch?v=eSaIKHQOo4c
3:31:55
smokeink
Semantics-based Program Verifiers for All Languages https://www.youtube.com/watch?v=cxdPjbpn95s
3:36:15
verisimilitude
Also, pfdietz, if you actually are inspecting that code, even a tad, know that I purposefully wrote the macros to attempt to generate invalid lambda lists if my rules weren't followed.
4:08:05
White_Flame
verisimilitude: yeah, it's great that we can use runtime checks at compiletime in lisp
4:08:25
White_Flame
as opposed to having the runtime burden, or running separate sanity testing code not included in the runtime
4:10:34
pillton
verisimilitude: The unit tests aren't for you today, they are for you in six to twelve months time and they are there for your contributors to ensure they don't make the same mistakes as you did.
4:11:14
pillton
verisimilitude: Unit tests are also valuable when you are developing across multiple lisp implementations and on different platforms.
4:11:30
White_Flame
the biggest problem with unit testing is that people have no idea what a "unit" should be, and end up meaninglessly fine-grained
4:12:24
White_Flame
that, and complected design makes separating out & configuring units for testing incredibly difficult
4:15:16
White_Flame
I've always done coarser grained testing, and never once lamented not spending the time to meticulously unit test
4:15:44
aeth
Lisp is actually a good choice for if performance matters. It's not competing against fast languages like C or C++ or Java or C# (although it can be about as fast as the latter two)
4:15:58
aeth
It's competing against Ruby, Python, etc. Slow, interpreted languages for the most part.
4:16:50
aeth
White_Flame: I mostly REPL-test and run example programs. REPL-testing is perfectly fine... until you refactor. Oh well, I hope I don't introduce new bugs.
4:19:14
White_Flame
but even so, you choose when to call your testing functions. Startup your code environment, then call test functions
4:20:39
aeth
Not everything I do is currently dynamic. Some things were trivial, like for any higher ordered function using 'foo instead of #'foo
4:21:51
aeth
With the exception of an entirely CLX graphical application (which would be 2D-only?), that's basically impossible for graphical applications, although C can be minimized.
4:29:54
verisimilitude
As you can imagine, I don't have any contributors, pillton; note that in CL-ECMA-48, there is a single check to determine if the Lisp implementation meets the one nonstandard quality needed (support for a seven-bit character set) and one additional check if ASCII is supported for optimizations. Asides from this, there's no nonstandard dependencies, but checking on multiple implementations is still valuable and what I do.
4:30:53
verisimilitude
While I can understand how tests are comparable to a seatbelt, I disagree with the analogy. A seatbelt isn't going to protect you if you drive recklessly into an eighteen wheeler; you will still be destroyed, with or without the seatbelt.
4:35:34
verisimilitude
I'd think tests, at least as commonly used, are more comparable to wearing a helmet constantly.
4:36:25
verisimilitude
A helmet will protect you from a subset of truly oblivious and stupid mistakes, such as walking near a building with debris falling, so long as the debris isn't so strong to break the neck or strikes a part of the body not protected by the helmet.
4:37:05
verisimilitude
Well, you have some people writing that tests are mandatory; I'm simply challenging such an assertion.
4:39:26
verisimilitude
In closing, wearing a helmet while wearing a seatbelt is an even safer way to drive, so people should clearly do that.
4:39:46
verisimilitude
If you're going to be a professional trucker, a helmet should be mandatory; I'd fire any truck driver of mine who refused to wear a helmet.
4:44:10
pfdietz
V, out of curiosity: what's the size of the largest program you've been involved in the development and maintenance of?
4:46:56
jcowan_
I have a little plugin for the Chibi Scheme REPL; if you type @OK, it writes the previous expression and its result into a file of tests.
4:47:39
jcowan_
Also, there is a counterexample to the correctness-ueber-alles assumption, I think due to Ken Thompson but I'm not sure.
4:48:10
jcowan_
See [a large, long-running program with many bugs]? Which would prefer, eliminating 100 bugs, or making it run 100 times as fast?
4:49:59
pfdietz
The reason I ask is that a lesson you have taken from a toy example of a few hundred lines will not apply to development of a system of many thousands or millions of lines.
4:50:11
verisimilitude
Well, I try very hard to not let any of my programs get larger than one thousand lines, if I can help it; one way I do this is by looking for functionality I can split off.
4:50:40
pfdietz
In large systems, testing is vital to prevent the system from regressing as it evolves.
4:50:47
verisimilitude
I'd be inclined to believe a project encompassing millions of lines is already doomed, one way or the other.
4:51:57
verisimilitude
That sentence reminds me of the ending to ``AKIRA'', pfdietz, the idea of a system so grossly large evolving without regressions.
4:53:02
verisimilitude
While I'm not going to claim a single man couldn't understand in its entirety a program that is millions of lines long, or any length, I will write that a program that a single man doesn't understand is too big.
4:53:39
verisimilitude
If you're making changes to a program and need tests because it is so grossly large that you can't be certain you've not made bad changes, it's too large.
4:54:21
verisimilitude
I will gladly concede, pfdietz, that tests are, perhaps, necessary for development of a large program if the designers are determined that no single man should understand it in its entirety.
4:56:40
verisimilitude
So, I suppose we can agree that any redundant measures are good when lives are truly going to be at stake and when things are unnecessarily complicated.
4:57:20
verisimilitude
However, the vast majority of drivers don't wear helmets and writing tests is a waste of time and effort for the vast majority of programmers.
4:57:39
pfdietz
"Unnecessarily complicated"? Large programmings systems do things that toy program can't. You can't just say the problems they solve shouldn't be solved.
4:58:22
verisimilitude
It is usually trivial to prove a program can be smaller and simpler than it currently is, pfdietz.
4:58:59
aeth
verisimilitude: 1 million lines is almost certainly bad engineering, with few exceptions. Especially in a language like Lisp. 100,000 is definitely something you might see, though. e.g. Compiler, OS, web browser, game engine.
4:59:26
aeth
Some things just require complexity, like OS drivers or supporting media formats. Although you could probably move those all into libraries.
4:59:43
pfdietz
The real world is a messy and complex place, and real programs in that world become messy and complex things as a result. Real programs aren't large just to spite you.
4:59:48
verisimilitude
My larger point was that you should section off programs and, when known to work, seal them off so they need not be worried about again.
5:00:10
verisimilitude
You don't need tests after that point and I'd argue you don't need them before in most cases.
5:01:21
aeth
verisimilitude: Breaking certain things up into thousands of libraries actually makes the task harder because the library function has to support general use but the application function can be very specific.
5:02:05
doesthiswork1
pfdietz: I like that that statement remains true for several different definitions of entropy
5:02:14
verisimilitude
There's a world of difference from making a change to a program, compiling it, and then checking that the changes work properly and ``abs(1)=1'' or, for poor languages, ``abs(MAX_INT)=1''.
5:02:50
verisimilitude
That's true, aeth, but human judgment is supposed to intervene with things become unreasonable, one way or the other.
5:06:10
aeth
verisimilitude: It depends on if you want performance or correctness. Fortunately, in CL, you can choose between the two instead of having one chosen for you.
5:06:38
aeth
(Well, sort of. You'd have to convince the compiler it's really still a fixnum, which isn't always easy.)
5:08:24
verisimilitude
The easiest way to do this, aeth, would be to define ABS in terms of more fundamental operations, until any necessary checking is done in very few or a single place.
8:19:19
verisimilitude
"{struct termios t; tcgetattr(#0, &t); t.c_lflag |= ECHO|ICANON; tcsetattr(#0, TCSANOW, &t);}")
8:20:04
verisimilitude
With other implementations, I'm writing the same thing, but tcgetattr, tcsetattr, the constants, and other tidbits are real Lisp functions.
8:20:30
verisimilitude
A really good implementation makes the functions accept actual Lisp streams, but only Allegro does this that I'm currently aware of.
8:21:12
verisimilitude
Allegro also provides a function specifically for enabling or disabling system echoing, which is more pleasant to work with than this.
8:23:05
verisimilitude
Of course, the implementations that provide these functions that want a file descriptor instead make you get the file descriptor from the stream and they're very unreasonable about it.
8:23:52
verisimilitude
You can't get the file descriptor of a synonym stream, as an example; no, you must get the stream it uses and then get that file descriptor.
8:24:31
verisimilitude
This is just one reason to avoid nonstandard Common Lisp, most of the implementations provide horrible nonstandard APIs.
8:50:45
beach
ELS is great in that there are so many great exchanges of ideas in such a short period of time.