freenode/#lisp - IRC Chatlog
Search
3:19:46
jgodbout
(defparameter *optional-field-info* '(... (optional-bytes "" #.(make-array '(3) :element-type '(unsigned-byte 8) :initial-contents '(49 49 54))) ...)
3:19:56
jgodbout
at run time it tells me the type of optional-bytes is (simple-array 3), but the type information gets removed...
3:31:46
fe[nl]ix
jgodbout: ABCL might be losing type info of literal specialized simple-array instances
4:14:16
jgodbout
https://abcl.org/svn/public_html/doc/abcl-start.html#batch It is currently not known what this option does.
4:18:14
philweb
any recommendations/pointers on building a small-ish sbcl image for use on a mobile device? I did some poking around on tree shakers and what little I found didn't seem to favor that approach
4:21:25
philweb
only that I'm more familiar with sbcl and know it runs reasonably well on 64-bit arm. I'm open to ecl if you think that would be a better option for this use case
4:28:26
bhartrihari
philweb: If you want to make apps for android or iOS then EQL5-Android allows you to do that using ECL. If you just want to run some lisp code on ARM sbcl (though single threaded, IIRC) should be fine. CCL might be preferred here because it has threads if you need them on ARM.
4:31:20
philweb
bhartrihari: my app will actually be running on linux (i.e. pinephone for now) and have moderate ffi needs (gtk etc)
4:31:38
ldb
i find that a space efficient way to implement property list is let a hash-table of keys with each entry hold a hash-table of value to each objects
6:18:50
ldb
I have a CLOS question: if I have a class allocation slot with initform that makes a hashtable, will this solt reinitialized when a subclass is created?
6:48:29
ldb_
from some testing with CCL seems re-eval the defclass won't cause the hashtable to be recreated
8:16:04
easye
minion: memo for jgodbout: unfortunately that is an outdated piece of documentation, the ABCL User Manual describes is as "evaluates forms specified by arguments and in the initialization file ~/.abclrc, and then exits without starting a REPL".
11:35:32
VincentVega
ldb: yeah, but that could conflit with some function already in existence. and in that case, renaming the slot accessor would be inconsistent.
11:35:35
treflip
I know that sometimes slots and acessors are named exactly the same, but slots are prefixed with %
11:37:43
VincentVega
treflip: I saw somewhere that % is used for low-level dangerous functions... though that gives me an idea to name the accessors @name
13:14:45
beach
VincentVega: The best choice is not to prefix or suffix the accessor with anything in particluar.
13:16:03
beach
VincentVega: The convention of prefixing with the class name looks really dumb when you have subclasses, so in CLIM, for instance, you see things like (SHEET-PARENT PANE). It would have been much better to just name it PARENT rather than SHEET-PARENT.
13:16:42
beach
VincentVega: And the convention of prefixing with GET- is not used in Common Lisp, other than some names that are there for historical reasons.
13:17:51
scymtym
i thought CLIM used the protocol name (which admittedly coincides with the name of the corresponding protocol class)
13:20:19
beach
We don't have a choice with an existing specification, but we can recommend the *fix-less version for new code.
13:20:57
beach
And I personally don't like the -OF convention, but I have no objective argument against it.
13:22:39
VincentVega
beach: Yeah, prefixing a class name looks overly verbose. I am currently considering slot@ which is both short and unlikely to create a clash.
13:24:43
ldb
there's a set of interesting conventions in KEIM that uses + = ~ * for different kinds of names
13:27:18
ldb
guess might need a feature to hide a name in current package and refer it with certain prefix
13:30:30
ldb
VincentVega: i don't recommend to adopt it, because that was based on a customized module system
13:39:51
beach
VincentVega99: There is no "clash" with the slot name, so people like Xach use the same name for the slot and the accessor, considering that any use of SLOT-VALUE is a no-no. I myself prefix the slot name with %, which is already used traditionally in Common Lisp to mean "private" or "watch out".
13:40:29
beach
VincentVega99: So then, client code who uses SLOT-VALUE would have to type package::%slot-name, where both :: and % indicates that something is off.
13:46:20
VincentVega99
beach: Oh, I don't mean the clash to be a clash with the slot name, but rather with a function defined somewhere else in the package (smth like range, I mean, it's not unimaginable). But, yeah, I see the use of % for the slots which aren't meant to be accessed directly.
13:49:44
beach
Even slots that are used only within a particular module can benefit from being accessed through accessors, because you can then define auxiliary methods on the accessor generic functions.
13:58:25
beach
Another point is that, if you ever want to change from one characteristic being stored to being calculated, or vice versa, then if you use SLOT-VALUE you have to change it everywhere.
13:59:55
beach
A simple example would be the CIRCUMFERENCE of a geometric figure. You may very well decide at some point that it should be calculated and then at some later point that it should be stored, or the other way around.
14:03:09
VincentVega99
beach: hey, man, I think there's a misunderstanding. I didn't really plan to name the slot any differently, just the accessor. So, like this https://pastebin.com/qTQkv4ju
14:08:16
beach
There is no such convention in Common Lisp, and the name of the accessor is what is typically exported.
14:09:18
beach
So if you had CIRCUMFERENCE before (calculated) you now have to tell your client to change all his or her code, when you decide to store it, and therefore you now call it CIRCUMFERENCE@.
14:12:03
beach
You would not end up in that situation, any more than you would end up wanting the same name for two different ordinary functions in a module. Different purposes imply different names.
14:14:19
VincentVega99
beach: "tell your client to change all his or her code, when you decide to store it" Sorry, but I am failing to see how that's the case if the convention in the package is to call all accessors CIRCUMFERENCE@ from the beginning
14:15:07
VincentVega99
beach: "Different purposes imply different names." I agree, maybe I am worried without a good reason about this
14:15:28
beach
I am saying that it is not an accessor from the beginning. You write your code like this (defgeneric circumference (object) ;; compute from stored information in the object...
14:16:17
beach
Then you change your mind, and store the circumference to avoid computing it each time, so now you have a slot (circumference :accessor circumference@). Now your client must change his or her code.
14:17:10
beach
Look, you wanted to know the conventions, and you asked for advice. You got it. But I have the impression you just wanted to have your initial idea OK-d by #lisp.
14:18:18
VincentVega99
beach: I am not complaining, that's what I came here for (both for advice and for the idea to be OK'd) : ) And yes, now I see what you mean.