7 ms·
Dunno if just mobile problem, but most code has ^M instead of linebreaks; hard to browse oneline source
by damck 8y ago
Dunno if just mobile problem, but most code has ^M instead of linebreaks; hard to browse oneline source
- jsheard 8y agoIt's because the code was written on classic Mac OS, which used CR newlines rather than the LF or CRLF styles used today.
- shmerl 8y agoWell, they could just apply a minimal cleanup for end lines before posting.
- pvg 8y agoThen the people who want to compile it rather than complain about it would have to go through an extra hoop to fix it again. They published it the right way.
- Skunkleton 8y agoPlus, if they replaced the ^Ms, what would we have to complain about? This truly is the best way. People can complain, and people can compile.
- pvg 8y agoThat is an excellent point although I suspect your question is going to be answered in spades when people notice who the developer posting the code is.
- Skunkleton 8y agoI don't know anything about this developer?
- mrpippy 8y agoAgreed, at least make sure it will still compile with line endings changed before submitting pull requests. This builds with CodeWarrior 10 (from 1996) which is probably OK with non-Mac line endings, but there are other old Mac codebases on GitHub using older toolchains that require CR. (i.e. Pararena 2: http://bslabs.net/2016/11/13/building-pararena/ http://bslabs.net/2016/11/13/building-pararena/) A PPC Mac running OS X 10.4 is basically the only way to work with both git and classic Mac dev environments, I'll be trying this out myself.
- vt240 8y agoI still have my Power MachTen CD. I used to love wasting time porting GNU/Linux source to that odd ball environment.
- mrpippy 8y agoA year or two ago I built dropbear on Power MachTen, worked great and just needed a couple fixes to bring it back into compatibility with GCC 2.x. Playing around with Professional MachTen (for 68k) is a real trip though. 4.3BSD, an even older GCC, and it implements virtual memory and protection by taking over the system memory manager. (You actually have to restart when quitting it) It would be so cool to have something like MachTen on iOS, some people have tried but the restrictions on executable pages really restricts things.
- monocasa 8y agoEh, I prefer when they don't clean up anything. It feels more like real archival work.
- deleted 8y ago[deleted]
- k__ 8y agolol, I knew LF and CRLF was a thing, but only CR? Interesting :D
- eterm 8y agoTaken literally just CR seems very odd. You probably know this, but LF is "line feed" which advances the feed. CR is "carriage return" which puts the carridge to the start of the line. The combination makes sense because it does both, it returns the carriage and advances the line. Just LF kind of makes sense because when you advance the line you can think of the line being empty. But conceptually just CR suggests returning the carriage but that doesn't imply the newline. Of course the terminology is originally from type-writers so it doesn't have to make sense, but it does seem odd that some systems chose just CR.
- chc 8y agoOn a typewriter from around the time of the first Macs, the return key normally moves back to the beginning and moves down a line, so that's probably why they picked it. They also called the key "return" rather than "enter."
- craftyguy 8y agoStrange that 'return' takes you to a new line, rather than returning you to the previous line. English!
- doughj3 8y ago(Nevermind)
- boomlinde 8y agoIt's a simple mechanical artefact. Carriage return moves the paper carriage all the way to the right (returning it to its initial position), while line feed will advance the paper vertically (feeding a line through the carriage). With that in mind, line feed and carriage return on their own make about as little sense. On later type writers both the line feed and carriage return were integrated into a single key or lever, which was just called carriage return or return. From this perspective, an encoding using a lone CR for newlines might make more sense than one using a lone LF. But neither combination really makes intuitive sense in buffered, electronic systems. It's just how it is.
- deleted 8y ago[deleted]
- defen 8y agoIf you click on the "raw" view it will render properly in the browser. You might also need to force your browser to display with "Western" text encoding (that's what it's called in Firefox, not sure about other browsers).
- alexrage 8y agoViewing the raw file, at least in Chrome on OSX shows line breaks.
- vmsp 8y agoSame thing on desktop.
- tibbon 8y agoI put in a PR to fix that: https://github.com/NightDiveStudios/shockmac/pull/2 https://github.com/NightDiveStudios/shockmac/pull/2 Best thing about GPL code is that we can fix it!
- amatecha 8y agoChanging line endings isn't a "fix"... if you do that, it's unusable on the intended system upon which you would work on this code - System 7 or Mac OS 8.
- Kristine1975 8y agoI'm pretty sure CodeWarrior was able to deal with any kind of line endings: CR, LF, CR+LF.
- tibbon 8y agoThis might be a dumb question (I spend most of my days in Ruby), why can't this compile with gcc and make? It's all just C (and a few files C++) right?
- carussell 8y agoThe fix that needs to be made here is in Git, which fails to process line endings in a sane way (and includes a bunch of insane, poorly documented config options that approach the problem completely sideways).
- duskwuff 8y agoThere's a CR->LF conversion at: https://github.com/chungy/shockmac/ https://github.com/chungy/shockmac/