freenode/#lisp - IRC Chatlog
Search
12:56:53
jcowan
beach: I may have mentioned this before, but a good object store should have knowledge of which properties subsume which other properties, which allows the easy recovery of flexible hierarchies.
13:05:54
jcowan
If property A subsumes property B, then (treating them wlg as binary properties) anything with B but not A is treated as a direct child of B, whereas anything with both A and B is treated as a direct child of A. Posix operations mkdir and rmdir establish and disestablish subsumption.
13:10:00
jcowan
(Hmm, that may be wrong; I tend to get A subsumes B and B subsumes A mixed up, but it is correct modulo that.)
13:11:59
jcowan
not that there is anything wrong with links, the idea is to make a directory structure fall out of the meta-information about properties
13:16:15
jcowan
if we are examining the contributors to a paper using our object store, then we see all the contributors listed under the node "contributor". If we then add the information that Alice and Bob are authors, Charlie is an editor, and we do not know what kind of contributor Dave is, we will see three parallel nodes 'author', 'editor', contributor', whose children are Alice + Bob, Charlie, Alice + Bob + Charlie + Dave respectively.
13:16:58
jcowan
But if we now add the metainformation that author and editor are subproperties of contributor, then things change: under contributor we still see Dave, but we also see subdirectories author and editor.
13:21:11
flip214
jcowan: I meant the "links" not as in filesystem links, but as parent-child relationships; you wrote "mkdir" and "rmdir" operations, but don't see how "mkdir" can register a connection between two already existing things
13:24:33
jcowan
The effect of mkdir(A, B) is that directory B becomes a child of directory A. The fact that a directory cannot be the child of more than one directory is due to the problems early Unix encountered with an arbitrary directory graph (it needs memory to traverse and potentially a garbage collector to eliminate or restore closed loops).
13:24:49
jcowan
These issues are now pushed off onto the batch tool fsck, but in a Lisp OS they should be and are an inherent part of the system.
13:25:16
jcowan
Likewise, rmdir removes the parent-child relationship between two directories, and only destroys the former child because it knows that there is no other parent.
13:27:57
flip214
jcowan: yeah, but your example had _preexisting_ things - contributor and author - and for that _my_ view would be "link author contributor/" to establish an "is a" relationship
13:28:48
jcowan
Properties are lightweight: there is no reason to distinguish between creation and reuse.
13:29:46
jcowan
Something I am shoving under the rug is that Posix file graphs have named edges, whereas this one has named nodes. However, people almost always treat Posix files as if they had names.
13:36:59
Bike
yes. declaring the types of arguments in a function tells the compiler what those variables in the function body will be. declaring the type of a function tells the compiler what the types of inputs to and outputs from a function call are.
16:49:00
beach
Hello frodef. Ju just showed up when my (admittedly small) family announced that dinner is ready.
17:16:02
LdBeth
beach: what do you think about integrating object oriented access control? The basic principle is given here http://www.object-oriented-security.org
17:47:30
beach
LdBeth: Thanks for the link. I am too tired to read it today, but I'll have a look tomorrow. I may have to be reminded.
17:58:03
shka_
i have other object, it full fills the same protocol, but it happens to have file that should be closed
17:59:09
shka_
now i lost way to close my file, because proxy can't implement every possible functions
18:00:36
shka_
1) add auto forwarding into proxy (default implementation of generic function will call something like pass-along with it's arguments and the right function so proxy won't have to be bothered with it)
18:01:24
shka_
2) some sort of taint (everything that touches file object produces proxy object that also will be file object
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.