freenode/#lisp - IRC Chatlog
Search
20:27:19
pfdietz
Lycurgus: ansi-test has a simple 'make-random-element-of-type' function. It's quite useful for testing various CL built-ins, and has found lots of bugs in various implementations.
21:15:48
sebboh
LdBeth: funny you should mention that, I am specifically curious about whether or not the next such tool will use symlinks in that way... theres-got-to-be-a-better-way.gif?
21:19:22
LdBeth
the reason why people develop package mngrs like nix is because haskell is the language that has most of the libraries are not compatible with each others
21:20:41
LdBeth
well you could get similar probs in C++, but most of the time this problem doesn't exists in CL
21:22:21
LdBeth
well, I just build a minimal version of graphviz not producing raster imgs but postscript/svg
21:23:23
sebboh
hm that would solve all the renderer problems! Nice. But, I've had build problems with layout stuff too
21:28:39
sebboh
the latter, yes. bind that to some sequence.. But that would reveal that there's more than one thing I don't understand about haskell. :P
21:29:39
sebboh
(or maybe it would reveal that I know you can type 7-bit clean ascii in haskell always and not be limited in anyway because the glyph feature is like.. basically macro expansion or something?)
22:35:51
_death
np.. btw, ironclad should also export modular-inverse, since it's a useful operation
22:36:39
pjb
_death: you want ironclad:generate-safe-prime, or com.informatimago.common-lisp.arithmetic.primes:compute-primes-to
22:40:33
pjb
asarch: you will prefer com.informatimago.common-lisp.arithmetic.primes:compute-primes-to then.
22:40:42
pjb
(com.informatimago.common-lisp.arithmetic.primes:compute-primes-to 64) #| --> #(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61) |#
22:44:57
aeth
easiest way to double your limit is to skip multiples of 2 and just always put 2 in front
22:48:29
_death
apparently ironclad has ironclad::generate-small-primes, "for mathematical interest"
23:08:25
asarch
Another stupid question: how can I install com.informatimago.common-lisp.arithmetic.primes?: (ql:system-apropos :com.informatimago) -> ; No value
23:13:50
pjb
asarch: ( cd ~/quicklisp/local-projects ; mkdir -p com ; cd com ; git clone https://github.com/informatimago/lisp.git informatimago )
0:06:31
patrixl
asarch: according to their gitlab readme, they also are on quicklisp, just need to know the exact names: https://gitlab.com/com-informatimago/com-informatimago
0:27:19
pjb
But it's in the ultralisp quicklisp distribution, so if you install ultralisp, you will be able to just quickload it.
1:05:07
pritambaral
Anybody know a lib for converting byte sizes into human-readable ones? Like, 1024 => "1kib".
1:08:06
lxbarbosa
hey, is it wrong to NOT be too precise on what a function should do? eg: run through list, if there is 'xx' do action
1:09:38
loke
lxbarbosa: You have to be a bit more precise in your question. I'd like to answer, but I don't understand what you're asking.
1:11:16
lxbarbosa
loke: parsing a list and once if finds an strings that match do action... is it wrong to be so unprecise? I reckon, one should always be sure what the list has before hand
1:27:08
loke
lxbarbosa: No, why would it? If you have use for such function, why not? The only issue here is what you would name it such that it's (somewhat) obvious what it does.
1:29:04
lxbarbosa
imagine that function would to download a file and someone can just rename that list to some virus file :D
1:37:24
loke
lxbarbosa: I think you're touching on the issue of injection attacks. That's a much broader issue, and has to do with how you treat untrusted data (i.e. data that getsarrives into the system from sources that you don't control)
1:37:39
no-defun-allowed
lxbarbosa: Then it's someone's fault passing it a function that does something that produces a virus.
1:39:17
no-defun-allowed
Then you have bigger problems if someone can put a function in your program that can produce a virus.
1:39:45
loke
lxbarbosa: It's a difficult topic. I've spent several years at work trying to teach this to the develeopers. It's something all programmers need to understand, not just so that they can write secure code, but also so that they don't spend time implementing useless security features that doesn't help security (your misunderstanding fell into the second category)
1:40:12
no-defun-allowed
Perhaps I should add a virus scanner to SBCL. Something like `(car '("foo" "bar" "Invoke-Mimikatz" "baz"))` should signal an error, since the caddr could be used for virusing.
1:48:53
lxbarbosa
loke: can you share any book or article on that topic? if it aint asking too much :D
1:49:57
lxbarbosa
no-defun-allowed: Although Ive said 'virus' I meant any vicious file, cant even name those :D
1:50:59
lxbarbosa
soon, I will port my python scripts to lisp, just to see how much it differ from each other approach :D
1:57:31
loke
lxbarbosa: I have to admit that I don't know of a good book that purely talks about secure coding in a language-agnostic context
1:58:27
loke
There is a Microsoft book called “Writing Secure Code (Developer Best Practices)” which, as far as I understand (I didn't read it), talk about these things. The examples are all Windows-specific though, but that shouldn't take away from the general points.
2:00:53
loke
Another Microsoft source: https://docs.microsoft.com/en-us/previous-versions/msdn10/aa570401(v=msdn.10)
2:45:47
shinohai
``````````````````````````````````````````````````````````````````````````````````````````````````
3:12:58
no-defun-allowed
Not being intellij sounds like a compliment if my Java using friend is a good source on it.
7:19:42
jdz
I might be misremembering exact figures, but according to Microsoft around 80–90% of security problems (remote code execution) are due to memory management problems (buffer overflows and use-after-free).
7:21:15
jdz
Here's one from a quick interwebs search, that quotes 70%: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
7:31:26
jdz
And instead of improving the tools (i.e., programming languages/runtimes), they push the burden of securing software to kernel/hardware.
7:39:22
Shinmera
I mean, if y'all are gonna hoot and holler about unsafe, let's talk about people using safety 0 in Lisp.
7:40:32
no-defun-allowed
I should stop but a lot of the standard library uses unsafe, probably moreso than Lisp
7:40:49
shka__
Shinmera: safety 0 in a hot function can make sense, the problem is that sometimes it is used accross the whole project
7:41:30
no-defun-allowed
We were bitten by safety 0 in jsown quite a bit. Got unhandled memory faults and all cause we wrote (:obj (stuff)) instead of (:obj . stuff)
7:41:32
jdz
And sometimes people think their hot loop is correct and use safety 0 and then it turns out it's not.
7:45:00
no-defun-allowed
loke: I also have to stop with this too, but it sounds very anti-Climacsictic.
7:45:06
loke
Duuqnd: It's a typical “let's rewrite it in rust” project. Just a bit more stupid than the others.
7:45:35
loke
Anyone who actually _understand_ Emacs understands that the goal must be to get _rid_ of the low-level code. Not replace it.
7:46:02
no-defun-allowed
My favourite is the one that rewrites GNU Hurd basically, but it's actually vaguely usable (not to the extent of Mezzano, no quake), but it's still trash cause Unix.
7:46:56
no-defun-allowed
Then when it was time to learn redox reactions in chemistry class I had flashbacks. Never got the hang of chemistry either.
7:47:02
jdz
loke: Better as in they've been talking on Emacs mailing list about moving to Common Lisp (for performance reasons).
7:47:16
loke
Duuqnd: That's the thing, they don't “work” on the Emacs code. They don't even understand it. They just mechanically replace function with the Rust workalikes. Whcih also explains why most of these fucntions have ‘unsafe’ in them.
7:47:48
loke
jdz: Yes, that has at least been mentioned. Although the likelyhood of that happening is also absolutely tiny.
7:48:17
loke
But... at least it's nonzero when looking at a 20-year horizon. The likelyhood of Remacs becoming something better than real Emacs is zero.
7:48:20
no-defun-allowed
I also heard about troubles with unexec (similar to sb-ext:save-lisp-and-die but it also has to deal with the C side) too.
7:48:41
loke
no-defun-allowed: unexec was removed in the recent version of Emacs. They use the portable dumper now.
7:49:40
loke
The portable dumper basically portably serialises the object graph and writes it to a file. When emacs starts it can use that heap dump to pre-populate the heap.
7:50:16
loke
Another benfit is that you can dump the heap at any time, creating a snapshot of an emacs session that you can load later (there is a flag to Emacs that tells it which dump file to load)
7:51:46
loke
Duuqnd: I don't think the goal sound be to replace GNU Emacs in the general case. The goal should be to be useful to at least a nonzero number of users.
7:52:35
Duuqnd
Yeah, that makes sense. It's just that there's a lot of Emacs packages that my workflow kind of depends on.
7:53:20
Duuqnd
What would be nice would be an Emacs clone written in Common Lisp with some sort of semi-automatic porting tool for Emacs Lisp -> CL.
7:54:14
loke
Duuqnd: It's feasible (or, even better: It would be easy to implement an Emacs lisp runtime for CL). However, the problem isn't Elisp per se. The issue is the behaviour of Emacs that Elisp depends on. Replicating that would bea nightmare. In fact, it would be futile.
7:54:31
no-defun-allowed
It should be possible, I think? Elisp is rougly a subset of Common Lisp with editor stuff on top.
7:54:57
Duuqnd
loke: Maybe some of the more commonly used quirks and features could be emulated/translated by the porting tool.
7:55:19
loke
no-defun-allowed: But you'd need a full implementation of a lot of behjaviours... For example, you need to replicate the behaviour of the Emacs-style string properties and overlays.
7:56:07
loke
So you'd need to bodge on something that implements the Emacs style overlay behaviour on top.
7:56:54
Duuqnd
What about manually porting/replacing most things, but having rough automatic porting for more obscure things.
7:57:10
phoe
if you want to avoid the "let's replicate legacy emacs behaviour" nightmare, then you *have* to rewrite a lot of elisp code to something that doesn't depend on that behaviour. that's an either-or.
7:57:37
phoe
and a rewrite of the emacs C layer in Rust/CL/TeX/whatever won't fix this particular issue.
7:58:28
Duuqnd
phoe: Yeah, many things need to be remade from scratch, but automatic porting could exist for when you don't want to port/rewrite old code yourself.
7:58:58
phoe
Duuqnd: do you mean a compatibility layer that accepts legacy emacs behaviour and outputs new saner behaviour?
8:00:09
phoe
And 95% of the code still goes through that library. And now you have bugs that happen inside the emacs-as-a-library, and on the interface between it and the editor below, and also compatibility issues that will nonetheless arise.