[HN Gopher] I got the J language working on OpenBSD
___________________________________________________________________
I got the J language working on OpenBSD
Author : ingve
Score : 83 points
Date : 2021-09-12 18:21 UTC (4 hours ago)
(HTM) web link (briancallahan.net)
(TXT) w3m dump (briancallahan.net)
| JulianMorrison wrote:
| It feels to me like this is a bit of an indictment of the J build
| system. I wonder how hard it would be to port it all to something
| more standard?
| mlochbaum wrote:
| Thirty year old codebase with few developers, built on multiple
| platforms. It's about what you'd expect. But I believe there
| have been some improvements made in the past five years or so
| (the source was released under GPLv3 about ten years ago).
|
| BEST, llc has built it with Tup (see
| https://github.com/iocane/unbox), so changing the build system
| is at least possible.
|
| Edit: there's also a long-open PR to move to CMake at
| https://github.com/jsoftware/jsource/pull/20.
| tyingq wrote:
| The changes made were pretty minor. It looks like one #ifdef
| __linux__ needs to be looked at, and some better detect/#ifdefs
| around AVX and SSE3. At least to make it work on unix-y
| systems.
| nerdponx wrote:
| It would be interesting to see a writeup comparing J and the
| open-source implementation(s) of K. Which would be better for a
| complete novice at array programming?
| lvass wrote:
| I'd recommend APL2 and the GNU APL implementation instead. The
| reasoning is you can follow through the excellent Ken Iverson
| Turing Award paper [0], and, while using non-ascii is a small
| upfront cost, it IMO makes array languages much more readable.
|
| [0]Notation as a tool of thought,
| https://doi.org/10.1145/1283920.1283935
| rak1507 wrote:
| I would recommend Dyalog APL over GNU APL, it is much more
| modern.
| lvass wrote:
| That's proprietary. And modern isn't an advantage in
| itself, unlike open-source for someone requesting open-
| source.
| rak1507 wrote:
| I know it's proprietary, it isn't my language of choice,
| but it's a lot better than GNU APL.
|
| If they really want something open source and good, J,
| open source ks, or BQN will be better. But if you're
| suggesting an APL dialect, Dyalog is much better than GNU
| despite being proprietary.
| liveranga wrote:
| J is definitely more batteries-included than the open source K
| implementations.
|
| There's also a wealth of documentation and books on J: J for C
| Programmers: https://www.jsoftware.com/help/jforc/contents.htm
|
| Learning J:
| https://www.jsoftware.com/help/learning/contents.htm
|
| And the New Vocabulary "Nuvoc" on the wiki:
| https://code.jsoftware.com/wiki/NuVoc
|
| Edit: spelling.
| rjeli wrote:
| _One thing that I noticed that we tend to not like in OpenBSD
| ports is that -Werror was in every compiler invocation line. That
| had to go._
|
| Googling "openbsd werror" doesn't show anything, why is this?
| ianlevesque wrote:
| Werror is great for development but not actionable if you're
| just trying to install it as a user.
| spijdar wrote:
| This is true, but the whole things sounds like anathema to
| the OpenBSD ethos, as I know it, which seems obsessed with a
| sort of functional correctness and consistency.
|
| Enabling Werror sounds like exactly the sort of thing that'd
| be encouraged by default, and only disabled on ports that
| couldn't be patched to fix it. Or at least, enabled on ports
| that can have it enabled.
|
| (that said, I know that the vast majority of software won't
| compile with Werror, so, ?)
| ploxiln wrote:
| -Werror can be useful for CI, but elsewhere it is
| obnoxious. Warnings should be warnings, errors should be
| errors. If you always turn warnings into errors then you
| remove a useful tool.
|
| Warnings do not mean the program is incorrect, and lack of
| warnings do not mean the program is correct. It is just
| heuristics, and changes between major versions and
| different implementations, even while the program execution
| behavior is exactly the same. OpenBSD cares about
| portability. A well implemented program should work
| correctly with a good range of different reasonable
| compilers, and -Werror really throws a wrench in that.
|
| Imagine you want to update the compiler to a new major
| version that has some corner-case correctness improvement
| or some security mitigation feature - but it also has a new
| warning. Can't do that! Unless you change the source of a
| bunch of libraries and applications which you didn't write.
| Mistakes have been made fixing warnings, like the infamous
| Debian openssl fix that removed most of the entropy from
| generated ssh keys.
|
| If you care about correctness, you pay attention to and fix
| warnings where appropriate, without forcing yourself by
| making all your builds on different compiler
| versions/implementations just fail.
|
| There was a time that CPython wanted to add a deprecation
| warning, but some popular libraries ran tests with the
| equivalent of -Werror during a regular build/install
| (trying to be super-correct best-practices etc), so adding
| a warning would break compatibility with most of the
| ecosystem, so CPython couldn't just add the warning using
| the long-established system. Instead they had to come up
| with a new system for warnings shown in some circumstances
| and not others, to effectively trick these super-best-
| practices projects into still working.
| kazinator wrote:
| There is nothing wrong with -Werror, if you control the
| exact set of diagnostics!
|
| The problem are the "surprise me!" warning options
| (-Wall, -Wextra) of GCC which bring in diagnostics which
| differ from version to version. So then with -Werror, the
| language has become a moving target: what is considered a
| bad construct that stops the translation is changing.
|
| The problem with _not_ using -Wall and -Werror and just
| specifying the exact diagnostics you want, together with
| -Werror, is that you don 't benefit from the discovery of
| defects brought about by new diagnostic options.
|
| The fix for that is to have an ongoing thread of activity
| in your project dedicated to exploring new compiler
| options (supported by a special build configuration).
| ianlevesque wrote:
| I'm not involved in OpenBSD but I don't see the value in
| preventing an end user from installing arbitrary packages
| just because the compiler was updated recently. The person
| being notified of the error is the wrong person.
| spijdar wrote:
| True, but OpenBSD seems to _some extent_ value
| correctness over "usability". I can imagine the argument
| being made that if something changed and caused the
| package to stop building, it should be fixed, because the
| warning was potentially significant.
|
| Since they _do_ want the OS to be practical and usable,
| though, your argument also holds true, and seems to take
| precedence here. Just kind of surprised they 'd make a
| policy of explicitly patching out upstream's Werror,
| since it implies it's "supposed" to work with no errors.
| MichaelBurge wrote:
| You are speaking way too conceptually and not looking at
| the actual warnings that compilers report.
|
| Some compilers will warn about: while
| (true) { ... }
|
| having a constant condition. The fix is to write:
| for (;;) { ... }
|
| to nobody's benefit.
|
| I've used languages that warn if you use snake_case
| instead of camelCase, because it violates their preferred
| naming convention. Or if you accidentally use a tab
| somewhere, it'll warn about a mix of tabs and spaces.
|
| None of these matter for correctness, yet you're
| advocating to break the build for correctness.
| brynet wrote:
| OpenBSD's ports tree gets compiled using multiple
| compilers (clang/gcc) and compiler versions (base 4.2.1,
| ports gcc8/11), across many different architectures. In
| most cases when an upstream has added -Werror to a
| Makefile, they have not considered this. It's good for
| testing, but not for reliably compiling software.
| bollcv wrote:
| gcc has been shoving warnings into _-Wall_ or _-Wextra_
| that actually belong to a linter for years, for example
| _-Wmisleading-indentation_.
|
| Bug free software that compiles warning free has to be
| updated because of the stylistic preferences of some RedHat
| person practically with every new gcc release.
|
| For KPI harvesting developers of course "fixing" non-issues
| is financially attractive.
| chrisseaton wrote:
| If a user tries to compile with a compiler that gives a new
| warning, what do you expect the user to do about that?
| unwind wrote:
| I know nothing about OpenBSD, but one reason to avoid -Werror
| in shipping code that I've heard is that the set of warnings is
| a moving target.
|
| It's easy to imagine having a compiler upgrade then add new
| warnings, that cause unchanged code in a project with -Werror
| to no longer build, thus breaking it.
|
| Of course it can be argued that such "exposure" flushes out bad
| code with a vengeance, but it can also be considered to be
| annoying.
| mikepurvis wrote:
| As someone in a DevOps role who has three times been the
| steward of major migrations between baseline OS versions, I
| have often been frustrated at teams who have hard-coded
| -Werror into their build configs, thus forcing me to jump
| through hoops to patching it out because the new compiler has
| some trivial complaint about this or that and the build is
| uncompileable on the new target.
|
| I understand the noble goal of being warning-clean, but I
| wish there was a way to implement it in such a way that it
| could also be globally disabled. Then I could get a top level
| build, but the local resolution of the issues would still be
| on the owners of the code.
| initplus wrote:
| Zero warnings is the kind of thing that should be enforced
| as a pre merge check rather than a build showstopper.
| userbinator wrote:
| The new warnings also tend to be increasingly asinine, and I
| remember an instance where two warnings happened to be in
| direct contradiction to each other, making it impossible to
| satisfy them both without some extensive and absolutely
| useless rewriting of the code.
|
| I think one was about superfluous parentheses, and the other
| about _not_ parenthesising an expression because it assumed
| the programmer would be too stupid to know the precedence of
| operators.
| mistrial9 wrote:
| Thank you! this is what senior programmers are for, you-all
| wyc wrote:
| Thank you! Now OpenBSD routers will have a powerful array
| language available for statistical analysis of network traffic.
| :)
| 7thaccount wrote:
| I think there is a J book on statically analyzing network
| traffic
| enduku wrote:
| Link to the book in question
| https://www.springer.com/gp/book/9781846288227
| stirfish wrote:
| http://libgen.rs/book/index.php?md5=4FA72167BDF2DC436A22F5C
| 0...
___________________________________________________________________
(page generated 2021-09-12 23:00 UTC)