freenode/#lisp - IRC Chatlog
Search
10:51:24
jmercouris
Ok, so yesterday we established that we can't do FFI to C++ because the ABI is not standard in C++ world
11:43:06
no-defun-allowed
Standardise the C++ ABI? That would be half-polite of the – well, sure. No good if you want to use Qt though.
11:45:03
beach
But I will be quiet now because I am not adding anything new that I haven't already said.
11:48:53
no-defun-allowed
I agree life is much simpler if you are able to avoid FFI completely or avoid it as much as possible, or if you grow vegetables; but there may be reasons one wants to use Qt.
11:51:34
no-defun-allowed
My favourite reason is to use the Qt WebEngine to load documents off a CL server, and implement the UI in HTML/CSS/JavaScript. Then use your favourite C->JavaScript transpiler to run Qt in the browser, and repeat until you get bored.
11:55:24
no-defun-allowed
But seriously, it may be less effort per individual to bite the bullet and work with Qt than to test/port/develop/&c a CL toolkit, even though all the time taken to accomodate for foreign code would probably add up to more than enough required to make that toolkit work.
13:18:29
beach
I am convinced we represent an instance of the prisoner's dilemma. The optimal solution is to collaborate to create Common Lisp solutions to our collective software needs, but individually, it is better to take the FFI route.
13:18:31
beach
As a result, everybody pays the price of increased development and maintenance burden. Except those who can and do choose to work on something that can be done entirely in Common Lisp.
13:22:09
beach
FFI solutions require a different kind of maintenance, namely catching up with moving targets, like Qt versions, LLVM versions, Gnome versions.
13:28:44
Xach
I wrote pure lisp stuff for gifs and pngs because I was frightened by the thought of foreign code crashing my long-running server.
13:31:09
_death
I didn't write OpenCV in pure lisp because it would require tens of thousands of man hours or more..
13:33:11
beach
Anyway, having identified the reason for the state of things, I now understand much better what is going on, and I know that it would usually be futile to try to influence someone's choice.
13:33:45
_death
beach: but you could also flip it, so that the utilitarian solution is to use the language where most effort has already gone to, and the choosing Lisp is the egoistic individual choice
13:36:06
beach
That might have been true if the "utilitarian solution" were effortless or nearly so. The many questions and problems related to FFI solutions that are discussed here suggest otherwise.
13:41:26
_death
there is reason, but it is an egoistic reason.. I like CL better than C++, so I don't mind putting effort into making the rest of the world work with CL.. only a small group of people may benefit from this choice
13:41:52
beach
_death: You don't need an excuse to choose the FFI solution ("tens of thousands of man hours or more"). Like I said, it is perfectly clear to me now why this solution is optimal to the individual.
13:45:40
beach
_death: I think that is a very good idea, i.e. create a Common Lisp "wrapper" for an existing foreign library. However, what I usually observe is a badly documented wrapper library that requires the user to understand both the foreign library, the foreign language it is written in, *and* the undocumented code of the wrapper.
13:45:41
beach
I am not saying this is the case with yours of course. I haven't looked at it at all.
13:47:31
_death
beach: I definitely agree with this observation.. I think it's difficult to design good interfaces, and the Lisp standard is a high one.. it's much easier to ape the foreign library's existing interface.. in the past I did that, but also did the harder work at times
13:49:34
_death
beach: it also has to do with means and ends.. if utilization of this library is just a means to an urgent end, then it's likely the initial solution would involve less thought about the interface
13:50:22
beach
Yes, but then it is not really usable by a wide audience. And we are back to the prisoner's dilemma.
15:53:23
Shinmera
Speaking of UI, though, here's another brief demo for Alloy I put together today https://youtu.be/oLRBZrdzJS0
16:07:38
Kabriel
Shinmera: that looks like plotting. Excuse my ignorance, but is this part of McCLIM or based on it, or something else?
18:15:33
phoe
I have been working with MIT LOOP for a moment now and I am somewhat puzzled at https://gitlab.common-lisp.net/ansi-test/ansi-test/commit/60cb6583156fa625925a24f16153da44a59e6371
18:16:52
phoe
does anyone on #lisp know which part of the standard specifies the rationale for these tests? In particular, that X is not supposed to be set anywhere outside (INTEGER 1 5)?
18:18:03
pfdietz
"In an iteration control clause, the for or as construct causes termination when the supplied limit is reached. That is, iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
18:19:16
White_Flame
phoe: the definition of stepping says that the variable itself is updated in anticipation for the next iteration
18:19:33
White_Flame
by that, X would legitimately be 6, and the declaration of (integer 1 5) is wrong
18:20:00
Bike
"For these clauses, iteration terminates when a local variable reaches some supplied value or when some other loop clause terminates iteration." is in 6.1.2.1, too
18:20:18
specbot
The for-as-arithmetic subclause: http://www.lispworks.com/reference/HyperSpec/Body/06_abaa.htm
18:22:17
White_Flame
"is reached" is problematic with those examples, if taken to be "is equal to". The examples clearly show overshooting the target "to 10" value, not reaching it exactly
18:23:06
White_Flame
the first paragraph does say that the variable is stepped after each iteration, with no exemption for the final iteration
18:24:39
White_Flame
in 6.1.2.1.1: (let ((x 1)) (loop for i from x by (incf x) to 10 collect i)) => (1 3 5 7 9)
18:26:15
pjb
(let ((x 1)) (loop for i from x by (incf x) to 10 collect i into is finally (return (values is i)))) #| --> (1 3 5 7 9) ; 11 |#
18:27:23
phoe
(loop for i from 1 by 2 to 10 collect i into is finally (return (values is i))) is equivalent
18:27:25
pjb
I cannot find where it says that the loop variables scope covers the finally expressions…
18:27:35
White_Flame
to my reading of the spec, regarding the definition of stepping (that it affects the variable itself), and that stepping happens at the end of each iteration, yes the test is wrong
18:28:54
White_Flame
within pretty much every LOOP clause but FINALLY, the variable is in (integer 1 5), but it does go past that after the final iteration
18:29:50
White_Flame
if each loop clause had (locally (declare ((integer 1 5) x)) ...) that would be another thing
18:30:32
phoe
pjb: clhs 6.1.7.2 has some info, http://www.lispworks.com/documentation/HyperSpec/Body/06_agb.htm
18:30:47
phoe
and the epilogue is described in 6.1.1.4 at http://www.lispworks.com/documentation/HyperSpec/Body/06_aad.htm
18:31:13
phoe
LOOP is expanded into bindings and block and tagbody, and inside this there is a prologue, body, and epilogue
18:31:25
phoe
this means that the epilogue is inside the bindings, which implies that the variables are accessible
18:34:03
pjb
Note that 6.1.2.1 says that: Stepping assignments are made in the loop body BEFORE any other forms are evaluated in the body. and Stepping assignments are made in the loop body BEFORE any other forms are evaluated in the body.
18:34:06
phoe
6.1.2.1.1 states "iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
18:34:57
phoe
so if I loop for x below/to most-positive-fixnum, then x can be set to most-positive-fixnum but must never exceed it
18:35:31
pjb
Therefore one could expect (if (= x last) (loop-finish) (incf x)) and x being 5 in the epilog. Of course, this would require x to be initialized to -1, so the type would still be broken.
18:36:23
White_Flame
pjb: but again, there are examples where it overshoots and never exactly matches the "to" clause, yet still halts
18:37:06
White_Flame
I don't think the tests happen anywhere outside the clauses such as for/while/until
18:37:08
jackdaniel
one could argue, that do doesn't have such problems thanks to intelligible specification ;) good night and good luck
18:38:25
pjb
White_Flame: But we can test: (if (<= x (- last increment)) (incf x increment) (loop-finish))
18:39:08
pjb
the spec doesn't specify the order between the test and the step. (incf x increment) is my step.
18:44:38
phoe
what if you test after the last iteration but before the next iteration - is this permitted by the spec?
18:45:13
phoe
because then you could check that the next X is going to pass the boundary, and do not pass GO, do not collect $200, go straight to epilogue
18:46:51
pjb
so you can test first, and not execute the body. Then you must not increment. This shows that x should never be 6.
18:50:54
phoe
do we have a conclusion now, because my brain is fuzzy after discussing this on #ccl #ecl and now here
18:52:44
phoe
pfdietz: as for LOOP.1.41, I've created https://gitlab.common-lisp.net/ansi-test/ansi-test/issues/14 since this one seems somewhat less troubling
18:55:29
White_Flame
pjb: semantically, in order to get the result I think you want, you'd have to test the current value (in case its equal), test the hypothetical value that it would take on if it were stepped, and then step if that hypothetical value was still in range
18:56:08
White_Flame
it all comes down to what it means by "reached" when you're talking about overshooting a threshold
19:00:10
White_Flame
(the threshold being tripped is exclusive of equalling 10, I guess that's confusing wording from me)
19:00:26
phoe
if the threshold permits another iteration on equality, we then iterate once more and terminate
19:00:57
White_Flame
and a related question is does the test occur against a hypotehtical value, or against the stepped value of the variable itself
19:03:54
phoe
so the question is, is the variable in FINALLY supposed to ever overshoot the threshold
19:12:56
phoe
going away from the orthodox and going for the practical now - if it does not overshoot, then it makes sense to iterate e.g. on fixnums
19:14:05
phoe
and that could both be unsafe due to possible overflows and slow if LOOP must expect that a fixnum variable cannot be expected to be a fixnum
19:15:27
phoe
19:34 < phoe> 6.1.2.1.1 states "iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
19:15:35
pfdietz
I would have specified it this way: the variable visible in the body and the finally is bound to successive values in the indicated range, but is never incremented. Its value is incremented, but that is not stored into the variable before the test for termination.
19:15:52
phoe
19:34 < phoe> so if I loop for x below/to most-positive-fixnum, then x can be set to most-positive-fixnum but must never exceed it
19:16:38
White_Flame
however, it's stepped before the iteration. In "to 10", when it "is stepped to the .. inclusive limit supplied by form2", the iteration is still supposed to run
19:16:50
phoe
pfdietz: if it is incremented, then you could run into type issues as well - if you iterate on a fixnum variable, then the hidden variable must be an integer
19:18:06
phoe
so either after the body but before jumping to the beginning for the next iteration, or between the beginning of the iteration and the stepping?
19:18:34
White_Flame
that's what I replied to pjb with: You'd need to test existing, test the would-be stepped value, and then save the increment as 3 separate steps
19:19:22
phoe
so we would nonetheless need to typecheck in order to test the would-be stepped value?...
19:19:25
pfdietz
phoe: that is an implementation detail. One could test before adding to it, converting (<= (+ x step) limit) to (<= x (- limit step))
19:21:17
phoe
White_Flame: but anyway, if that is what is required to make it correct, then why can't we do this?
19:23:04
White_Flame
at least, with everything the spec says about it, I think it contradicts the least to overshoot it
19:25:15
phoe
so if the spec contradicts itself, I could assume that the implementations are free to do whatever they can and therefore the behaviour is undefined
19:31:33
beach
note to self, specify the behavior of the for-as-arithmetic subclause behavior better in WSCL.
19:39:55
Posterdati
Posterdati: the c-toolchain code cannot get the value for $CC resulting in using cc which is NOT gcc
20:01:01
Kabriel
The range is exclusive if form3 increases or decreases var to the value of form2 without reaching that value; the loop keywords below and above provide exclusive limits. An inclusive limit allows var to attain the value of form2; to, downto, and upto provide inclusive limits.
20:02:03
Kabriel
but I think most implementations do it wrong; see https://youtu.be/ZJr81DtSwUc?t=204
20:06:11
Kabriel
I think test 1.40 is very similar, except it is testing the inclusive ranges (to, downto, upto, etc), where the value of var should take on the value of form2.
20:06:39
Kabriel
In SBCL it exceeds it, and I suspect this is the case in most implementations using a derivative of the MIT loop.
20:16:03
White_Flame
yeah, that's part of the conflicting part. Does that talk about the value of the variable visible within the body?
20:16:26
White_Flame
or does that constraint extend out to the full lifecycle of the epilogue and such?
20:17:40
White_Flame
and teh sentence before that one is also a very ambiguous one "That is, iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
20:18:32
White_Flame
especially if you take the inclusive forms, that sentence makes no sense regarding the intent
20:25:52
White_Flame
it also doesn't help that "iteration" doesn't seem to be explicitly defined, specifically with regards to the fenceposting of "iteration continues until"
20:30:31
Kabriel
White_Flame: I see your point that it is ambiguous. I tend to think of "iteration" as the body (i.e. execution clauses). I would like to say that the epilogue should be included in that, too, but the terms aren't defined.
20:31:38
White_Flame
my main point derives from a bottom-up reading of the mechanics and stepping, which would imply overshoot. The top-down statements like this might be taken to imply no overshoot.
20:43:07
Kabriel
White_Flame: I definitely agree from a mechanics standpoint; the test would always be done after the stepping of var, so the last value of var will not satisfy the test (i.e. in the epiloge). To do otherwise requires extra stuff.
20:44:21
Kabriel
I was thinking about this last week, which is how I stumbled on beach's ELS presentation.
20:44:34
White_Flame
the glossary entry for step as well: "to assign the variable a new value at the end of an iteration, in preparation for a new iteration."
20:44:50
pfdietz
I have no strong emotional attachment to these tests. I've conditionalized tests for lesser reason.
20:45:45
White_Flame
(which again begs what an "iteration" even means in that context. One time around the LOOP body? One pass through that clause?)
20:45:49
pfdietz
At the end of the day, it's up to the implementers to make their decisions. They should, I think, document how they interpret this part of the standard.
20:45:55
Kabriel
Me either. I am interested to hear what beach has to say, since he implemented sicl loop facility differently.
20:47:33
phoe
even if consistency means that we all agree for this to be undefined and therefore impossible to depend on
20:49:12
aeth
All of this talk of iteration makes me wonder why CL hasn't added iterators as an extension yet... or has it? Is that part of that extensible sequences thing that no one uses?
20:49:54
aeth
In particular, though, it seems like it would be useful for using the implementation's sort algorithm
20:50:20
dlowe
one of my someday-maybe projects has always been to make an SERIES implementation that actually integrates gracefully into sbcl
20:51:40
pfdietz
I know some people who prefer it to LOOP. I'm annoyed it breaks Waters' COVER package, but that's mostly COVER's fault.
20:53:18
aeth
pfdietz: I want to like ITERATE, but it's not LOOP-compatible enough so I'm going to eventually write a DO-LOOP that at its base is basically just LOOP with parentheses added around the clauses and keywords required (rather than accepting any symbol package)
20:55:37
aeth
pfdietz: Does ITERATE support sorting? #'sort is pretty weak. It doesn't even accept start and end points.
21:00:22
aeth
pfdietz: An iteration macro could support sorting in a range, at least on vectors, perhaps even composing with the other functionality to determine the start and end range instead of having to know the indices in advance... and combined with iterators, it would be able to sort arbitrary things, not just the built in (whole) sequences that #'sort does.
21:00:37
aeth
Slightly unrelated to pure iteration, but they usually do have things like sum, anyway.
21:01:55
pfdietz
That doesn't really seem to be what ITERATE is about. I suppose merging of two generators could be an interesting capability.
21:02:45
aeth
Well, maybe I am looking at it differently, but to me it seems like the natural extension in functionality past things like summation.
21:04:01
aeth
Possibly. Perhaps the correct way to look at things is (1) providing the primitives for vector and list (and arbitrary iterator) sort and (2) providing the extensibility so that it can be added in
21:04:44
pfdietz
Like making a header cons cell with tail pointer for RPLACD accumulation of a list, and returning the actual head at the end.
21:05:53
phoe
pfdietz: should we comment out those LOOP tests with the rationale that the spec is contradictory and the behaviour is undefined, then?
21:06:12
phoe
I'd suggest commenting them out, because someone in the future might notice this and reignite the religious dispute
21:14:36
pfdietz
When a test is defined, notes can be attached. The function RT:DISABLE-NOTE allows tests with that note to be disabled and not run by RT:DO-TESTS
21:21:13
phoe
https://gitlab.common-lisp.net/ansi-test/ansi-test/commits/master lists some recent activity
21:21:39
no-defun-allowed
Just a little exclamation of disbelief: does GitHub seriously not notify you when someone creates an issue or PR?
21:22:22
no-defun-allowed
I pinged the maintainer (wrote @foo) and they merged my changes to heroku-buildpack-cl.
21:23:17
phoe
check your notification settings and spam folders and whether you didn't un-watch the issue after making it
21:23:50
no-defun-allowed
All on their end. I think I disabled emails for everything, but I should still get it in GitHub.
21:24:54
no-defun-allowed
There's individual check boxes for "email" and "web" notifications. Weird.
21:30:04
sjl
pfdietz: aeth: thanks for nerd-sniping me http://paste.stevelosh.com/041a96442fa3f41de3b78f1b15a2d6c90cb59c92