freenode/#lisp - IRC Chatlog
Search
16:09:54
beach
phenoble: Yes, one way of looking at macros is as a means of programming the compiler.
16:11:04
phenoble
beach: I can imagine. I have a bit of a background in C++ metaprogramming, so I'm not all too new to the rationale behind it. Though this in particular, changing the way bindings are done or the like, intrigues me very much.
16:11:33
pjb
phenoble: have a look at OpenC++ https://www.informatimago.com/articles/life-saver.html
16:12:30
phoe
with Lisp macros, you simply accept some S-expressions and then output some S-expressions
16:12:40
beach
MichaelRaskin: For debugging, I would prefer not to modify the source. For one thing, it takes time to insert the code, and then I often forget to take it out. And I certainly don't want my "production" code to have debugging information in it. But it is also sometimes the case that the problem disappears when the code is modified that way.
16:13:41
phenoble
pjb: interesting link to this OpenC++ project, thanks! Most likely not an option in my professional environment though. We have our tools in place, and some momentum with it.
16:13:46
beach
MichaelRaskin: But, as pjb pointed out, that is often the only way to do it with the tools at our disposal.
16:14:05
phoe
beach: in theory, you could use the CLtL2 environments to insert additional debugging information into code only when DEBUG is 3, for example.
16:14:46
phoe
And you could do this without touching the compiler - just inside macros and/or compiler macros, because you have the ability to query &env for declaration information.
16:14:47
pjb
There's also the elpp proof-of-concept (a copy at https://github.com/informatimago/elpp ) this is an emacs lisp pre-processor, which allows you to define macros in emacs lisp to generate code for any programming language you have to use.
16:14:51
MichaelRaskin
I am too used to putting debug printing as a way of understanding the code (not only in Lisp)
16:15:09
phenoble
phoe: I know, yes. That's why things like "binding code in some trace printing" is considered normal in CL I suppose. Rather impossible in C++ (I suppose).
16:15:56
MichaelRaskin
beach: well, at least this is a tranferrable skill, I can read strace output comfortably, too
16:16:45
phenoble
beach: Interesting point about not modifying the source for debugging. I appreciate very much that this is so easy in lisp(s).
16:17:09
phenoble
beach: You write "with the tools at our disposal"... - that sounds like you had better tools in mind. That so? Like what?
16:17:41
phoe
beach: (defmacro foo (...) (if (= 3 (second (find 'speed (declaration-information 'optimize env) :key #'first))) '(progn (print-debug-stuff) (%foo) (print-more-debug-stuff)) '(%foo)))
16:17:59
phoe
where declaration-information is provided via trivial-cltl2 and described at https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html
16:18:57
phoe
beach: yes, but here I assume that FOO is a macro that is already used somewhere in the code.
16:19:27
MichaelRaskin
Hm, I guess I have all the moving parts to inject tracing the bindings without changing the source code, just with a recompilation.
16:19:42
beach
phoe: So then I would have to modify every function or macro that I use in the same way?
16:20:39
phoe
beach: the ones you want to debug, yep. Quite possibly it can be wrapped in a macro to hide the syntax, but this implies that you need to wrap your functions in special debugging sugar to be able to utilize this behavior at DEBUG 3.
16:20:42
beach
MichaelRaskin: That's another thing. I usually don't want tracing. I want a breakpoint where I can stop, examine the variables using the inspector, step from that breakpoint to some other place, etc.
16:21:40
MichaelRaskin
Well, injecting tracing and injecting breaks are comparable implementation-wise
16:22:35
pjb
shka_: not really. There's may one or two languages that implement actual message passing.
16:22:37
beach
MichaelRaskin: Sounds good. Now you just need to wrap the entire thing in an interactive application called a "debugger".
16:22:47
MichaelRaskin
Traces give me time-dimensions (with restrictions on breadth), breakpoints give broad access space-wise, but in a limited amount of points in time
16:23:02
pjb
shka_: what all the OOP implement (including smalltalk!) are function calls with some dispatching.
16:24:02
pjb
shka_: now you can still use a "message passing programming style". For example, don't let your method compute stuff and return results. Instead, if there are results to be obtained, let them send back a message to some other object.
16:24:31
beach
MichaelRaskin: Yes, I understand. Then the current debugging environment that is available to us should suit you just fine.
16:25:04
pjb
shka_: but you have to be careful, because you code can still have implicit synchronization expectations.
16:25:38
pjb
Those expectations are met until you change the implementation of your methods and "order" of message sending changes…
16:25:43
MichaelRaskin
Yes, pure SBCL debug REPL plus some macros added as-needed mostly satisfy my needs.
16:26:38
pjb
Well, multiple dispatch is rather an orthogonal point, and can trivially mapped to single-dispatch, so there's no reason to avoid it, when pertinent.
16:26:59
shka_
It seems like if you want to compare CLOS to something in vein of C++ you better of put table to compare those two
16:28:13
jmercouris
ASDF mentions a link-farm: https://common-lisp.net/project/asdf/asdf/Configuring-ASDF-to-find-your-systems.html
16:29:29
MichaelRaskin
A place with symbolic links to files scattered across a complicated directory structure
16:31:00
pjb
But it's as easy to have functions to fill asdf:*central-registry* with the directories where your systems are stored too.
16:31:55
jmercouris
Is that the question? I thought we weren't supposed to attempt to redefine asdf:*central-registry* directly anymore
16:33:34
pjb
eg. I still cannot use llvm. I don't see why it should have a different user interface than gdb (and why I should get python backtraces each time I launch it).
16:34:32
pjb
Anyways, this is the big advantage of CL, it hasn't changed since 1989 and is mostly compatible with everything done worth doing since 1959…
16:35:12
jmercouris
anyways, I'm not interested in getting into this argument, gotta go, thanks for the info!
16:35:23
pjb
This means that the little code we write now with the few resources we have, gets a chance to be usable in 20 or 50 years…
17:35:30
puchacz
hi, if I pass readonly that is known at compile time, this macro gives me deleting unused code warning (obviously): (defmacro <textarea ((readonly) &rest rest) `(if ,readonly (<:textarea :readonly "readonly" ,@rest) (<:textarea ,@rest)))
17:37:58
stylewarning
puchacz: try doing (if (constantp readonly) <do explicit if> <expand into if like above>)
17:42:15
flip214
`(<:textarea :readonly (if ,readonly "readonly" "not-readonly") ,@rest) and let the compiler be smart enough for constants
17:43:22
flip214
I guess that at compile time _more_ "constantp"-ness is known than at macro-expansion time...
17:44:53
stylewarning
The point isn’t that the compiler can or cannot figure something out, it’s that it *is* working but identifying dead code and annoyingly emitting messages about it.
17:45:37
puchacz
well, the flip214 solution muffles compiler OK, I only wonder if readonly="not-readonly" is a standard HTML
17:50:06
flip214
is that true currently? > (At present, no companies or consultants wish to advertise paid support or custom SBCL development in this manual).
17:52:20
pjb
puchacz: you seem to be wanting a function, not a macro. Why is this <textarea operator a macro?
17:53:36
pjb
puchacz: also, the recursive calls don't have the right form. The macro takes a list containing readonly. The recursive calls don't pass such a list!
18:41:09
rumbler31
beach: re: debugging, what tools have you used that are not available in free implementations?
19:02:58
pjb
rumbler31: what tool would you trust that 1- you haven't programmed yourself. 2- that are not at least available as free software?
19:24:11
ealfonso
how can I disable ldb from lisp? is ldb an sbcl-specific feature? I'm trying to use fmakunbound but can't find the right function.. is it SB-KERNEL:%LDB?
19:27:11
ealfonso
also, is there a simple way to intentionally trigger ldb to test this? other than requesting a lot of memory?
19:29:39
ealfonso
yeah. thanks. (disable-debugger) works since I'm using it from buildapp to create an executable
21:57:54
ealfonso
what is the best way to understand which objects are consuming the most memory in the heap? is it the sbcl statistical profiler?
21:59:10
aeth
I use sb-profile and if you break things up into small enough functions it's pretty easy to see where the allocations are happening.
22:02:38
ealfonso
if I'm interpreting correctly, statistical profiler or sb-profile gives me a 'consed' column or the amount of new allocs, but does not account for gc'd memory. I have a lot of functions that seem to alloc memory temporarily. what I'd like to see is which memory has been allocated and not gc'd (e.g. to optimize long-running process slow memory leak)
22:08:35
aeth
you can diff two (rooms) to see what has changed, but the act of producing the string for (room) probably allocates. There's probably a low-level, SBCL-specific thing you can use to bypass this.
22:12:45
ealfonso
I can see dynamic space usage with (room), but not which objects or which functions are generating it. I can see a snapshot of new allocations with sb-*prof*, but it includes temporary allocations that might be gc'd. I guess I also need information about what is being gc'd
22:13:42
aeth
ealfonso: how temporary are the temporary allocations? Could you (declare (dynamic-extent foo)) them?
22:18:40
ealfonso
I don't know why a function with a single cffi:foreign-funcall sexp is showing the most 'consed'. when there should not be any allocs in the foreign function
22:20:19
aeth
I don't think so. My CFFI code doesn't cons. The overhead tends to be from poorly wrapped CFFI, like copying huge arrays (cl-opengl likes do do this, but fortunately it also has the %gl package)
22:24:39
ealfonso
https://pastebin.com/2tacbyZZ this is my wrapper that is showing the most conses... does it mean my_foreign_function must be allocating?
22:38:12
ealfonso
pjb is cffi:foreign-funcall the wrong (slower) approach, should I be using defcfun instead?
22:39:03
pjb
Using defcfun will generate at macroexpansion time the native FFI definitions that the compiler should be able to call directly. AFAIK, it's bound to be more efficient.
22:40:32
pjb
Yes, for the lisp object it's implementation dependent whether there's such a function, or even such a notion.
22:43:16
ealfonso
pjb I will try switching to defcfun. how about getting the size of a lisp class (or defstruct)
23:18:53
pjb
minion: memo for beach: apropos 9:17 https://www.youtube.com/watch?v=ZJr81DtSwUc (loop for i below 10 sum i maximizing (sin i) into maxin collect (* i i) into squares finally (print (list maxin squares))) is conforming AFAIK. it has several accumulations clauses of different types… ;-)
0:17:23
aeth
com.informatimago and xelf and ECL are officially ahead of the trend because they've been on Gitlab for forever.
0:36:58
rumbler31
pjb: regarding trust, if I held that mindset I'm not sure how I would have gotten anything done.
0:56:20
aeth
rumbler31: It definitely depends on your domain. For some domains, you have no choice but to pay thousands of dollars for some overpriced specialized software.
0:57:25
rumbler31
the discussion I meant to re-start was about debugging tools. beach mentioned something that suggested that in his experience, paid implementations have better debugging experiences and I wanted them to expound on that
1:02:58
aeth
It wouldn't surprise me. Commerical software like that tends to focus on features to justify upgrades. e.g. integrated Prologs.
3:10:55
minion
beach, memo from pjb: apropos 9:17 https://www.youtube.com/watch?v=ZJr81DtSwUc (loop for i below 10 sum i maximizing (sin i) into maxin collect (* i i) into squares finally (print (list maxin squares))) is conforming AFAIK. it has several accumulations clauses of different types… ;-)
3:12:40
beach
rumbler31: I have no experience with commercial Common Lisp implementations, but I hear they are much better than the free ones for debugging. For my own experience, I still miss using GDB back in the days when I was programming in C. I find I can't do things with our free Common Lisp implementations that I could do then.
3:15:49
beach
rumbler31: I do know what I would like to see for our free Common Lisp implementations, namely this: http://metamodular.com/clordane.pdf but it will require significant support from the implementation, so it probably won't happen with the existing free implementations.
3:48:07
jeosol
I have not gone through your linked pdf in detail, but does your design closely match gdb in c/c++ or it's different with added functionality.
3:49:38
jeosol
Also, what do you mean by "significant support from implementation", obviously man hours, but does this also mean it is likely to require lot of implementation details that it is likely to be very different for each free implementation
3:50:11
jeosol
also since SBCL is very popular, is this feasible to at least put efforts for that implementation.
3:51:42
jeosol
As the designer, you are in better place to push this because it is going to be more clearer to you, and subsequently others who take time to study the document (and who may have used other debugging systems)
3:52:30
beach
jeosol: I did not try to match GDB. I was considering something I would like for Common Lisp.
3:53:11
beach
jeosol: In particular, I won't use different processes. I want one thread to debug another thread, and the debugged thread could be the debugger.
3:54:03
beach
jeosol: I am totally confident that I would be unable to convince the maintainers of any current implementation, including SBCL, to add the support that Clordane requires.
3:55:03
dtornabene
i just finished it btw, seems like the implementation of this on sbcl wouldn't be....momentous? but then I have the barest knowledge of sbcl internals
3:56:19
beach
jeosol: I don't know SBCL well enough to give an estimate. It requires compiler support and, as I understand it, the SBCL compiler is very complicated.
3:56:23
jeosol
and possibly implement using a style with as little modification to the original code base.
3:57:13
jeosol
if it has to involve working deep in the compiler, then it will require major effort for sure
3:57:50
beach
The SBCL maintainers will likely say that it might slow down the generated code, and reject it before even considering it.
3:57:55
dtornabene
talk about a subject in need of a good book, a serious thorough book on SBCL internals would be *awesome*
3:57:59
jeosol
for my applications, I wouldn't say I have not had a need for debugger, but I ensure my systems are testing in very small units, and when CLOS objects are used, I have constructor functions for easy testing.
3:59:09
jeosol
however, my debugging probably sucks, combination of inlet and outlet statements to function (stopped this), SLDB, good old print statements, ...
4:00:03
jeosol
beach: on the issue of rejecting, it would have been nice if it was even possible to scope out requirements and what might change or be impacted in the context of SBCL
4:01:22
beach
dtornabene: You have to consider that SBCL has a long history and the internals have very likely become a bit messy over time.
4:02:53
dtornabene
beach: for sure, i spent a few hours recently just reading, taking line counts, investigating the layout. It seemed like a huge task to get on top of the system as a whole, but its something I'd like to devote a non-trivial amount of time to over the next 12 months or so
4:03:48
beach
jeosol: I totally think that we need a more modern implementation. That is why I am not willing to put any effort into SBCL. In particular, if I have to convince the current maintainers to make changes that are very unlikely to be accepted, I prefer putting my energy into something more modern.
4:05:25
beach
jeosol: One that has first-class global environments, my generic dispatch, my LOOP implementation, my garbage collector, the debugging support I want, etc, etc.
4:06:44
jeosol
Good points. I take it there is not way to implement these new functionalities or add them in existing implementation
4:08:34
beach
jeosol: There is always a way to implement them in an existing implementation, but it is a question of how much work it requires, and whether the maintainers are willing to accept it.