261500+ entries in 0.169s

trinque: in no small part because V is utterly useful as a
tool on its own
phf: one day orcs perhaps will use it
to last
through
the night, as a kindle
phf: why is
that? i've never
tried
phf: i have an ansi copy, it's a piece of shit
though
phf: fwiw dpans has a copy of
tex source, first or second
to last draft before
the standard was sent over
to ansi.
there's
two projects
that cleanup
that
tex, one is dpans2texi which produces
texinfo formatted (this is what i use from emacs) and another by some russians
that produces a clean pdf with hyperlinks
mircea_popescu: the ~only possible interpretation is
that people simply suck at knowing what
they got.
a111: Logged on 2016-09-08 21:44 gabriel_laddel: I'm
translating
the spec from HTML
to CLIM.
a111: Logged on 2016-09-08 21:58 mircea_popescu: wait,
the clim authoritative spec exists as a html ?!
mod6: thanks Gentlemen. I'll keep polishing here. more
to come, I'm sure.
mod6: for you and I,
this is routine.
mod6: the setup of v; verify v; place everything where it needs
to go, etc.
mod6: not a problem
then.
mod6: ok.
that's a minor consideration.
mod6: that's
the easy part imho.
the hard part is getting v, et. al., set up.
mod6: <+mircea_popescu> "
then navigate
to pressed dir, " << i mean. << ah, ok yeah one ~might~ be able
to do
that. not an expert on make
tho.
mod6: which, seems
to be
the "pistols" way
mod6: well, one would still need
to press everything out, which includes
the source and makefiles in
this case.
mod6: does
this seem acceptable?
mod6: i'll see where i can get
to with
this new idea. however, a person would have
to do
this
to build
the entire
thing: get v; verify v; put vpatches, seals, and keys in place; press;
then navigate
to pressed dir,
then `make`.
☟︎ mod6: i could go on here.. but let's just say i didn't
think it all
the way
through.
mod6: yeah, after discussing with myself in here mainly, i'm not in love with
that solution either.
mod6: (working on
that /
testing it now)
mircea_popescu: ok let's approach it
this way : what is so special about
the make files
that
they get
their own
tree ? why not say, all .c files get
their own, all .h files get
their separate own ? inasmuch as you can't use
the makefiles without
the sources,
they belong in
the same
tree as
the sources.
mod6: anyway, i might be able
to get it so
that you press
the
tree, including
the makefiles, and
then just build.
mod6: well it's earliest implementation, was a clone of our build scripts, which, used V
to pull and press
the source.
scriba: Logged on 2016-09-08: [23:52:51] <mod6>
this is because
the makefile process does it's own V press.
mod6: <+mircea_popescu>
http://log.mkj.lt/trilema/20160908/#1160 << so basically we got v running
twice ? << yeah, which wont do. after my monologue earlier, I have a hunch
that I might be able
to get it down
to a single press.
scriba: Logged on 2016-09-08: [23:59:57] <mod6> Altogether, since we have V, I like
the idea of keeping
things like makefiles and buildscripts out of
the main source
tree. One can get V, press
the makefile project. Run a `make`, which will in-turn, press everything via V and
then build with buildroot.
scriba: Logged on 2016-09-08: [23:52:51] <mod6>
this is because
the makefile process does it's own V press.
mircea_popescu: Framedragger can we stop having
this "multiline" bs unless specifically
togled on somehow ?
☟︎ scriba: Logged on 2016-09-08: [19:19:02] <mircea_popescu> yeah but
the wrong one.
scriba: Logged on 2016-09-08: [19:19:02] <mircea_popescu> yeah but
the wrong one.
mod6: asciilifeform: verified,
thanks!
mod6: i've got: 72.83.9.184 listed on
the foundation site. is it back up now with different ip alf?
mod6: Then let
the makefiles do all
the rest of
the heavy lifting.
mod6: The simplest solution would be
to perhaps have a deedified
tarball of makefiles, much like
trinque already has, get
the deed, verifiy it, decode it, extract it, navigate
to
the make script and `make`.
mod6: This hypothetical solution, even if it does work, wouldn't make it a one-button-push solution. Why? A person would need
to get V + V.sig, verify, create a .wot dir, sync
the patches + seals, manually or automatically, press
the
tree,
then navigate into
the pressed
tree, and
then `make`.
mod6: Will
try
to work
that out.
mod6: Well, if it could be done without having
to move anything
that is already in place (as far as bitcoin is concerned),
then it might work out alright.
mod6: It would probably need some
tweaks in
there ... hmm.
mod6: Actually, I forgot,
trinque already did
that part. Makefile.rotor exists.
shinohai: Seriously mod6 it's coming along great,
today's makefile build was so easy
these Eulora noobs could probably do it.
mod6: so, im not 100% off
the
top of my head, but getting rid of
the
two rotor build script and integrating
that portion into our makefiles ~might~ resolve at least part of
the source redundancy issue.
mod6: oh yeah, we're not reall messing with any of
that stuff. stator hasn't been a part of
the 'orchastra' for some
time now.
a111: Logged on 2016-09-09 00:28 mod6: oh, if you're saying
that
the rotor is no longer needed, i can agree with
that.
to an extent anyway.
mod6: the
two .sh scripts you have in
there can be integrated into
the makefiles directly i
think. however, we'll still need
the openssl-004-musl-termios.patch and rotor_buildroot_dot_config
mod6: oh, if you're saying
that
the rotor is no longer needed, i can agree with
that.
to an extent anyway.
☟︎ mod6: When you come back, maybe we can discuss what you're
trying
to exactly say.
mod6: I can't make heads or
tails out out of what you're saying
there asciilifeform.
a111: Logged on 2016-09-08 23:46 mod6: It was my first hunch, during a pre-emptive go around with
this
to not place
the makefiles in with current source base -- as pressed out via V.
mod6: Altogether, since we have V, I like
the idea of keeping
things like makefiles and buildscripts out of
the main source
tree. One can get V, press
the makefile project. Run a `make`, which will in-turn, press everything via V and
then build with buildroot.
mod6: I
think
that keeping
the Makefiles as a separate V
tree would keep
things a lot more clean.
mod6: Anyway, I bring
this up because if we're determined
to stick with
this plan;
the Makefiles included with
the bitcoin source,
then
there is another ball of wax
that needs
to be discussed.
mod6: this is because
the makefile process does it's own V press.
mod6: The problem is here,
that when you run `make`, it'll build everthing under: build/rotor/TEST2/bitcoin/src despite
the fact
that
the source is really under src/
mod6: We discussed
this, it was Mr. P.'s hunch
that
these should belong
together (I hope I'm remembering
this correctly), and I saw
the wisdom in
that.
mod6: It was my first hunch, during a pre-emptive go around with
this
to not place
the makefiles in with current source base -- as pressed out via V.
☟︎ shinohai takes down
the samovar
to make
tea for
this discussion.
mod6: And in doing so, it kinda brings us back
to a previous discussion.
mod6: We are pretty much at
the point of starting V-ify
these makefiles.