freenode/#lisp - IRC Chatlog
Search
3:53:03
Fare
or did you then have an asdf more recent than those earlier versions of uiop, say asdf 3.2.1?
3:56:28
Zhivago
You could have an account which ran the interpreter as its shell. This would allow access via telnet or ssp. It would be simple, but perhaps unwise.
3:57:28
turkja
or maybe play with things like socat? but i don't know how well these things work readline etc.
3:58:20
beach
vutral: Why does it have to be an interpreter. Are you particularly attached to bad performance? Also, insisting that it is an interpreter will limit the number of Common Lisp implementations available to you.
4:00:54
vutral
i guess i should write some kind of tcp server in lisp which evaluates input and returns the result
4:02:45
Fare
vutral: you can make SLIME servers available on a port available through ssh redirection
4:03:28
Fare
I knew someone who did that in a distributed system --- plenty of slaves listening to orders via SWANK
4:05:12
jmercouris
Anything connected to the internet is inherently exposing all of its resources, but I agree, take precautions
4:23:09
nixfreak
Hello I am looking for away to create "hot folders" like a workflow, where I can drop files in a folder and it goes through a workflow
4:41:16
beach
nixfreak: If you are going to make something like that compatible with the underlying operating system, i.e., use OS directories for the folders and OS files for the files, then I suspect you won't get much help from Common Lisp compared to other languages.
4:42:25
loke
nixfreak: There are libraries that hook into the file notification infrastructure of your operating system
4:43:05
loke
Since this meahcnism is different in all different operating systems, I don't knwo which one is the best one.
4:54:12
turkja
hey still about SLIME... i wonder if there are good libraries for python or other language to connect to slime server?
4:56:00
turkja
well i don't know about SLIME protocol, maybe it's simple enough to connect with raw tcp and start throwing expressions?
5:02:13
Zhivago
Having unrestricted communication is probably not a good idea for purposes of security.
5:03:18
Zhivago
They also require the caller to be able to print things as expected for that lisp implementation.
5:03:41
turkja
i don't know, i didn't see what exactly vutral is trying to do... but to his initial question, i think "socat" can do the job in a dirty way
5:07:39
Fare
oh, I misread Xach's blog as meaning there was brokenness and e.g. an infinite loop. But reproducing the bug, I see that's it's the known behavior of asdf < 3.3.0 and has nothing to do with uiop.
5:16:21
mfiano
Hello all. I found a nasty bug in the fast-io library. I wrote a little test case to reproduce it, but I'm having a hard time figuring out why it occurs.
5:18:17
mfiano
This is supposed to behave similarly to cl:read-sequence, except when I read a single byte from a stream, it reports that it read the entire stream's contents. this does not occur when reading from a vector. https://github.com/rpav/fast-io/blob/master/src/io.lisp#L142-L163
5:25:31
Zhivago
But there's no documentation, so it's not clear what it ought to be doing in the first place.
5:26:08
mfiano
indeed. there lies my problem. sad part is this is being used by quite a few projects so i'm surprised it hasn't been detected
5:29:17
mfiano
I'm using a third party library that uses fast-io, and it doesn't depend on a C library
5:30:50
mfiano
Also the author moved away from lisp, so I'd have to become familiar enough with it to fork and maintain it
5:41:07
mfiano
I maintain enough libraries, and if I were to maintain this, I'd rewrite it from scratch. The code is a bit...obtuse
5:52:31
beach
thebardian: Are you just planning to learn Common Lisp for kicks, or do you have any particular projects in mind?
6:11:49
Fare
mfiano: this is how maintainers are made: someone who cares enough to complain about some software... https://fare.livejournal.com/149264.html
8:25:27
scymtym
Fare: re UIOP 3.3.0 problem: would upgrading SBCL's bundled ASDF (and UIOP) to 3.3.0 also cause this problem?
11:02:34
Xach
scymtym: I think the problem occurs for current sbcl and new uiop. the explanation on asdf-devel does not match my experience, though.
11:05:43
Xach
(the explanation is that this happens because there is no uiop.asd, but there is, and that it has happened since 3.2.0, but i don't see that behavior in 3.2.1 when i test)
11:39:54
scymtym
Xach: thank you. so upgrading would likely not only not cause the problem but instead prevent it in some instances (for SBCL users) since the combination of old ASDF and new UIOP would become impossible?
12:50:12
jmercouris
what's the difference between (require :some-package) and (require "some-package")
12:51:58
mfiano
jmercouris: nothing, they are both string designators. However, you probably don't want to be using REQUIRE anyway
12:52:35
jackdaniel
jmercouris: there is a difference, because as spec says, they are compared with string=
12:52:57
jackdaniel
and :some-package designator is "SOME-PACKAGE", and it is not the same as "some-package"
12:57:59
jackdaniel
fwiw asdf plugs into implementation machinery when it can, so (require "foo") should be equivalent to (asdf:load-system "foo") - if implementation provides require hooks
13:00:58
jackdaniel
but used string provided by jmercouris, didn't think about the string content tbh
13:01:45
jackdaniel
and I meant module in explanation, because that's what require/provide are about
13:02:47
Fare
yeah, and CL modules seem to standardize on symbol names, that are upcased, where asdf standardizes on canonical system names, that are downcased. Hence suffering at the interface between the two.
13:03:24
jackdaniel
Fare: is ASDF plugging into require machinery officially supported? or it just happens to be implemented?
13:04:23
Fare
jackdaniel, currently, it seems to be defined for all sizable free software implementations, and only them.
13:04:24
jackdaniel
all implementations must support case-sensitive modules, otherwise that would be non-conformant
13:04:45
Fare
but I personally think it's a bad idea and a relic of the past, that I would gladly do away with.
13:05:07
Fare
jackdaniel, they "support" it, but do they actually use it for the modules they provide?
13:08:02
Fare
in any way, I'd like to discourage use of :require for anything than implementation-provided modules.
13:08:33
Xach
scymtym: it looks like the UIOP problem does not occur for asdf 3.3.0 and uiop 3.3.0 together, but it does occur for asdf 3.1.5 (sbcl's provided version) and uiop 3.3.0.
13:25:51
scymtym
Fare: Xach: thanks. so upgrading SBCL's bundled ASDF and UIOP to 3.3.0 (as planned) seems like the way to go
13:27:08
Xach
scymtym: It avoids this specific issue. I would be interested in more testing for other issues.
13:27:22
Fare
I don't see anything special about uiop 3.3.0 that make it differ from 3.2.1 buildwise
13:29:02
scymtym
Xach: the plan is to apply an already-prepared and looked-at-by-fare patch directly after the upcoming release. that way, we have about a month for testing with 3.3.0 before the next release
13:29:34
Fare
also, the behavior of sometimes loading defsystem-depends-on dependencies too many times is expected from asdf 3.2.1 and earlier (or not enough times, in an incremental build).
13:30:27
Fare
scymtym, I don't know if/when rpgoldman will have time to release 3.3.1, but I recommend 3.3.0.1 over 3.3.0 because of a bug fix.
13:38:31
Xach
With stock SBCL, UIOP 3.3.0 increases my build time by a factor of 6 and breaks things previously unbroken, due to package variance warnings.
13:40:27
scymtym
Xach: Fare: https://github.com/scymtym/sbcl/tree/asdf-3.3.0.1 (changes: https://github.com/scymtym/sbcl/compare/asdf-3.3.0.1~5...asdf-3.3.0.1 )
13:59:05
Fare
Xach: I still don't see what the code differences in UIOP can possibly bring that make a difference when the uiop.asd hasn't changed.
14:09:06
Fare
I made a backward incompatible change in representation in stamp< thinking that "nobody uses it except ASDF". I failed to take into account using a newer UIOP with an older ASDF.
14:13:55
mfiano
I would argue that programming is quite easy. Software engineering is another story.
14:15:18
beach
Is it a specialty of #lisp to argue about concepts that are undefined or ill defined, or does that occur in other channels as well?
14:16:28
Shinmera
It is a speciality of lisp that people hardly don't often get steamed, though. Or at least that's my perception.
14:19:29
beach
I can get very angry, but I think it is counterproductive to let it show in utterings.
14:20:43
mfiano
Xach, Fare: What is :NET.DIDIERVERNA.ASDF-FLV? Apparently fiveam doesn't load because of some asdf-flv error
14:29:12
Fare
any suggestions for a better name than stamp< or timestamp< ? what the function does is comparing two real numbers where t means -infinity and nil means +infinity (previously, the opposite)
14:30:56
beach
asarch: That depends on your definition of "object oriented". But this channel is dedicated to Common Lisp, so people here might not know.
14:31:30
beach
asarch: Common Lisp on the other hand, has one of the most sophisticated object systems around.
14:34:23
Fare
asarch, "OO" is a bad, badly defined, package deal. Unbundle the package, and you'll see which parts Emacs has or doesn't have.
14:35:23
Shinmera
Apparently, yes. https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.alangref/idalangref_eieio_instrs.htm
14:43:42
jackdaniel
hm, am I wrong here or file-local-variables name is a bit confusing, because it's about bindings not the variables?
14:45:56
jackdaniel
imo UIOP shouldn't be bundled with ASDF (regarding the issue) – it is unreasonable to expect everybody to ship build system at some specific version if library is used. at price of slight increase of memory footprint bundled UIOP could reside in some internal package, like ASDF.INTERNAL.UIOP
14:46:12
jdz
Fare: whatever name you choose I'd vote for the name to include the direction character (i.e., < or >), otherwise it will be unclear which direction the comparison is being made.
14:48:14
Shinmera
I'm used to </<= so much to the point where when I encounter >/>= in algorithms or papers I get confused for a bit.
14:49:01
jdz
I usually get very confused when I see UNLESS, it also does not have to come with the use of AND or OR.
14:49:10
pjb
Furthermore, > and >= are obviously slower, since they're defined as (defun > (&rest args) (not (apply (function <=) args))) and (defun >= (&rest args) (not (apply (function <) args)))
14:49:51
Shinmera
Nah, I think unless is harder to parse because it is an inversion and people think better in terms of affirmatives than negatives.
14:53:21
Fare
no, the situation with UIOP is fine, as long as I don't fuckup and introduce a backward incompatibility
14:54:22
Shinmera
Can't blame you for not having thought of the possibility of ASDF and UIOP being of different versions, since they're treated as one project.
14:55:07
Fare
no, no, I should have known. UIOP was detached specifically so it could be used without ASDF.
14:55:41
Fare
I just forgot about how strict the "no backward incompatibility" requirement was when I made that change.
14:56:10
Fare
"who cares about a slight change in representation when literally no one uses this function except me?"
14:56:43
Fare
(no one in QL was using it, and before 3.2.0 there was only one comment for the entire set of functions)
14:59:18
Fare
OK, renaming stampFOO to timestampFOO in uiop/utility.lisp (mutatis mutandis in asdf) seems to do the trick, including with QL (I reproduced Xach's test case).
15:11:57
d4ryus
yeah there should be a rule that everyone has to use 'affirmative' names instead of 'negatives'. especially on c DEFINEs. reading stuff like '#ifndef NOT_FOR_X' makes me stop for several seconds...