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.