log
349 entries in 0.398s
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L65 << incidentally this is erroneous. a correctly-inited FG will never produce interrupt ( the tty ~must not~ interpret 0x03 as control char, it must return all octets verbatim )
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L84 << seems like you re-init the usb dongle every time you read. this is not recommended, i've encountered a chinese ttl plug that wedges if you init it one too many times
asciilifeform: diana_coman: is http://btcbase.org/patches/eucrypt_manifest/tree/ current ?
mod6: Hm, I wasn't taking about the manifest thing really, which is another whole question not completely answered.
asciilifeform: mod6: there's the manifest thing; what else was there
asciilifeform currently writing a manifest, goes 'down'
mod6: After looking at PeterL's blogpost, was curious if there had been any consideration into if a manifest file should grow up or down (i.e. newest change first, or newest change last in the file). This is purely a cosmetic thing, I suppose it would be up to the author too. Probably why trinque didn't touch on this in the post either http://trinque.org/2018/06/02/v-manifest-specification/
asciilifeform: i suppose there is also the other variant, where manifest.txt actually gets speshul treatment. but imho that's ugly.
mircea_popescu: http://btcbase.org/log/2018-07-10#1833125 << something the manifest should actually fix ; if it's included why doesn't it fix it ?☝︎
phf: manifest doesn't solve this problem, because manifest doesn't get any kind of priority treatment. if you hinged your press purely on a manifest descendent/antecedent chain then everything else will just work™
phf: there is a manifest in this version of vtools
phf: asciilifeform: well, i'm not sure what "spuriously bifurcated tree" means in this case, the goal was stated in the one of the posts, that i'm explicitly maintain two separate branches, that hinge on two separate manifest paths. this is the kind of stuff v is designed for neh? press to vdiff_sha_static to get one thing, press to vtools_vpatch_newline to get the other
asciilifeform: the http://btcbase.org/patches?patchset=vtools picture suggests that it's the classic mistake of spuriously bifurcated tree, the kind of thing that had trinque & mircea_popescu raging in the old days and prompted manifest.txt etc
a111: Logged on 2018-07-07 23:27 phf: i've been using vpatch/vdiff without full blown v, because i can order the patches by hand (and there's now an explicit ordering provided by manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
esthlos: wrt http://btcbase.org/log/2018-07-07#1832726 and asciilifeform 's "sad mode", the idea of using the manifest was the confusing way the fuck back in http://btcbase.org/log/2018-03-07#1787163 , where I thought "oh, mp wants me to build a vtron using manifest to resolve tree, guess I need a manifest spec!"☝︎☝︎
phf: i've been using vpatch/vdiff without full blown v, because i can order the patches by hand (and there's now an explicit ordering provided by manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
phf: well, yes, you have all the tarbas/ebuilds have a blake in manifest, but there's no equivalent for a git repo. those are just pulled
mircea_popescu: point being, "blind" v could exist that just puts in the patches as seen in manifest, checks no sigs.
a111: Logged on 2018-06-26 17:45 phf: trinque: one reason i didn't include patch name in the manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard manifest does include patch name, than perhaps V ought to check the manifest against the patchset. relatedly fully manifest-based v doesn't even need graph tooling, can presumably press according to manifest's chain.
mircea_popescu: http://btcbase.org/log/2018-06-26#1829714 << this is a significant gain, in that it reduces the need for elaborate toposorting. first, check the manifest chain.☝︎
trinque: I brought up the graffiti because that'd be (and has historically been, before manifest) the way to attach the graph
trinque: wont be able to press a "makefiles" + manifest until that subsequent patch, but I don't really see a problem with that
ben_vulpes: add a new file for the manifest, create a vpatch, any subsequent vpatches that don't also edit manifest must be reground into mainline.
trinque: I was discussing how the manifest gets welded on, if welding on
trinque: anyhow, if we're talking about how to use the manifest, got it.
mircea_popescu: ircbot/manifest.txt
ben_vulpes: manifest.txt $hash_prev $hash_curr ?
ben_vulpes: reference the manifest file in a later patch.
mircea_popescu: if you find the manifest patrch is useful (as you do), YOU INCLUDE IT.
mircea_popescu: 2. you sign another new patch, later on, "fixing-bugzappers.patch". this patch references manifest patch and ircbot-multichan-etc.
mircea_popescu: 1. you sign a new patch, manifest.patch. at this juncture, phf's viewer will show it to the side, unconnected to the tree.
trinque: aha, once there's a manifest, all's fine.
asciilifeform: i think trinque's observation is re how to glue the ~old~ tree on, in the first manifest-bearing patch
mircea_popescu: ed patch is now also well ordered, "caught in the patchchain" as it were) and b) we can and very likely will re-organize the portion between genesis and the manifest patch later anyway.
mircea_popescu: it's not being proposed as a retoactive fix. the idea is, ~after~ the patch that puts in a manifest, ~subsequent~ patches will be well ordered. and the fact that the earlier ones aren't exactly well ordered is a) resolved in any practical sense by the fact that you won't have patch imports across the barrier more than 1 deep (ie, once a patch after the manifest patch references a patch before the manifest patch, THAT refernec
a111: Logged on 2018-06-26 17:26 trinque: ben_vulpes: because the manifest has no antecedent, and you're gonna have to go graffiti other files like an idiot
mircea_popescu: http://btcbase.org/log/2018-06-26#1829660 << you could just add the manifest in a patch, like diana_coman did for eucrypt.☝︎
trinque: phf: thought I had there was that if you have only a manifest in hand, perhaps the name is useful in some dht lookup for the patches later
phf: trinque: one reason i didn't include patch name in the manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard manifest does include patch name, than perhaps V ought to check the manifest against the patchset. relatedly fully manifest-based v doesn't even need graph tooling, can presumably press according to manifest's chain.
trinque: what it means is that before that point, there isn't a manifest-enforced press order
trinque: mod6: what do you imagine needs to change in a vtron to support the manifest?
trinque: phf: harping on it because I don't see evidence that reason for the manifest has been internalized
a111: Logged on 2018-06-15 17:26 phf: http://btcbase.org/log/2018-06-15#1825631 << updated, but it's a novel way of using manifest though: normally it requires a regrind where manifest is built up as you go, so the press order is enforced through graph. right now your manifest gives a press order, that's not enforced by anything
phf: trinque: ftr we have the "introduce manifest now without regrind, use it moving forward" pattern already implemented once
mod6: Perhaps we need to 1: Formally adopt the manifest spec proposed by trinque, 2: build a V that supports it.
mod6: we'll cross that bridge when we come to it. but first and foremost, the manifest items seems alright to me; "$blockCount $patchTitle $patchAuthor $comment".
mod6: I can delcare the v054 release with a manifest of my own ala: To declare a "release", an author's GNS pointer for a project would point to his selected manifest.
trinque: wherever you introduce the manifest, if it is not the root, in order to involve it in the flow of the tree, that patch must also edit some other file.
mod6: i see ben's point, but i'd rather trb one whole thing, instead of a 'before manifest' and 'after manifest'.
ben_vulpes: well in theory, but in practice everything below makefiles already needs a regrind; aggression to request newblocks if none have been advertised recently; hash truncation atop that. so there's an opportunity to significantly reduce the amount of regrinding by introducing the manifest after the makefiles release and just regrinding 2 patches instead of the whole tree. unless i misread the situation.
trinque: ben_vulpes: because the manifest has no antecedent, and you're gonna have to go graffiti other files like an idiot
ben_vulpes: mod6: my original q was in re why regrinding the whole tree is necessary instead of introducing the manifest now and using it going forward
mod6: ben_vulpes: im trying to look at the big picture. the manifest spec is a part of that, ya.
trinque: the words I wrote right there gave it as an example of "this needs a manifest"
trinque: there ~are no~ manifest capabilities to be had
ben_vulpes: "manifest capabilities" are baked into all V implementations
mod6: is his lisp version of V to become the new defacto thing that has manifest capabilities?
ben_vulpes: mod6: focus on the manifest design, not the v implementation linked in trinque 's post
trinque: the blog post there is talking about the manifest file format.
trinque: mod6: http://trinque.org/2018/06/02/v-manifest-specification/ << can have the thread here if you like
mod6: that said, everything must be pretty much "firmly" in place with V rules, manifest, naming conventions, what have you, before I wanna move on that.
ben_vulpes: for the sake of exploring the state space; it is more desirable to regrind the whole tree rather than to introduce the manifest at this point and use it going forward?
trinque: they're ready, being held because I haven't reground the entire tree around a manifest.
mircea_popescu: <asciilifeform> http://btcbase.org/log/2018-06-25#1829397 << imho a genesis oughta be a proggy, if a minimal one << nah, a genesis can well be nothing more than the manifest, if the manifest is a one line poem.☝︎
a111: Logged on 2018-06-19 20:52 mircea_popescu: it's not "oh, errybody has a rotten plank or two keeping'em afloat." it's "oh, everybody ~can manifest matter by will~, currently everybody hanging off the bare minimum rotten plank and they're not even COMPARED".
asciilifeform: re 'manifest matter at will' : in early 2000s asciilifeform grasped the mega-problem , that programming ain't actually hard, except for stripping away the monkey shit produced by 50 yrs of monkey. 'i want a sane emacs' turned into 'sane prog lang' and quickly 'sane os' then 'sane iron' , and afaik this actually the inevitable correct cut, rather than caprice
mircea_popescu: it's not "oh, errybody has a rotten plank or two keeping'em afloat." it's "oh, everybody ~can manifest matter by will~, currently everybody hanging off the bare minimum rotten plank and they're not even COMPARED".
a111: Logged on 2018-06-15 13:10 diana_coman: phf, please add the last 2 patches of eucrypt: http://www.dianacoman.com/2018/05/03/eucrypt-chapter-13-smg-rng/ and http://www.dianacoman.com/2018/06/15/eucrypt-manifest-file/
phf: http://btcbase.org/log/2018-06-15#1825631 << updated, but it's a novel way of using manifest though: normally it requires a regrind where manifest is built up as you go, so the press order is enforced through graph. right now your manifest gives a press order, that's not enforced by anything☝︎
asciilifeform: funnily enuff, seems like the earliest vtree to include manifest was : FG -- http://btcbase.org/patches?patchset=fg
diana_coman: phf, please add the last 2 patches of eucrypt: http://www.dianacoman.com/2018/05/03/eucrypt-chapter-13-smg-rng/ and http://www.dianacoman.com/2018/06/15/eucrypt-manifest-file/
deedbot: http://www.dianacoman.com/2018/06/15/eucrypt-manifest-file/ << Ossasepia - EuCrypt Manifest File
esthlos: trinque: I added a manifest to my v_genesis vpatch. I'm curious, though, how these items (vtron, manifest) become declared "standard", if ever
mircea_popescu: esthlos, every link that goes in chan is also found at https://archive.is/http://trinque.org/2018/06/02/v-manifest-specification/
ben_vulpes: i see manifest draf, art car parade, and then the cuntoo instapper
a111: Logged on 2018-06-02 21:47 trinque: bugger, it's actually http://trinque.org/2018/06/02/v-manifest-specification/
esthlos: trinque: I might be being thick, but your link http://btcbase.org/log/2018-06-02#1820306 doesn't work for me, and I don't see the post on the rest of your site. have you posted the manifest spec somewhere?☝︎
phf: http://btcbase.org/log/2018-06-03#1820367 << there isn't one, there is a peculiar bug that seems to only manifest in my lispworks dev environment. things actually work on production, though the patch page is 20mb☝︎
mircea_popescu: spyked, yes, b/project_name_toplevel_dir/manifest
spyked: http://btcbase.org/log/2018-06-02#1820283 <-- reading this thread, it just occured to me: is there a convention re. directory structure? the implicit one (in my own head at least) was that each project lives under its own top-level directory (e.g. b/ircbot, b/ffa, b/eucrypt, where b is the press tree). so then does the manifest reside in b/project_name_toplevel_dir/manifest?☝︎
a111: Logged on 2018-06-02 20:02 mircea_popescu: for instance i can't even tell whether hanbot's mp-wp genesis includes a manifest atm, by virtue of it not even being on btcbase.
diana_coman: mircea_popescu, do you mean adding a manifest to eucrypt or what exactly?
deedbot: http://trinque.org/2018/06/02/v-manifest-specification/ << trinque - V Manifest Specification Draft
trinque: bugger, it's actually http://trinque.org/2018/06/02/v-manifest-specification/
deedbot: http://trinque.org/2018/06/02/v-manifest-specification-draft/ << trinque - V Manifest Specification Draft
mircea_popescu: alright, plox trinque write a v manifest specification, so it can be linked to for the future.
a111: Logged on 2018-05-01 16:26 mircea_popescu: trinque, what's your stance here, do you particularly want to implement a grapher / manifest / generally fix a v ? not really ?
mircea_popescu: for instance i can't even tell whether hanbot's mp-wp genesis includes a manifest atm, by virtue of it not even being on btcbase.
mircea_popescu: i want a link point for "hey, i gotta include manifest ?!" queries which will keep flowing ; no doubt.
trinque: nah, his viewer is doing the link, http://btcbase.org/patches/vtools_vpatch_newline/tree/vtools/manifest?raw=true
mircea_popescu: http://btcbase.org/patches/vtools_vpatch_newline/tree/vtools/manifest aha
esthlos: hey guys, should I have included a manifest file in my genesis? see http://blog.esthlos.com/esthlos-v-genesis-or-who-presses-the-pressor/comment-page-1/#comment-17
spyked: mircea_popescu, the rss bot would branch the ircbot tree then. if trinque or mircea_popescu see any reason for adding rss bot on top of ircbot, I see no reason not to, but it would be disjoint item (i.e. only file changed would be manifest)
mircea_popescu: anyway, the "up" and "down" may not be as firmly manifest as you personally imagine. postmodernism is bizarro world, up is down, they say hello when they leave...
hanbot: i dunno, i think the best thing they can hear about homework is that they're so special they don't need to do it. their unicornity shall manifest, and better to retain/don the woolies of youth to maximize the potential for manifesting firstbestbiggest.
trinque: http://p.bvulpes.com/pastes/xHwCM/?raw=true << deps manifest
trinque: there's a manifest in the deps dir
mircea_popescu: don't say "plz read the manifest", say "plz read the manifest : http://www.loper-os.org/?p=2277 or w/er it is. what is it ?
asciilifeform: mircea_popescu: plz read the manifest
asciilifeform: ben_vulpes lemme know if you have any q re the items in manifest ( they are all in BingoBoingo's inventory nao )