freenode/#lisp - IRC Chatlog
Search
6:30:12
krwq
phoe_: I've wrote my own func for checking equality of files already but perhaps there is some more idiomatic way
6:47:28
phoe_
krwq: streams? take into account that a stream (a Gray stream, for example) can do arbitrary computation on read, so this becomes an instance of a halting problem
6:48:13
Zhivago
There are a number of efficient methods for determining file equality but they have overhead.
6:50:15
Shinmera
I mean, it's just a short loop: (loop for i from 0 always (eql (read-* s1) (read-* s2)) finally (return i))
6:51:40
Shinmera
phoe_: Sure, but that only applies to some streams, and even then what's the point of determining this position?
7:28:42
tapioco71
please help, I've got a strange problem with bordeaux-threads and binary-types: cannot load one of then if the other was quiloaded before due to bt name conflit!
7:33:11
beach
tapioco71: You are probably out of luck. It seems both those systems use BT as the nickname of a package.
7:34:07
shrdlu68
Perhaps there's some way to recover? "A correctable error is signaled if the package-name or any of the nicknames is already the name or nickname of an existing package."
7:37:36
beach
When package-local nicknames become sufficiently widespread, we don't need global package nicknames anymore.
7:40:55
shrdlu68
"the sb-ext:resolve-conflict restart should be invoked with one argument, which should be a member of the list returned by the condition accessor sb-ext:name-conflict-symbols"
7:41:38
beach
Does CCL have package-local nicknames? I am pretty sure I saw that jackdaniel recently added that feature to ECL.
8:10:38
dim
I'll present pgloader at PostgreSQL Conference Europe later this week (in Warsaw), will try to get contributors... putting CL to the “popularity test” again
8:10:45
beach
There, SICL now also has package-local nicknames. :) Now I just need to modify the reader to take them into account.
8:11:06
dim
I want to use the arguement “programming in Common Lisp actually is easy”, would you agree with that?
8:12:16
Shinmera
dim: My argument for CL is that it makes me angry much less often than when I work in other languages.
8:12:26
dim
Shinmera: I'd like to send a message that hacking an existing CL program to add a new feature or fix a bug isn't harder than doing the same thing with a Python program, say, or even easier
8:14:02
dim
but some people like JS, and some of them might be in the room, I don't want to start another flame war, I'd like people to consider contributing to pgloader
8:14:10
Shinmera
Anyway, what usually impresses people is the live redefinition stuff. A lot of programmers "grow up" thinking that that's not even possible.
8:15:13
Zhivago
These days live redefinition impresses me very little since machines are fast enough that it generally doesn't matter any more and invites incremental error.
8:15:49
Shinmera
Zhivago: It matters a lot in some scenarios where running the program to get back to the state you want to investigate is difficult or takes a lot of time.
8:17:19
dim
Shinmera: in that case it means most contributors will want to hack on pgloader using the Makefile rather than setting up a CL environement
8:18:25
beach
dim: Another important obstacle that I often encounter is that many programmers (especially those with insufficient knowledge and experience) confuse "interactive" and "interpreted". So their reasoning goes "interactive" => "interpreted" => "slow" => "can't use". If I were you, I would make it clear that modern Common Lisp implementations are fast.
8:18:38
dim
for me the best thing in CL/SLIME is the interactive debugger that I get for free in case something unexpected happens, with all the debug info
8:19:35
dim
beach: hehe, the reason why pgloader is now CL rather than Python like it used to be is a 20x to 30x improvement ;-)
8:20:10
beach
dim: Yes, that's good. But you may have people in the audience who think that C++ would give another 30x improvement.
8:21:21
dim
I need to find how to optimize it further, it's only chopping about 6MBps of data trafic (with transformations), saturating CPUs doing so
8:21:27
beach
I recently gave a talk to a major consulting company in Sweden, and most of the people in the audience were confused about this issue. They were certain that compilation required batch processing and generation of object files.
8:21:48
phoe_
People tend to react differently when they unexpectedly see something that looks like assembly.
8:22:20
dim
beach: I would like to understand this “linker” stage better, I failed again and again to explain why Lisp doesn't need it
8:23:23
dim
the current hot spot to fix is https://github.com/dimitri/pgloader/blob/master/src/pgsql/copy-format.lisp
8:23:27
Shinmera
Has someone written a paper yet titled: "A Transpiler is Just a Compiler, A Transpiler is Just a Compiler, A Transpiler is Just a Compiler!"
8:23:48
beach
dim: Basically, Common Lisp implementations have an indirection between a name and what it stands for, and the indirection is managed within the implementation, as opposed to by an external linker.
8:24:19
dim
Shinmera: as one who began writing an Oracle PL/SQL to PostgreSQL PLpgSQL “compiler”, I'd like to read it ;-)
8:25:05
dim
beach: that I think I understand (function cell, extra pointer, allows replacement at recompile, ok) ; but what the linker does in the C/libc setup I don't understand
8:25:59
phoe_
the compiler creates object files, the linker links symbols from the object files together so object A knows where symbol FOO is if object A is linked with object B that has a symbol FOO.
8:26:31
beach
dim: Other languages typically use 1960s linker technology, though all that stuff is blurred these days with shared libraries. Traditionally, a function in one file calls a function in a different file DIRECTLY using its address. To make that work, the compiler generates files where some addresses are marked as RELOCATABLE. The linker fills in the final address when the executable is created.
8:28:02
Shinmera
People are doing crazy stuff with linkers nowadays where they do inlining during the linking process.
8:28:46
phoe_
To me, this means that you're modifying the assembly that was already generated by the compiler.
8:29:27
dim
would a lisp OS need a linker? I guess it would maintain a global function addresses table for the whole OS?
8:30:44
dim
and an “environment” could then be a dynamic version of that global table, with overloading entries, maybe?
8:30:49
beach
dim: The indirection used by Common Lisp has many advantages. Without it, you need to restart Firefox whenever you get a new version, and you need to restart your entire computer when the kernel is updated. None of these problems exist when you have this one indirectly.
8:37:13
beach
shka: As I recall, the implementation is allowed to skimp on the indirection that I mentioned within a compilation unit. It can then generate faster code, but the disadvantage is that you can then not use C-c C-c to redefine individual functions, etc.
8:37:39
jackdaniel
but they are in repository only, they were implemented after the last release afair
8:38:20
beach
jackdaniel: It is not that I plan to use ECL soon. But the more implementations that have it, the more it becomes practical to use them.
8:40:08
beach
I just added them to SICL, but since the definition of the package class in SICL is just a DEFCLASS form, it was easy. I just have to modify the reader to take advantage of this feature.
8:49:08
jackdaniel
I think he doesn't have time to implement it himself, but last time I've talked with him about that, he was rather positive on merging such thing
9:01:15
phoe_
rme is pretty happy to maintain CCL but he does not have the time to implement big changes AFAIK
9:02:06
jackdaniel
this is not that big change anyway - adding a few slots to package structure and making find-package to perform lookup there first. and a few adjustments to defpackage macro
9:04:44
beach
It is slightly more complicated in SICL, because other implementation may want to use first-class global environments, so I can't just directly call (sicl-package:local-nicknames *package*). That's why we need TRIVIAL-LOCAL-PACKAGE-NICKNAMES.
9:08:26
beach
Any takers for implementing TRIVIAL-LOCAL-PACKAGE-NICKNAMES? It should not be too hard.
9:16:29
beach
It would have to contain functions (I suggest generic functions) for obtaining a list of (nickname . name) pairs for a given package, for adding and removing a (nickname . name) pair from a package, and maybe some error conditions to signal. That ought to be it.
9:17:23
beach
And it would have reader conditionals for the implementations that currently have this feature.
9:58:01
scymtym
beach: what about an extended DEFPACKAGE? or would you rely on implementations supporting the feature all having compatible CL:DEFPACKAGEs?
9:58:54
jackdaniel
so I think that implementation supporting local-package-nickname must support this in defpackage
9:59:26
jackdaniel
well, it wasn't put as CDR, see my question in here: https://github.com/nikodemus/SBCL/commit/3c11847d1e12db89b24a7887b18a137c45ed4661
10:01:44
jackdaniel
ah, right, one of the differences between ECL and SBCL implementation is that package locks aren't protecting package local nicknames I think (don't remember for sure)
10:06:11
beach
Anyway, what is needed in the compatibility system is the functionality of adding/removing/retrieving package local nicknames.
10:08:29
jackdaniel
my point is that trivial-… would be actually (defpackage trivial- (:import-from #+ecl #:ext #+sbcl #:sb-ext ,@our-symbols) (:export ,@our-symbols))
10:09:52
Shinmera
A trivial package would still be useful in case another implementation comes along that changes things slightly, or we discover incompatibilities of some kind.
10:10:46
Shinmera
Speaking of package things, how many implementations have package locks? I don't think we have a trivial system for that yet
10:12:41
Shinmera
Seems it only supports allegro, clisp, cmucl, and sbcl. I thought there were more nowadays?