freenode/#lisp - IRC Chatlog
Search
20:13:59
jcowan
Yes. But the LOGBITP and BYTE functions treat integers in a little-endian way, even if the internal representation is big-endian. That is, bit 0 is 2^0, bit 1 is 2^1, etc.
20:15:01
Bike
i guess i would just think of it as bit vectors being written left to right while numbers are written write to left
20:16:07
jcowan
Just so. (In actual Arabic writing (but not Persian, which uses the Arabic script), people actually do write numbers from right to left. In Persian and Hebrew, you jump forward (rightward) for the appropriate number of digits and then write them left to right, and then jump forward again.
20:18:32
ecraven
jcowan: you mean arabic writes literal "61" for 16? that is incorrect, I think, 1 is left and 6 is right, in arabic writing
20:22:32
aeth
ecraven: I think so, too. There are also two Arabic numerals. The first are the ones in the west (west of Egypt?) that Europe eventually got. The second are distinct
20:22:48
ecraven
I actually can't think of any number system that writes least-significant-digit-leftmost (unless you count things like ancient greek boustrophedon, which is not a positional numeral system anyway)
20:23:44
anamorphic
Is there any kind of guide on what's good practice when designing an API for a CFFI'd library?
20:24:57
anamorphic
e.g. should I make it really lispy, or make it very C-ish so that it is more easilly documented by the library's own C documentation
20:25:23
ecraven
anamorphic: I usually split it, one thin layer above C, and then a better abstraction on top of it
20:25:40
ecraven
so if anyone wants to, they can import the lower-level API, but for most use cases the higher-level API is better
20:26:48
sjl
that's the approach cl-charms takes. there's a charms/low-level package with the CFFI wrappers and charms/high-level with the Lispy abstractions. I've used that approach for some other things and it works pretty well.
20:27:28
anamorphic
would it matter if the low-level thing is defined at a asdf system level or is it enought as a system with low and high level packages?
20:27:34
sjl
You can even generate the low-level package with something like SWIG if that appeals to you (I know some people don't like it though).
20:27:49
Shinmera
Generally I make a *-cffi package for direct bindings, and a * package for a "no headaches" wrapper
20:28:13
sjl
I suppose you could make them separate systems if you really wanted to. I generally don't bother and just make them two packages in one system.
20:28:41
anamorphic
ok cool. I went the way of creating a foo-cffi pacakge and a foo pacakge with some niceties
20:32:27
Shinmera
Ok to be clear: I don't think splitting systems is a good idea. I do think splitting packages is a good idea.
20:33:34
|3b|
ACTION usually intends the low-level to be used in addition to the high-level for specific bits that need higher performance or something, so both would generally be used together
20:34:09
|3b|
i probably wouldn't reject a pull request from someone that wanted to be able to load the low-level by itself, but wouldn't set it up that way to start with
20:35:20
|3b|
like in the opengl case, i could see wanting to write a separate high-level layer for gles, which would usually run on resource constrained systems so skipping normal GL wrappers would be good
20:36:49
|3b|
in general for the part about pull requests and intent, cl-opengl specifically for gles example
20:37:54
|3b|
ACTION probably wouldn't accept a pull request for gles specific systems of my non-gl libraries :)
20:49:30
pjb
jcowan: (let ((i (random 1024)) (bv (make-array 10 :element-type 'bit))) (loop for bit below (integer-length i) do (setf (aref bv bit) (if (logbitp bit i) 1 0))) (values (format nil "~B" i) bv)) #| --> "1110100101" ; #*1010010111 |#
20:50:05
pjb
jcowan: it's just a matter of convention in the binary representation of integers, and the lisp printed representation of bit-vectors.
20:50:33
pjb
jcowan: if the bit weren't in the same order, we'd have to write (setf (aref bv (- (integer-length i) bit)) …)
20:59:54
jcowan
ecraven: no, I mean that when writing "16" in Arabic text, the 6 is written before the 1, whereas in Persian/Hebrew/Latin writing, the 1 is written before the 6.
21:01:23
aeth
jcowan: Saudi currency seems to disagree with you. https://en.wikipedia.org/wiki/Saudi_riyal#/media/File:Saudi_Riyal_5th_Domination.jpg
21:02:30
aeth
also e.g. Qatari riyal (only 50 has a picture). https://en.wikipedia.org/wiki/Qatari_riyal#/media/File:50_qatari_riyal.jpg
21:45:34
jcowan
"before" is ambiguous, I meant it in the temporal rather than the spatial sense. First you write the 6, then you write the 1 to its right.
22:25:25
|3b|
if you are passing to OS, native is better. CL one might escape things oddly to maintain CL semantics
22:36:11
jmercouris
then again, there is so much to learn, I feel like I could spend at least a decade before really mastering CL
22:39:40
pjb
A decade if you put in a dedicated effort learning it. I've been doing CL for 22 years, and I'm still very light on parts, such as the MOP.
23:01:10
Petit_Dejeuner
...how many years until you become such expert who regularly uses eval and read.
23:18:11
Petit_Dejeuner
Since we're on the topic, is there anyway to control what dynamic environment #'eval sees to limit what functions it can call?
23:20:00
White_Flame
it can always use package::private in order to hit whatever dynamic variable it wants
23:21:10
White_Flame
after read and before eval, maybe you could sweep through all the symbols to try to ensure they're always white-listed. Then you also have to eliminate interning, and it might be a difficult cat-and-mouse game
23:31:07
jasom
Petit_Dejeuner: there is no way to control the environment of eval in general; if you want to have a sandbox, it's probably better to write a CL-like DSL
23:32:33
Petit_Dejeuner
This ALMOST seems right, but I need to make sure stuff like #. isn't creating leaks. https://pastebin.com/raw/gQYwVRkF
23:36:49
Petit_Dejeuner
Maybe I can change the reader so qualified (or whatever they're called) symbols don't work?
23:52:11
jasom
Petit_Dejeuner: if you change the reader so it can't get at other packages and you don't import any symbols that could allow them to intern strings, then you might be almost right.
0:17:50
jcowan
given the limited objectives of safe-read, I would think writing it from scratch (by which I mean read-char) would be not only safer but easier
0:20:27
jcowan
come to think of it, though, there is no string->number, is there? If not, you'd have to sanitize numbers and call read on them.
1:03:11
didi
What should I use for the parameter `default' of function `getf' if I want to know, for certain, that an indicator is absent?
1:06:16
drewc
didi: I use a GENSYM for that if I really care, for often, :asbent, or a similar keyword that states my intention if it is vancant.
1:08:02
didi
I am thinking of using something like (list :absent) as default, so I can test it using `eq'.
1:09:53
jcowan
The advantage of that over a pair is that it doesn't interfere with the way things are printed
1:12:05
didi
The manual mentions function `get-properties' but seems a bit overkill. Maybe it isn't.
1:48:09
asarch_
I was watching a video about how to construct a menu using CSS and the programmer wrote: ul>li*5>a[href="#"]{Item $}
2:50:05
beach
phoe: Could your safe reader be implemented as a bunch of specific methods for Eclector?
3:23:15
beach
Are you saying that the safe-read code is simpler than the combined amount of code required to configure Eclector?
3:26:03
beach
So the combined maintenance burden is less than with a specific implementation for safe-read.
3:26:32
beach
jcowan: I don't know, but I am sure scymtym would be happy to consider such an addition.
3:27:33
beach
He has been doing a fantastic job of testing and documenting Eclector. Also, uniforminzing the code so that it is understandable and maintainable.
3:27:56
jcowan
(I'm not talking about phoe's impleentation specifically, but a lower-level version not involving readtables or REQD istself.
3:28:51
jcowan
I suspect that such code would be easier to audit, since it is part of the security perimeter
3:28:55
beach
The current clients for Eclector are: SICL, Clasp, Second Climacs, and scymtym's experimental (and very impressive) Common Lisp development environment.
3:30:44
beach
And it's more than a reader. It can "read" the comments and other skipped material as well.
3:31:36
beach
There have been portable readers in the past, but I think this is the first one that is written with heavy use of generic functions, so that it can be adapted to the needs of the client.
4:24:24
jcowan
beach, Petit_Dejeuner: arbitrary predicates supplemented by subsumption relationships between them
4:41:10
fiddlerwoaroof
I've been thinking recently about what would make code completion for lisp nicer
4:58:08
PuercoPop
fiddlerwoaroof: I like the m-v-b<tab> approach to completion, although its main use is to save typing when I know what I want to call but am to lazy to type it
5:00:23
fiddlerwoaroof
So, you can advise the IDE that the first argument to a function is "normally" one of a certain set of keywords
5:01:39
fiddlerwoaroof
And then ways to customize the argument list things like eldoc show, so that complicated forms like LOOP can be easier to use
5:03:00
PuercoPop
fiddlerwoaroof: you could start from the arglists contrib that sl{y,ime} uses for function specific eldocs maybe?
5:06:00
PuercoPop
What I think we are missing from a tooling perspective is a way to declare custom indentation for forms that is well integrated with the system. The cl-indent.el 'contrib' has that functionality but the API appears to expect the user of a library to copy emacs-lisp into their init.el (or .dir-locals.el at least)
5:06:01
fiddlerwoaroof
Just skimming through that code, it looks very similar to the things I was thinking about
5:07:01
PuercoPop
I've seen some code that configures it from the CL side only if it finds slime is loaded in the image
5:07:05
fiddlerwoaroof
Yeah, and there are other things: I'd like to be able to have a single emacs buffer that contains the source for all the methods of a generic function
5:07:45
fiddlerwoaroof
But, to do that right, I'd need an implementation that made the code in the image the source of truth
5:08:09
fiddlerwoaroof
e.g. it'd be more like a smalltalk environment than like modern CL environments
5:10:36
fiddlerwoaroof
One advantage of this would be that, it wouldn't matter _where_ I define a function: if I type it in the repl, or enter it through a buffer, the code will end up in the same place and I could extract it into a buffer using a hypothetical query language for source code
5:11:47
PuercoPop
But with current xref's capabilities you could create a buffer that is the 'view' current loaded methods associated with a generic functions today
5:12:59
fiddlerwoaroof
Yeah, the problem with that is that if I edit the from that buffer, I'd have to manage patching those functions back into their source files
5:13:14
PuercoPop
Except the prospect of writing complex UI controls in elisp is not an enticing one
5:14:42
fiddlerwoaroof
I think so, although from what I gather, combining parts of several files into one file doesn't work very reliably in emacs.
5:15:42
fiddlerwoaroof
Also, the other thing is, if the source of truth for the code is whatever is stored in the image, it might be less painful to maintain customizations of other people's code
5:17:25
PuercoPop
yeah, an indirect-buffers can only show content from one buffer. But you a buffer to select the method and a buffer to display its contents. Similar to how the Smalltalk Browser shows protocols and methods. Although that is mostly the same to the current xref capabilities in sl{y,ime}
5:19:29
fiddlerwoaroof
I'm actually a bit curious if it's possible to tell something like sqlite to embed a database at the end of a file
5:20:58
oni-on-ion
i was looking at org-mode attachments for a similar purpose; to compound a given project source tree into a single org file