tmsr - Search: " T"

124400+ entries in 0.07s

apeloyee: I proposed being able to name arbitrary required antecedents << also probably needs a mechanism to declare "there are no other files in the tree" ☟︎

asciilifeform: fromloper: correct. almost totally useless.

fromloper: VLM is not very informative for this purpose, unfortunately

asciilifeform: ( or what it expects to find on the bus, or almost anything else ) ☟︎

asciilifeform: or the necessary timings.

asciilifeform: fromloper: currently however i do not even know where the power supply pins are, much less bus addressing, i/o, clock, etc

fromloper: asciilifeform: if I remember, you wanted to hook this intact chip to some emulation of Ivory's life support

apeloyee: "may be a 50kg sword" << doesn't seem to be. can be retrofitted into an existing design. as i said above "there needs to be a tree hash in the _leaf_ patch. and it MUST match the resulting tree"

asciilifeform: so i'ma save mine for proper commercial lab. but that means potentially forever. maybe whoever takes it off my corpse, can get it photo'd.

asciilifeform: fromloper: i only have two 'ivory' chips, and ideally would like to leave one intact , for active test . iirc phf also has 2 to use.

asciilifeform: apeloyee: trinqueian / mircea_popescuine vtron is arguably The Right Thing. my observation is that it may be a 50kg sword.

asciilifeform: fromloper: that's where it stopped. i do not have 25k usd to use on ivory die photo.

apeloyee: when you sign a tarball, the signature is not transferrable to anything else

asciilifeform: fromloper: i shopped around in commercial labs; the best bid was in the neighbourhood of 25,000 usd.

asciilifeform: fromloper: that was phf's plan. afaik he has not, as of yet.

asciilifeform: apeloyee: there is not a mechanical solution to preventing someone from 'putting in format c:' proverbially

fromloper: did you succeed in scanning the chip at Zeptobars?

asciilifeform: fromloper: i'ma look. ty

asciilifeform: fromloper: it is not a complete arch description, you cannot write a working emulator with it ( or even make the existing snap4 not-crash )

apeloyee: point is, the situation when you can replace one of the patches with figurative "format c:" and 'v' will be none the wiser as long as the file is not touched by later patches is insane

fromloper: there were older versions of three chapters from this documents on Bitsavers, but not the whole thing

asciilifeform: fromloper: pretty sure i've seen this before

fromloper: it's more complete than the previously published documents on the Ivory

fromloper: asciilifeform: someone uploaded "I-Machine Architecture Specification" to Bitsavers three days ago, I thought you might find it interesting: http://www.bitsavers.org/pdf/symbolics/I_Machine/I-Machine%20Architecture%20Specification.pdf ☟︎

trinque: then we are closer than it appeared in the long thread. I proposed being able to name arbitrary required antecedents in a vpatch's header, and this appears equivalent in effect to copying the file in whole.

asciilifeform: so answ to trinque's q is yes

asciilifeform: as i did in trb.

asciilifeform: under classical, you can grab antecedents from any trees you want, by copying files, aha

asciilifeform: trinque: under classical v, or trinqueian ?

trinque: asciilifeform: to see if I can restate your opinion back to you, if I edit (as single author) both readme.txt and doesallthework.adb in separate vpatches, your view is I combine those into a single vpatch, if I want to build atop both in a new vpatch?

asciilifeform: for multi-author projects, that is.

asciilifeform: however it DOES mean even ~more~ work for folx using v, than ever before. and not less. ☟︎

asciilifeform: i don't have a good counter-argument to this.

asciilifeform: iirc mircea_popescu's argument was that it is wrong to say that they could ~ever~ be properly independent. and that if they could be shown to be independent, they ought to be separate v-trees. ☟︎

asciilifeform: and in both cases, the ability to explicitly mark subsystems as independent ( e.g. a readme.txt being independent from doesallthework.adb ) is lost.

