179 entries in 0.67s
phf: xquartz builds with an
llvm for sure, it built with a gcc recently, it's quite likely that it still builds with gcc, since it's a direct fork of freedesktop version (but then it's not clear what crazy things fd put into X11 proper upstream), you can find a range of vintage that'll build all the way back to 10.4, but i'm not sure if you can build what i linked on e.g 10.4 specifically. the bulk of code there is combination of posix AND
ave1: yes, and they will happily import any old project these days (new code analys framework is based on python, even
llvm is now imported etc.)
mircea_popescu: apparently usg came to terms with
llvm failing in its strategic goals being unavoidable by now.
ben_vulpes: gcc has the ken thompson hack and
llvm doesn't dontcha know
phf: likewise a lot of them pull gcc for build, lots of complaints about "
llvm broke N" when you search for anything
a111: Logged on 2017-12-03 23:41 asciilifeform: re gcc, recall also that it's been put on the usg hitlist, they would like to lead it to a level of dysfunction that will have naive folx welcoming its shooting behind the shed and replacement with Officially blessed clang-
llvm phf: mike_c: i had it working with pretty much everything, gcc4, gcc5, clang/
llvm. when i build manually i just use dependencies that whatever local package gives me, at which point make Just Works
phf: fwiw, i'm just tryin' ta get a way to publish an occasional document; i was under an impression that TeX is a no brainer, it's supposedly inherently tmsr friendly. apparently not, and not only that, the whole stack, since before i was even doing computing was already
llvm-like. layers upon layers of "autotools"
a111: Logged on 2017-01-16 23:36 asciilifeform: leaving entirely aside the question of whether ice40 can in fact be made to do anything useful with the 'open' toolchain discussed earlier, or whether a toolchain that required clang,
llvm, and ten other poetteringesque abortions is 'open'
mircea_popescu: asciilifeform gcc is no longer an interesting tool -
llvm took over. currently being maintained as "coreboot".
Framedragger: i never got to really explore D, but vaguely recall the compiler not being / not relying on
llvm some years ago
a111: Logged on 2016-01-15 01:38 asciilifeform: 'OpenSSH 6.6 is the only version that is not affected, because it calls explicit_bzero() instead of memset() or bzero(). ..... older GCC versions do not remove the memset() or bzero() call made by buffer_free() or sshbuf_free(). GCC 5 and Clang/
LLVM do, however, remove it.'
trinque:
llvm can compile js to native code. now what?
mircea_popescu: specifically because the
llvm heads discussed earlier apparently don't get very far.
a111: Logged on 2016-12-31 18:20 mircea_popescu: but not just
llvm - the whole world exists, and it produces things such as "'Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example). We strongly recommend tha
mircea_popescu: are you talking about
llvm or about the imaginary market for "Tablets" ?
mircea_popescu: the ~only thing that is even vaguely similar to that is the sort of deep-in-the-bowels systems engineering as to my mind best exemplified by the
llvm thing and ~nothing else.
mircea_popescu: i'm on the record not conflating them, take the recent c/
llvm discussion.
ben_vulpes: and yes wtf
llvm is an iridium brick of apple compiler phd time
ben_vulpes: asciilifeform: i don't really know what you're asking. his uses
llvm-ir to tie into cpp, it's the ~whole point of it.
ben_vulpes: strandh got his working in
llvm in relatively short order
jurov: asciilifeform: i think these somebodies went on to make their own lisp dialect, using python build system or jvm or
llvm or somesuch
ben_vulpes: why aren't you using
llvm to crap out asts and diff those?
a111: Logged on 2016-12-31 18:20 mircea_popescu: but not just
llvm - the whole world exists, and it produces things such as "'Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example). We strongly recommend tha
mircea_popescu: but not just
llvm - the whole world exists, and it produces things such as "'Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example). We strongly recommend tha
☟︎☟︎ mircea_popescu:
llvm is, from a gnoseologic point of view, a superset of gcc, the upper node.
mircea_popescu: asciilifeform to say it again :
llvm is not "a competitor" for gcc.
llvm was written quite exactly with full knowledge of gcc in mind. you know they fully understand how gcc works, and i don't mean on the first order, but on the last, BECAUSE of little signs like these.
mircea_popescu: sure. they know how to do it ;
llvm is not "a competitor" for gcc, the notion that someone could "hold out" is nonsense.
llvm was written quite exactly with full knowledge of gcc in mind.
phf: asciilifeform: well, fwiw i used sbcl for years and was running in increasingly larger number of problems. just small annoyances. when i tried interacting with sbcl "community" it turned out to be the usual suspects, google employees, gender pronounced. i have the same antipathy to sbcl as you to
llvm scriba: Logged on 2016-09-13: [17:46:58] <trinque>
llvm will never actually implement c/c++ as currently "specified" by the existence of gcc
trinque:
llvm will never actually implement c/c++ as currently "specified" by the existence of gcc
mircea_popescu: asciilifeform as a model, i propose to you that there's no substantial difference between this and say your bizarro position re
llvm yest.
trinque: asciilifeform: ftr yesterday my point was not lets rally around
llvm; you'll notice I've been using nothing but sbcl lately.
BingoBoingo: <mircea_popescu> but in this sense, merely writing c code is the sin ; compiling it in the nazi flavour of socialism or in the soviet flavour of socialism,
llvm vs gcc, is sort-of like, what flowers to leave on the raped body, roses or tulips. << Kalanchoe!
mircea_popescu: but in this sense, merely writing c code is the sin ; compiling it in the nazi flavour of socialism or in the soviet flavour of socialism,
llvm vs gcc, is sort-of like, what flowers to leave on the raped body, roses or tulips.
mircea_popescu: the problem here (as well as above, with
llvm) is that without the strongarm to kill sipa / force obedience from hardware vendors etc, you will never be able to make a compiler that works
trinque: point isn't "
llvm is good"
a111: Logged on 2016-09-05 20:27 trinque: to ben_vulpes link, it does not diminish my regard for openbsd that it is moving towards
llvm. considering solely the political aspect, they've previously used their own old (and maintained) fork of gcc.
trinque: I would not be surprised if they forked
llvm if they ever needed.
trinque: to ben_vulpes link, it does not diminish my regard for openbsd that it is moving towards
llvm. considering solely the political aspect, they've previously used their own old (and maintained) fork of gcc.
☟︎ mod6: alf would you be willing to write up a critque/review of
llvm/clang in your blog -- something that rounds up the previously stated?
trinque: anybody have a real critique of
llvm/clang aside "is more clearly written, has API for hooking in tools, and is therefore evil?"
mircea_popescu: well no, jurov compiles the client for windows with something ; iirc
llvm also worked.
a111: Logged on 2016-06-20 18:52 phf: you might not notice it, because you look at it from the perspective of release summaries and hacker news posts, but the kind of decisions that go into
llvm are ~entirely~ driven by large corporate with large teams and large hardware needs. it's synergistic.
a111: Logged on 2016-06-20 18:49 phf: Framedragger: despite the rhetoric people here are extremely pragmatic. but when you think about these things there's no reason to allow sloppy thinking. the question is "how much of a dick up your ass is too much dick", and the healthy answer is "none at all".
llvm is good technology (it gives you same kind of layering that a decent common lisp compiler does, but for languages that are not used to that kind of richnes
a111: Logged on 2016-06-20 18:49 phf: Framedragger: despite the rhetoric people here are extremely pragmatic. but when you think about these things there's no reason to allow sloppy thinking. the question is "how much of a dick up your ass is too much dick", and the healthy answer is "none at all".
llvm is good technology (it gives you same kind of layering that a decent common lisp compiler does, but for languages that are not used to that kind of richnes
phf: you might not notice it, because you look at it from the perspective of release summaries and hacker news posts, but the kind of decisions that go into
llvm are ~entirely~ driven by large corporate with large teams and large hardware needs. it's synergistic.
☟︎ phf: t it), but unlike federated gcc,
llvm is owned entirely by apple and greater extent other apple aligned corporations. their interests are ~opposite~ to those of enterprising individuals.
phf: Framedragger: despite the rhetoric people here are extremely pragmatic. but when you think about these things there's no reason to allow sloppy thinking. the question is "how much of a dick up your ass is too much dick", and the healthy answer is "none at all".
llvm is good technology (it gives you same kind of layering that a decent common lisp compiler does, but for languages that are not used to that kind of richness, so everyone's excited abou
☟︎☟︎ phf: but
llvm is definitely toxic because it was designed with the ~explicitly stated goal~ of killing gcc
mats:
llvm is p technically interesting
Framedragger: is
llvm surely shit? i was always wary of it, but technically speaking, why shit?
assbot: Logged on 03-03-2016 15:17:37; jurov: just for the record, there are several projects built on top of
llvm (cling,clang,clasp) promising C++ interpretation and easy interop with lisp. i tried to build and use these, not one succeeded and they are so behemoth so any analysis of the problem was out of the question
jurov: just for the record, there are several projects built on top of
llvm (cling,clang,clasp) promising C++ interpretation and easy interop with lisp. i tried to build and use these, not one succeeded and they are so behemoth so any analysis of the problem was out of the question
☟︎ phf: i have it running in a frowned upon state. cmake,
llvm, clang
assbot: Logged on 20-02-2016 22:26:08; mircea_popescu: and you may NEVER say to any user "your program is not working correctly because you've not given tyhe developer enough control over it". this is anathema, and the source of the "
llvm-ization" comment.
mircea_popescu: and you may NEVER say to any user "your program is not working correctly because you've not given tyhe developer enough control over it". this is anathema, and the source of the "
llvm-ization" comment.
☟︎ ben_vulpes: i am not well versed enough in the history of gcc and
llvm to understand this.
mircea_popescu: In addition to many internal projects at Google, Google Test is also used by the following notable projects: The Chromium projects (behind the Chrome browser and Chrome OS). The
LLVM compiler. Protocol Buffers, Google's data interchange format. The OpenCV computer vision library.