00:29:44  <daurnimator>Yorlik: if someone messes with require yell at them
00:29:53  <Yorlik>lol
00:30:18  <Yorlik>Actually they had to mess with it
00:30:31  <daurnimator>Yorlik: require already *officially* supports changing behaviour with package.searchers. if someone changes the 'require' function itself they are doing something 'wrong'
00:31:30  <Yorlik>When modding the server, you can use: require "default:somescript" inside your own somescript.lua
00:32:04  <Yorlik>Also they have a special setup which caches certain scripts while running multiple VMs and contexts
00:32:29  <Yorlik>Its not too bad and after all we can use the native require by calling lua_require
00:32:34  <daurnimator>Yorlik: require will happily pass on default:somescript to your custom package.searcher.
00:32:44  <Yorlik>But I'd prefer they had just introduced their own function name
00:33:22  <Yorlik>I'm not that familiar with package searchers. how do they work ? I only know about the paths wioth the many question markis
00:34:38  <daurnimator>Yorlik: check the docs :) http://www.lua.org/manual/5.3/manual.html#pdf-require
00:34:45  <Yorlik>KK
00:34:56  <Yorlik>I must haver overread that when reading the book
02:11:09  * DarkGodquit (Ping timeout: 252 seconds)
06:20:03  * creationix_quit (Ping timeout: 245 seconds)
06:21:29  * creationix_joined
07:01:29  * rendarjoined
07:09:08  <Yorlik>Seems i just spent the night building various libraries from the Lua Universe in 32 and 64 bit.
07:09:57  <Yorlik>Building in Lualands can cost you your sanity. I'm no longer sane.
07:32:11  * CapsAdminjoined
09:24:02  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
09:46:48  * rendarjoined
10:03:26  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
16:29:25  * SkyRocknRolljoined
16:32:56  * SkyRocknRollquit (Read error: Connection reset by peer)
16:46:18  * SkyRocknRolljoined
17:46:17  * SkyRocknRollquit (Ping timeout: 258 seconds)
18:00:08  * SkyRocknRolljoined
18:36:23  * SkyRocknRollquit (Ping timeout: 260 seconds)
19:04:04  * rgrinbergjoined
20:46:32  * grncdrjoined
20:46:37  <grncdr>hi again ;)
20:46:43  <creationix>hi
20:46:57  <creationix>we'll see if will joins
20:47:40  <creationix>grncdr so my basic idea is to do away with fs based dependency trees
20:48:01  <creationix>lit (luvit's package manager) already has a CAS based backend for caching packages
20:48:16  <creationix>but I'm trying to see if it's feasable to require directly out of it
20:48:22  <grncdr>ah nice
20:48:26  <creationix>(the db is written in luvit so library support is not a problem)
20:48:41  <grncdr>what is a "package" in luvit? many files or a single one?
20:48:46  <creationix>I'm more concerned about what the new semantics will be
20:48:54  <creationix>currently it is either a single file or a single tree
20:49:13  * dtzWilljoined
20:49:14  <dtzWill>o/
20:49:23  <creationix>hi will
20:49:25  <grncdr>👋
20:49:56  <creationix>dtzWill http://logs.nodejs.org/luvit/latest
20:50:10  <dtzWill>haha yep, looking at them presently (ᵔᴥᵔ)
20:50:31  <creationix>oh, I forgot I put a link in the topic. that's handy
20:50:35  <dtzWill>:D
20:50:54  <grncdr>ok so... can you do things like require("that-package/lib/whatever") ?
20:51:11  <creationix>grncdr right, the require semantics are very close to node's algorithm
20:51:47  <grncdr>ok so! I'll talk a bit about what I did before
20:51:48  <creationix>there is relative requires and package requires that look in the ./deps/$foo ../deps/$foo ../../deps/$foo, etc
20:52:09  <grncdr>well not yet actually, I have more questions... :P
20:52:20  <creationix>I'm willing to change semantics a bit if it helps
20:52:30  <grncdr>do you try and dedupe compatible versions?
20:52:34  <creationix>lua already has it's own require system that is extensible, but not enough
20:52:42  <creationix>grncdr lit doesn't dedupe automatically
20:52:56  <creationix>err, I mean it doesn't do deep trees automatically
20:52:57  <grncdr>ok that's kind of nice
20:53:21  <creationix>lit assumes you have no conflicts and puts all deep dependencies in a single flat tree at ./deps/
20:53:22  <grncdr>ah, so no `lit_modules/child/lit_modules/child` ?
20:53:31  <grncdr>nice nice
20:53:36  <creationix>not automatically, but require supports it
20:53:41  <grncdr>got it
20:53:46  <dtzWill>(there's lots of interesting ways to do dedup--syntactic equivalence as a start and moving upwards--depending on what you're looking for)
20:53:47  <creationix>or rather, my require replacement
20:53:57  <creationix>lua's require is based on global system paths
20:53:59  <dtzWill>but without knowing more about the domain I'd imagine there's a natural granularity for such :)
20:54:28  <creationix>dtzWill personally, I'd like it very granular
20:54:48  <grncdr>ok super good then :)
20:54:48  <creationix>when I was designing a greenfield programming language I had a really nice system where each function was a "package" of sorts
20:55:12  <grncdr>was this Jack? (I think you might have renamed it at some point?) ^
20:55:36  <creationix>I don't remember if that one was jack syntax
20:55:48  <creationix>I've got several new languages in addition to jack aimed more at embedded
20:56:03  <dtzWill>FWIW my current ambitious endeavor is exploring this sort of idea across an entire system (where system==commodity OS, like linux/freebsd)--as an important part of a project I'm leading called "ALLVM"-- creating a system where everything is available as LLVM IR
20:56:07  <dtzWill>(for great justice)
20:56:37  <creationix>dtzWill is there a single IR layer in llvm?
20:56:42  <creationix>and is it portable?
20:56:49  <dtzWill>and so things like content-addressable and flexible granularity are things I have lots of notes on O:)
20:56:59  <creationix>now with luvit, we have luajit bytecode. That's pretty portable
20:57:28  <dtzWill>well there' mostly a single primary IR layer, but it's not what I'd call portable (not arch-indep for sure)
20:58:17  <creationix>let me see if I can find a link to the system I designed
20:58:19  <dtzWill>in fact I'm much mre interested in the ideas and challenges than LLVM per-se--honestly LLVM IR itself is more of a convenient temporary solution we're using while putting this together and showing why it's such a useful way to do things
20:58:43  <dtzWill>(and iff we're successful we can get folks working on a better format, was my plan)
20:58:52  <creationix>webasm could be another target
20:59:11  <creationix>I believe it's portable since it's meant to be run in any browser unmodified
20:59:22  <grncdr>creationix: so my previous experience was with JS (or anything that could compile to it...)
20:59:37  <dtzWill>but since there's so much code that exists as LLVM IR at some point in its lifetime, it's a useful format to show how powerful this can be (and how much better systems can be if we free ourselves from things like ... file-based resolution and ELF and such)
20:59:58  <dtzWill>creationix: yeah webasm is compelling in that regard--and yep I've spoken with them and basically it has the other problem
21:00:05  <grncdr>I built a system that stored & linked together modules (not packages) out of IPFS
21:00:21  <dtzWill>it's a solid distribution format but a lot less analyzable/useful for the sort of compiler-y things I'd like to see happen
21:00:27  <creationix>grncdr so the file/module was the unit of granularity?
21:00:34  <grncdr>yes
21:00:43  <grncdr>and a (really crappy) editor that let you edit code / jump between modules and introduce new versions
21:01:02  <dtzWill>haha :D awesome
21:01:10  <creationix>grncdr that's the part I'm interested in. How do you describe links/dependencies
21:01:12  <grncdr>this was a commonjs style module, so the unit of granularity was really a function scope
21:01:14  <creationix>hashes are opaque and a pain to update
21:01:32  <grncdr>yes, this is hard
21:01:37  <creationix>though I guess ipfs gives you path-based resolution
21:01:59  <grncdr>so the main thing is if you're willing to accept _any_ centralized points of failure
21:02:23  <grncdr>although, IPFS has gotten quite a few new features since I did this
21:02:44  <creationix>ideally I'd like a system where I can describe dependencies using semver or something symbolic that can resolve to a hash tree at any point in time. But I also want to be able to snapshot a concrete dependency tree
21:02:54  <dtzWill>(did y'all see https://github.com/whyrusleeping/gx ?)
21:03:11  <grncdr>ah yes, gx is pretty nice
21:03:26  <dtzWill>and I'd like to reiterate the pointer to systems like Nix (and Guix) in terms of expressing dependencies and using a hashed store and whatnot
21:04:14  <creationix>the reproducible builds of nix is really nice
21:04:39  <creationix>with lit I have a somewhat nice compromise. Dependencies are declared as name + semver
21:05:02  <grncdr>any sort of lockfile mechanism?
21:05:10  <creationix>but when you publish anything that depends on other packages, it will take a snapshot of the current dependency tree and store that as well in the package metadata
21:05:19  <creationix>and in lit you can publish apps and libraries
21:05:29  <dtzWill>oh okay so you perhaps have a bit more control/sanity in terms of some of the versioning challenges (Which is easier in some ways, but harder in others hehe)
21:05:32  * dtzWilllistens
21:05:39  <creationix>if you do `lit install creationix/luvit` it will look for the latest luvit release and it's frozen tree of hashes
21:06:21  <creationix>so basically, dynamic resolution from symbolic versions to concrete hashes is done at publish time and the snapshot is used at install time
21:06:41  <creationix>and it's deep, not recursive. I don't have to wait for deep dependencies to republish to get updated to their dependencies
21:07:11  <creationix>if that makes sense
21:07:48  <grncdr>I think so
21:08:26  <creationix>so if you know npm's shrinkwrap feature, lit does this by default for applications, but stays fluid for libraries
21:08:38  <dtzWill>a deps on b (a -> b), b -> c, you wanna be able to bump c and use the new version in a without needing 'b' to be changed/republished/processed?
21:08:41  <creationix>the app developer is responsible to test their dependency tree when publishing
21:08:56  <dtzWill>i guess basically the different between a-> (b->c) vs a->{b,c}
21:08:58  <creationix>dtzWill correct. my current systems has that
21:09:12  <creationix>my problem is that the actual runtime implementation depends on lit dumping the files to the disk in a folder
21:09:18  <creationix>and hoping there are no name or version conflicts
21:09:25  <grncdr>it sounds like you're very close to having everything in a CAS anyways
21:09:47  <creationix>right, I just need to design semantics for an alternative require that pulls directly from the local db
21:09:54  <creationix>it can even pull down hashes on-demand and cache them
21:09:58  <dtzWill>neat! obviously that's only possible in worlds where you can do things like what you're describing--fair part of my ALLVM project is bringing that sort of sanity to 'native' software :)
21:10:00  <grncdr>yeah, so at runtime, you need to resolve names to hashes
21:10:08  <dtzWill>mmhmm
21:10:21  <grncdr>in my system a module was an object containing hashes
21:10:37  <creationix>maybe I could have a command to manually take a snapshot and store it in a file
21:10:53  <creationix>instead of dumping files, dump a single file with mapping of paths to hashes
21:10:57  <grncdr>the structure was roughly { source: $hash1, deps: { dep1: $hash2, dep3: $hash4 } }
21:11:11  <creationix>yeah, something like that
21:11:21  <dtzWill>just like a nix derivation (.drv) file! lol O:)
21:11:40  <creationix>I would love to be able to do `lit run $hash` and just run that hash as an app
21:11:55  <creationix>or create a tiny unix file with that in the shebang
21:11:57  <dtzWill>not at all saying Nix does everything you want, but often useful to learn from other things to steal their good ideas :D ;)
21:12:04  <grncdr>when the source pointed at by $hash1 was loaded, it would be evaluated in a scope where `dep1` was a reference to the already loaded $hash2
21:12:04  <dtzWill>haha, like nix-shell! O:)
21:12:04  <creationix>the dependency graph can be the body of the script
21:12:23  <dtzWill>well kinda not like Nix too O:)
21:12:29  <creationix>I had a friend that works at nix, I should look closer at what they do
21:12:52  <creationix>currently in luvit / lit apps are just the luvi binary + a zip file containing the app and all dependencies
21:12:53  <grncdr>there were some other neat features (compilers...) but I think compile-to-lua languages are a bit less common than for JS?
21:12:58  <dtzWill>creationix: /perfect/, it's hard to understand/get into at first in my experience, and someone who knows you well AND knows Nix can probably get you the parts that are useful to you fastest :)
21:13:12  <creationix>I have a feature where you can have a shebang line pointing to luvi followed by the zip
21:13:34  <dtzWill>this is a fantastic opportunity for me to revive my project to make a lua backend for LLVM lol
21:13:43  <dtzWill>and by revive I mean "start it, for real this time"
21:13:45  <creationix>grncdr right, there is moonscript (coffeescript for lua), but it's not that popular
21:13:55  * dtzWillseriously looked at luajit as the base of things previously
21:14:00  <creationix>one interesting thing is lua has first-class support for bytecode
21:14:11  <creationix>you can load lua source or bytecode that it runs either wahy
21:14:46  <creationix>I've seriously considered making my homegrown languages emit luajit bytecode, but it forced my semantics to become too lua like
21:14:49  <dtzWill>mostly I was going to do it because I really couldn't understand why no one even really tried--I mean with empscripten and whatnot... and LLVM's JIT is ... well let's just say the famous LuaJIT could probably do some neat things :)
21:14:53  <grncdr>yeah, so you would probably want 2 pointers, $sourceHash & $bytecodeHash
21:15:11  <dtzWill>(is source -> bytecode not a deterministic process?)
21:15:26  <creationix>now I also need the ability to run from a folder for dev mode
21:15:36  <dtzWill>(at least when parameterized by like, compiler version or something? O:))
21:15:40  <creationix>with a mix of local dependencies and interned dependencies
21:15:54  <dtzWill>hehe :D
21:16:18  <grncdr>so you implement your own `require` that does the node thing of "if path starts with a `.` resolve as a relative file" right?
21:16:20  <creationix>with luvi we've solved that pretty well. You can have files in a folder or a zip file or appended to luvit itself. It runs the same
21:16:30  <creationix>grncdr right
21:16:44  <creationix>but if there are no paths anymore, I'm not sure what that would mean
21:16:56  <grncdr>well, there are paths in dev mode
21:17:05  <dtzWill>naming is a challenge, indeed
21:17:07  <dtzWill>oh errm. hmm.
21:17:14  <creationix>right, and I don't want to have to update my paths to hashes when I publish
21:17:15  <grncdr>and if you were using e.g. IPFS, you can have relative paths trivially
21:17:19  <creationix>not manually at least
21:17:59  <grncdr>like, I was using the unixfs stuff in IPFS
21:18:11  <creationix>makes sense
21:18:38  <grncdr>(for the `source` and in your case `bytecode` hashes)
21:19:24  <grncdr>so the only place you need symbolic mapping is non-relative package names
21:19:40  <grncdr>the stuff that would be resolved out of `./deps` now
21:20:02  <dtzWill>(relative packages == named by relative path from source?)
21:20:09  <creationix>yeah, I guess relative requires could work within a multi-file package
21:20:09  <grncdr>yes
21:20:19  <dtzWill>(ty)
21:20:54  <grncdr>creationix: I _might_ have some of the JS I wrote for this project _somewhere_ but no guarantees it even works
21:21:01  <grncdr>the whole project was eaten by hubris :P
21:21:16  <creationix>grncdr that's fine. I'm more worried about the semantics than actual implementation
21:21:49  <grncdr>yeah, you're familiar enough with how node & browser bundlers work that you can fill in the blanks I think :)
21:22:01  <dtzWill>aw man, well said grncdr O:)
21:22:34  <grncdr>dtzWill: quite literally, I made it self-hosting too soon, stopped working on it for a couple of months, all the hashes were expired from IPFS :P
21:22:44  <dtzWill>and I'm /not/ particularly familiar with some of the systems y'all are talking about but I would say that indeed most of the challenge is sorting out a consistent set of desirable behavior
21:23:01  <dtzWill>grncdr: lmao, I, uh, am definitely not stalling in the wake of my self-hosting blitz
21:23:08  <dtzWill>certainly not! O:)
21:23:11  <creationix>exactly
21:23:14  <grncdr>:)
21:23:23  <grncdr>creationix: does lit use a registry?
21:23:25  <creationix>for history, here was the last attempt at adding relative requires to lua's native require https://github.com/luvit/luvit/pull/932
21:23:31  <creationix>tl;dr, it's impossible
21:23:38  <APNG>creationix, is there any way I can get normal require in luvit 2.x?
21:23:45  <creationix>grncdr it does
21:23:53  <creationix>APNG it should fall back to native require
21:24:04  <dtzWill>but mostly I'm happy with what I ahve and see lots of possibilities.. just need to pick a few and march on O:)
21:24:05  * dtzWillreads
21:24:11  <creationix>APNG: also if you use luvi directly instead of luvit, it doesn't replace require
21:24:44  <creationix>grncdr the registry is namespaced to github usernames. People authenticate with their private ssh keys
21:25:00  <creationix>the server itself is just a copy of lit running in server mode, the database is identical
21:25:01  <APNG>creationix, well any way to fallback to bastardized require instead?
21:25:20  <creationix>APNG what are you trying to do? I think _G.require is the real one in luvit 2.x
21:25:31  <creationix>the replacement require is a local variable in the created closure
21:25:35  <APNG>creationix, well I wanna be able to return a module
21:26:17  <creationix>grncdr https://luvit.io/lit.html
21:26:41  <creationix>so currently, packages declare dependencies with name and semver combo just like npm. Except all packages are namespaced
21:27:11  <creationix>plus the extra snapshot I mentioned before that is used when deploying/building an app (vs depending on a library)
21:29:48  <creationix>For example, here is the metadata for the luvit CLI tool itself https://lit.luvit.io/packages/luvit/luvit/latest
21:29:59  <creationix>the "snapshot" property is a literal git tree hash
21:30:15  <creationix>(lit's db uses git compatible trees/tags/blobs for it's CAS)
21:30:15  <APNG>creationix, you know, with `return M` and stuff
21:30:28  <creationix>APNG luvit's require supports returning a module
21:30:32  <APNG>creationix, I also wanna be able to do package.loaded[...] = M at the top of my module (allows cyclic requires)
21:30:40  <dtzWill>haha okay that's super cool that it actually creates git tree hashes
21:31:08  <APNG>creationix, in other words I wanna be able to use normal lua cyclic modules in luvit
21:31:11  <creationix>dtzWill I publish a backup of the database to github
21:31:13  <creationix>speaking of, I should update that
21:31:25  <dtzWill>hahaha, brilliant! :D
21:31:48  <dtzWill>honestly it's a pretty great storage format for a lot of things... and yay free backup
21:32:11  <grncdr>creationix: you've mentioned a couple of times that your concern is with semantics, do you have any specific worries?
21:32:15  <creationix>new backup pushed! https://github.com/luvit/lit-backup
21:32:33  <creationix>though since everything is a git tag pointing directly to a git tree, github's UI doesn't allow browsing
21:33:42  <creationix>APNG I think you'll be happier using luv with normal lua
21:33:51  <creationix>or at least making a luvi based app directly and not using luvit
21:34:10  <creationix>luvit has a lot of conventions that make it hard to mix in lua packages from the greater ecosystem
21:34:34  <creationix>I'm trying to fix this in luvit 3.x, but it doesn't seem possible without dropping luvit style requires entirely
21:34:43  <APNG>creationix, uh
21:34:43  <creationix>(thus the desire to make an alternative system)
21:34:57  <APNG>you could wrap require such that it does some name mangling before calling the native require
21:35:29  <creationix>APNG luvit require doesn't call native require at all (unless there is no match found)
21:35:48  <creationix>it's got it's own cache apart from package.loaded
21:36:03  <APNG>and that's stupid as it breaks lua modules
21:36:11  <APNG>like luvirt
21:36:18  <creationix>lua modules break libuv
21:36:25  <APNG>how?
21:36:27  <creationix>anything that does sync I/O will break the event loop
21:36:36  <creationix>originally I made it incompatible on purpose
21:36:40  <creationix>to avoid such problems
21:37:07  <APNG>you do realize lua require doesn't actually do sync I/O right?
21:37:26  <creationix>require is a process startup thing, sync is fine
21:37:42  <creationix>I'm talking about some DB driver blocking the main thread while waiting for postgresql to return a result
21:37:49  <APNG>no I mean you do realize the sync I/O is in the loader, not in require itself, right?
21:38:03  <creationix>and your entire high-performance webserver comes to a screaching halt.
21:38:04  <APNG>so just replace the loader
21:38:18  <APNG>or searcher, w/e it's called in luajit
21:38:20  <creationix>I'm not worried about sync require
21:38:31  <creationix>I'm worried about loading libraries that block on I/O later
21:38:46  <APNG>oh
21:38:53  <APNG>tried replacing the native iolib?
21:39:05  <dtzWill>alright awesome stuff I gotta run, hope you don't mind if I lurk, look forward to seeing where this goes and chatting about it some more :). Thanks folks! o/
21:39:13  <creationix>dtzWill thanks
21:39:20  <creationix>APNG did you see this? https://luvit.io/blog/pure-luv.html
21:39:22  <APNG>https://github.com/SoniEx2/Luva/blob/master/src/liolib.lua
21:39:37  <creationix>I explicitly made this path for people wanting to mix with luarocks
21:39:43  <APNG>(that repo is awful btw, https://github.com/SoniEx2/Luva/blob/master/src/Makefile )
21:39:56  <dtzWill>i know I have a stack of references that'd be interesting somewhere, but not finding them immediately. Will see if can't turn them up :)
21:40:36  <creationix>APNG I suppose you could replace the standard I/O stack with something coroutine based so that blocking APIs could be using inside a coroutine without blocking the main thread
21:40:55  <creationix>but not all third-party I/O is extensible.
21:41:19  <APNG>creationix, I know a Minecraft mod that does that
21:41:40  <creationix>grncdr I don't have concerns per se. I'm just trying to understand the scope how it would work
21:41:41  <APNG>uh, yeah... that MC mod doesn't let you do native code... :P
21:43:33  <creationix>grncdr I have a crazy idea. What if there was a way to overlay git hashes onto the fs used by the require system
21:43:55  <creationix>it would still be path based, but I could overlay immutable trees (like the dependency snapshot already published)
21:44:26  <APNG>creationix, how well does luvit handle graph-based filesystems?
21:44:33  <APNG>(e.g. hardlinks)
21:44:44  <APNG>(to directories*)
21:44:46  <creationix>APNG fine I would assume
21:44:54  <grncdr>I actually did something like this in an alternate npm once ^
21:44:56  <creationix>that's more a libuv or linux question
21:45:07  <APNG>creationix, linux doesn't have them
21:45:11  <creationix>grncdr this is basically how docker containers are setup right?
21:45:23  <creationix>dependencies are snapshotted and layered under mutable or local fs
21:45:27  <APNG>I'm not talking about linux
21:45:28  <grncdr>no idea, I've thus far avoided peaking under the hood of docker
21:45:33  <APNG>just graph-based FS in general
21:45:49  <creationix>APNG luvit doesn't know anything about filesystems other than it's interaction with libuv
21:45:56  <creationix>which uses posix APIs on unix
21:46:02  <APNG>does libuv support virtual FS?
21:46:20  <creationix>APNG nothing on top of what the OS provides
21:46:27  <APNG>meh ok
21:46:58  <APNG>how well does libuv handle graph-based FS then?
21:47:11  <APNG>assuming a BSD with hardlinks to dirs
21:47:20  <creationix>grncdr it's not the fine granularity I want, but it does make mapping with the fs easier
21:47:32  <grncdr>creationix: the thing I made put all the source in one place, then filled `node_modules` with appropriate symlinks so packages would resolve.
21:47:48  <creationix>grncdr that's one way to do it
21:48:05  <grncdr>(it did some other gnarly stuff regarding semver that somehow made the above seem reasonable)
21:48:10  <creationix>I'd love to go full graph, but then I need a dev workflow that's not fs based
21:48:22  <creationix>as I know from my other experiments, that is hard
21:48:29  <grncdr>yes :)
21:48:35  <grncdr>very hard
21:48:46  <grncdr>so my symlink hackery worked surprisingly well
21:48:54  <creationix>dev tools are so much entrenched in text files in filesystems, it's riduclous
21:48:58  <grncdr>at least, it wasn't the thing that killed that project
21:49:13  <APNG>I hate trees
21:49:36  <creationix>APNG libuv can't see hardlinks, they just look like duplicate data
21:49:40  <APNG>they're so limited
21:49:47  <APNG>creationix, meh
21:49:51  <APNG>:/
21:49:52  <creationix>that's part of posix, nothing to do with luvit
21:50:15  <APNG>creationix, ok it's fine if it just sees duplicate data
21:50:25  <grncdr>creationix: one thing to consider when you have files on disk, people will edit them
21:50:26  <APNG>but it doesn't track inodes to avoid infinite loops?
21:50:27  <creationix>like I said, it should work as far as I know
21:50:41  <grncdr>and their content becomes inconsistent with their known hashes
21:50:41  <APNG>(or w/e the file-level "UUIDs" are called)
21:50:57  <creationix>APNG no, I don't have algorithms that recursivly walk trees
21:51:28  <creationix>grncdr yeah. With git this is less of an issue since they are a royal pain to edit
21:51:34  <APNG>ok
21:51:38  <APNG>that sucks
21:51:40  <creationix>the files are named by hash and the contents are deflated
21:51:44  <APNG>because then everyone implements their own
21:51:52  <APNG>so yeah >.<
21:52:12  <grncdr>creationix: that's a nice impediment
21:52:12  <creationix>APNG I have no idea what you're asking for. Libuv provides low-level OS-level apis similar to posix
21:52:46  <APNG>creationix, but not a way to visit every child of a directory?
21:52:58  <creationix>grncdr and when I say deflated, I don't mean gzip, I mean raw deflate. No system that I know of has out of the box tools for working with them. Just APIS in zlib
21:53:25  <creationix>APNG there is scandir, but you, the coder needs to write recursion if you want it
21:53:34  <creationix>and stat does give you inodes so you can track them
21:53:46  <APNG>creationix, but does anyone? :/
21:54:20  <creationix>luvit hardly has users to begin with. I've never heard of anyone writing that kind of code
21:54:37  <APNG>I wish POSIX had high-level, object-oriented FS APIs
21:54:42  <creationix>APNG sounds like a great library to write and publish to lit
21:55:09  <APNG>no paths
21:55:11  <creationix>then others can reuse your code and luvit's scope doesn't have to explode to support it
21:55:46  <creationix>grncdr I've got to go work on other stuff, thanks for helping me think things through
21:56:03  * DarkGodjoined
21:56:29  <grncdr>creationix: I imagine that if you had a package-local mapping of `depname` to a hash, and keep only byte code in the "object store" you don't have to worry too much about the problem of people changing "immutable" data
21:56:36  <creationix>APNG I don't wish posix had high-level APIs for things that almost nobody uses. Then all implementations of posix would have that much more work to do
21:56:40  <APNG>FSNode* root = get_root_node(); FSNode** children = get_children_nodes(root); FSNode* child = children[0]; etc
21:56:49  <creationix>they expose the needed primitives to implement it yourself. As does luvit
21:57:05  <APNG>no idea if my C is correct tho
21:57:11  <creationix>and lit even provides an easy way to publish and share your code so others can reuse it
21:57:26  <APNG>ok
21:57:48  <creationix>I'm sure it's a great interface for certain workloads
21:57:57  <creationix>just not something that fits in luvit or libuv or posix
21:58:08  <grncdr>then you would want some sort of "checkout for development" command that modifies (or overlays) the name->hash mapping to say "actually name should be loaded from this directory over here"
21:58:09  <creationix>it's perfect for a library written on top
21:58:20  <creationix>grncdr that could work
21:58:32  <creationix>manual commands to start and leave dev mode is just fine
21:58:36  <APNG>creationix, I mean the API I listed above would still allow you to loop on hardlinks...
21:58:44  <APNG>it'd just not have any paths
21:58:57  <APNG>no concept of a path
21:59:11  <APNG>/ in file names
21:59:32  <grncdr>creationix: yes, your "publish" action would then compile modified sources to new byte codes, hash that, and update the dependency pointer
21:59:40  <grncdr>s/pointer/hash/
21:59:41  <creationix>APNG all graphs have paths. If you don't name the entries then it's just 1.4.3.12 where the numbers are indexes in the parents
22:00:11  <creationix>grncdr oh, so replace git workflow
22:00:25  <creationix>I could checkout a previously published project, edit it, and save it back to the graph
22:01:00  <grncdr>yes
22:01:07  <grncdr>but rather than say "replace git"
22:01:21  <creationix>grncdr did you see my revision.studio project?
22:01:22  <grncdr>I think it makes more sense to say "publish packages more like git tags"
22:01:29  <grncdr>I don't think so
22:01:30  <creationix>grncdr right and it can acually use git
22:01:32  <grncdr>I saw Tedit
22:01:49  <grncdr>but I don't remember revision.studio
22:02:09  <APNG>creationix, yeah but paths in a tree is a completely different thing from paths in a graph
22:02:40  <creationix>not really, only difference is tree paths are unique while a node in a graph has infinite possible paths
22:03:11  <creationix>A tree is simply a graph with no cycles
22:03:54  <creationix>grncdr when you have time https://www.youtube.com/watch?v=X7AmdsXpUMI
22:04:20  <creationix>the basic idea is a web-based IDE where you checkout from a lit-style graph, edit files, running locally and then publish back to get a new hash
22:04:32  <creationix>someone else can checkout your hash, edit and then publish their own hash
22:04:38  <APNG>creationix, a node in a graph may have* infinite possible paths
22:04:39  <creationix>it also supports importing from github to bootstrap projects
22:06:03  <creationix>APNG know what the part of a graph that doesn't have infinite paths is called? a tree
22:06:44  <creationix>anyway, I don't see point in arguing pendantics.
22:06:58  <creationix>graphs are cool, filesystems are trees (unless your allow hardlinks)
22:07:36  <creationix>making an OO graph abstraction on top of filesystems with hardlinks would make for a neat lit package
22:08:19  <grncdr>creationix: oh nice, this is very very similar to the project I was talking about earlier
22:08:26  <grncdr>except, you know, it seems to work :P
22:08:36  <creationix>I havn't worked on it since the talk. There has been very little interest
22:08:55  <creationix>probably because it's in an alpha state. Most people expect more polish before jumping onboard
22:09:01  <grncdr>hm, that's too bad
22:09:09  <grncdr>btw, your cert expired 2 days ago
22:09:25  <creationix>I should stop ignoring emails from lets encrypt
22:09:35  <creationix>really I should automate it
22:09:41  <grncdr>indeed
22:09:56  <creationix>hmm, Permission denied (publickey).
22:10:20  <creationix>I've formatted my machine since I set that up. I think I used the wrong ssh key for login
22:10:45  * CapsAdminquit (Remote host closed the connection)
22:13:24  * CapsAdminjoined
22:13:46  <creationix>oh well, dinner time
22:25:37  <APNG>creationix, there are no trees