asciilifeform: trinque is right tho, they are equivalent

trinque: pretty obvious I'm saying signed hash, i.e. hash is in the signed vpatch

apeloyee: but there can be several of them

apeloyee: well, a hash is not the same as the signature, but otherwise yes.

trinque: and in the case of signed antecedent state, don't have to press first to know if you could

trinque: they're equivalent neh? signed antecedent state or signed resulting state + fact that the patch is signed

apeloyee: ...responsibility for the resultant tree state).. otherwise it's unclear what one signs.

a111: Logged on 2018-01-17 19:31 apeloyee: a vpatch's purpose is twofold. 1) to provide a way to construct some files based on some antedecent files, whose hashes are given. 2) to take some responsibility about the entire tree. but the signature on a vpatch doesn't fix the state of the tree; it is defined implicitly by antedecent patches, which are liable to change at any time ("regrinding") and thereby change some files not...

apeloyee: that's a spurious objection. one need not to sign an antedecent state, one needs to sign a RESULTING state. to expand on http://btcbase.org/log/2018-01-17#1771900 , you're free to pick individual files from wherever, possibly several different trees, but there needs to be a tree hash in the _leaf_ patch. and it MUST match the resulting tree (under the principle that patch author takes the... ☝︎

BingoBoingo: asciilifeform: Uruguay pointedly does not border Columbia. Other side of the Continent

BingoBoingo: The closest thing so far was they time an Israeli embassy worker was busted with a bomb or fake bomb near the WTC

asciilifeform: ( it borders, e.g., columbia. nothing exploded there ?0 )

BingoBoingo: On most days they do not explode on this side of the border.

asciilifeform: fenómenos que "no tiene antecedentes" en el país << orly? ☟︎

asciilifeform: BingoBoingo: and on most days they do not ?

BingoBoingo: And in other news, a police car exploded near the Brazilian border https://www.elobservador.com.uy/bomberos-explosion-auto-policial-fue-intencional-n1160744

asciilifeform: so it is not correct to say 'you made the man do what the machine could do.' rather, lightened the work for operator for one kind of operation, and made heavier -- other kind.

asciilifeform: it severely constrains the kind of things you can do without manual surgery

asciilifeform: as i described in the linked thread, forcing the entire program under the antecedent hasher is not free

apeloyee: well, your point seems to be specifically that work which can be done by machine is shifted onto a human. this is insane.

asciilifeform: ( asciilifeform traded his lispm for two last-made lispm single-ic cpu... )

asciilifeform: hey it's the only kind i have nao!11

apeloyee: do you advocate the brick "lisp machine", too?

asciilifeform: and yes it is entirely true that files-are-not-guaranteedly-independent.

asciilifeform: apeloyee: trinque and mircea_popescu would like to put more of it on the machine. i haven't with what to dissuade them, it is a philosophical q, not even technical.

asciilifeform: apeloyee: see the quite 'flammable' log from that thread. i put the burden of correct operation ~100% on the human operator. ☟︎

apeloyee: files are NOT INDEPENDENT. despite CVS and v pretending they are. this is a problem. you could have required some form of cryptographic commitment to either the tree state or even the antedecent patches themselves, but didn't ☟︎

asciilifeform: apeloyee: some of the 'cvsism' is deliberate -- cvs made collaborative writing harder by accident, we -- on purpose !11

asciilifeform: apeloyee: the 'liable to change' thing was very much NOT part of my orig design for v. ☟︎

apeloyee: hence the hash-manifest proposals

apeloyee: a vpatch's purpose is twofold. 1) to provide a way to construct some files based on some antedecent files, whose hashes are given. 2) to take some responsibility about the entire tree. but the signature on a vpatch doesn't fix the state of the tree; it is defined implicitly by antedecent patches, which are liable to change at any time ("regrinding") and thereby change some files not... ☟︎

BingoBoingo: It gets 30 minutes with the audience, remarks on the size on the audience, and then silence

a111: Logged on 2018-01-05 23:30 asciilifeform: trinque: if you really hate files, you are welcome to make the whole proggy 1 file

apeloyee: http://btcbase.org/log/2018-01-05#1765560 << this looks to be the only safe way. asciilifeform : don't you think that's insane? ☝︎

BingoBoingo: Now that was a wasted voice

a111: Logged on 2018-01-17 01:29 mircea_popescu: http://btcbase.org/log/2018-01-16#1771435 << hey, is that your blog then ?

Covale`: http://btcbase.org/log/2018-01-17#1771610 - no, not mine, I don´t have one. Neither do I have that cup, but it´s a pretty decent Lenin nonetheless ☝︎

asciilifeform: if gcc actually puts in the 'jump-likely' . currently i have nfi whether it does.

apeloyee: this is gpl gnat tho

asciilifeform: apeloyee: neato. gotta wonder how this is implemented tho.

apeloyee: from above: "Check that the actual parameters of a subprogram call are not aliases of one another. To qualify as aliasing, the actuals must denote objects of a composite type, their memory locations must be identical or overlapping, and at least one of the corresponding formal parameters must be of mode OUT or IN OUT. "

freetlas: asciilifeform: Just a person who likes to read trilema from time to time :)

asciilifeform: freetlas: you did not answer the question

freetlas: Wow, first time I see too many people in here :o

apeloyee: https://gcc.gnu.org/onlinedocs/gnat_ugn/Alphabetical-List-of-All-Switches.html#Alphabetical-List-of-All-Switches : "-gnateA" Check that the actual parameters of a subprogram call are not aliases of one another.

asciilifeform: ( i'd rather not. but there is nothing fundamentally unusable about it )

asciilifeform: the variant with booleans doesn't rely on non-nullities tho.

asciilifeform: will have to see what gets removed, what -- not

asciilifeform: but this is one of the reasons why there is no escape from disasm

asciilifeform: doesn't seem to , in gnat '2016'

asciilifeform: ( i will omit the rest of the mechanism, i think it is pretty obvious )

asciilifeform: the first cell has a false HasPrev ; the last -- a false HasNext.

asciilifeform: so a stack cell would contain not only an FZ of the current bitness, but two boolean values, e.g. HasPrev and HasNext

asciilifeform: nao that i think about it, it doesn't even have to introduce 'access types' ( pointers in ada ) , can use ordinary integers

asciilifeform: you can trivially show that any attempt to walk under or over the stack, would have to involve a null-dereference.

asciilifeform: currently it actually seems to me , to be cleaner -- in that its correctness proof is simpler, does not use arithmetic at all

asciilifeform: whether this is cleaner than the existing item, i will leave up to the readers, incl. apeloyee .

asciilifeform: want() would then vanish; both stack underflow and overflow checks would be handled by the nullity check ( first cell has a null in its 'prev' slot; last cell in stack -- in its 'next' . )

asciilifeform: however this introduces explicit pointerism. ( though, i will add, NOT pointer-arithmetism ) ☟︎

asciilifeform: apeloyee: here's another idea from my notes , that would do the job : to dispense with the array representation for the stack, in favour of linked list. ada permits the definition of a 'not null' pointer type (whose non-nullity is checked on every reference) .

asciilifeform: ( prolly still are today, somewhere in ssl liquishit )

asciilifeform: incidentally there were pivot-position bugs in commonly-used karatsubas as late as the early 2000s.

asciilifeform: or for another example, take the ugliness and 'pointericity' of the traditional 'pivoting' form of karatsuba. which i killed by forcing all FZ bitnesses to be powers of 2.

asciilifeform: ideally so as to maximally compartmentalize and document the ugly

asciilifeform: one way to model this process is that there is an 'ugliness budget', just like there is a cpu cycle budget, that can be 'spent' in certain ways