On Sat, Jun 7, 2014 at 3:40 PM, <to...@acm.org> wrote: > * Several old time assemblers will choke on wrong line endings. Their >>> binaries cannot be updated as the source is no longer available. So, you >>> must edit code only in the right format or you’re out of luck. >>> >> > This seems to be conflating the editing of assembly source with editing >> of binaries for which source is no longer available. What am I missing? >> > > What is not clear? Old assembly source may still be updated, as needed, > to support existing products. But the assembler used to convert this > source to binary cannot itself be updated as its source is no longer > available, only the binary survives. The assembly source is written for > this assembler so you’re stuck using it. For old projects that will > eventually die, it's not worth the effort creating a newer (better > behaving) assembler, and possibly converting all target source code to a > possibly incompatible new assembler's syntax introducing a whole bunch of > new problems.
AH! That is what was not clear to me, and hence why I asked. You meant the assembler's source code was no longer available to edit, when I thought you meant the assembler's output was not editable. But in this case if you have the source for the program you want to assemble, and an assembler that only understands a single EOL marker, you can modify the EOL markers of your source via tr or dos2unix/unix2dos. > Now this is maybe a slightly emotional response. No one has told you EOL >> conversion is a useless feature, just that in their opinion that it doesn't >> belong in a particular DVCS whose primary overriding concern is "store what >> I tell you to store exactly as I have stored it". To me this makes sense, >> particularly on a platform (unixen) that is notorious (to a fault maybe?) >> of advocating tools do one thing and do it well. >> > > In general, an SCM that is supposed to be used by various people each > working on a their own ‘random’ platform should be able to give to all of > them the impression that text files are normal text files, that is ‘normal’ > according to their own system, not to the system of the person who > initiated the repo. Otherwise, repos should be marked as ‘Linux-only’, > ‘Windows-only’, ‘Mac-only’, etc. and trying to open them in the wrong > platform should fail with a related error message. Do we agree so far? If > not, there is no need to read further. > > Given that all text files contain their meaningful info in the part of the > file that is not the EOL marker, and the EOL marker is only there to assist > the underlying OS/library to be able to correctly load/process that text > file, changing those EOL at will to be compatible with the user’s current > platform is not a violation of any sanctity. If the platform’s tool cannot > deal with a text file in its own native format, then that tool is at fault, > nobody else. But if a tool cannot deal with a text file of a different > platform, we cannot blame the tool. > > Finally, regarding a comment in another response about the complexity of > this change, as for the hash values computation, a stream can easily be > wrapped inside another routine that produces a normalized stream that is > then fed into the hash calculator. I really do not see the complexity. > Maybe I don't have enough decades in this job yet, who knows? > I completely agree with the points other than the one that "the DVCS is the only tool that can effectively manage the EOL convention of the files". I use a text editor daily that is capable of normalizing EOL convention (though of course there are few things capable of starting a flame war as effectively as suggesting to any random group of people that their OS or text editor is inadequate to some task). :) As long as we're talking about features we'd like to see in a swiss army knife DVCS: a lot of time is spent telling people what the coding standards are for an individual project, things that make EOL conventions seem minor (but would certainly include such things). I'm surprised no one has grafted onto git (or some other DVCS, or maybe I'm just not aware of the one that does) an ability to reformat all source code to match the standards of the project before committing it to the repository. Plenty of programs exist to reformat source code (at least for C & C++), and wouldn't it be awesome if we could always check out code formatted to our own preferences and always make sure that no matter what our preferences were out commits always matched the project standards? Hey, DRH, get right on this, will ya? ;) Also, I dislike editing Ruby. I need a DVCS that will convert it to Python automatically for me and then reverse that when I commit. :) Yes, I'm being ridiculous, and I apology. It's more because I found these last two thoughts amusing (particularly the last). I can see a use for tools / hooks that can do this. I don't always agree with DRH, and admit that I liked the idea of the svn ability to convert EOL markers even though I never used it. But I can also see the point to the idea that "this is the file I created and this is exactly what I want to see when I pull it out of a repo that I put it into". No one is suggesting that EOL conversion is a bad idea, and creating a workflow that does it for you automatically (albeit with extra effort) is possible today without a single changed character of fossil source code! The only difference of opinion is whether or not it belongs in fossil proper. Passive aggressive comments about "git devs must have implemented a useless feature" or "I must not be smart enough to see your wisdom due to insufficient years of work experience" might help get these features into fossil, but I'm not going to hold my breath. In any case, if you'd like some help creating a workflow, I'd be happy to help you do so if you really need it. Good luck! SDR
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
