freenode/#sicl - IRC Chatlog
Search
9:03:30
beach
There is no applicable for the generic function #<STANDARD-GENERIC-FUNCTION CLIM-BACKEND:FONT-GLYPH-DX (1)> when called with arguments (#<XLIB:FONT fixed :0 ....> 84).
10:50:43
scymtym
beach: thanks for trying. that's the kind of failure i feared. i believe it is a result of https://github.com/McCLIM/McCLIM/issues/705 . if you want to keep trying, doing apt install fonts-dejavu-extra (assuming ubuntu) might help. if that doesn't help, waiting for a bug fix in mcclim is probably more time-economical
10:57:02
scymtym
sorry for the trouble. i put in some effort to reduce friction (building in a container with an old libc, compressing the executable) but it is still fragile
10:58:53
scymtym
try a missing closing ) or " somewhere in the middle of multiple top-level forms. i hacked something for that yesterday evening
11:03:38
scymtym
it's a throwaway program. i'm using it to test eclector, my s-expression syntax library and some other pieces that will eventually be needed
11:04:30
scymtym
i'm thinking about extracting the pieces that read multiple top-level forms with error recovery, with a "read environment", without interning symbols, etc. into a library
11:06:00
scymtym
if you find bugs, i'm happy to address them, but the program itself is not something that i would like to polish and improve
11:07:40
scymtym
i promised pushing the in-progress version so people can look at it, but i would not yet recommend using it
11:09:05
scymtym
i have an approach for indentation that attaches operations of a wadler(i think was the name)-style pretty printer to defined syntactic constructs, but it is not very along
11:09:50
scymtym
i keep going back to eclector and improving so progress in the upper layers is slow
11:11:05
beach
A ;; comment inside a TAGBODY should be aligned with the following line and the indentation of the following line depends on whether it is a tag or a statement.
11:12:39
scymtym
the common case is aligning "parts" of a forms given the operator and the kind of part (e.g. operator = let, part = binding)
11:13:13
scymtym
but maybe there could be rules for the whole operator for these non-local decisions
11:13:51
no-defun-allowed
scymtym: So, are you making a pretty printer for all Lisp reader syntax, including comments and conditional reader macros?
11:14:35
scymtym
the pretty printing is basically the output format, it doesn't do the indention logic. the pretty printer can do indent, fill, branch based on available remaining columns
11:16:17
beach
I started contemplating some kind of declarative syntax for indentation information, but it quickly got complicated.
11:17:02
no-defun-allowed
I think a Lisp syntax-aware git clone is something that's been brought up in #lisp a few times, and that and some kind of unification for things like defsystem/defgeneric/defclass/&c information would be a good start IMHO.
11:18:18
beach
scymtym: Here is a remark already: It doesn't seem to distinguish between a non-existing package and a package with no symbols in it.
11:19:17
no-defun-allowed
scymtym: Today I had a nasty case of "you committed but you forgot to pull beforehand, and now you have to clean up git's chicken footprints in your code", and it was mostly different indentation and a couple of different symbols.
11:21:13
no-defun-allowed
So then if the version control stored syntax data instead of plain text, and gave pretty-printed expressions to the client, most of that wouldn't have been an issue.
11:22:06
scymtym
beach: yes, that's kind of neither here nor there at the moment. to know which packages exist at a given input location, it will be required to basically compute the ASDF plan for getting to that point and reading and processing everything in the plan with all that entails
11:22:14
no-defun-allowed
(Sorry that's a bit irrelevent, I just had more technology problems than usual today and that somehow seems like the easiest one to prevent.)
11:22:51
beach
scymtym: You could do the simple thing and require the user to load the system in order for it to find the package.
11:23:39
scymtym
no-defun-allowed: sure, a structure editor with a version control system to go with it would solve a bunch of problems, but that's a different discussion
11:23:45
beach
I would imagine that it is not often that one starts editing a file without having loaded some basic system first.
11:25:03
scymtym
beach: right. the approach is already hybrid in that regard, because it "imports" the COMMON-LISP and ASDF packages into the environment
11:25:06
beach
no-defun-allowed: I am convinced that version control should not be done on text, but I also have not had the time or energy to think it through any further. I am also convinced that the technique used would be specific to each type of source, like code, text, LaTeX, etc.
11:26:17
scymtym
beach: probably. just have to figure out an efficient way to declare which host packages to import into the static analysis environment
11:26:28
beach
scymtym: I need to think harder about incremental first-class global environments then, because having packages created in the unique global environment that most implementations use would be annoying.
11:27:53
scymtym
beach: i use a simple kind of hierarchical (or incremental environments) into which i can stick arbitrary stuff. i.e. you can use any namespace you like
11:28:58
scymtym
that said, i'm not sure whether trucler should accomodate, say, storing reader state in its environments
11:30:31
beach
I am thinking of a layered approach, where a new layer is added after each top-level form has been processed.
11:31:18
scymtym
sure, but traditional lisp environments have no slot or namespace for storing e.g. the readtable and related stack or packages
11:31:53
beach
I am thinking about the possibility of having the readtable functions trampoline to the environment.
11:32:45
beach
The natural reaction is to think of all symbol-xxx functions as naming a slot, but that is not necessary at all.
11:33:34
beach
So if it were possible to have the readtable functions trampoline to the first-class global environment, and if that environment were incremental, one could back up fairly easily.
11:33:37
scymtym
eclector already has CALL-WITH-CURRENT-PACKAGE which is a step in that direction, but there would have to be protocol for *READ-BASE* and friends as well
11:34:34
beach
I am thinking that layered first-class global environments would be fairly simple to implement.
11:35:11
scymtym
i current use a chain in which environments know their parent. that has been working ok so far
11:35:36
beach
Yes, that's precisely what I am thinking for the first-class global environments protocol.
11:36:05
scymtym
i don't whether i works right at the moment, but you might be able to try (cl:in-package …) in the editor to see it in action
11:36:06
beach
I think the protocol could be mostly intact, but some functionality for pushing/popping a layer would need to be added.
11:37:00
scymtym
i also may LOOKUP and DIRECT-LOOKUP, so you can distinguish between inherited and not inherited
11:39:45
scymtym
you can type (in-package "ASDF")<newline>(defsystem 1) and it will complain about the ASDF:DEFSYSTEM syntax error. if you remove the first line, it won't complain, because the s-expression parser won't have a definition for CL-USER:DEFSYSTEM (or CL:DEFSYSTEM or whatever the default package currently is)
11:41:26
scymtym
yeah, just got that as well. it's from the delimiter pair repair suggester i added yesterday. probably missed cases
11:42:07
scymtym
you can type the package name as an uppercase string if still want to try it. but i suspect you would like to get back to actual work
11:49:20
scymtym
regarding why i doesn't complain about (CL-USER:DEFSYSTEM …): that's the next layer. when i said it had no definition, i mean the s-expression syntax level. so checking (CL-USER:DEFSYSTEM …) involves querying the environment to see whether there is binding in the function namespace for that name
11:52:09
beach
Though, CST-to-AST should also be improved with information about standard functions and such.
11:52:25
scymtym
how the s-expression syntax library and CST-to-AST is one of the things to figure out
11:52:57
scymtym
can cleavir be extended to work with custom symbol and package representations? remember that none of the "symbols" read are actually objects of type CL:SYMBOL
11:54:07
scymtym
i guess that affects CST-to-AST as well, but to a lesser extent since the s-expression syntax library can already work on CSTs containing custom symbols
11:55:57
scymtym
yeah, i call those character syntax, s-expression syntax, abstract syntax. not sure if that's standard or even makes sense
11:57:32
scymtym
but i wouldn't want your cleavir work to get sidetracked because of the custom symbol issue
11:57:57
beach
So I am thinking that the user won't expect any significant feedback on code that contains undefined packages, or non-existing symbols.
12:01:01
scymtym
the problem i'm seeing is that typing (let ((my-variable-name involves the "symbols" m, my, my-, my-v, etc.
12:03:30
scymtym
ok, yeah, but i count that as custom symbol representation. maybe depending on the host the code is running in
12:04:35
scymtym
i think making the whole pipeline work with an abstraction of symbols is feasible. but maybe there's a better way
12:04:55
beach
Sure. And I don't know whether it would be possible to have package functions trampoline to environment functions.
12:05:21
beach
If that is possible, then just baking out the top-layer of the environment would undo the symbol interns.
12:06:24
scymtym
yes, eclector with my environments already behaves like that. it might just be a lot of work to make the rest of the pipeline work with this representation
12:07:52
beach
If I add that functionality (trampolines for package functions) to the first-class global environments protocol, and create a layered implementation of the protocol, it should just work.
12:08:54
scymtym
yes, that part is not too scary. i'm worried about places in the compiler that assume names are objects of type CL:SYMBOL
12:10:46
beach
The current top-level form will be process in an initially empty layer of the first-class global environments.
12:11:56
beach
The layer that corresponds to the top-level form you are editing would be destroyed, and the one that precedes that form is used with a fresh new layer on top.
12:12:48
beach
All that provided that I can make package functions trampoline to environment functions.
12:15:18
scymtym
i completely follow regarding adding and discarding the environment entry and so on
12:15:21
scymtym
my question is: is the mapping in the leaf environment (<current-package> "M") -> <custom-symbol "M"> or (<current-package> "M") -> <cl:symbol "M">? in the latter case, you still affect the host's package system (the change could be undone, but it is a global change, and finicky to undo)
12:15:53
scymtym
but for the rest of the compiler to only see CL:SYMBOLs it would have to be the latter
12:18:42
beach
When you do (FIND-SYMBOL string package), it trampolines to (env:find-symbol environment string package).
12:19:49
scymtym
yes, i understand (that's what i meant with the "mapping" above), but does that FIND-SYMBOL return a CL:SYMBOL?
12:24:07
scymtym
yes, as long as you can make all symbol- and package-related functions go through the fcge version or all code explicitly calls fcge versions of the symbol- and package-related functions