freenode/#clasp - IRC Chatlog
Search
13:26:52
kpoeck
So I am tempted the try the SICL-Loop to see whether this particular issue is solved there
13:27:39
kpoeck
In parallel I will compare ecl/clasp loop against sbcl/ccl loop, perhaps there is an easy fix
13:30:04
drmeister
I don't anticipate any problems incorporating sicl's loop in clasp - just toss it on the pile of sicl we compile in cclasp.
13:35:19
kpoeck
I'f be interested in the result of (macroexpand '(LOOP FOR X FROM 1 to 4.0 COLLECT X))
13:40:33
drmeister
The stackmaps stuff appears to work fine now on macOS. I haven't tested linux yet.
13:42:51
beach
kpoeck: As I recall, there were a few ANSI tests that were wrong, but I don't remember which ones.
13:48:33
beach
As I recall, I tried to follow the specification very precisely, so SICL LOOP may not pass those tests.
13:50:56
kpoeck
So I will try to report them as issues in the ansi-test repository (advise from jackdaniel)
13:55:39
jackdaniel
kpoeck: you mean that ansi-tests has tests which check implementation to conform with undefined behavior? I'm not sure I follow
13:58:42
jackdaniel
or do you mean, that you assume that undefined behavior should result in some kind of error? because if the latter then it is not a matter of conformance but being strict (implementation is free to define behavior which is undefined in a spec to do something sensible and it is still conforming)
14:42:16
kpoeck
I can easily change this in clasp, but I haven't found a place where the order is specified in the ansi
14:43:58
kpoeck
Should I have overlooked something, than we have to change clasp to follow the specification
14:46:00
pfdietz
(I have a copy of ansi-test here; I assume the test names weren't changed in your version)
14:47:10
kpoeck
this one: https://gitlab.common-lisp.net/kpoeck/ansi-test/blob/feature-clasp-changes/cons/pushnew.lsp#L137
14:47:17
Bike
i thought the standard mandated all the standard macros evaluate left to right, but i don't know a reference
14:48:22
pfdietz
"For each of the ``read-modify-write'' operators in the next figure, and for any additional macros defined by the programmer using define-modify-macro, an exception is made to the normal rule of left-to-right evaluation of arguments. Evaluation of argument forms occurs in left-to-right order, with the exception that for the place argument, the actual read of the ``old value'' from that place happens after all of the argument form
14:48:22
pfdietz
evaluations, and just before a ``new value'' is computed and written back into the place. "
14:53:48
jackdaniel
I have some wip with McCLIM interface for running ansi-tests (so instead of sh you'd run tests against clasp from i.e sbcl)
15:03:40
drmeister
Here's an interesting application of machine learning - autocompletion. https://tabnine.com/
15:05:43
Bike
kpoeck: do you mean the adjoin compiler macro is evaluating things in the wrong order?
15:18:37
beach
Bike: It can happen easily. When I imagined writing compiler macros for the sequence functions, I found out that it is extremely hard to preserve evaluation order.
15:19:17
pfdietz
One thing I don't know if it's specified is what happens if the same keyword argument occurs more than once in a macro form. Is only the first one evaluated, or both?
15:20:23
pfdietz
In keyword arguments to ordinary functions, they are both evaluated, but only the first value is used.
15:21:47
pfdietz
Probably not important though. The semantics for ordinary functions is there so you can override keyword arguments using APPLY.
15:24:14
pfdietz
On the other hand, a COMPILER macro had better preserve the behavior of the function it's replacing.
15:24:46
pfdietz
And the function, if invoked as a function, would evaluate those redundant keyword args.
15:26:32
pfdietz
:test and :test-not is a special case. IIRC it's unspecified what happens if you include both.
15:27:56
pfdietz
"The consequences are unspecified if both a :test and a :test-not argument are supplied in the same call to F. "
15:28:50
beach
Then the compiler macro must arrange for all of them to be evaluated, and in the right order.
15:41:40
beach
So a compiler macro without a &rest parameter for a function that takes keyword parameters is necessarily incorrect.
17:00:33
Bike
Right now I'm redoing the implementation of the argument parsing code (i.e. the translation of enter-instruction), which naturally is pretty complex
18:44:26
Bike
drmeister: just remembered something- while you're messing with discriminators it might be nice to make *current-function-description* or something available so argument counte rrors can be nicer
18:50:26
drmeister
Do you mean to pass it through to the functions that report the argument count errors? That sounds like a good idea and it's pretty straightforward.
18:53:15
Bike
yeah. right now we use *gv-current-function-name* which i think probably shouldn't even exist
18:56:22
drmeister
Right - we should pass in the pointer to the function-description and the pointer to the constants vector. Those two things will give us everything we need.
18:56:44
drmeister
Ah - we have to solve the problem of setting up the generic function name in the function-description. Right now it is LAMBDA
19:25:54
drmeister
shiho: That makes sense - but now that we have a clear plan, I'd like to check it with scymtym
22:56:28
scymtym
drmeister: yes (or a thing that should replace the left node if your tree construction works without mutation)
22:57:37
drmeister
We had another question - another method came up that wasn't make-node, resolve or finish-????
22:59:01
scymtym
for nodes, it's normally roughly like (finish-node (reduce #'relate relations :initial-value (make-node kind initargs)))
22:59:14
drmeister
We will have to keep putting in dump-module statements until we see where the functions disappear.
23:19:14
drmeister
We will (1) turn your computer off and then on again. (2) refresh llvm. (3) distclean (4) rebuild.
23:19:51
drmeister
Especially because it said the one pointer was <bad> or <undef> (I don't recall exactly). That was really weird.