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

Reply via email to