156700+ entries in 0.611s
mircea_popescu: asciilifeform hey, you were
the one with "errythang exists in russian" kick no ? :D
mircea_popescu: and i'll point out
that while Попескy is acceptable, Мирчи is pretty far from
the original.
a111: Logged on 2017-09-20 01:35 mircea_popescu:
http://btcbase.org/log/2017-09-19#1715948 << i suspect
that was
the original idea of pointers. "you want
to insert X between A and B in AB memory ? NO PROBLEM! make A point
to X instead of B and X
to B itself AND IT IS DONE! MAGICALLY!"
a111: Logged on 2017-09-20 01:32 mircea_popescu:
http://btcbase.org/log/2017-09-19#1715929 << and yet nano can handle
tb. it'll
take a while
to bring it up, but it will. insertions np, seek-next back and forth np, whole line deletions etc.
mircea_popescu: and in other randoms of
today, "Есть удобный справочник от Мирчи Попеску о том, как взаимодействовать с фиатными учреждениями, которые пытаются требовать юрисдикции над виртуальными мирами."
mircea_popescu: then
the whole stack came
tumbling down ;
the chair
that collapsed
the moon unit.
a111: Logged on 2017-09-19 22:15 phf: it would be interesting
to
try and design architecture where you have an insert operation on a memory region (cons and lisp machines is kind of it, but
that's done by sidestepping
the issue; i'm
talking a
traditional von neumann machine)
a111: Logged on 2017-09-19 21:51 phf: additional point is
that
traditionally when someone said "multi-gb" what was really meant is "file bigger
than can fit in memory", and suddenly(!11) your whole underlying editor algorithm changes drastically, because you have be doing partial updates, and
temp files, and all kinds of cut-and-paste
trickery.
that's why emacs has a special cased "big file" support. with ropes if you want
to achieve multi-gb
that way you basically have
to
a111: Logged on 2017-09-19 21:39 phf: i've actually
tried putting ropes in a bunch of projects and
they never have good performance characteristics. in fact for
text editors no one has invented anything better
than "one string per one line", and if you want
to be fancy you split it at point (what emacs does)
a111: Logged on 2017-09-19 21:30 phf: i don't know why you explain
to me
things
that ~i argued in
the past~. fwiw, i argued "utf-8 is a whole spittoon" back when
the question of encoding first came up,
to somewhat fierce opposition
mircea_popescu: shit's not gonna be reading any ssds, dvds, etcs, so why
the fuck is my 2gb sample of
two girls fucking each other's ass on
the brandemburg expressed in z80 units.
mod6: join
the joyride alf
mircea_popescu: nothing wrong with
that. but note
the fucking 8-bit byte friendly programs COME ON FUCKING CASSETTE
TAPE! LIKE ROXETTE OMFG!
mircea_popescu: and me entirely by accident, lawyer's den had his antique playthings, we did some rally
thing on an old crt
tv.
mircea_popescu: asciilifeform it's fine on some platforms. i
think we might be like
the only people who even
touched such a platform
this decade.
mircea_popescu: there is ~no benefit in maintaining a "quarter byte" antiquated notion,
this isn't
the museum of Z80 computing science.
mircea_popescu: it's pretty fucking clear by now
that 64bit is where it stops anyway.
mircea_popescu: so why even maintain
the "8 bit byte" nonsense ? "oh, it'd be hard for people
to change" ? WHAT FUCKING PEOPLE!!! 80% of everyone involved with computers heard about
this "programmable"
thing sometime LAST YEAR
mircea_popescu: knock yourself out, have 64 bit long glyph pages, who
the fuck is keeping you.
a111: Logged on 2017-09-19 21:21 asciilifeform: phf: it's
the root of 90% of
the bloat and outright retardation in
the currently extant utils
mircea_popescu:
http://btcbase.org/log/2017-09-19#1715881 << here's an alt
take on
this :
the problem comes from having
the notion of byte be anything else but bus width. if 64 bit machines natively worked on 64 bit bytes, all
the message fucktification bs known as unicode would be significantly less of a conversation issue.
☝︎ mircea_popescu: but
the bill as written by
the usg.hacks was "takes over", not "lingers irrelevantly for as long as we keep pouring money into
the sand"
jhvh1: mircea_popescu: service for
the collection of revalorizable materials
mircea_popescu: !~translate es
to en servicio por el recollectamiento de materiales revalorizables
mircea_popescu: i always
thought it somewhat weird
that ~all we ever interview is chicks for
the
topless position, fwiw.
a111: Logged on 2017-09-19 21:04 phf: i was
trying
to be ~polite~. if you put "10 years of unix" on your resume, i sort of assume "tell me your favorite editor and
then ssh into
the box for interview" is a bushido level of politeness
a111: Logged on 2017-09-19 21:02 phf: same
thread as a guy who freaked
the fuck out, because i
told him
to ssh into a box for
the interview
a111: Logged on 2017-09-19 20:25 asciilifeform: (
translation from usg limba de lemn : 'there will now be concrete penalties for exposing dnc diddling of elections' )
mircea_popescu: "who
the fuck designs a p2p network like
this ?" "hey,
thank your lucky stars he didn't build it out of wxwidgets"
a111: Logged on 2017-09-19 22:15 phf: it would be interesting
to
try and design architecture where you have an insert operation on a memory region (cons and lisp machines is kind of it, but
that's done by sidestepping
the issue; i'm
talking a
traditional von neumann machine)
phf: it would eliminate
the need for a very large number of data structures
phf: it would be interesting
to
try and design architecture where you have an insert operation on a memory region (cons and lisp machines is kind of it, but
that's done by sidestepping
the issue; i'm
talking a
traditional von neumann machine)
☟︎☟︎ phf: hand patching binary blobs before you write a
tool for it,
traditionally
barpub: phf: up
to you. i've already conceded
the basic point: on actual hardware you can buy, ropes are fragile and corruptible and represent incidental complexity
phf: i regret wasting
time explaining
barpub: again, predicated on hardware-level bedrock support for
treelike structure
barpub: memory should cache disk, implying
the filesystem rep should also, yes, be a rope
phf: and yes you have
to use mmap, but
that's not
the end of
the story by a long shot
phf: make your ropes persist on disk, and
then have a single pass
that build ropes out of
the complete contents of file (which you already have
to do), and
then you offload rope subtree
that doesn't fit in memory, and
then you edit
the whole monster by swapping rope subtrees in and out, and FINALLY you have
to walk
the whole rope structure, file and memory alike,
to serialize it back into file
phf: additional point is
that
traditionally when someone said "multi-gb" what was really meant is "file bigger
than can fit in memory", and suddenly(!11) your whole underlying editor algorithm changes drastically, because you have be doing partial updates, and
temp files, and all kinds of cut-and-paste
trickery.
that's why emacs has a special cased "big file" support. with ropes if you want
to achieve multi-gb
that way you basically have
to
☟︎ barpub: and if your bedrock is
the byte, use ascii and hope for
the best
barpub: is a reasonable prerequisite
to having nice
things, like ropes, and variable-length encoding
barpub: so perhaps waiting until someone reboots
the scheme chip,
thus hardware-enforced cellularity,
thus avoiding pointerism
barpub: i've read your blog if
that's what you mean
barpub: and robustness is a cogent and reasonable objection
to using
them
barpub: it's
the only example of a rope i've actual experience with
phf: i suspect xi
trades snappiness for multi-gb use, which you don't notice, since you have
to run it on
the most recent mac (at least mac front end requires maxver xcode)
barpub: since i do write ordinary English from
time
to
time, and would need in
the latter case
two programs when i want only one
barpub: if
there was a structure editor whose structures include free
text, and one whose structures do not, i would pick
the former
phf: barpub: nah, real structure editor doesn't. but
then i've no idea what asciilifeform is
talking about.
there's not really any real structure editors in production. i know of a dead one, and it's an interlisp programming environment
barpub: in which case
the ast is just a rope and has no further semantics
phf: i've actually
tried putting ropes in a bunch of projects and
they never have good performance characteristics. in fact for
text editors no one has invented anything better
than "one string per one line", and if you want
to be fancy you split it at point (what emacs does)
☟︎ barpub: sure any binary
tree has an underlying flat representation, because hardware itself enforces
this
barpub: it strikes me
that variable-length encoding and ropes are natural complements
phf: i don't know why you explain
to me
things
that ~i argued in
the past~. fwiw, i argued "utf-8 is a whole spittoon" back when
the question of encoding first came up,
to somewhat fierce opposition
☟︎