Rugxulo, It wasn't clear what is not buffered. Is TurboC 2.0.1 itself (the compiler, linker, make, etc.)? Or TurboC 2.0.1's runtime?
On Fri, Mar 29, 2019 at 11:06 AM Rugxulo <rugx...@gmail.com> wrote: > Hi, Tom, > > I thought you might find this interesting since you're always raving > about old C compilers for DOS (e.g. you mentioned MSC 1990 in that > IA16-ELF thread). I don't think we've personally discussed this issue > before. > > Just for the record, "sed" is probably my favorite *nix util. So I've > used it quite a lot over the years (mostly in DOS!). > > (... discussion continued below ...) > > > On Tue, Mar 26, 2019 at 7:31 PM Rugxulo <rugx...@gmail.com> wrote: > > > > Gruess Gott, > > > > On Tue, Mar 26, 2019 at 1:20 PM Tom Ehlert <t...@drivesnapshot.de> wrote: > > > > > > > Developers are very sloppy and include lots of things that they don't > > > > need. They also split up things into too many files. Too many > > > > dependencies. I'm just saying, it's overwhelming, even for them. > > > > > for a clueless moron, you are making fairly big claims. > > > > > do you have ANYTHING to show to support these claims? > > I'm fairly certain you've never rebuilt GNU sed. Nor have I lately. > For instance, it uses Gnulib (which does *not* officially support > DJGPP), which is POSIX-heavy "library", thus a lot of files. Back in > the old days, GNU sed was a version based upon simpler code, but they > switched to an "over-extended" regexp code, and things got complex > fast. (Long story short, hhsed and csed and minised are all using > derivative code, based upon that by Eric S. Raymond.) > > While I like and enjoy GNU sed (DJGPP build, thus 386+ DPMI), I > normally prefer Cheap Sed (improved upon hhsed from 1991). It even had > an "experimental" 16-bit DOS build back in 2004. Minised doesn't have > a default DOS build, but it's easy to compile and was last updated in > 2014. > > * ftp://ftp.fu-berlin.de/pc/languages/djgpp/current/v2gnu/sed47s.zip > * http://lvogel.free.fr/sed.htm > * https://exactcode.com/opensource/minised/ > > There are several things to note about Cheap Sed: > > 1). that it was built with freeware Turbo C 2.01 (which is buggy, > default unbuffered, thus slower than needs to be). > 2). I added rebuilding it as a "test" on my MetaDOS (which you're > vaguely familiar with). There I used old DJGPP (my one-flop setup), > and it was extremely simple to rebuild (unlike GNU sed). > 3). I did also rebuild it with Turbo C++ 1.01 a few years ago, and > that alone sped it up significantly. That's when I discovered that > TC2.01 isn't buffered by default (for whatever reason). IIRC, you've > personally mentioned at least one other bug (re: FIND) with that old > TC2.01 compiler. > > * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/sed/ > > > For PSR Invaders, I used Sed (which is fairly minimal, at least > > MiniSed or Cheap Sed) instead of relying on Perl + Devore's NoMySo > > converter script. The (old) package for GNU Sed that we have is "only" a > > little over 2 MB. (Cheap Sed would be significantly smaller, less than > > half a MB. But I've not made a package for that yet.) > > I'm not sure how that would work for us. If the default package (which > I've not installed) is GNU, then Cheap Sed would (probably?) have to > be renamed differently ("csed"?). Locally, I prefer Cheap Sed as "sed" > and GNU sed as "gsed". This is partially because it's a 16-bit build, > which is also smaller, faster, and more compatible (although GNU does > have some few interesting extra features). > > > > > Things need to be minimalized, simplified! But it takes a lot of time > > > > and effort, and most don't care enough. (I know that's a cheap thing > > > > to say, but trust me, it's a mess that should be avoided.) > > > > > > One of the rare times where you are right. It's a cheap thing to say. > > Again, it's moreso that developers are too busy (or AWOL) to fix > things. I know it's not easy, just saying, sometimes it can be a real > hassle. > > > > > Most things can be simplified and slimmed greatly without losing > any functionality (without dirty tricks). > > > > > > just show your resume with this respect. else shut up. > > > > I'm not totally clueless, but things can get complicated *very* fast. > > Yes, we do have to worry about dependencies and rebuilding because of > > the prevalence of GPL-licensed code. All FD packages nowadays contain > > both binaries and source code. > > Well, I guess you get my point by now. Whatever, not trying to start > an argument, just trying to clarify. Feel free to benchmark ("time") > Cheap Sed (built by various C compilers) yourself, e.g. see my scripts > for rebuilding PSR Invaders with various assemblers using sed. > > * > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/psrinvad.html > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel