3000+ entries in 0.002s
ossabot: Logged on 2019-12-29 18:01:33
trinque: I'd be willing
to abandon lisp for now, seeing as how
the usable components incur at least another 400k lines of bloat, and for
that you gain yet another javascript ecosystem.
mircea_popescu: and of course fixing c compilation so it's no longer outrageous idiocy "that works" (tm) is precisely not a possible utilization of lisp because
the fucking reason it even exist is so as
to not have
those problems, and so on.
mircea_popescu: sp systems
that just _don't_ offer
the serious advantages
that solid Common Lisp systems do
that people can't _afford_
to provide for free." carrying
the day with me, but in larger part
the actual absence of any serious problem (besides, ~perhaps~,
this) we actually could meaningfully use it for. you really don't need lisp
to make a blog anymore
than you need a
mircea_popescu: this is in part naggum's "in my view, Common Lisp provides _values_
that far exceed what other languages do, but I fully realize
that people won't understand
this until
they have actually experienced
the problems
that it solves for
them. now, what's _really_ sad is
that
those who want free Common Lisp systems have _not_ seen what
the commercial systems provide in just
this way, and
they will go on
to make free Common Li
mircea_popescu: in short : i honestly don't
think deploying lisp ~at all~ is such a great idea, or should be done.
mircea_popescu: (sadly,
there's a much better example, also in
the form of a naggum exchange. it revolves around "common misconceptions" and such
typically pantsuitist wooden
tongue, but now i can't fucking find it.
though i clearly remember discussing it recently(
mircea_popescu: "latest and greatest" asdf is exactly like all
the other gpg 2.0 - gcc 19.firefox & assorted
thunderbirds. and François-René Rideau aka fare is still
that infantile dumbass.
ossabot: Logged on 2019-12-29 17:38:31 whaack: diana_coman: From my experience, for most packages from quicklisp you're going
to have problems if you don't have asdf 3+, which comes with sbcl 1.4.14 (not sure what
the first version of sbcl with asdf 3+ was)
mircea_popescu always knew kicking mechanisms is legitimate maintenance
technique.
ossabot: Logged on 2019-12-29 13:57:52 bvt: in
this case, i can restate it as 'depends on how current fragments will get composed into one
tree'
ossabot: Logged on 2019-12-29 13:51:19
trinque: I agree
that
there should be single, correct answers when choosing components (as I'm
trying
to lay out
the options for such selection in my series), but not
that each component is always present in any system.
mircea_popescu: imo
this is from an earlier stage when
the building blocks of what
the problem was going
to be were still being assembled.
diana_coman: mircea_popescu:
tbh re ints I recall an article on
trilema.com - if I can find it now, hm.
mircea_popescu: diana_coman, i didn't imagine you had, no. just... you know, my own amusements, what can i say.
tara mica da' vesela.
diana_coman: fwiw I went
there because of a former friend who kept pulling at me about it; nothing
to do with stanca really, never even
talked
to him ever.
diana_coman: ahahah;
that was one of
those
things where "at least I figure it out quickly enough", lolz
diana_coman: well,
technically it was first
the move
to int64 and
then
the rest but practically
they still overlapped
to some degree and
the similar pains etc.
diana_coman: hm, in my memory
the int64 kind of merges with eviscerating
the gem mess out of
the server
mircea_popescu: pretty sure i insisted a
thing be published at
the end of what was a longish march if memory serves, and pretty sure i was gratified in it ; moreover i recall interacting with a nobject
diana_coman: mircea_popescu:
that's not possible as
the only "old blog not moved" is
that
thing on wordpress.org
that dates from...uhm, 2009/10 ?
mircea_popescu: was it on some old blog and never got moved, is
that possible ?
diana_coman: hmmmm, let me see but I
think it was just a mention in one of
those open sores rants
diana_coman: mircea_popescu: do you mean
the move
to int64?
mircea_popescu: btw diana_coman
there's no ossasepia on
the original "holy shit, ints!!" or am i just not finding it ?
lobbesbot: Logged on 2017-02-21 21:53:17: <mircea_popescu> now, eulora DID move away from broken ints
to sane ints during migration
to 0.1.2, and i don't know anyone cared enohgh
to extensively debug
the insanity
that is microsoft. so you might have found something. what exactly were
those new errors ?
ossabot: Logged on 2019-12-29 13:49:02
trinque: mircea_popescu: does
this mean "everything is always built and installed" ?
mircea_popescu: chema/?b=Compared&e=be#select][bit],
then eventually a small pile of actually useful and working code is left behind, implementing 108% or so of what
the old pile actually did while removing 98% or so of what it had no business doing"
ossabot: Logged on 2019-12-28 22:56:45
trinque: and jfw, dorion_road, if you don't see
the word "Gales" in
there, it's because I'm
trying
to disabuse you of
the notion
that
there's such
thing as a "Gales" which you made, by way of sheer numbers.
diana_coman: trinque: I'll
take some more
time
to digest both
the article and
the comment.
trinque: whaack: starting at beliefs is going
to be a shaky foundation, but fwiw I "believe" most folks writing lisp
today are compulsive masturbators like gabriel_laddel
trinque: which is not just a bunch of bawww. it's worthwhile
to question wtf we use
to value
things within which *whole lifetimes* can be lost, wasted.
whaack: diana_coman: if i search for a piece of lisp code
to do something, I have a (perhaps naive) belief
that I am more likely
to find something well written, since
there are fewer people using
the language
trinque: all my
tmsr work
to date could've been php or pyshits for all
the difference it would've made.
trinque: nobody's defending python; I'm questioning
the superiority of lisp for anything you might actually be doing on a regular basis.
whaack: trinque: pasting chunks of python code is also a pain given
the blocks-created-by-tabs design
diana_coman: re paster
though
tbh
this attempt (coming as it does on
top of
the previous mess with
python and its flask) left me looking again for not using either.
whaack: trinque: First, I find it more pleasant writing in lisp. Second, I like
the cultural aspect of a (present day) more niche language.
Then for problems with python: i find
the single line lambdas a strange requirement, and not having
tail call optimization is lame (although i admit i can't
think of many/any cases where
that's been a problem)
diana_coman: ahaha, by now I see
that
trinque will measure everything in multiples of busybox.
trinque: not saying it shouldn't, but why do you hope
that?
whaack: trinque: well fwiw I sincerely hope
tmsr-os comes with a lisp over a python
trinque: anyhow, gonna stop skipping ahead and get
to writing
trinque: and
that's
the latest, fattest busybox yet.
trinque: and both of
these are larger, again,
than ALL OF BUSYBOX
trinque: clozurecl ftr is just about as fat as sbcl
these days.
trinque: if we were
to retain lisp, I'd say pick one, don't have a python alongside it, and don't expect
to use much "open source"
to help you.
trinque: I'd be willing
to abandon lisp for now, seeing as how
the usable components incur at least another 400k lines of bloat, and for
that you gain yet another javascript ecosystem.
trinque: but I've had a pretty violently negative reaction
to
the whole pile.
trinque: I
try not
to use asdf at all, anymore.
whaack: trinque: what were
the sizes of
the C kernel and lisp part
to begin with?
trinque: lines are another bad proxy for complexity, but
they're a better measure
than
the version
triple
trinque: so it's not so clear
that it got harder
to maintain as
time went on, depending a whole bunch on where
that extra lisp ended up
trinque: whaack: in
this case, between sbcl-1.0.50 and
the latest,
the C kernel of
the
thing actually got smaller by roughly a
third, while
the lisp part expanded by about 100k lines
trinque: there's also
this hard-to-define cultural decay element
whaack: trinque: i am more
than open
to hear yours
trinque: I
think
this is a bad heuristic.
whaack: trinque: I can't say I am principled in
the manner. in general, i use
the lowest version
that works
trinque: whaack: what's
the principle upon which you choose versions of
these?
whaack: diana_coman: I
tried and failed
to upgrade
to asdf 3+ while keeping my sbcl 1.something .
That is one reason why I switched my sbcl
to 1.4.14
diana_coman: noted,
thanks; basically so far it's have fun with python versions or fun with asdf version, lolz.
trinque: I can genesize
the phpwad as well.
whaack: diana_coman: From my experience, for most packages from quicklisp you're going
to have problems if you don't have asdf 3+, which comes with sbcl 1.4.14 (not sure what
the first version of sbcl with asdf 3+ was)
diana_coman: whaack: what version of asdf did you get
to work with all
the rest anyway?
trinque: yeah,
that
thing's just a lib around doing
http posts
to what's a very simple wad of php
diana_coman: ... lisp code is
that it pulls in
the drakma
http client
that pulls in as far as I can see another 18 deps (and moreover so far one of
them fails anyway on my current setup aka centos 6 with sbcl 1.0.39, asdf 2.26; but I see
that whaack reports
sbcl 1.4.14 working for
the logbot so I'll
try it next with
that and see.)
diana_coman: trinque: I had a look at your published
paster lisp code; my current understanding is
that it's only a part of what's required
to stand up a backup paste service
though, isn't it? mind pointing me
to
the rest of
the bits/a recipe
to put it all
together? I had
this idea
that it's saner
to replicate at
the very least
the paste service and a mirrored wot website. My current understanding of
that paster ...
ossabot: Logged on 2019-12-29 05:44:04 diana_coman:
trinque: is
the select
thing not working on your blog? I'm
trying
to select
that great "fits in hand" and I can't seem
to,
this doesn't do anything.
bvt: in
this case, i can restate it as 'depends on how current fragments will get composed into one
tree'
trinque: no,
there's only one v
tree
bvt: at
the individual v-trees sure, but on
the yddragsil level?
trinque: bvt: not
trying
to be a pedantic dick over here, but it's v
that's
the boundary around
the other stuff, not
the other stuff around v
bvt: mircea_popescu: re second q, imho cleaning up
the components will be driven by how
the OS gets [re]structured around V,
too early
to say right now
trinque: they are however all
to be in
the source v-tree, of course.
trinque: I agree
that
there should be single, correct answers when choosing components (as I'm
trying
to lay out
the options for such selection in my series), but not
that each component is always present in any system.
bvt: mircea_popescu:
ty; fixed.
trinque: mircea_popescu: does
this mean "everything is always built and installed" ?
mircea_popescu: or
to put it another way, i do not believe it is either intelligent or even
tolerable
to
try and carry forward
the "install" paradigm from derpworld. something much more akin
to diana_coman 's work on eulora is what "get installed" will have
to mean.
mircea_popescu: neways, as
to
the burning "OTOH, I wonder if
things like Apache or imagemagick get installed, how will
the package management system work out, and how comprehensible will system stay?" question -- i see
the merit of using
the clean spot as a fixed point
to attempt expanding cleanliness. so, it would work by apache becoming
tmserv or w/e, and not sucking anymore.
mircea_popescu: by ready availability of python or others." << indeed
this is mindblowingly beautiful, and as far as i current;y know
the foremost fearher in jfw 's cap.