Re: Ann: Luxasm 00.01.00 (2004-04-08)

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 04/29/04 

Date: Thu, 29 Apr 2004 02:38:32 +0100

C wrote:
> Beth wrote:
> [snip]
>
> Good to see you can start experimenting soon :-)

You'll probably change your mind about that, once I start poking
around with your code and that kind of thing...nah, just
kidding...I'll work from the "modular GUI framework" angle because,
well, that was my mad idea...it can then "meet up in the middle"
somewhere...

> > ...technically, in fact, 64MB doesn't
> > meet the "requirements" they specify (but, as usual, they aren't
> > really a true "minimum" at all...more of a "right, you use it with
> > less than these figures and it's your own fault if the thing
crawls
> > like a snail and we accept no responsibility for that
>
> My system is only a P120 with 48Mb of memory running Mandrake 9.0
> -- Luxasm will still tokenise/parse raw (non macro) code at around
> 25000 lines per second on that system (calculated using 'time' and
> Randall's tokeniser test bench (see the test/ directory for the
> Luxasm code generator -- b_scan)) and that is _without_ heavy
> optimisation for most of the code.

Ah, well, I wasn't worrying about our own code's efficiency...there's
not much of it yet and we're using ASM and all that...my concern was
the "other stuff" like X / KDE and the GUI stuff...you know, 10 years
booting up, 7 years waiting for the "menu" to appear, 3 years waiting
for submenus to appear, 8 years per application loading them into
memory, etc., etc....as I was saying before, _no-one_ seems to design
or program these GUIs very efficiently anymore that they eat through
memory like some really strong acid that the bad guy wants to dip
James Bond into...and as LuxAsm is going to be a GUI application
ultimately, then there's only so long "hiding" away at the good old
text-mode command shell...

As I mentioned above, it's not really about getting it to actually run
this stuff...it's about getting it to run this stuff fast enough that
I don't fall asleep between mouse clicks, as they are each 7 years
apart...okay, an exaggeration but nothing is more annoying and
damaging to "productivity" than when it takes so long just to pick a
bunch of menu items that you've plain forgot what it is that you
should be doing (N.B. As I've mentioned before, my short-term memory
is often dreadful that it's got to respond quickly or I _will_ simply
forget what it is I wanted to do, anyway ;)...the fact that none of
the modern GUIs seem particularly concern with lowering requirements
to make this stuff as "instant" as possible, suggests they're doing
that whole thing of concentrating too much on the "technical side" and
their own work, and not enough on the _usage_ side of things or what
some "pretty icons" do to the speed at which users can move around
things...in other words, they'd _FAIL_ my "the users and the
application define what's right" test completely...I'm not one of
those people who thinks that there's something "mutually exclusive"
about having functionality and having pretty graphics...but, clearly,
the _priority_ is functionality each and every time...if it don't work
properly, then it's _BROKEN_ (and, yeah, as speed _is_ a factor in the
way users use these things - they should basically be so quick and
instant that the user can _ignore_ them, so to speak - then not making
the speed _IS_ criteria to call such interfaces _BROKEN_...they are
not meeting the basic requirements that the application lays upon them
:)...in such a context as this, the goal to aim for is literally "so
instant that the user forgets they even selected any menu"...these are
the basic navigations in such an environment so they should literally
be "back of my hand" stuff in both ease of use and _speed_...if they
take too long, they are distracting attention from the _REAL WORK_ and
are, thus, _broken designs_...the problem is perhaps one of pride that
they don't see this, thinking "wow! Look how nice my icons look and
how smooth the menu appears"...concentrating on _their_ concerns to
the detriment of the user...selecting menus is a _delay_ to what they
really want to be doing...the things should literally appear and
disappear instantaneously - nope, not even "fraction of a second" is
good enough unless that fraction is so low as to be effectively
"instant" from a human perspective - and that should be the case
always, except for the most extreme low virtual memory conditions...in
other words, these things need to be taking up practically no RAM at
all that they can be sitting "pre-cached"...rather than re-read any
directory on disk that they may represent, stick "tracers" onto the
folders and only make incremental changes when those folders are
altered...blah-blah-blah...the point, anyway, is that they should be
thinking "instant" and not tolerate anything less (and, in fact, _how_
they go about that isn't that important...this stresses the point, I
think, that it's the _application_, not some "technical" things here
and there which are paramount considerations...if inserting bananas
into their CD-ROM drive is a way for the developers to achieve code of
this calibre then they should start banana-stuffing immediately and
throw in a few extra bananas to boot ;)...it's basically a kind of
"attitudinal" problem in the computing industry...this stuff is
actually completely unacceptable - especially when far, far lesser
machines before them could manage the criteria just specified - but
everyone's learnt to "tolerate" such crap from Microsoft crap-peddling
that they don't complain or think differently when they
_should_...Apple are on the money: "Think different" ;)...

> [snip]
>
> > I still have absolutely no idea how you managed to work out the
> > problem remotely when I've been giving such bad descriptions of
> > what's happening...
>
> Probably happened to him before -- that has happened to me enough
> times that I should have though of it too. Never mind you'll know
> what to try next time.

Yeah, that's what Herbert said too...but I wouldn't detract too much
from Herbert here because, hey, I stuffed up my problem for everyone
here to see...as you say, "should have thought of it too"...only he
did...that alone is worthy of my thanks and stuff, I reckon...

> > [ * Well, okay, FreeBSD and *NIXen too aren't completely ruled
> > out as yet...
>
> Porting to *BSD should be easy -- all the system calls have been
> placed in the system.asm module, just a matter of changing them to
> *BSD style syscalls (and maybe modifying the _linux.aml portion of
> the NASM macro library for a _bsd.aml section). For now though,
> everything seems find just working with linux, so long as porting
> is kept in mind.

Yeah; Full agreement there...so, basically, it's the "macro" approach
to just switch system calls...good, because that would only have been
what I'd have insisted on, anyway ;)...

Beth :)

Quantcast