freenode/#lisp - IRC Chatlog
Search
4:53:23
pjb
antonv: eg. void* p=&p; is wrong on some level, because &p is of type void** not void*. Now of course, given the rules of void*, it will be accepted. But is it acceptable?
4:54:58
pjb
To do the equivalent in C, you need a more complex structure, with struct, union, etc; basically you need to implement symbols in C.
7:15:20
earl-ducaine
Hey Lisponauts! Trying to determine what the potential difference might be between sb-int:fixnump and a naively defined (defun fixnump (object) (typep object 'fixnum))
7:16:22
earl-ducaine
I looked at the SBCL code, but it's not easy to decern what it accomplished appart from the usual SBCL coldboot-ish machinery.
7:19:32
beach
earl-ducaine: TYPEP can be quite expensive. FIXNUMP is just a matter of testing the last bit of the work and return true if it is 0.
7:20:18
|3b|
built-in one is also more likely to take advantage of type-inference in surrounding code, which would be lost by full function call
7:23:08
|3b|
also whether the compiler knows if it can skip the call entirely if you ignore the results, since it has no side effects, and some things like that
7:30:14
|3b|
probably most important difference is that typep is a supported function, so less likely to be randomly changed/removed by sbcl devs :)
7:48:46
beach
Hmm, I should learn to use reader conditionals. I mean, I know the way they work, but I don't naturally think of them for structuring my code.
7:50:07
beach
For example, I need to test SICL systems implementing things like the package dictionary, but I want to test it in some host environment like SBCL. Obviously, there are tons of package-lock violations then. I think perhaps reader conditional can help here.
7:52:21
beach
Even doing something like (defpackage package (...) (:metaclass built-in-class)) won't work in a host environment, but I can wrap the :metaclass part in a reader conditional.
8:23:10
beach
If I have an ASFD system for the SYMBOL dictionary and another for the PACKAGE dictionary, then invariably, they are going to depend on each other. I think I'll make a common system for both. Does that seem like a good idea?
8:28:38
mfiano
Is it good practice to use EXPORT in a macro which generates hundreds of functions that you want external?
8:29:50
mfiano
Shinmera: That's quite funny actually, because I am using it for the exact same thing.
8:37:26
mfiano
It was implemented almost 2 years before your first commit, and was designed for critical physics simulations outside of game development until it was renamed and served as part of my game development toolbox. Afterwards a few such as yours and Baggers' rtg-math showed up.
8:38:24
mfiano
I am only now adding swizzling because I am removing a custom accessor system I've been using, and wanted to integrate it into varjo to have the same API on the CPU and GPU
8:41:46
dmiles
well all the docs related to the symbol is always nice (varible, function, class, etc)
8:47:24
mfiano
Shinmera: I will give you some feedback though. It would be nice if you also defined SETF swizzles (or maybe I'm just blind), and you also support the other 2 GLSL masks.
8:48:26
mfiano
"there are 3 sets of swizzle masks. You can use xyzw, rgba (for colors), or stpq (for texture coordinates)."
8:49:30
mfiano
I am avoiding SETF too, I think. I don't really need it, and it has some additional tricky bits
10:32:49
dmiles
am i correct to assume most compiled lisp programs do not need eval or macroexpansion at runtime ?
10:34:33
Shinmera
Well, it's less that the compiler eliminates the need to do that, it's more that the cases where using eval or compile at runtime are hard to justify.
10:34:54
Shinmera
In the overwhelming majority of cases there are better ways to solve the problem than eval.
10:35:37
dmiles
Well assuming user code uses eval.. most of the time the compiler can still eliminate if in the end
10:38:47
beach
dmiles: If the application calls EVAL, it's because the code to be evaluated is not known at compile time, so it has to happen at run time.
10:38:57
dmiles
well forget that last question it is probably a red herring. the real reason i am asking to is if after compiling i should be able to expect that i can completely macroexpect things away at compile time
10:41:13
dmiles
on the side eliminating eval is not any more special than eliminating funcall or apply in most cases outside of (evaluating a string supplied by a user)
10:41:47
beach
EVAL takes a Common Lisp expression and that expression can be built at run time without any strings involved.
10:43:42
dmiles
i am asking "outside of some program that wanted to read a string with a lisp reader and eval it"
10:44:31
beach
An expression can be constructed at run time without any strings, and if the application programmer needs to evaluate such an expression, then it must happen at run time.
10:45:42
phoe
that's simple, because READ reads bytes from standard-input, so, technically, from streams
10:45:46
beach
The answer to your question is "no". It is not just in the case of a string that the evaluation must happen at run time, simply because there are other ways of building expressions at run time, and if they are not known at compile time, they must be evaluated at run time.
10:45:54
random-nick
dmiles: well, it is common for people to include a Read Eval Print Loop in their program, so some programs do use "eval"
10:46:47
phoe
but (let ((expr (list (random-operator) (random-argument) (random-argument)))) (eval expr))
10:47:39
Shinmera
Either the user knows what they're doing and it has to happen at runtime, or they don't and they should eat the slowdown.
10:49:42
beach
dmiles: No sane application programmer would write that, so it is pointless (as Shinmera says) to optimize it.
10:50:17
beach
dmiles: Yes, there is. It is called "software maintenance". The more pointless code you have, the harder it is to maintain.
10:51:04
dmiles
i already have the code that eliminates that (time is done) .. what i am trying to decide is if i can expect that i will not need to macroexpand as well
10:53:06
dmiles
i eliminate them with 4 lines of code: https://github.com/TeamSPoon/wam_common_lisp/blob/master/prolog/wam_cl/funcall.pl#L140-L143
10:54:34
phoe
to sum things up really fast and messy, you need to have the compiler at your disposal to properly implement EVAL.
10:54:57
Shinmera
What was the reason that eval is different from (compile NIL `(lambda () () ,expr))?
10:57:08
dmiles
the orignal question was "outside of the case of EVAL and some whereness of trying to eval at runtime" .. x y z
10:57:09
beach
dmiles: Because the arguments can contain arbitrary expressions that need to be evaluated before the function can be applied. This is elementary in implementing Common Lisp. You really should have a look at Lisp in Small Pieces.
10:57:47
dmiles
i was trying to avoid discussing eval :P but i accidently brought it upo in the question
10:58:53
dmiles
the question was "outside the case of EVAL, is there a reason one might have to macroexpand at runtime"
11:04:11
dmiles
phoe: yeah, though mostly i make a little lambda that returns that experession with load-time-value for things liek that if they dont seem constant
11:16:07
beach
So #.(random 666) is first an example of something that is NOT constant at compile time, and then you agree that it IS?
11:16:18
dmiles
ok so i think the answer to my question is: "except in the cases that the programmer is forcing the need for eval, (yet they can still use apply/funcall), except the case the programmer is using macroexpand (or evaluating the macroexpransion with hopes of evaluating it next), you should be able able to complle programs well enough that you will not need to relly on preserving your enviroment
11:16:55
random-nick
shouldn't everything evaluated with #. be constant at compile-time since it is evaluated at read-time?
11:17:45
dmiles
beach: really i assumed the lisp reader gave me a random number and i compile things never knowing the number ws random
11:18:36
beach
It gives you one number. So it is constant. But you gave this as an example of something that is NOT constant. And then you changed your mind.
11:19:57
dmiles
i was under the assumption it related to load-time-value (but i think that assumption was wrong)
11:21:38
dmiles
if the users code contained (read-from-string ".(random 666) ") that might be differnt
11:21:44
beach
Maybe you don't care whether your implementation is conforming or not, but if you do, I think you are in for A LOT of work.
11:24:22
dmiles
well i been working for 3 months it.. i have one month left in budget to be able to run 2 differnt applications.. then if i can get that done i get 2 more months to run/compile 2 more applications.. then after that i get to worry about conformance and passing the ansi-tests
11:30:32
dmiles
so my intial goal is compile and run "DAYDREAMER" and (PTTP or "Knowledge Machine") by end of January
11:39:18
flip214
Xach's report of ASDF 3.3.1 breakage in newer SBCL includes a few non-ASDF related things, AFAICT.
11:39:23
flip214
for example, http://report.quicklisp.org/2017-12-25/failure-report/cl-sendmail.html#cl-sendmail says
11:39:44
flip214
; Derived type of CHILD is (VALUES LIST &OPTIONAL), conflicting with its asserted type XMLS:NODE.
11:51:39
flip214
Xach: yeah. so QL tries to build systems even if any of the dependencies are known broken?
11:52:36
flip214
and re http://lispblog.xach.com/post/169109562413/fasl-package-pitfall: is the right solution a (:depends-on #+project-b :project-b) in the ASDF?
11:57:44
dmiles
but i am doing it backwards in hopes of being able to get paid durring the time of "A LOT of work"
12:58:55
flip214
well, the idea is that if it existed during compilation, it'll do so after reloading the FASLs too
13:16:35
Shinmera
So if you load b, load a, restart, load a, then a contains fasls with b in it, but the asd won't load b.
13:19:14
Shinmera
A "solution" would be to put #+b (ql:quickload :b) into the source files, except that'll give you nasal demons because recursive loading in ASDF is bad juju.
13:23:58
Shinmera
More than weakly-depends-on, you'd need to be able to say that a component only gets loaded/compiled in the presence of a certain system.
13:26:57
jackdaniel
well, I agree there is no good solution for that. If anything, before first use of b putting #+project-b (eval-when (…) (asdf:load-system :project-b))
13:27:43
Xach
jackdaniel: that seems like it would only load project-b when project-b is already loaded?
13:28:17
Shinmera
Xach: The idea of the snippet is to encode the fact that it was compiled with b in the fasl.
13:29:10
Xach
jackdaniel: How does project-b get added to *features*? In my example, it is added by loading project-b.
13:30:39
jackdaniel
Shinmera: if you grok asdf enough you start to understand, that it's nasal deamons even without recursive load (as in – it does what it does)
13:32:08
jackdaniel
actually undefined consequences are always undefined, that was at least claim in the original article
13:42:44
jackdaniel
Xach: fwiw, if you consider loading fasls that way, you may want to put (require 'asdf) before asdf:load-system in this chunk
13:46:12
Shinmera
Xach: Do you have info on which systems conflict with each other? As in, they can't both be loaded in the same instance
14:39:27
scymtym
Xach: are you aware of any progress regarding cxml? i didn't hear back from dlichteblau yet (sent mail mid November, CCed you)
14:50:48
beach
So export takes a designator for a list of symbols. According to the glossary, that excludes a string or a list of strings if I read it correctly. Am I right?
14:57:46
scymtym
beach: assuming you mean the "designator" glossary entry, which part of the entry lets you conclude that?
15:01:57
beach
So if I substitute SYMBOL for OBJECT, I get "a non-nil symbol (denoting a singleton list whose element is that non-nil symbol) or a proper list (denoting itself)".
15:04:55
beach
I guess I am on the right track, because SBCL rejects a string (which would be a symbol DESIGNATOR, but not a symbol, of course).
15:06:25
scymtym
the EXPORT example. i thought it used a string which would become a singleton list containing a string. thus the question
15:08:34
beach
By the way, I found a cute way of checking if something is a proper list. No doubt I am not the first one to do that, but it's simple: (integerp (ignore-error (list-length list)))
15:59:25
beach
KZiemian: I don't know if you have thought about this issue yet: There is a general explanation in the Common Lisp HyperSpec that if a dictionary page mentions an object type, and nothing explicit is said on that page about what happens if the type is violated, then the consequences are undefined (or perhaps unspecified, I don't remember) if it is.
15:59:26
beach
I think many people incorrectly assume that en error will be signaled. It would be worthwhile to remind the reader of such dictionary pages of these consequences. It could be in the form of a link to the general page (with an appropriate text), or a direct statement of what happens if the type is violated.
16:04:34
specbot
The ``Arguments and Values'' Section of a Dictionary Entry: http://www.lispworks.com/reference/HyperSpec/Body/01_ddc.htm
16:04:55
beach
Notice: "Except as explicitly specified otherwise, the consequences are undefined if these type restrictions are violated."
16:06:32
KZiemian
beach: If I had time, I put today some explenation about CLUS current aims and problem
16:11:26
beach
KZiemian: If you want to make a specific note on each entry concerned, I can help you with the text for that. Like, for this one, I would say something like:
16:11:35
beach
Note from the CLUS maintainer: While this page explicitly says that there are no exceptional situations, notice that section 1.4.4.3 implies that, if the lists (all arguments except the last) are not proper lists, the consequences are undefined.
16:13:28
beach
... and if you compile a list of dictionary entries that need to be amended, I can work on such a list, and create specific notes.
16:15:21
KZiemian
beach: When I start to understand direction in which CLUS is going now enough to make this come true I will contact you
16:15:48
KZiemian
beach: now CLUS is for me like a maze, which have one path that I more or less understand