31400+ entries in 0.335s

a111: Logged on 2018-04-29 13:50 asciilifeform: esthlos: imho absolutely not;
i haven't built a linix box with swapping to disk enabled, in decade+ ( 'secure alloc' simply means 'marked unswappable' )
mircea_popescu:
i'm like leaving in a hurry and shit, but can't not stop and read that
diana_coman: <asciilifeform> as
i understand this will be the first field test outside of his bench. <- smg is an ice breaker of all sorts, what can
I tell you
trinque: asciilifeform: pretty high degree of confidence in the build. oughta be exact same deps on your end as what
I had on the workbench
diana_coman: yes;
I suppose it would have helped to have in the list there the move form sha to keccak
☟︎ mircea_popescu: tbh,
i tihnk what happened here was : original mpwp was sha, then hanbot reground it
a111: Logged on 2018-07-05 17:59 diana_coman: asciilifeform,
I get it: clone of dulap is pointless because it requires rotor-style which can be equally done on existing server; but we are talking of having a box with trinque's musltronic proto-cuntoo
ben_vulpes: ah, thanks trinque, figured
i was s.o.l.
hanbot: diana_coman the regrind presses here without errors with phf's vpatch.
i didn't try pressing with v.pl, possibly they're incompatible...?
esthlos: trinque: yes it does,
I'm trying not to overcommit but could definitely add once the Keccak/V stuff is off my plate
a111: Logged on 2018-07-10 14:17 phf: like
i said couple of days ago
i'm going to forward merge that whole right side, right now the only advise is to delete the right hand side because none of the extant V's can resolve that graph, obviously a suboptimal suggestion.
i'm working on a better grapher, but until then..
esthlos: (
I couldn't find it, added by hand)
a111: Logged on 2018-07-10 21:41 diana_coman: no idea but fwiw
I was playing with it on the rockchip; as far as
I can tell both lobbes and esthlos used some previous versions; (btw esthlos can you maybe show the date of the post somewhere convenient? it's really weird to have to guess it/search for it)
mod6: ok,
i think the deposit will be coming from ben_vulpes
trinque: mod6: yep don't see any inbound yet.
I will likely be asleep when the required confirmations roll in.
mod6: ah! ok, ben and
I are gonna need that -- just holler when you're ready.
trinque: as it happens,
I can reach the deposit lever and will shortly mod6
PeterL:
I was thinking of trying to repurpose an old macbookpro
I had lying around
ben_vulpes: PeterL:
i started from the output of 'make menuconfig' and pruned it over time
diana_coman: no idea but fwiw
I was playing with it on the rockchip; as far as
I can tell both lobbes and esthlos used some previous versions; (btw esthlos can you maybe show the date of the post somewhere convenient? it's really weird to have to guess it/search for it)
☟︎ diana_coman: so
I'm asking here as honestly
I had quite enough of software for today
diana_coman: and on one hand the file complained about has only *one* entry in the genesis vpatch
i.e. just created so wtf
diana_coman: today is clearly not my day for working stuff; it's the weirdest thing
I've seen: v.pl dies at *different files* at each run complaining that sha sum doesn't match
PeterL: alright,
I will try to refine my language
PeterL: so
I have been looking at v. (specifically asciilifeform's python version) it seems to me that there should be a "pruning" step after the flow is laid out to remove any patches that are not ancestors of the desired leaf, so that you would not have to manually remove patches.
mircea_popescu:
i was just thinking, it's so rare for one to take a hint.
phf: BingoBoingo:
i think it's about the right mindset though, can have all the tools in the world, and you're still going to look like a jerk off. nah,
i think
i just need to get my head game straight
phf:
i'm going to go with mp's theory
phf: asciilifeform: have you been using yours extensively,
i.e. as a booted device, running linux etc. on a day to day, or it's only been on trepanation table so far?
phf: sad,
i was warming up to it as a note taking tool..
phf: so
i closed the lid, reopened tried again, now it boots, but the unix time is at 0
phf: nah,
i didn't go as far as motherboard removal.
i was thinking this might be heat issue, but that would be out of the box, and the pattern don't really correspond to heating
phf: hmm, cp101pa hardware is really flaky, or perhaps
i got a dud unit, because the "random shutdowns" "can't wake up" "stuck in a turn on/turn off mode" issues persist
☟︎ a111: Logged on 2017-12-05 14:17 asciilifeform: as for asciilifeform , he would actually prefer if mircea_popescu shot straight and said 'hell no
i won't pay for no stinkin' software', rather than the peculiar ritual of having a contest, then to proclaim the submitters as a whole 'self-indulgent indolent' and then in the end to take s.nsa crypto lib and use for phree anyway
mircea_popescu: and it shames me to admit just exactly how
i came to not have any.
mircea_popescu:
i'm having for breakfast leftover sandwiches that were originally made for camping on the beach, so
i figure... what the hell... and made myself a little model campfire out of toothpicks in the middle of the table.
a111: Logged on 2018-01-05 23:18 trinque: you edit db.cpp.
I edit main.cpp. how does someone now use both of those pieces of work in a 3rd patch.
mircea_popescu: and the smalle third brother is reference-by-memory, where
i say dumb shit like "that @@ discussion" instead of putting in a link.
phf:
i figured that's not the case,
i'm just reiterating the logs for the logs, because the evil twin of not reading the logs is apparently forgetting what was read in the logs
phf: btcbase (being a sprawling common lisp beast) has one of the possible solutions actually implemented and working.
i'm wrestling the essence of it out, enough to add some kind of graph sorter to vtools
phf: originally my replacement was for diffing and patching exclusively, not the graph resolution problems.
i was tasked with a replacement around the time when my food work got heavy, and
i'm only now revisiting it. the problem wasn't even verbalized until closer the the end of vtools development, because particular choice of vtools delivery demonstrated the problem to begin with
phf:
i haven't thought about it very much?
phf: well,
i'm having hard time thinking about it, yet alone articulating it. like
i told ascii (before we continued talking about it anyway),
i need some time to reupload the problem, because
i haven't thought about it in a while.
phf: mircea_popescu: the problem
i describe exists in every single V implementation, hence none of them can press a particular graph
mircea_popescu: the only reason
i can imagine someone'd have the problem you describe is if they built their thing around the primitive "file" rather than around the primitive "patch"
phf: actually,
i think
i have a memory of that, and no btcbase is entirely hash first
phf:
i don't know what a by file processor is
mircea_popescu:
i don't understand this, you mean patch A having changes a, b, d, e (ie, 4 different patch sections) and B having c, d, e, f ?
phf: mircea_popescu:
i didn't say more than one vpatch are identical,
i said that they shouldn't contain identical changes. a single vpatch can contain changes for several files. if two vpatches have a same subset of changes to individual files you have a problem.
phf: well,
i kind of dig the emergent v graph behaviors, so
i don't mind it either way, though btcbase doesn't press cleanly either (^ "all extant V's"). nothing keeping one from tacking on additional state to a crystalized vpatch either, and then you're stuck with another "though shall not, because reasons"
phf: if you want to reduce the problem to a "don't do this" policy, then it stems from repeated hunks across multiple vpatches,
i.e. if you have two or more vpatches that have identical state transitions. something like that is bound to happen when you're attempting to port a feature between branches, as is the case with vtools. (
i.e. you patched foo.c in one file "remove broken behavior", you now want to also introduce same fix to the other branch)
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
phf: asciilifeform:
i need to upload it into my brain first, let me get back to you on that one
phf: let me retest it, but as far as
i recall it was producing a patch order that doesn't press
phf: like
i said couple of days ago
i'm going to forward merge that whole right side, right now the only advise is to delete the right hand side because none of the extant V's can resolve that graph, obviously a suboptimal suggestion.
i'm working on a better grapher, but until then..
☟︎ mod6:
i never eat pancakes
mod6:
i just realized that
i want pancakes
diana_coman: aha,
I just entirely forgot that discussion until spyked mentioned it
diana_coman:
I guess
I'll leave a comment on his blog for easier future ref