freenode/#lisp - IRC Chatlog
Search
18:53:37
frodef
..if security is based on "having a references implies having permission", you need to know how to prevent attackers from guessing/construction references.
18:58:37
jcowan
well, it depends; if security depends on guessing a well-chosen random number of sufficient bits, then probabilistically it is secure, though someone could land on the number by sheer chance
19:05:19
frodef
jcowan: "guessing" in all likelihood means some heuristics that includes scanning all available memory.
19:28:32
jcowan
Well, yes, if you have access to memory below the object level, then of course there is no security. That's like saying "I can open any lock if I can scan all the keys in the world to get their shapes."
19:29:17
didi
I need ideas on how to deal with symbols from other packages. I dislike prefixing symbols with their packages, but some packages define symbols with the same name, so I can't import them all.
19:35:46
didi
Well, more like (setf (symbol-function bar) package:foo) because supposedly I already have a FOO inside.
19:44:02
pjb
(com.informatimago.common-lisp.cesarum.package:add-nickname :really.long.package.name :rlpn)
19:44:19
pjb
(com.informatimago.common-lisp.cesarum.package:add-nickname :really.long.package.name :rlpn :steal t :force t) ;-)
19:45:12
frodef
someone wrote a library for dealing better with packages like this, but I forget what it's called..?
19:47:43
dlowe
package-local-nicknames solve all my complaints, except that we don't have a culture of long package names so their use is somewhat limited
19:48:50
didi
I dislike prefixing symbols with their packages because it feels like a less tight system. Maybe I just need to get used to it.
19:49:56
pjb
notably when people use short symbols, such as name instead of enterprise-name person-name car-name horse-name.
19:51:15
pjb
(horse-name *daddy*) -> "Dada" (person-name *daddy*) -> "John Wayne" (enterprise-name *daddy*) -> "Short Movies, Inc"
19:52:14
pjb
(com.informatimago.life.play.hu-dada-play:name *daddy*) (com.informatimago.life.etat-civil.usa:name *daddy*) -> "John Wayne" etc.
19:53:54
White_Flame
pjb: have you find that anybody else uses the java-style package naming, or is it pretty much only informatimago?
19:58:39
pjb
I could have created the domain name com.man.who.do.tricks.of.act.of.riting.text.for.thing.that.add.things.used.to.count.life.play.…
20:21:04
LdBeth
frodef: if you mean binary level security, you can do exploit to UNX style ACL too, but ACL is centralized and object oriented access control is distributed in memory, so in that case it still has superior security level
20:22:34
aeth
Idk, long packages are very inconvenient at the REPL. I know because I have a bunch of long package names
20:26:02
aeth
And the worst part is that tab completion doesn't help much because the packages are hierarchical based on the directory structure.
20:28:54
aeth
foo/bar/baz as the package for foo/bar/baz.lisp (or for foo/bar/baz/package.lisp depending on your conventions)
20:31:27
aeth
They're not that bad, I just have the style rule that you can :use cl and any other internal-to-the-project package.
20:32:07
aeth
Then it's only annoying when you want to e.g. (disassemble #'foobar-baz/some-dir/some-file::private-function) from the REPL
20:32:33
aeth
Although if you're doing that often enough it's probably best to just switch into that file's package.
20:32:34
Shinmera
they're bad because they conflate public interface (packages) with internal structure (files)
20:33:22
aeth
The packages don't have to be the actually public interface. That's only if you :use-reexport via uiop:define-package
20:34:02
aeth
You could have an "internal" file/package by simply using it in the uiop:define-package instead of use-rexporting it afaik
20:35:15
aeth
It depends on the size of the project. I wouldn't want to work in any very large project that did *not* use package-inferred-system, but it's probably overkill if the project fits into a single (reasonable) directory (obviously any project can be in one directory).
20:36:49
aeth
Once you get to very many directories and very many files, the lines get blurred. At that point, it's pretty convenient to just be able to load the system zombie-raptor/math or zombie-raptor/util
20:37:04
aeth
Could those be spun off into their own separate projects? Maybe. But they didn't start that way.
20:38:39
aeth
Having a directory package and system is very convenient for very large projects. The thing about CL is that there aren't many very large projects.
20:39:06
Shinmera
I have several very large projects and I especially see p-i-s as a tremendously bad thing for those
20:42:28
aeth
I'd hate to have to try to maintain a project where there are dozens of .lisp files at the top level working in one package. The relationship between the files would be incredibly unclear.
20:44:35
aeth
This looks like a lot more of a maintenance nightmare to me than p-i-s. https://github.com/Shirakumo/trial/blob/4ec570466be2f749105beb97482116f80ff56ef2/package.lisp
20:47:33
aeth
I would much rather have the exports from a given file at the top of the file. Yes, there would be issues if foo.lisp exports some things only for other files and some things for the global package. But if that's necessary, that file alone could be special cased in the main package's export list. Everything else would just be :use-reexport
20:48:57
aeth
But files themselves can have external interfaces that are internal from the perspective of the main package and system!
20:49:55
Shinmera
Packages are a global, public interface. There are no anonymous or internal packages.
20:50:53
Shinmera
Tying them to files means you lose the ability to use multiple files that would allow you to structure your internal mechanisms more apropriately compared to the visible interface
20:51:23
aeth
If you want to use my game engine as a unit, use zombie-raptor. If you want to use my math system as a unit, use zombie-raptor/math, if you want to use my vectors as a unit use zombie-raptor/math/vector. But everything in zombie-raptor/math/vector doesn't have to be part of the interface of zombie-raptor/math or zombie-raptor (although in that case, it probably makes sense that they are)
20:52:14
Shinmera
If they're separate libraries then make them actually separate libraries. This is not an argument for anything.
20:53:51
aeth
They're not necessarily separate libraries. Consider zombie-raptor/data/generate-glsl, which generates GLSL strings from s-expressions. This is very closely tied to zombie-raptor/data/shader. If I wanted to (and I probably should), only zombie-raptor/data/shader needs the full access to the exports of zombie-raptor/data/generate-glsl so zombie-raptor/data should only export a few symbols from zombie-raptor/data/generate-glsl.
20:54:41
aeth
And since zombie-raptor/all use-reexports from zombie-raptor/data, it would also only export a few symbols from that file.
20:55:36
jmercouris
I've noticed some older lispers have massive systems and images that have grown, why this tendency?
20:58:38
aeth
jmercouris: Why break it apart, though? A massive project's a massive project, and it's incredibly modular as it is even though it's all one project. And I try to keep it small! My game engine doesn't even load textures, it just assumes the user loads or generates textures in a compatible format.
20:59:20
jmercouris
aeth: No reason to break it apart, I'm actually asking a different question, "when should I break something apart into a library"?
21:00:32
aeth
jmercouris: If you use package-inferred-system then there is basically no difference between a directory and a library. I can just (ql:quickload :zombie-raptor/math) and only load that. Most of my projects use zombie-raptor/util at this point.
21:01:16
aeth
In that case, the time to break something apart is when you wind up using just that part everywhere, like I'm doing with my util directory. Except, unfortunately, it's not all generally useful so I'd have to move out only the generally useful parts.
21:01:59
jmercouris
I've been also thinking about breaking apart many of my util functions from one of my caveman projects and turning it into a new system
21:02:23
aeth
jmercouris: But even if you don't use p-i-s, the time to break something apart is when you want to use Foo/Bar elsewhere half a dozen times but don't care about the rest of Foo.
21:05:27
aeth
But, going back to the separate libraries thing, the problem is that the directories aren't really independent from each other in my game engine. Most assume certain parts of the engine, just different parts. Only zombie-raptor/util has (by design) 0 dependencies from other directories.
21:06:28
aeth
If I spun off zombie-raptor/math I'd have to spin off zombie-raptor/util first. And most of the rest would be considerably more complicated than that.
21:11:44
aeth
Having separate repos make me hestiate way more than I should to split things into their own projects
21:13:15
aeth
of course, if I had a monorepo I'd probably be thinking about how great it would be to have separate repos
21:13:58
aeth
because the issue is moving all-my-cl-projects/foo/bar into all-my-cl-projects/bar and losing all the history from when it was foo/bar
21:14:15
aeth
Probably not the biggest deal since the original repo is still there, but a bit problematic
21:16:58
aeth
Shinmera: You have hundreds of projects. Do you ever deal with splitting A/B from project A into a new project B?
21:28:57
_death
I have a snippets repository, which contains hundreds of small (usually <500loc) programs.. for that package-inferred-systems works well..
21:30:43
_death
some snippets depend on other snippets, and that's no problem.. non-snippet projects should not depend on snippets though
21:46:11
Shinmera
aeth: Sure, it has happened. Though typically I plan my projects in such a way that I write the libraries first and they're already separate as a result.
21:53:31
sjl
git subtree can split a subdirectory into its own repository (preserving history) really easily. If the thing you're trying to split isn't isolated to one directory (e.g. it has a .asd file at the monorepo root) you'll have to use git filter-branch, which is less friendly.
22:01:12
sjl
I thought you still needed a system definition with that? I thought it was just useful for not having to list out the :components?
22:05:25
aeth
iirc what winds up being the most convenient is having a foo.lisp for every directory foo that consists of a package that uses every file in foo. Then you get foobar/foo in addition to foobar/foo/bar and foobar/foo/baz
22:06:20
_death
I also have a site "monorepo", which contains multiple services.. for that package-inferred-systems works well too. in simple "library" projects, package-inferred-systems has less advantage, and so some use it and others do not.
22:13:51
_death
I do have a repository called "sehnsucht" with old ass projects from 20-10 years ago, with each having its own dir :D
22:15:21
jcowan
ldbeth: you can fall back in the Java convention from a domain to an email address: org.ccil.cowan is what I use, reflecting my email cowan@ccil.org
22:15:33
oni-on-ion
going to put all 'old' projects into an 'attic' and freeze it. bringing current stuff more to the forefront
22:49:48
oni-on-ion
package names are flat, right? so its just convention and almost doesnt matter. i dont think that having a *namespace* problem with actual package names should be a thing.
23:18:11
no-defun-allowed
i'm reading https://lispcookbook.github.io/cl-cookbook/testing.html#gitlab-ci
23:19:21
aeth
I should write my own unit test suite and introduce yet another unit test suite that solves a different 70% of the unit testing problem
23:26:24
aeth
fe[nl]ix: It's more like they're both incomplete. e.g. prove times your tests so you can see when something is slow, and fiveam supports random testing
23:26:46
aeth
fe[nl]ix: prove defaulting to colors in SLIME is *definitely* a flaw, though. I don't think most people have colored output in SLIME, so it makes it look like noise unless you turn it off.
23:27:07
pjb
that said, nothing prevents you to name your package in 3D: (make-package "glutSolidTeapot(42)")
23:36:34
aeth
pjb: Nope, I can't name my package in 3D: (make-package (make-array '(2 2 2) :element-type 'charcter))
23:40:11
no-defun-allowed
i have to write a command to run sbcl that loads netfarm-test and runs the tests
23:42:20
no-defun-allowed
so just to check, can i use LET on dynamic scoped variables like `*debugger-hook*`?
0:40:27
aeth
The thing about this sort of config file is that no one writes it from scratch. There is one genesis file that just evolves over time.
0:40:54
aeth
I have tests in about half of my projects but I never got the CI working in any of them.
1:04:00
slightlycyborg
is there a single symbol let function that returns the symbol created after sideeffects?
1:06:24
aeth
no-defun-allowed: Oh I see what you did there. The examples all have make, but you just directly called SBCL instead of a make file. That's also why you asked about make
1:06:37
aeth
I had a .gitlab-ci.yml from a while back that I didn't commit yet and it had a make, which is unnecessary
1:07:20
aeth
no-defun-allowed: You might want to fail the CI if there are style warnings or compilation errors. You could verbose the quickload but that also makes... everything else verbose
1:08:48
aeth
So what I did wrong in my YAML from earlier is I had the wrong clone syntax and I was relying on a make file
1:15:13
aeth
make sure not to fail on notes because there are lots of stuff like "hey you're using rationals, we'd like if you didn't"
1:16:11
aeth
no-defun-allowed: You might want to turn on sb-ext:*derive-function-types* in your CI and in your build step in SBCL
1:16:33
aeth
That turns on full type inference, but at the cost of assuming that a redefined function must have the same ftype
1:18:19
no-defun-allowed
maybe i should put this in a script so i can just do `sbcl --script tests.lisp`
1:46:04
no-defun-allowed
aeth: i got an error: https://gitlab.com/netfarm.gq/netfarm/-/jobs/108420689
1:47:05
no-defun-allowed
it probably is sbcl putting out notes for other packages where SPEED 3 is used but idc
2:08:48
aeth
This is what I'm currently running: https://gitlab.com/zombie-raptor/zombie-raptor/blob/b90f23cf6168f892fce8fd980649eaf882662acb/.gitlab-ci.yml https://gitlab.com/zombie-raptor/zombie-raptor/blob/b90f23cf6168f892fce8fd980649eaf882662acb/tests/test-script.lisp
2:09:10
aeth
It looks like it finally works: https://gitlab.com/zombie-raptor/zombie-raptor/-/jobs/108423265
2:09:41
aeth
I'm not sure if the type errors would stop the job as a failure, though, because iirc they're just style-warnings, not errors
2:14:56
aeth
Hmm... It looks like, no, the type errors are caught at runtime in my tests, not at compile time.
2:35:43
stylewarning
slightlycyborg: it's a short way to say "if the argument is nil, move on, otherwise do what's in the brackets"
2:36:08
stylewarning
slightlycyborg: the designers of FORMAT were pretty well aware of the kind of use-case you're looking at: a function which returns useful stuff most of the time but NIL sometimes
5:45:33
jackdaniel
russellw: maybe with (defun reference (array &rest subscripts) (if (apply #'array-in-bounds-p array subscripts) (apply #'aref …) (error (make-condition 'out-of-bounds))) ;?
5:46:21
jackdaniel
if you do not care about portability, you may of course reach to implementation conditions if they exist
5:47:26
jack_rabbit
I'd be surprised there's not some library somewhere that has implemented implementation-specific checks for these error conditions.
5:50:15
jack_rabbit
I'm sort of surprised that a specific error type isn't specified for out-of-bounds conditions.
5:50:45
russellw
hmm! What about something like opening a nonexistent file? Is there any way to catch that?
5:52:55
jackdaniel
if you want something more specifc, then I can only propose similar solution to the one proposed before
5:54:36
jackdaniel
or handle file-error, access fire-error-pathname, check it out with probe-file and signal your own condition if it does not exist (otherwise resignal condition you have received)
5:56:54
russellw
Suppose you are generating errors yourself - say writing a parser, that must signal errors. For that, you could use handle-case and define a suitable error, right? But is there a reason not to just use throw and catch instead? That would seem simpler?
5:59:52
russellw
Oh yes indeed, there is a nice tutorial about it at http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html and it's good that all those features are there for people who need them. But all I need is the ability to throw and catch errors :)
6:00:31
aeth
I should correct myself, type errors are warnings, not style-warnings. But not compilation errors, either.
6:00:41
jackdaniel
I have this: https://lisper.in/restarts but I'm not sure if this is the one I have remembered being so good
6:01:13
jackdaniel
if all you need is throw/catch, then you need a throw/catch and claiming otherwise would be denying a tautology ;-)
6:02:29
aeth
jack_rabbit: That's a flaw in the spec imo. It's really random what kind of error you could see for common things.
6:03:02
jackdaniel
I've been debugging McCLIM internal mechanism (one of the downstream functions which does not have access to the screen - no medium argument)
6:03:28
jackdaniel
and I wanted to display a rectangle of the pixarray size (without disrupting computation)
6:04:18
jackdaniel
so I've defined a display-rectangle-condition and signalled it from this function. it was handled higher on the call stack with handler-bind, rectangle was displayed and downstream function working has been continued after that
6:04:41
jackdaniel
when I didn't want to handle it I've simply removed handler bind and despite being signalled condition was ignored