469 entries in 0.07s
bvt: mp_en_viaje: http://trilema.com/2017/when-did-america-end/
bvt: asciilifeform: can you try curl -s logs.nosuchlabs.com/log | grep --perl-regexp '\x01'
bvt: so far i've been doing everything manually. for 10 vpatches, i would start automating the process. typicall i'd run full test set for each vpatch
bvt: the two things for comparison -- less total number of vpatches at cost of vpatch size, or more vpatches, but smaller ones?
bvt: but again, i think the first to points are more important; the third one has less priority (at least for me).
bvt: in my workflow, each vpatch individually receives full press-build-test cycle; more smaller vpatches can make this process a bit longer and tedious.
bvt: maybe that's too much testing for re-signing, i dunno.
bvt: and i know that when re-signing multiple vpatches, i would have done the same thing individually for each vpatch.
bvt: well when i was re-signing another vtools vpatch at phf's request (for keccak regrind), i did the full re-testing as when releasing it the first time, to make sure that everything is ok.
bvt: there is also an aspect of potential future re-signing work on regrinds, which forces bigger vpatches, but imo the first two are more important
bvt: mp_en_viaje: i think there are two aspects: 1. readability (whether readers would be able to understand what is going on; in that vpatch the changes are local enough); 2. atomicity (whether someone would ever want to have one fix without the other; here my position is much weaker -- perhaps someone would want to have a crash on empty vpatches?)
bvt: asciilifeform: re ctcp, you can spot /me messages in the curl output of your logger: http://p.bvulpes.com/pastes/sUDA5/?raw=true (extra ' 01 ' byte) ♖︎
bvt: asciilifeform: there is another thing that i just noticed that different between phf's logger and yours: single quote (') is encoded as &#039 in phf's logger, and as &apos in yours -- and &apos happens to be totally broken in links graphical mode (links -g). i can fix this on the links side, but i wonder if this is intended/acceptable behavior
bvt: mp_en_viaje: http://trilema.com/2015/the-mp-suicide-self-evaluation-scale/#footnote_11_59975
bvt: asciilifeform: fished out some info re aws: http://p.bvulpes.com/pastes/koCFa/?raw=true (small patch for musl compat) and http://p.bvulpes.com/pastes/avKyY/?raw=true (build instructions) seem to be it ♖︎♖︎
bvt: http://logs.nosuchlabs.com/log/trilema/2019-08-09#1926770 << wb, and gute besserung!
bvt: iirc it is buildable without xmlada and all the crazy deps with some tweaks; at least i did build it once and run one of the examples
bvt: http://logs.nosuchlabs.com/log/trilema/2019-08-09#1926692 << there is ~20 years old 'AWS' https://github.com/adacore/aws
bvt: at least it was reiterated here http://trilema.com/2019/so-what-is-the-man-saying/
bvt: lol vintage, from 2019?
bvt: http://logs.nosuchlabs.com/log/trilema/2019-08-08#1926500 << i think get your point; though tbh, from my reading of linux it's not clear that urandom uses separate entropy pool, as i understood so far urandom uses the same pool as random, just ignores all 'entropy' measures (i still did not quite load that part in head, so this is not final info).
bvt: asciilifeform: until the day for tcp to die arrives, you'd still have to interact with tcp warts in that or other form
bvt: on posix, don't think there is way out of exposing fds and syscalls
bvt: re pg - yes, you'd have to implement the protocol; and serialization/deserialization is error prone and typically takes lots of code (i.e. too much), agreed
bvt: true, but i don't find '80% of cl argument' too convincing; if want comfort, sure, use cl/python; want hard memory limits and gcc performance, can use ada, it won't be fundamentally dirtier (due to tcp and db stuff), just more boilerplate code
bvt: i would actually expect that pg protocol does not use 0terminated strings. re 80% of CL -- inside of it's implementation you'd find same shit. dunno how it would be different from using heathen libs
bvt: i don't think there is a way out of treating utf8ism as raw bytes, other than finding a heathen library
bvt: i did some minor nginx plugin development -- the linked list approach was not bad, the only op i had to do with actual buffer was splitting it across chains links to insert data between.
bvt: re logotron with arbitrary number of messages - can't you send data in a loop? otherwise the problem touches all levels of net stack -- can't have arbitrary sized packets either
bvt: well, for most of format strings you know the number of formatted elements, right. re memory allocator -- an arena allocator is typically used, and file data can be mmaped
bvt: you still need to format the numbers, etc, but for this can always know upper bound
bvt: asciilifeform: you make a chain (linked list of buffers with content), pass it's head to kernel
bvt: http://logs.nosuchlabs.com/log/trilema/2019-08-08#1926442 << the lag is noticable, but i'd say it is entirely usable.
bvt: tbh i would not mind attempting an irc bot in ada, but it seems more like leasure activity so far.
bvt: asciilifeform: did not try myself
bvt: http://logs.nosuchlabs.com/log/trilema/2019-08-08#1926433 << you don't actually need to concatenate anything as long as writev(3) is there. whether any gnat lib uses it -- dunno. at least nginx does use it (http://archive.is/QKjvD#selection-2735.36-2861.26), and imo this is a correct approach to the problem -- let kernel do the copying, if it needs to
bvt: http://logs.nosuchlabs.com/log/trilema/2019-08-08#1926429 << well, if you're willing to use heathen libs, there are at least 2 pgsql bindings libs, but dunno about the quality (most likely with gnat.socket inside, yes).
bvt: hello. asciilifeform: i like the new logger, esp the multi-chan support
bvt: hi. i'm back from my travel (incidentally, also from ukraine, though not kyiv)
bvt: maybe this http://danielpbarron.com/2019/the-truth-often-seems-paradoxical/#comment-2713 ?
bvt: hello. i'll be traveling this week, the end result is supposed to be a working trb node; i don't expect that any other productive work will be done otherwise. bvt_away is the account that i may switch to during this time.
bvt: re korzhen, his son's www has english version of the story http://www.korzhan.art/biography.html
bvt: hello. I will try to finish the ffa work from the workplan over next two days. i had some meatspace interference that stole a few work hours.
bvt: mp_en_viaje: https://thelastpsychiatrist.com/2013/01/no_self-respecting_woman_would.html
bvt: mp_en_viaje: i will have a look if i can arrange it -- right now i have another travel scheduled around that time.
bvt: asciilifeform: http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/comment-page-1/#comment-23 re firefly; re kernel blocking, i expect that correctly implemented ring buffer would be immune from the concurrent access interference.
bvt: mp_en_viaje: ty for the comment; i have to go afk now, so most likely vdiff fix will be out tomorrow 2nd half of the day. right now it is at http://bvt-trace.net/vpatches/vdiff_blockwise_read.vpatch (add .bvt.sig for the seal) ☟︎
bvt: i see, when the last person who was there when the isp was set up retires... ; the internet situation in germany is outrageous -- dsl everywhere, highest prices for shittiest quality, providers (2 or 3 that are still there) making sure that no fiber gets to the customers, etc (iirc they invested heavily in copper 'cause "isdn is the future!" in 90ties).
bvt: well, i still have access to irc/inet at saltmine; and working offline is also possible, so i don't waste time in meantime.
bvt: hello. i have also prepared a work schedule document; however internet at my workplace died this week, will post the plan as soon as the internet goes back up; the plan for next two weeks is to get to ffa14b, update asm code to it; after that, i will have a look at some other work.
bvt: phf: if you are still here, one small question: what is the purpose of this line http://btcbase.org/patches/vtools_ksum#L64 ? Fs is not used anywhere later.
bvt: i'd say vienna
bvt: i have never worked with slip, so can't tell right now ☟︎
bvt: re rtc -- i can see that. re network - i guess at some point it may be easier to provide a (first, emulated, later hardwarized) pipe device and write a custom driver to it; basically a high-speed tty that also transfers information about message boundaries
bvt: well, building is actually trivial -- sed 's/aarch64 x86_64/x86_64 mipsel-sf/' build-ada-arm64.sh > build-ada-mipsel.sh ; i'll do a post about this, but this'd be all the technical meat in it
bvt: if you want, can share the tarballs as well. afaik mips also uses zcx by default -- i did not change anything there
bvt: asciilifeform: i have built ave1gnat with mipsel-sf support with a small patch (http://bvt-trace.net/src/gcc-4.9.adacore2016-4-mipsel.diff) -- adacore has snipped those files from their source distribution.
bvt: in case only asm is used, plain comba may be fast enough as well
bvt: you mean, can use just karatsuba?
bvt: re ~2.5x speedup: for 8-indeces-threshold asm comba makes up only ~25% of runtime, rest is spent in karatsuba squaring
bvt: i agree. i played a bit with the code, arrived at slightly cleaner (and sub-1% faster) code for multiplication, seems that the performance is close to the hw limit (at least at 32 Indices Comba-Karatsuba threshold)
bvt: asciilifeform: myeah, i was too fast with sse -- simdifying such loops would be ~impossible.
bvt: now, sse could theoretically help, but there is a question of whether sse operations are constant time (in each generation of intel cpus)
bvt: asciilifeform: perhaps i could get a bit better performance after scrutinizing multiplication code a bit; however i don't think it'll get much faster with current code structure
bvt: the hard part is 'fiat overlord' and being able to dedicate stable amounts of time to republican work, for this i don't have an acceptable answer.
bvt: after ffa I will have a look at other things (like ripping out kernel rng, having another look at gnat-arm64 internals, as it seems there is no ongoing work on this front atm). i expect to get something useful as a result, and maintain it in long term.
bvt: mircea_popescu: i guess that there two components in your question. the easy is ffa: is agree that my ffa-related output is underwhelming for a lord, however 1) i don't expect that it will eat much more time (at ch.14 i'll see if there is really need for further asming, the anticipated answer is "not really") 2) i find speedup from asming generally useful, so i don't think the time i spent on it is wasted. ☟︎
bvt: oh, and re http://btcbase.org/log/2019-04-24#1909684 -- i wrote to the dude back then, he promised to respond in a week 'after travelling', never came back to we afterwards ☝︎
bvt: i do expect that 'saltmine season' is over now -- i've been working on asming karatsuba squaring (ffa ch.12b) over this week, post expected tomorrow. ☟︎
bvt: hello. i am also sorry for my unacceptably low output over past ~2 months; and particularly sorry of not doing the right thing of notifying the forum (which i did before)
bvt: (talking about rk3399 here)
bvt: yes, but nevertheless the boards with these chips appear every day. perhaps need to show inca earplugs of some minimum size to get them?
bvt: to my understanding you design them yourself; devboards are just for testing the cpu/chipset
bvt: well, those are devboards, i don't think anyone sells them as a serious item. but amateurs - buy
bvt: (chinese messed with m.2 port wiring, need to buy strange adapter board to bring it to sanity)
bvt: i have an m.2 nvme ssd there, but the hw setup is convoluted enough to recommend bying *some other* board for these purposes
bvt: i have a http://archive.is/EUW9n item at home, with kernel from some arm64 distro and pizarro rockchip rootfs, but i never got time properly setup this device (plan was, run trb node)
bvt: it is not clear to me if big.little ever worked acceptably with linux -- they are tuning even today
bvt: iirc changed, but too recently to even consider a switch anyways
bvt: asciilifeform: rk3399 is a bit trickier in usage than rk3328 of pizarro rockchip -- big.little arch, so scheduling and power management have to come from rockchip kernel tree, not vanilla.
bvt: the kind of cloth used for lens cleaning works as well?
bvt: could be, i never got to disassemble and check the board after changing wlan card.
bvt: it has an annoing problem of producing high-pitched noise when running with ext. input devices or wlan on, but overheat happends only after ~45 min of compiling, which i don't do any more.
bvt: is it that much more stable with lenovo bios? i had it overheat with both orig. and coreboot variants, so stayed with coreboot
bvt: at the time i was getting mine - only w. T2400 and iirc slower cpu were available
bvt: right, t2400 is 32bit, t7200 is later generation - 64bit
bvt: please check, because all docks pointed into '32bit only' direction - perhaps it was disinfo.
bvt: hm. i have the same, but T2400 is 64bit in 'PAE' sense, not in register width sense.
bvt: this would actually be interesting for x60 machine owners as well. the register pressure would also increase on i386
bvt: only on mult, not on modexp
bvt: asciilifeform: depends on whether there will be a usecase for such item, but in any case shifts/adds should be simpler than comba
bvt: then, perf increase should be substantial
bvt: hi. the exact cut will depend on what % of ops in barret are mults
bvt: also, i was under impression that asciilifeform suggests to ditch C after getting sane iron ☟︎
bvt: http://btcbase.org/log/2019-04-25#1909969 << that clarifies the issue, thanks. i got momentarily confused because imho cuntoo (as gentoo repo snapshot) is too large to pull off http://btcbase.org/log/2019-04-24#1909621 - i see no way to replace gcc with tcc and 'rebuild world' without rewriting ebuilds/getting a ton of errors; but should be realistic with something smaller (which i plan to do). ☝︎☝︎
bvt: http://btcbase.org/log/2019-04-24#1909728 << he indeed looks very experienced http://archive.is/VOaOV#selection-1166.1-1192.0 http://archive.is/nmzYW#selection-3746.0-3773.78 http://archive.is/FeiYm#selection-3319.1-3321.349 ☝︎
bvt: though to my understanding he uses zeptobars photos at least sometimes (http://archive.is/pjqcH#selection-1139.1-1483.105 , http://archive.is/K1Efi#selection-3499.55-3503.154)
bvt: he worked with 580BM80A as well http://archive.is/01iuf, http://archive.is/RKAEx , also with feature recognition
bvt: http://btcbase.org/log/2019-04-24#1909723 << i will definitely write him ☝︎
bvt: *the cited link should've been http://btcbase.org/log/2019-04-24#1909727 ☝︎