freenode/lisp - IRC Chatlog
Search
0:31:23
White_Flame
radiance does look interesting. once our web stuff is more mature, maybe I'll take a harder look at it
1:55:46
charles`
White_Flame: clack is not really meant to be used by someone developing websites. It is just a internal thing that Fukamachi decided to make separate and modular. It is meant to be used via niggle or caveman which has good documentation. clack by itself is not a drop in for hunchcentoot.
1:56:41
White_Flame
well, I wonder if those other things have workarounds then for when clack loses errors and such ;)
1:57:38
charles`
I have yet to actually try caveman, but it actually looks better than hunchentoot with more batteries included.
1:58:51
no-defun-allowed
Hyeh, you use <these-class-names> and Python @annotation syntax with Caveman?
2:46:34
Guest50292
i like the idea of migrating my server to hunchentoot so i can live code it remotely
2:54:07
CrashTestDummy
Ok, cool, I have a question about the results I am seeing from running the tests...
2:55:18
CrashTestDummy
Is it normal to receive various failures from the tests after doing a build from the 2.1.3 source?
2:55:26
CrashTestDummy
Expected failure: fopcompiler.impure.lisp / FOPCOMPILER-DEPRECATED-VAR-WARNING
2:55:30
CrashTestDummy
Skipped (broken): gethash-concurrency.impure.lisp / (HASH-TABLE UNSYNCHRONIZED)
2:56:04
CrashTestDummy
Expected failure: fopcompiler.impure.lisp / FOPCOMPILER-DEPRECATED-VAR-WARNING
2:56:08
CrashTestDummy
Skipped (broken): gethash-concurrency.impure.lisp / (HASH-TABLE UNSYNCHRONIZED)
2:56:20
CrashTestDummy
Expected failure: x86-64-codegen.impure.lisp / MOV-MOV-ELIM-IGNORE-RESIZED-REG
2:56:28
CrashTestDummy
Are those "Expected failures", "Skipped (broken)", and "Invalid exit status" items normal? Or am I doing something wrong?
3:09:26
dieggsy
A lot of the CL projects i've been looking at haven't been worked on for 2+ years. is this stability, abandonment, little of both?
3:10:49
beach
dieggsy: Probably depends on the project. My projects Flexichain and Cluffer have not been touchechd because they are stable.
3:11:36
CrashTestDummy
The typical answer is that a lot of the projects are just "complete" and don't need to be updated because CL is such a "stable" language. In other words, the libraries don't need to be updated to keep up with the language since the language doesn't change.
3:18:42
Jachy
Similarly, library dependency chains aren't such gigantic monsters like they can be in other ecosystems, so there's less chance for churn to update libraries solely because libraries they depended on updated
3:30:52
nij
CrashTestDummy: I have no idea. I did rememeber receiving some failures of testing.. but that didn't bother me.
3:33:34
beach
nij: What is your reason for being interested in environment objects? If it is just to see how things could be done, check out our libraries Clostrum and Trucler on GitHub.
3:40:20
jcowan
nij: CL is stable because no one person, group, or implementer group controls the evolution of the language. The current standard has been in place for 30 years, and most unofficial extensions have been worked on in parallel, so that even what is not standard is de facto portable.
3:40:38
Jachy
nij: https://github.com/guicho271828/asdf-viz shows some dependency graphs of a few systems. It might be illustrative to compare to the example on https://github.com/0815fox/node-dependency-visualizer/ for Angular (a JS framework)
3:41:09
Jachy
I invite you to run the visualizers on a sampling of CL libs vs JS libs though to compare overall complexities, especially on similarly-scoped projects. Multiple selection pressures contribute to the differences.
3:41:57
Jachy
(You can also see what I mean by churn with the JS project's recent commit in the doc/js folders, "add --all option to npm ls (needed from npm 7 on)".)
3:56:36
nij
beach: environment objects - I'm just curious to see how to make one like making a list as in (list 1 2 3).
3:56:37
Bike
if you're asking why people make breaking changes to software, it's because sometimes the old interface sucks
3:58:43
Bike
to some extent, and that's why my computer has instructions for working with binary coded decimal
4:16:26
jcowan
The Scheme standards are not as stable as the CL standards: they do grow. But very little of that is backward incompatible.
4:40:31
CrashTestDummy
Anyone here ever use Qemu (or some other hardware emulation rather that a normal VM) to compile the SBCL source?
4:47:12
moon-child
jcowan: really, huh. I always thought the main point of cl (and the reason it was so big) was to keep majority compatibility with all the lisps that preceeded it
4:47:47
jcowan
In many respects, yes. But CL was the firat "mainstream" lisp to do lexical scope, an idea borrowed -- from Scheme.
5:10:17
Nilby
I don't think dynamic scope is cheating, since it's basicly what the hardware does. But special variables seem a little like cheating, since it's like having undo on your memory.
5:10:25
beach
So the MacLisp compiler used lexical scope, but the interpreter used dynamic scope. The next Lisp system I used was Franz Lisp on Unix, and they worked very hard to make everything use dynamic scope.
5:17:04
moon-child
to my recollection, it was responsible for a number of elisp's performance problems
5:21:44
charles`
I don't see why one would be "cheating" and the other not though since I see them as basically the same thing. specials just have the advantage of being able to control which variables are dynamic
5:35:44
Nilby
I'll probably explain it wrong, so I don't want to annoy our experts. Old fashioned dynamic scope isn't much different than writing to a memory location. Lexicals can increase performance because they allow optimizations, increased locality, simplified management, as well as helping get rid of a class of bugs.
5:46:20
Nilby
In some way most old Lisps, but not the first, had a form of lexical scope with function arguments. We're lucky the whole scoping thing was nicely resolved in CL.
7:56:48
beach
Work is going fine, thank you. I am currently preparing my slides for the ELS talk. And yes, I work every day for around 10-12 hours.
8:02:51
saganman
Yeah, it is brought by people and government with their carelessness. Anyway you work relentlessly beach
8:04:31
beach
saganman: I think most researchers work all the time. One can't just turn the brain off.
8:20:33
remby
what is a lisp image? I know it's a binary that holds the interpreter, but I'm not sure how to picture this
8:23:08
beach
It is a bit long to quote it all here, but you can read it yourself in the Common Lisp HyperSpec.
8:31:03
remby
I think this is just kinda hard for me to imagine cause I'm not experienced with low level stuff, but I'll do more research
8:33:25
beach
Just think of it as a large graph of objects, each object taking up a chunk of memory, and some words in the chunk may contain pointers to other objects.
8:34:04
beach
So, a symbol will be a chunk that has a pointer to a string that holds the name of the symbol, and another pointer that refers to a package object.
8:35:04
beach
Executable code is just a vector of bytes that is tagged so that the operating system accepts that it is executed.
8:37:25
Nilby
ACTION laments that operating systems lost the ability to save a restartable image for any process.
8:38:58
beach
remby: Code is truly executable only when it is in the primary memory of the computer.
8:39:19
beach
And then it is just a sequence of bytes that the processor understands as instructions.
8:42:23
beach
There are lots of details that you need to know about to understand everything, of course. Like how a function calls another function, and how a function can refer to its arguments and its lexical variables.
12:08:17
daphnis
i couldn't find a straightforward way to checking that "foobar" ends in "ar" for example