freenode/#lisp - IRC Chatlog
Search
18:00:48
Bike
i don't think read suppress isn't allowed to put in a handler or do something equivalent, though
18:05:17
Bike
fun fact: the person who added that test is the same person who patched ecl to not signal an error
18:11:36
jackdaniel
I'm not sure how this is relevant (he might have misread the spec, but testing on other implementations may only tell you that implementation implements one or another strategy)
18:13:22
phoe
back to the topic - #\GARBAGE should be read correctly I think, but #GARBAGE needs not be
18:13:52
jackdaniel
examples are not normative of course, still it is worth something that in the example there is both #\garbage and #ralpha
18:14:50
phoe
it is supposed to behave well under read-suppress, even though no numeric argument is provided to it and ALPHA needs not be valid
18:15:00
pfdietz
Handling of bogus char names is relevant, since different implementations may have different char names.
18:25:17
jackdaniel
the spec talks about skipping a printed representation of an expression (even if syntax is slightly invalid), I think that it is a reasonable to asume that in case of dispatch characters expression has (informally) a recursive definition expression=#e expression, given that all defined dispatch characters work that way
18:26:13
Bike
well sometimes it's a token. like for #\ since I just looked that up, or #* since if it used READ it would drop initial zeroes.
18:31:33
phoe
but this implies another constraint on dispatch reader macros - "whatever your reader macro is capable of consuming, it must also make sense if it was READ as a normal Lisp expression with *READ-SUPPRESS* true"
18:32:15
phoe
so it would be forbidden to write #G1(((( which, even though it would be technically correct under some implementation of #G, would also confuse READ with READ-SUPPRESS
18:35:47
jackdaniel
it says about skipping the next "expression" whatever it means, *even* if it is not valid common lisp. so for things which we can /guess/ that are the next expression we should not signal a condition
18:39:55
jackdaniel
^ doesn't fall in this category, because we'd end suppressed reading after #G1, no?
18:42:31
Bike
if we say that a suppressed read error returns no values, it might still have the ((( in a suppressed context
19:08:16
phoe
also in case of a mismatched open paren we end up with an end-of-file error since there is no matching right paren
19:08:52
Bike
it hits #+(or), so the next thing is read with read suppress. it reads #+(or) 1, but there's no actual object, so it continues and reads 2 with suppression. then the suppression is over, so it reads 3 4 5
19:09:27
Bike
so if #g1 is read and that reading returns no values it could be understood to not yet undo the suppression, analogously.
19:14:02
Bike
anyway i stil think the behavior is undefined and the test shouldn't go either way (i.e., shouldn't mandate an error, and shouldn't mandate no error, so overall shouldn't exist)
19:32:02
fiddlerwoaroof
I don't really know why I keep pushing PRs, only about 80% of them get merged
19:32:26
fiddlerwoaroof
But, I hope someone else running into the same issues finds them and can get the software to work
19:34:03
fiddlerwoaroof
luis: CFFI's static linking support is broken on macOS without this patch https://github.com/cffi/cffi/pull/135/commits/1e43f7b62556fc7059c69a9c6d04c25bc9c2061e
19:35:52
fiddlerwoaroof
Basically, for some reason, macOS ignores a .a file if it's produced with ar
19:35:56
semz
Say I have an array in a CLOS slot. It's possible to perform some actions (e.g. computing a checksum) after changes to the slot by defining (SETF SLOT) accordingly, but is there a straightforward way to do the same whenever we only replace some entries of the array rather than the entire thing?
19:36:46
fiddlerwoaroof
And so, when using static-image-op, the cc invocation to link the SBCL runtime with the FFI libs fails
19:38:21
fiddlerwoaroof
I use this here to deal with osicat-hell, https://github.com/fiddlerwoaroof/daydreamer/blob/master/build.lisp
19:39:27
fiddlerwoaroof
Hmm, I should look into using nix hydra to build this, circle-ci charges for macOS
20:24:17
phoe
one of them is Bike's treating it as undefined, which implies removing the test from ansi-test
20:25:15
phoe
the other is jackdaniel's idea of requiring that stuff that is actually read by reader macros must be readable as Lisp data under *READ-SUPPRESS* which would then make it possible for the reader to omit them completely
20:28:35
phoe
the first one is very easy to implement, the second puts additional logical constraints on portable code that clarify the spec's intention on the matter
20:29:15
phoe
namely, the other assumes that the datum that optionally follows the macro is a readable (under *READ-SUPPRESS*) Lisp expression
20:29:50
phoe
and therefore portable code must only use such data, even though stuff like #G1((( is technically legal Lisp
20:30:36
phoe
or rather, it would mandate that code that uses such unusual reader macro data must NOT be read under *READ-SUPPRESS* which in turn means that reader conditionals cannot be combined with such reader macros
20:31:21
phoe
in other words, code that uses such unusual reader macros must be split into separate files that are loaded conditionally on implementations or in the presence of systems that support those reader macros.
20:31:48
phoe
I think that would be enough to satisfy that constraint - isolate #G1((( into its own file and NEVER mix it with *READ-SUPPRESS*.
21:09:44
jackdaniel
I was saying that you can't require signalling error under such circumstances, then I've mentioned what sounds like the most reasonable implementation
21:10:19
jackdaniel
I tend to agree with what Bike said -- consequences are here undefined *especially* that the paragraph in the spec mentions that it should accept even "invalid syntax"
21:11:16
jackdaniel
so I'm OK with commenting out the test with a brief comment why it is not part of the package (pull requests welcome :)
21:13:33
phoe
If anyone has any objections, please throw them at me or the issue at gitlab.clnet/ansi-test
21:13:40
fiddlerwoaroof
Would it make sense to move this sort of test to a separate "interoperability" set of tests
21:14:19
fiddlerwoaroof
It'd be useful to tabulate these testcases and show how each implementation implements this feature
21:18:08
phoe
jackdaniel: would it make sense to merge test suites for package-local nicknames into beyond-ansi?
4:57:03
tourjin
on windows10, windowsemacs with slime, if i run this it creates output file on c:\users\choij not on d:\home where can I check the settings for default file creation?
4:59:22
no-defun-allowed
Probably where you started your Lisp implementation. You may want merge-pathnames and user-homedir-pathname to ensure you are writing to your home directory.
4:59:49
no-defun-allowed
e.g (with-open-file (stream (merge-pathnames "testfile.txt" (user-homedir-pathname)) ...) ...)
5:00:50
no-defun-allowed
Josh_2: I don't wear glasses surprisingly, but if it ticks you off, I can polish them all day.
5:09:06
tourjin
no-defun-allowed , your tip worked fine . thanks. ck_ your tip shows #P"c:/Users/choij". is it determined by emacs? or by slime? how can I change it permanantly to d:/home?
5:09:41
no-defun-allowed
The CLHS page states "An implementation-dependent pathname, typically in the working directory that was current when Common Lisp was started up."