Live data from Hacker News

Decoded: GNU Coreutils

maizure.org

41–50 of 56 posts

Re: Decoded: GNU Coreutils

#41
post #29

Rather than a flow chart, etc. It would better to convert the utilities to simple C with no error handling or optimization. So `cat` would be about 5 lines. No mmap() or fancy stuff.

Many older operating systems do a pretty decent job at this: I would suggest taking a look at those. (Alternatively, if you're looking for something that's still modern, BSD usually cares less about optimization than GNU does.)

Re: Decoded: GNU Coreutils

#42
post #38

I've been trying to contribute additional flags for some coreutils commands, but I've been having trouble building on macOS. Should I use a certain VM or container instead? Does anyone have a link to instructions for building on a mac?

Do you have a modern GCC installed?

Re: Decoded: GNU Coreutils

#43

Earlier quoted context omitted.

Agreed, this would be very beneficial to students and people learning C.

I have used the source code for Plan 9's core utilities as a teaching aid for students learning the basics of C and operating systems to great effect. I have found GNU's tools to contain a lot of "cruft" to make them run fast, which is not necessarily conducive for those who are not familiar to why they work.

Yeah, plan 9 was my second thought when I saw this. The first one was suckless' core.

Re: Decoded: GNU Coreutils

#46

I'm not particularly interested in coreutils per se but this is a super-interesting way to look at any piece of software. I just _love_ the block diagrams... why can't source code look like this? Great work!

There are languages that model code like this. Using one for a while will likely teach you why. If you think "spaghetti" is an apt description for text code, wait until you see flow based code that's evolved in place for a while.

Labview is one of these languages, which I’ve used for the last 5 years. It’s the only tool I use daily that makes me want to blow my brains out. I think diagrams like these are really useful as high level visualizations, but fail miserably as a low level implementation.

It’s my opinion that one of the things that turns visual code into spaghetti is that refactoring is difficult, because the code grows in 2d, as opposed to 1d (I don’t count line length). It’s sort of like if you could have infinitely many columns of concurrently executing code in text a based function, where any line in a given column can be connected to any line in a different column.

I think what could be useful is a hybrid model, where you have something like text based modules whose communication is orchestrated by a visual diagram. For what it’s worth, Simulink can be used like this to some extent(e.g., hooking S-functions together) and I find it orders of magnitude more pleasant than labview.

Re: Decoded: GNU Coreutils

#47
post #42
post #38

I've been trying to contribute additional flags for some coreutils commands, but I've been having trouble building on macOS. Should I use a certain VM or container instead? Does anyone have a link to instructions for building on a mac?

Do you have a modern GCC installed?

  $ gcc -v
  Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
  Apple LLVM version 10.0.1 (clang-1001.0.46.4)
  Target: x86_64-apple-darwin18.6.0
  Thread model: posix
  InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Re: Decoded: GNU Coreutils

#48
post #47
post #42

Earlier quoted context omitted.

Do you have a modern GCC installed?

$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1 Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/…

I would not at all be suprised to learn that GNU coreutils does not build with clang/llvm. Try installing a real GNU C compiler with homebrew (brew install gcc)

Re: Decoded: GNU Coreutils

#49
post #29

Rather than a flow chart, etc. It would better to convert the utilities to simple C with no error handling or optimization. So `cat` would be about 5 lines. No mmap() or fancy stuff.

You might find source of Xv6 - educational version of unix - useful. Here is their implementation of cat, all 44 lines of it: https://github.com/mit-pdos/xv6-public/blob/master/cat.c

Re: Decoded: GNU Coreutils

#50

I'm not particularly interested in coreutils per se but this is a super-interesting way to look at any piece of software. I just _love_ the block diagrams... why can't source code look like this? Great work!

There are languages that model code like this. Using one for a while will likely teach you why. If you think "spaghetti" is an apt description for text code, wait until you see flow based code that's evolved in place for a while.

Presumably all the detail is shown at once? I'm picturing something more like Google Maps navigation where you zoom into the source diagram and the code appears.

Perhaps I'm imagining an alternative way to manage source trees, or modules, rather than the code in individual source files. A hierarchy like a traditional file system but with extra kinds of relationships. Perhaps it'd have to be curated like reference documentation, perhaps it could be automatically generated from source directives. I dunno, just idle thoughts...

Post reply on HN