Date: Wed, 25 Jun 1997 00:15:18 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: un_x@anchorage.net (Steve Howe) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: BSD io Message-ID: <199706241445.AAA24909@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.95q.970624004901.9670C-100000@aak.anchorage.net> from Steve Howe at "Jun 24, 97 01:00:20 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Howe stands accused of saying: > On Tue, 24 Jun 1997, Michael Smith wrote: > > > "read in a character mode from the keyboard" doesn't actually _mean_ > > anything, so it's impossible to give you a useful answer. How about > > you explain the situation you're trying to handle, rather than coming > > up with half a solution on your own and having us try to guess at it? > > i did - i initially wanted fast char i/o from/to vga, > preferably portable, so it seems as if S-Lang would've > been the "obvious" choice from the start, but none of > you hackers even mentioned it. so "hackers" advice > wasn't as good as my hunch. Well, I wouldn't be paying much for your hunch then., as has already been pointed out. And I'll state, again, that you did _not_ state your requirement in any sort of comprehensible fashion. Or, more specifically, the only fashion in which your query _could_ be comprehended was answered by several people (including myself), and yet it seems that you'd be much happier finding an answer to a different question entirely, on your own, and despite the fact that the new question doesn't fit the new answer, this is cause for smug self-satisfaction and gloating. Are you aware that this is meant to be a forum for technical discussion? Having had my time and efforts thus abused, you can be pretty sure that I'm not terribly kindly disposed to you just now. > > > > Firstly; why on earth do you want to read back from the screen anyway? > > > > because i find it more efficient to scan a screen for data entries > > > / error checking (at the end of user input) than to write code that > > > deals with all field related functions as each field is entered by a > > > cursor. > > > Uh. As this message is rated PG, I'll reserve my judgement on that one. > > huh? i have no idea what you are talking about, i spent years fine > tuning code and algorithms for certain things .... Well, all I can say is that in the "years" you have spent fine tuning your code, you must have been locked completely away from any source of correctional inspiration, or for that matter much in the way of coherent thought. If I had to bother explaining why reading stuff back off the screen was such a totally losing idea to someone I was training, I'd probably be having some quiet words to their employer about a responsibility transfer to something more appropriate like, say, janitorial work. Ultimately, it is such a basic violation of the premises and abstractions on which a user interface is based that it's literally unthinkable. > > Unfortunately, RAM tests aren't worth spit in most cases. > > unfortunately, i can't make the us government change it's mind > all by myself or my opinions. *shrug* Another case of attempting to retroactively justify a pointless aside. Your original point was "you guyz must kno nuthing about RAM testerz", wheras the reality is that we know too _much_ about RAM teters. The only RAM testers worth using are standalone hardware in the $10k+ bracket. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706241445.AAA24909>