freenode/#clasp - IRC Chatlog
Search
15:55:45
drmeister
I made a few more commits to dev that fixed some problems - it should build now - it's building on Shiho's system
15:56:37
drmeister
Shinmera: I can see linut - thank you. It's building the latest now - finally we will get some timing data.
15:57:48
beach
Bike: I am again considering what to do when the compiler detects a fatal error, like a malformed special form or an incorrect number of arguments to a standard function. It may seem reasonable to compile a call to error, but then, can we be sure that forms that would normally follow the fatal form would be compiled normally?
15:57:49
beach
I suppose the answer is "yes", since we don't use the fact that error does not return until much later in the compilation process. I am sorry if this is a silly question. It is late in the day, and I am too tired to think it through myself.
15:59:20
beach
If so, we should be able to construct a call to ERROR such that the sub-forms of the fatal form are compiled normally as much as possible.
16:00:11
beach
This tactic may fail, of course, since we can't be entirely sure why the fatal form was incorrect, so we don't know for sure what sub-expressions are supposed to be forms to compile.
16:01:06
Bike
maybe i don't follow. "the forms that normally follow the fatal form" meaning what? Like, if we have (progn (let 4) (car x)) the (car x) is following?
16:04:00
beach
We could build something like (error "Attempt to execute a form compiled with an error: ~s~*" 'form (progn sub-form1 sub-form2 ... sub-formn))
16:05:40
Bike
i suspect that a lot of the time, or even most, there would be spurious (to the programmer) errors if compilation continues. like, if we have (progn (defun foo) (foo ...)) the defun would be an error, and then there'd be "undefined function" warnings, which are just clutter after the initial problem
16:05:42
beach
So if we have (progn (let 4 f1 f2 f3) (car x)) we would get (progn (error "..." '(let 4 f1 f2 f3) (progn f1 f2 f3)) (car x))
16:06:49
beach
I see what you are saying. I need to consider the consequences to the user experience of Second Climacs of excluding the subforms.
16:07:23
Bike
i think i've run into this in sbcl, though i don't have a real example off the top of my head
16:07:47
Bike
for the bad let, i'd imagine that f1 f2 and f3 might refer to bindings that the programmer meant to establish
16:07:51
beach
I guess it would not be too bad. The user will fix up the incorrect expression and then immediately get additional problems highlighted.
16:09:38
beach
Well, what I attempted so far was to try to preserve any correct bindings. But the code for doing that is very bulky, so if I can get away with just signaling the problem and a simple recovery strategy, that would make my life easier.
16:10:46
beach
So, if we had (let ((x 10) 234 (z 20)) ... x ... y), I would fix it up to (let ((x 10) generated-symbol (z 20)) ... x ... y)
16:15:53
beach
Also, nothing prevents us from proposing several restarts. One that does the simple thing and another that tries something more sophisticated.
16:15:58
Bike
is it? could you not just signal a bad-binding condition as you iterate through the list, and offer a use restart?
16:19:42
beach
Sure. So in order to proceed, I suggest doing the simple thing you suggest, and then, from experience with the editor, see whether there are cases that occur frequently, and if so, improve the code later.
16:22:31
beach
Heh, users of Second Climacs should definitely be encouraged to use a mode where parentheses are kept balanced, or else there will be some very interesting mistakes highlighted.
16:24:21
beach
Suppose not, then for example: (let <point-is-here> (format t "hello")), so format is taken to be a binding, T as well, but that is not allowed, and "hello" is not allowed as well.
16:30:59
beach
It is less important in the normal compiler, because programmers don't submit just any old crap to be compiled. But in the editor, there can be some arbitrary half-finished forms.
16:34:58
beach
In fact, now that I think about it, it is probably less important to attempt to recover in the editor, because the error will be corrected immediately and the next one will be signaled. It is more important for "batch" compilation, because the programmer would want as many errors to be corrected before the next compilation is attempted.
16:44:34
Bike
looks like defun-inline-hook is just load time, so if you compile-file inline-prep it won't be available for inlining
16:44:36
drmeister
defun-inline-hook is defined in inline-prep.lisp - I don't know why inline.lisp would think it is unbound
16:48:05
shiho
drmeister, mine says "Build aborted. Received condition of type: SIMPLE-PROGRAM-ERROR #S(SIMPLE-PROGRAM-ERROR ) Entering repl No restarts available."
16:48:46
drmeister
Yeah - I tried to improve the error reporting in the build system and I introduced an edge-case bug.
16:56:37
drmeister
I already know that github is a few commits ahead of you - so we don't need to worry about rebasing
17:21:54
drmeister
I was looking at the Google energy efficiency of different languages paper again.
19:07:14
drmeister
After the last week of changes and addition of an LLVM-IR rewriting pass to move activation frame variables into allocas and registers - I expected a big win.
19:08:46
drmeister
So - overall, the improvement in performance is almost perfectly balanced by the increased time spent optimizing things.
19:09:47
drmeister
Now the good news is that these last changes sweep away a lot of old code and consolidate code.
19:10:25
drmeister
So now I have an easier time improving method calls. That should be a win in both bclasp and cclasp with no additional overhead.
19:52:45
frgo
Hi Shinmera. I had been readimg your blog post https://reader.tymoon.eu/article/357 and noticed that the link for Harmony (https://shinmera.github.io/harmony) goes into nowhere land.
21:25:13
drmeister
ACTION doesn't need self aware AI's to make his life miserable. The stupid computers of today do a fine job.
21:32:53
drmeister
It looks like I've introduced another threading problem in the past week. I'm wracking my brain to try and recall what it could be.
21:33:34
drmeister
When I set preferred-communication-style in clasp.lisp to NIL slime starts up fine.
21:55:15
drmeister
Bike - in case you didn't see the log from the last hour - slime works if you set the preferred-communication-style to NIL.
21:56:26
Bike
so it does. well, on the bright side, things can be made to work, though on the downside, t hreading problems
21:56:38
drmeister
I can't recall what it was - but I don't want to be derailed at the moment - I'm working on method calls.
21:57:20
Bike
i already had a branch set up for my sandbox stuff, so i was just going to use that tomorrow. it's building right now
21:58:05
drmeister
I mean - I can't recall at the moment what I might have done that introduced a threading problem. I'll keep thinking on it.
21:59:03
drmeister
Emacs has frozen up like that half a dozen times - every time it was a threading issue.
23:33:08
emaczen
drmeiseter: All I want to do is something like the lisp method #'start-capturing at the bottom: http://paste.lisp.org/display/358268
23:34:02
emaczen
but Instead of CFFI I want to use Clasp because the C++ api is better/easier to deal with, and if Clasp has some conversion mechanism between the STL then what I want to do should be a piece of cake
23:38:32
emaczen
https://docs.opencv.org/3.0-beta/modules/imgcodecs/doc/reading_and_writing_images.html -- I really want to use the C++ function imencode rather than the equivalent C function cvEncodeImage
23:53:00
Bike
i don't work with that part, drmeister is better equipped to answer. but yeah there's https://github.com/drmeister/demo-clasp-cxx and https://github.com/drmeister/demo-bullet
0:14:41
drmeister
emaczen: If you are familiar with boost::python or luabind - those are two C++ template libraries that create bindings between C++ and Python and Lua respectively.
0:17:04
drmeister
Clasp uses these facilities to interoperate with the llvm C++ library and the Clang ASTMatcher library - as well as the Clasp C++ runtime. Thousands of functions and hundreds of C++ classes and methods and dozens of enums are exposed this way.
0:20:16
drmeister
The issue is we hack the X86-64 calling convention - although I might be fixing that soon.
0:20:57
emaczen
I didn't configure anything though and I think there are different JVMs you can install just for these purposes too.
2:41:22
drmeister
Waaaaaay back - when I was first developing Clasp. I'd run in emacs using 'run-lisp' and the *inferior-lisp* buffer.
2:42:30
drmeister
I'm glad that the last weekend put several nails in the coffin of the idea of writing a new bclasp compiler.