Re: Luxasm news
- From: "Beth" <BethStone21@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 09 May 2005 00:48:38 GMT
Rene wrote:
> 1) Of what use could be the "BackGround Compiling", with
> a Tool, that could compile almost anything in almost the
> Click time?
1. "Feedback"; As the programmer works on their source code, they
immediately receive feedback on the errors...
1a. This is excellent for learning the language in double-quick time...
1b. Statistics show that the majority of development time and expense is in
the _MAINTENANCE_ phase of the software lifecycle...also, bugs _COST MORE_
(time, money, effort, etc.) to be dealt with later rather than sooner...the
longer a bug exists, the more it generally costs to remove it
later...hence, this also helps target cheaper and faster development (not
simply the speed of doing it this way, but the _quality_ of doing it this
way with "feedback")...
1c. Removal of the "start / stop" multi-phased development cycle: "edit ->
assemble -> -> test -> edit -> assemble -> test -> edit -> assemble ->
test -> ...", replacing it with a "seamless development" cycle...where the
programmer can concentrate on the _CODE_, not on using their
tools...indeed, a clear objective with LuxAsm is that it does NOT make a
song and dance and wave its arms for attention...it is doing its job
properly when it is so "seamless" that you forget it's there and using it
becomes "like the back of your hand"...
1d. This is a _PREVENTATIVE_ rather than "curative" development
strategy...errors are tracked down and exterminated as soon as is
possible...it promotes a programmer - by direct and immediate feedback - to
simply develop a "habit" of not causing errors in the first
place...psychologically, for a tool to assist in such "good habit forming",
then the reaction must be near immediate...that is simply a fact of human
psychology, by the way, and can't be altered by any software means...so,
the tool must meet the human, not the other way...
1e. Not greatly important but it will simply be faster...as pure and simple
as that...and, as you regularly kick up a fuss about how you have the
"fastest of the actual assemblers" (ah, so, by qualifying with "actual
assemblers", then you finally admit that MASM kicks RosAsm's arse in speed,
as we know you don't count MASM as an "actual assembler"? Nice "side-step"
of the criticisms, Rene! ;), then you'd be the one to tell the rest of us
why this is such an oh-so-important criteria...nevertheless, this method
takes it to its ultimate extreme of "effectively instant" compiling
(obviously, it's not really "instant" but, as it happens in parallel to the
programmer doing other things, they aren't waiting for it, so do not
realise that it's taking any time whatsoever)...
1f. It pisses you off...which is good because you're very amusing when you
squirm...psyche! ;)
> 2) Of what use is compiling while the user is typing in?
> What for?
I have no idea why you're numbering this as "2", when it is, in fact, the
exact same as "1" repeated again...
I've already answered this question above...please refer to that answer...
> Is it simply _doable_?
Is it doable?
Short answer: Yes...
Completely so...utterly 100% doable...
I can state this without hesitation or doubt because, you see, it _HAS
BEEN_ done...more than once...with much more complex languages than
(relatively simple) assembly language...
So, as it has been done, then it is clearly be "doable", by
definition...and that's a complete statement of fact, not "opinion" in any
way...
Of course, for your "black propoganda" campaign, I fully expect you to
conjure up a series of _LIES_...such as "incremental assembly is
dangerous!" or "feedback makes you write worse code!"...and other OUTRIGHT
LIES...anything by which you may falsely gain any kind of "advantage" to
your assembler and "political agenda"...
This is because you are so sad, weak and pathetic as an individual that you
cannot win by your actual ability and by fair means...thus, you destroy,
poison, lie and employ whatever means gains you the results you want, by
hook or by crook...at all costs...
Which is exactly why you are a very weak person...
> [I have already pointed
> Beth to the good questions, at the time she proposed this
> stupid idea, but she never ansvered anything...]
If I recall correctly, this is because your questions were based on an
assumption of a naive implementation that was NOT going to be used...hence,
if you ask a non-question with no relation to anything that I was
proposing, then I can't give an answer to it...
For example, if I was to ask you how the Martians were going to enslave the
entire human race using purple bananas, then I'm sure you'd have no serious
or useful answer to that question either...seeing as there are no Martians
and no large stockpiles of WMD "purple bananas" on Mars either (and none of
it would have anything to do with you, anyway...so, even if there were, how
would you know what their plans are? ;)...
There is no answer to such "non-questions"...ask a proper question then you
might get a proper answer...
And be careful here, Rene...assembly language to machine code is a nigh-on
1:1 translation...hence, your suggestions that it is "not doable" and that
you can't see how to implement it, is nothing but a poor reflection on
yourself and your abilities...
[ Note to Randy: Don't you just Love it? Rene, of course, claims that he's
personally able to violate a mathematically proven _IMPOSSIBILITY_ with his
"two clicks re-assembly"...oh, yes...this is "easy"...very "doable"...yet
when I suggest merely making a mostly 1:1 translation process work in an
"incremental" way - hardly trying to "cure cancer" or the other
impossibilities and miracles Rene claims to be able to conjure up - then
this is all "not doable" / "impossible"...even when, lo and behold, it's
_BEEN DONE_ elsewhere to great success!!
Must be because Rene is an "assembly god", so he can use his "magic hammer"
that grants him "god powers" to do the impossible...and us poor mortals
will "never comprehend" the wisdom of the "assembly god"...a "wisdom" so
wise that it has "wrapped around" the meagre 16-bit register that was
devoted to storing his wisdom, to have become "completely idiotic" once
more...kind of like the Y2K bug or something ;) ]
> Admitting it would be doable, what would be the reponsivity
> of the Editor?
Effectively "instant", to all intents and purposes...
How can this be?
Simple: We are NOT re-compiling the source code entirely ever time, as
we're using an "incremental" process...this means that _ONLY CHANGES_ are
processed and they only need be processed _ONCE_...
Hence, solely that which is typed in needs to be assembled and any possible
"dependencies" on those source lines...as a typical assembler can process -
as you like to boast with your own assembler - I quote, "one and a half
Mega per second on Celeron 1.3" (a statistic you regularly give for
RosAsm's speed)...
Therefore, RosAsm can process one and a half mega a second (on a Celeron
1.3GHz)...yet, somehow, Luxasm can't process single source lines of, ooh,
16 or 21 ASCII bytes (those being relatively "long lines" too! ;)...without
terrible "responsivity"?
You are full of shit, Rene...and these attempts at "black propoganda" are
pathetic...
Trying to "imply" that it's "impossible"...and that (contradicting your own
conclusion that it's not possible) that it would "take seven years to
assemble one source line" or something, even though you yourself boast
about how your assembler eats through 1.5 Mega source code in its entirety
in a second...
Let's put that in context...RosAsm has a speed of 1.5MB/sec (or 1,572,864
bytes per second), so you tell us...right, if the monitor were refreshing
at 75Hz, then that's 20,971 bytes per frame...as the monitor is the means
of output here then it is _IMPOSSIBLE_ for the user to _see_ a faster
"response time" than that...
As LuxAsm is to use a fully "incremental" process then it _ONLY_ processes
changes _ONCE_...hence, LuxAsm only needs to deal with "merging" the
current changes into the already 99.9% assemble file that already
exists...assembling a line of, ooh, 21 bytes would be a "long line"...
To not be able to manage the _TOTALLY OVERKILL_ "response time" of NOT
missing a single frame of a 75Hz refresh rate, LuxAsm would have to process
those 21 bytes some _THOUSANDFOLD_ worse than RosAsm does before you'd even
notice there was a problem (remember, I'm talking the monitor refresh rate:
You simply _CANNOT_ see anything update on the screen any faster than this,
by definition)...even if this line were to "cascade" into effecting source
lines elsewhere in the program, it would have to "cascade" a _THOUSAND
TIMES_ before there's a visually noticable problem (and only the keenest
eye would even see it)...typically, this would NEVER happen naturally and
it would be very hard work to create a file to specifically exploit this to
try to make it "cascade"...and if you maange it then, ooh, your "thousand
line cascade" only makes it skip _ONE_ frame...one small, pathetic, useless
frame (which it then "catches up" with by the very next frame)...
Sorry, I simply don't care about that, as that's beyond pedantic...
This "black propoganda" won't really work...you "imply" that "incremental"
is impossible, even though it _ACTUALLY EXISTS_ elsewhere already (and
assembly language is relatively _EASIER_ because it's mostly 1:1 between
ASM and machine code...far, far more complex translation processes for more
complicated programming languages are able to do it with _ZERO_
problems)...
If this absurdity wasn't enough as a means to promote your "political
agenda", you're now asking us to believe that "merging" a few symbols and a
few machine code bytes into a file is somehow going to "take
forever"...utter nonsense...
And if your so concerned for "speed" and "responsiveness" then, pray tell,
Rene, why do you thus insist on a _FULL RE-COMPILE EVERY SINGLE TIME_ with
RosAsm?
On the contrary, the whole purpose of "incremental" processing is that it
_ONLY_ processes the "changes" and does so _ONCE_...and _ONCE_ only...it
vastly _REDUCES_ the amount of processing that the assembler needs to do
within a set time by simply making sure that the assembler NEVER wastes its
time processing _SOMETHING IT HAS ALREADY PROCESSED BEFORE_...and this is
proposed to work _IN PARALLEL_ with the act of the programmer typing
(which, with the very best typists - who know in advance what they are
typing (i.e. programmers tend not to type this fast because they have to
_THINK_ about what they are typing and frequently pause for thought) - is
not going to exceed some 60 words per minute...which is only 240 or so
bytes per second...you don't think your Celeron 1.3GHz is fast enough to
keep up with that "blisteringly fast" rate? I think someone sold you an
abacus and told you it was a Celeron 1.3GHz, if it seriously can't manage
that processing rate)...
This is beyond "straw man"...more like "cowardly lion", I think...just
_INVENTING_ problems and impossibilities that aren't there...ah, you know
they ain't there...but, well, if you "hint" and "imply" and "suggest" often
and repeatedly and regularly enough, then...well, some people might get
"taken in" by the "black propoganda", yes?
What's the saying? If you repeat something often enough then it becomes
"the truth", regardless of whether it is true or not?
Yeah, this is exactly how you operate, Rene...by FUD tactics, by trying to
destroy your "competition"...
You know, all the things that _MICROSOFT_ do...you _ARE_ Microsoft,
Rene...in this small sphere of the newsgroup, you _ARE_ Microsoft...you
defend them, you promote them, you behave exactly like them, you launch
"black propoganda" at a Linux assembler...why, Sir Bill would be proud of
you, Rene...you should stop working for him for free...show him your good
work and tell him that'll you continue to _PROMOTE MICROSOFT_ on the
newsgroup for a reasonable wage...then have yourself some "luxury" in your
retirement...
It's not as if you can claim to have "principles" or that you wouldn't
"sell out"...you've _ALREADY DONE SO_ on the assembly community, Rene...
> Do you have any idea of the complexity, for simply
> having a good "Code Completion", in a good Source Editor?
Depends on the implementation involved...the data structures and algorithms
chosen...
For example, a newbie came here before asking about how to implement
searching for "commands" the user typed in for their "command prompt"
program...everyone immediately jumped to saying "hash function" or "binary
search" or whatever...generic solutions...
But a simple solution was to tailor the data structures and algorithms to
the specific task itself...a simple table of some 26 entries, one for each
letter of the alphabet (if you need underscore and such too, just make the
table slightly bigger)...this table covers the first letter of the
command...and has a pointer to a further table (of the exact same
structure) or "NULL" if there is no commmand under that letter (and, hence,
no table hangs off that entry)...repeat until you've got a "tree" structure
big enough to be able to discern every unique command from every other one
(it does not need to go to the last letter of every command...only as many
characters as to make sure you've got one unique command that can't be
confused with any other)...the "leaf" nodes are either "NULL" (no entry for
that letter) or can house the address of the command's actual procedure to
be called (also, the rest of the uncompleted characters could be stored
there too for a "command completion" feature that fully integrates easily
and smoothly into how the algorithm works already)...
This _IS_ an "unusual" algorithm to choose for many...BUT, look at the
advantages: It is character based so that as the user types the character,
the program can _immediately_ use that character _directly_ as an "index"
into the first table...which gives it a pointer to the next table (or NULL,
if there is "no such command"), where the _exact same process_ is repeated
(hence, you'd actually write this in a small, simple loop)...the second the
amount of characters is typed to discern this command from every other
command, the program _HAS_ the address it needs to jump to, in order to
execute that command...this algorithm is _FINISHED_ before all the standard
algorithms ("hash functions", "binary search", etc.) have even
began...indeed, you press ENTER merely to "confirm" that the command it's
_already got_ is correct, not to start the search...the search is _ALREADY
OVER_ by the time ENTER is pressed...adding "command completion" is easy by
simply adding on the rest of the command string at its "leaf node" so that
if they type enough characters to uniquely identify a particular command,
it grabs the rest of the string and displays it for "command
completion"...this feature naturally fits into the way this algorithm works
that it's a very trivial addition...and the data structures - the "tree of
tables" - is very simple to create (could even be done dynamically or have
commands easily added onto it at run-time)...and to access it is also very
simple...use the character the user types as the very "index" by which to
look into the table...if there are no further tables for a particular
entry, then that entry in the table can be NULL...and you only need go as
far in the tables as as many tables as is needed to discern each "unique
command" from every other one...it does not have to go to the last letter
of every command...
Such an algorithm - though "unusual" - provides "instant search", requires
only the very, very simplest of code to use (indeed, finding an entry in
the table directly uses the users character as an "index" into the
table...it literally can be done in _ONE_ machine instruction to access the
entries in the tables! ;), uses a reasonably size-efficient data structure
(which is easy to create, can be dynamically changed at run-time and _ONLY_
needs as many characters as are needed to uniquely discern every command
from every other command)...adding "code completion" is easy because it's
already structured in an appropriate way...
For this implementation (perhaps an unusual implementation...but that's
kind of my point: I took the time to _think_ of what would be the very best
_SPECIFIC_ implementation that exactly suited this problem the newbie
had...I exactly _tailored_ the solution to fit the exact problem), "code
completion" is utterly trivial to add...
BUT, had you chosen instead to use a "hash function" or a "binary search"
to find the commands, then, yeah, you've screwed yourself up there...adding
"code completion" ain't quite so easy...complex, even...its performance
won't be as good either because the "standard" search algorithms - hashes,
linear / binary searches, trees, etc. - are all based on the assumption
you've got the entire entry to be searched before beginning to search...my
little unusual algorithm here makes no such assumption and searches _each
character one-by-one as it is typed_...hence, it can start the instant the
user types a single character to the keyboard...it is _COMPLETED_ long
before they hit ENTER, which is where all the other "standard" search
algorithm only _start_ their searches...
Now, this "search" is NOT appropriate for all situations...it is based on
the fact that users are _typing_ the commands and it only performs better
under those conditions...if reading commands from a file, then it'll
actually perform worse than an ordinary "hash function" would...I am NOT
giving a "generic" algorithm here...but that is why, in the right
conditions, it is a better performing algorithm: It is _SPECIFICALLY
TAILORED_ to the exact problem...that's how it can "cut corners", "start
early" and do a better job...
There are many ways to skin a cat, you see...and some ways are better than
others..._IF_ you've chosen a bad implementation that is NOT inherently
"appropriate" for incremental processing, then, yeah, adding these things
could be slow and tricky...BUT, if you choose the _appropriate algorithm_
that is specifically tailored to the conditions then it can, in fact, be
easier, better performing and simpler...
The _application itself_ is the final arbiter of what's "right" and what's
"wrong"...always...and it decides the most appropriate algorithm to choose
by the nature of its requirements...
Or, in other words, the algorithms and implementation chosen will not be a
"standard implemetation twisted to work incrementally" but an incremental
implementation from the ground up...indeed, if people are wondering what my
main problem with C's assembler source code on the CVS is, then it's
actually this aspect...for the very best performance, we can't simply
"twist around a traditional implementation" and expect it to work well...it
should fundamentally be "incremental" from the ground up in its design and
implementation...if this is achieved, then I'm completely 100% confident -
without any doubt or hesitation - that this is completely "doable" and will
perform _better_, not worse, than your "traditional" style of
implementation...
For example, one question you asked before was "if a line is inserted at
the top of the program, then all the addresses in instructions further on
in the program all need to be changed!!"...that's one way of implementing
it...the other is to _RETAIN_ the "symbolic labels" and not store absolute
addresses..._ONLY_ resolving "labels" into actual addresses at the very
last instant when the actual final executable is created...then you can
insert and delete as many lines as you like: We're NOT storing "absolute
addresses" but retaining "symbolic labels" (pointers to the symbol table
entries) all the way through until the very last second...it matters not
how many bytes are inserted and deleted, the "symbolic" label does not
itself change...and it can be "resolved" into a final address at the very
last instant for the final executable...
See? It wasn't difficult to "solve" that little problem, was it? The actual
address in the instructions will change when bytes are inserted and
deleted, as that pushes the program further on in memory or pulls it back
in memory...BUT the "symbol" that the instructions are referring to, DO NOT
change when extra lines are inserted and deleted...so, while processing, do
not store addresses, store the "symbols"...when it comes time to create
that final executable, then look up the addresses for the "symbols" and
insert those into the command...save that "relocation" kind of thing until
last...
That's it...many problems are, in fact, very easily solved by "looking at
them from a different angle"...taking a different style of
algorithm...moving a process forward or backward can often be the very
simple "solution"...
> Do you have an idea of the Editor responsivity cost for
> that simple implementation? Now 'Code Completion"
> "BackGround Compiling" "Saving along" ... ???!!!...
Ah, you're being "deceptive", as usual...the point with "background
compiling" is, in fact, that it _DISTRIBUTES_ the processing over the
editing sessions...
That is, RosAsm sits around blocked most of the time...waiting for user
input...and then only bothers to compile when instructed to...and, at that
point, it rushes hell for leather - as fast as it possibly can - to compile
the source code superfast...
The approach with LuxAsm is, instead, to simply _SPREAD OUT_ this
processing...the "background process" occurs in those otherwise _IDLE_
periods between the keystrokes...same amount of processing (more or less),
though, in terms of 4KB of source code is 4KB of source code whether it's
RosAsm or LuxAsm source code...
The fundamental difference is simply a matter of "timing", really...while
RosAsm sits around idle and blocked most of the time waiting for the user
to type in source code...only beginning to compile when it is given the
"go!" by hitting the "compile" button...
Instead, LuxAsm _always_ has the "go!"...whenever it's got a piece of new
data then it works on it...and this actually mostly happens in the
otherwise _IDLE_ time periods where RosAsm would, in fact, be just sitting
there - blocked - doing nothing...
Indeed, as Linux has "priority based scheduling" then we can even guarantee
that, if needs be...just run the "background processing" in a thread with
_lower_ priority than the rest of the program...hence, it'll only be given
time when the other threads are idle...and changes could even be stuck onto
a "queue" of things to process...so, yeah, even if you could really type
faster than it could process (not giving it enough "idle time")...the
second you stop and the main editor thread goes "idle" and blocks, the
"background process" carries on to "catch up" with the tasks on the
"queue"...which, by the way, is yet another way to counteract your nonsense
assertion about "responsiveness"...
> Mind you it will be prudent to not recommand to use LuxAsm
> with a 486.
>
> :)
On the contrary, implemented properly, LuxAsm properly _distributes_ the
processing of source code over a longer period...so it will likely perform
better on lower spec machines, just as well...indeed, it degrades in
performance far, far more smoothly than RosAsm and its "hell for leather
rushing" compilation strategy would...if it's 1.5MB/sec on a Celeron
1.3Ghz, then on a 650Mhz machine, it's two seconds for the same amount
(roughly)...on the other hand, LuxAsm's "spread out" processing during the
whole of the editing session may very well have _NO VISUALLY NOTICABLE
DIFFERENCE_ processing the code on a 650Mhz machine or on a 1.3Ghz
machine...
This scheme "scales" to lower spec machines better...and, by the way, that
isn't any "accident" either...
:)
> 3) Of what use is saving anything in between two Compilations?
> [What would a Programmer have written, in between two
> Compilations, that would be worthy any complex and dangerous
> implementation?]
Well, if it's been changed between compilations and the programmer wants to
save those changes then the use of saving it is so that the programmer gets
their wish in having their source code saved (you do not "need" to save
anything between compilations, by the way)...
I thought that would be pretty obvious...
Ah...and now we see the exact "black propoganda" that I _KNEW_ was coming
and predicted...it's "dangerous", he says...
How is incremental processing any more "dangerous" than non-incremental
processing? No vague answers trying to "blag" your way out of making this
absurd assertion..._FACTS_...how on Earth is it any more "dangerous" than
any other way?
> 4) The most sophisticated implementations you plan the more
> _BUGs_ you plan.
To a degree, this is true...
But, simply, if we do get more bugs from this, then we'll simply work
harder to debug them all out of there...if it's more work, then we'll just
do more work...
Hey, you used to build houses, Rene...you should be among the first to know
that, in fact, hard work doesn't kill you...indeed, it's often highly
beneficial to stop slacking off and do some hard work from time to
time...okay, I have yet to really do that yet, true enough...but more a
"lack of practice" to have become unaccustomed to doing it, than any "fear"
of doing a bit of "hard work" here and there...
If the "price" turns out to be a few "more bugs" in the implementation
then, so be it...it's still "cheap as chips" for such a "bobby dazzler" of
a feature set...
What a silly argument, anyway...trying to fly to the Moon is more "hard
work" than driving to the local supermarket...so NASA should never have
sent Neil Armstrong to the Moon but should have sent him to the local
K-mart instead? Yeah, great rationale...luckily, there are enough people
out there who _don't_ think as you do...or we'd all still be stuck living
in caves, doing that whole "hunter / gatherer" caveman thing...
> I am actually reviewing the "simple" Undo
> feature of RosAsm. Let me tell you that you can much probably
> not imagine the incredible complexity of such a "simple"
> feature. This is not at all a matter of recording the user's
> action and of undoing them backward. If it was only this, i
> would not have to review it again, after years of existence.
Yeah, actually, I fully agree with you and know that "undo" is something
easily "underestimated" for its actual complexity in implementation at
times...often, some actions are _irreversible_ by their nature (only work
"one way"...for instance, lots of "effects" that you can perform on images
in graphics programs are often inheritantly "one way" in the sense that you
can't simply "work backwards" from the final image to get back the previous
image...the operations are inherently "lossy" by their very nature...they
"increase the entropy" that you just can't get back...like you can't pick
up lots of fragments of a broken china plate and then try an "unsmash" it
by throwing the pieces backwards from the floor up to the table...it just
won't work..."entropy": It's an inherently "one way" process that's not
reversible by simply "doing things backwards" ;)...and, thus, you can't
simply "work backwards" from where you are to get it back...
Indeed, when you consider "entropy" and that, yes, there are some
inherently "one way" / "lossy" processes that cannot be naturally just
"reversed"...then it's actually obvious that "undo" isn't always as
"simple" as it might seem to implement...
I have a graphics editor where, in fact, it basically stores all the
operations you perform on an image...and instead of "working backwards"
from the current image, it, in fact, instead "works forwards" from the last
time you saved the image re-applying all the steps once more but stopping
short of the last operation, so as to "undo" it...because of this, it's
actually useful to save regularly with the program in order to "speed up"
any "undo" operations...that's a bit of a simple implementation in that
it's not always the speediest to perform because of all the "redoing" of
previous steps (if you've done a lot of things to the image, it can
actually take a while before this completes...but it's cool to watch
because you can see it quickly re-applying everything once more...so, you
can sort of watching it "redrawing" your image brush stroke by brush stroke
in "fast forward mode"...kind of like an episode of the Benny Hill show but
without the bald man or the women running around in their underwear ;)...
> Once you have to play with the Dynamic Break Points table
> that must assume the Sources Modifications all along, once
> you have to care of the multiple 'TITLEs' (or multiple Sources
> File - same problem -), that can be inserted and/or deleted
> in between, plus any switch from here to there, at any time,
> in between any of two user actions on the Source(s), this is
> becoming a true head break. A true Hell. So is it for a quite
> "simple" tradition Text Edition feature, once applied to a
> Sources Editor. So, i let you imagine what all of the Beth
> fantasies would imply in matter of complexity, and therefore
> of Evil crossed bugs.
....except that I'm proposing an "incremental assembler" from the
_start_...on the other hand, you introduced the "titles" features
_LATER_...
This makes a difference because if the "features" are all pre-planned and
worked out in advance, with the implementation decided as best to fit
supplying all those features then this makes the implementation much less
complex, neater and simpler...
Yes, very much I'd say that my ideas _aren't_ a good idea, if you're
imagining taking a "traditional" assembler and then trying to "bolt on"
these features...it could be made to work but it would NOT be the best
implementation...I am very much _assuming_ that these features will be
inherently designed into the implementation itself...
For instance, when suggesting the "unified model", I also suggested that
the implementation should use a hierarchical "symbol tree" rather than some
"flat" symbol table...in a sense, when thinking of the "unified model", I
was inherently assuming that the implementation would use a _hierarchical_
"tree" implementation...if it didn't - some "traditional assembler" being
"changed" to try to work with "unified syntax" - then it would NOT work
very well...the implementation would be much more complicated and
confusing...
But that's why I suggested the "a symbol table is itself a valid symbol in
another symbol table" (slightly OOP-like) implementation when I was
explaining the "unified model"...
With such a "tree" structure, though, it's actually very easy to implement
because, really, it's all inherently in the "tree" structure itself...just
like once you implement a "directory" (a file that stores files :) for a
file system, then you can then "nest" them and create very complex or very
simple "tree" structures of directories and files..."scope" - in that when
you type a command, it only searches for it in the "current directory"
(ignoring any "PATH" variable for a second ;) - is inherently dealt with by
only looking for symbols in the "current symbol table" (just like only
looking for files in the "current directory")...
Indeed, the "unified syntax" is, yes, based on the _assumption_ that the
implementation would work "hierarchically" underneath it all...the
comparison to a "file system" is, in fact, very close that it gives a good
indication and example of what I mean...if you tried to "emulate" a
directories and files file system but only using a "flat" implementation in
the actual file system data structures themselves...then, yeah, oh boy, are
you creating a lot of unnecessary trouble for yourself...
[ Actually, the odd "dispute" I've had with C and his current assembler
code on the CVS is actually, in part, about being annoyed and worried that
he "jumped too early" to implement that before I had a chance to talk about
my "unified syntax" ideas...not his fault, of course, as he didn't know I
was going to do that (and had no reason to think otherwise at the
time)...it's not really being annoyed at C himself in any way but, you
know, that horrible feeling when this kind of thing happens through
no-one's actual fault...and what we've ended up with isn't "ideal" with the
ideas we've later agreed upon...but, as the Americans like to say: "shit
happens"...it still doesn't, of course, stop you getting really pissed off
with all the "shit" that "happens" when it happens ;) ]
> I well know that i am preaching in the desert, but if there
> is one single thing that i can recommand you the most clearly,
> this is:
>
> KEEP IT SIMPLE.
>
> :)
As Randy's twigged, what you're really trying to say is:
"Oh crap! Beth's ideas sound really good and I think they may, in fact, be
very doable and plausible...if LuxAsm implements those features then it's
really going to show up just how much RosAsm sucks in comparison...I can't
let that happen...ah, I know! If I convince the rest of the LuxAsm team
that Beth is insane then perhaps I can encourage a 'mutiny on the bounty',
so to speak, that the team all reject Beth's ideas...then they'll write a
simple assembler that doesn't make RosAsm look bad"...
A very clever strategy, Rene...well, it would be...if you weren't so
"transparent" that it's blatantly obvious that this is a "propoganda" /
"FUD" trick you're trying here...
But, true enough, even though FUDs are outright lies, I cannot
underestimate them because they _ARE_ often very powerful...untrue...but,
you know, if people _BELIEVE_ something is true - even when it isn't in the
slightest - then it might as well be true, for how everyone "reacts" to the
FUD...
Check here for a description and interesting examples of "FUD tactics":
http://www.cavcomp.demon.co.uk/halloween/fuddef.html
Never underestimate the power of a FUD, indeed...in a sense, the war on
Iraq was "justified" by a FUD about these "WMDs", which, in fact, never
existed...but, it really doesn't matter how much this is repeatedly proved
over and over, there's literally millions out there who are _CONVINCED_
that the FUD is true...I have _STILL_ heard some particularly brain-washed
people _STILL_ saying "ah, but they'll find the WMD soon!"...what?!?
They've given up looking long ago...they've outrightly admitted there were
none there...but, no, they will "still be found", apparently...such is the
power of FUD...it can even exceed the originator of the FUD's initial
intended purpose for it...but the most powerful FUD involved there was how
Saddam had "links" to 9/11...indeed, Bush says one day - when asked
outrightly by a journalist - that, no, there was no evidence of any kind to
link Saddam with 9/11...and then what's he doing in a press conference
shortly afterwards? Why, he's "implying" that there's a "link" all over
again...it's a lawyer's tricks there: If you "imply heavily" but do not
actually outrightly say so (and say "no" when asked directly about it)
then, _TECHNICALLY_, you never actually lied, right? As "implication" is
not actually saying there is a "link", it's just "suggesting" to people
that there is one..."suggest" that often enough and people believe it's
true...
Just like Amstrad were forced to include a useless fan - which, as the
story above points out, could be _OUTRIGHTLY PROVED_ to be useless and that
the FUDs were simply _LIES_ - not because the fan was actually needed in
any way but because FUDs are really _THAT POWERFUL_ that it's easier to
"roll over" and just accept them, often, than it is to try to prove to the
particularly "brain-washed" that it's nothing but a _LIE_...and I think the
author of the website picks this particular example because, to this very
day, PCs _STILL_ have the noisy fans...and manufacturers like Amstrad
might, in fact, have thought of "alternative ways" to keep things cool, as
they did in this case...but they'll not "risk" being subject to such
FUDs...better to "conform" and not be a "FUD victim" than to end up on the
wrong end of a powerful FUD like this...and - who knows? - all our PCs
today _might_ have ended up very much different and much quieter (only the
CPU fan ;), if IBM weren't childish egotists...mind you, the PC itself
wouldn't really exist, if that wasn't the case, as IBM only created a
"personal computer" to try to get rid of Apples...an "ego" thing...
Well, don't worry...IBM also demonstrate another aspect of the "FUD
tactic"...if you live by the sword then you will die by the sword...one
day, you'll get your "come-uppance" for such attitudes and tactics...so,
just remember the "tale of IBM", Rene, next time...once "Giants" reduced to
"glorified web consultants" that sometimes "play chess" with grandmasters
(not that anyone much is interested)...
> The implementations you are planing _WILL_ create problems.
Yes, that's the nature of programming...it is essentially all just one big
"problem solving exercise", really...
But "the joy of hex" is all about taking those problems and then solving
them satisfactorily...
No such thing as "a free lunch" in this world, Rene...as well you know...a
more complex implementation can be trickier to implement, this is
true...but you're actually getting something _BETTER_ out of that
additional effort...
It's like I was saying before...when a HLL coder says "but assembly
programming takes longer"...then my reply is simply: "yes, it does...but
that's what _DOING A BETTER JOB_ costs"...
Building the Eiffel Tower is not as easy as putting up a tent...that's
quite true...carving the faces of the Forefathers onto Mount Rushmore is
more effort than - I don't know - making some small gold "plaque" somewhere
with their names on it...and then sticking it somewhere where no-one much
will ever see it...
Similarly, assembly programming can take longer...it can be more
complicated and difficult...but, well, assembly programming can also
deliver the _VERY BEST_ programs...those "great" pieces of software...so,
you know, that's the "cost" of _DOING A BETTER JOB_...it takes longer and
requires a little more effort to complete...
This is always true, regardless of what we're talking about...Da Vinci
could have just scribbled a "stick woman" with a "smiley face" onto a scrap
of paper and called it "the Mona Lisa"...he could have done that...it would
have only taken a minute to do...very "easy"...very "convenient"...very
"quick"...on the other hand, it would also have been total
crap...thankfully, he did NOT do that and took the time needed to _DO A
PROPER JOB OF IT_...indeed, in Da Vinci's case, he was a "Renaissance man"
(actually, let's not do him an injustice...he was _THE_ "Renaissance Man",
in fact :)...and, hence, his scrapbooks reveal that he often mathematically
worked out how the light would land on his (fictiously based)
paintings...and that was a LOT OF EFFORT, I'm sure, to calculate...but it
gave his paintings - even when based on pure "fiction" in his own
imagination (such as "the Last Supper": He was NOT alive when Jesus was
alive, obviously...so the paintings is not exactly painted from
reality...but based on what he imagined the Last Supper would look
like...indeed, that painting features a few delibrate "unrealities" like
having two "vanishing points" for the perspective...a delibrate trick that
some of the objects have a "vanishing point" in the natural place, while
others have their "vanishing point" set in the middle of Jesus' face...this
was a delibrate "trick" in order to give the otherwise "realistic" painting
a "supernatural" feel because you can look at it and something just isn't
totally right about it but you can't tell what it is (well, until you hear
someone like me reveal what the "trick" he used was :)...and having the
"vanishing point" on Jesus' face, thus centres him in the painting and
makes your eye naturally always drift to looking at Jesus...anyway, the
point of noting this is just to stress how much _EFFORT_ and _THINKING_ Da
Vinci put into his paintings...great works of art like this are _RARELY_
just a case of someone picking up a brush and scribbling away on a
canvas...Da Vinci - who painted some of the most known and Loved paintings
ever - is the perfect example because his sketchbooks reveal that he put a
_LOT_ of effort and calculation and "tricks" into his paintings...and it is
that effort that makes his works such works of "genius", in truth...after
all, other painters have had similar "natural talent" at painting as Da
Vinci...but what sets him _ABOVE_ most other painters is all these
"touches" and "attention to detail" ;)...
What would you rather? The "stick figure" painting with "smiley faces"? I
don't think so...
The objective of life is NOT simply to rush your way into the
grave...what's the point of being alive, if the only thing you do is
_IGNORE_ life itself on a "mad rush" to the grave, as fast as you can? The
joke being that those who "rush" like this are _CONVINCED_ that they'll
"miss something" if they don't rush...while, deeply ironically, it's
exactly that _RUSHING_ which means they _NEVER SAW A SINGLE THING_ all the
time they were alive...
So, in no way will I apologise for that...yes, what I'm proposing is NOT as
"easy" or "convenient" or "quick" to implement as, well, your "broken pile
of crap" which you like to call RosAsm...
I have to agree with Randy on this: RosAsm, in fact, is the _WHOLE PROOF_
needed to demonstrate that your "advice" ain't really worth the ASCII bits
it took to encode your post to send it to us (well, I can't say "not worth
the paper it's written on", as it isn't written on paper...not unless you
print it out, anyway...and, well, not being worth the paper it's written
on, then you wouldn't print it out as that would be a waste of paper, by
definition of not being worth the paper it _could_ be written on...ummm,
yeah...that makes sense...somehow ;)...
Yeah, "keep it simple" and we end up with RosAsm!! Yay!! Excellent!!
Faced with that prospect, then I bet the LuxAsm team would rather jump off
a cliff into the unknown - however insane my ideas might be - and "take the
risk"...rather than follow your advice and get the _certainty_ of a "broken
pile of crap", also known as "RosAsm" ;)...
> Then you will, as you say above, have to implement, again,
> additional fancyful things to solve the problem, that you
> will have created for no reason and for no advantage... that
> will necesserary introduce new problems, new confusions,
> and new bugs...
And the alternative is what exactly? Writing a broken pile of crap that
no-one much actually wants to use like RosAsm? "Keeping it simple" and,
instead of problems implementing _GOOD FEATURES_, we can delight in a whole
lot of problems implementing _crap_ instead?
Your "strategy" is completely transparent, Rene...you see the ideas being
touted for LuxAsm as a "threat" to RosAsm because, indeed, I unashamedly
say that, with LuxAsm, I'm implementing the ideas that _YOU SHOULD HAVE
IMPLEMENTED_ for RosAsm...and when LuxAsm implements those features, it's
really going to make RosAsm look like the broken pile of crap it really
is...you'd no longer really be able to get away with your "FUD tactics" and
"black propaganda" tricks...just as those you use against HLA will all but
entirely vanish, once Randy finishes implementing HLA v2, as well...
You're getting away with it solely because LuxAsm isn't written and HLA is
only in "prototype" at the moment...so, by Randy's own admission, the
implementation ain't the greatest at the moment and it _IS_ possible to
dispute the "compiler / assembler" stuff...to the degree that Randy happily
acknowledges that it is really a "compiler" in the strictest sense...not
that this is a bad thing, except in your rather deranged "reasoning" where
RosAsm is somehow a "real assembler" - even though there's a whole "HLL
pre-parser" _BUILT INTO_ the fracking executable!! - yet MASM / TASM and so
forth don't count because they have ".IF" macros...which you use throughout
your RosAsm source code, anyway...
So, take advantage of "your time" while it lasts, Rene...because it will
come to an end...and, unless you raise your game, you'll be wiped out by
the "competition" (not that you're doing particularly well with your 75
users at the moment, anyway)...
> Before runing into beautifull, but stupid, ideas, you'd
> better _analysing_ the _real_ problems. Let me recall
> you that the initial point of all of this demential
> discussion about Source Saving, was one of the usual
> Post from Randall Hyde about "RosAsm killing the users
> sources". If you are stupid enough for giving any credit
> to this ass-hole, instead of taking a look at the evident
> _FACTs_, ... good for you...
>
> :)
The LuxAsm designs that I've proposed are entirely based on _pragmatic_
solutions to that which I've _practically_ thought to be "lacking" in
current tools...as it only currently exists as "ideas", then, yes, it can
come across that these are all "theories"...and then you can wield your
"propoganda" to pretend that it's nothing but "fanciful theory"...yet,
every time you want to query the design, I will give you the long list of
_actual_ and _practical_ advantages - the problems I'm attempting to
"solve" - every time...
And my rejection (which C also seems to agree with) of getting carried away
with "overdoing things" with concurrent processes in separate address
spaces and so forth? _EXACTLY_ because I don't want the design to "explode"
into something too complicated...an entirely _PRACTICAL_ concern...because,
really, on the "theory" side of things, then it would be very "interesting"
to implement all these extra things...but you can keep on adding on "new
ideas" to a design forever...at some point, you have to say "okay, these
features are good...let's get these working" and stop dreaming of yet more
things...
To some, I may have seemingly already crossed that boundary...I could see
that as being the opinion of some because what I have proposed isn't all
exactly of the "simplest" nature...but they are all there for a _REASON_...
The choice of proposing the "modular architecture" is increasingly
beginning to be shown and understood by the discussions that have
emerged..._NOW_ you can see why I thought such a "decoupled foundation" was
important to get straight from the beginning...the "unified syntax" is, in
fact, arguably _easier_ to implement because of its "single mechanism does
it all" attitude...get the "hierarchical symbol tree" working and half the
implementation, so to speak, is already done there...and the benefits such
as "properties" and the way you can manipulate "blocks"...well,
increasingly I think people are "getting" the idea...it's good to see that
C generally "gets" my ideas straight away, usually (might not completely
agree with them all but I can see he's "getting" the basic concepts of what
I'm talking about...indeed, the second I mention the possibility of
"properties" - called "local defines" before we thought up a good name for
it - then he'd come up with examples straight away that exactly "got" the
idea and why it would be useful :)...
Indeed, the fact that you've begun to believe LuxAsm "worthy" of your FUDs
and "propoganda" techniques, Rene, is an accidental compliment...the more
you appear to be "getting" my ideas, the more and more you're trying to
persuade everyone else on the LuxAsm team to: "don't listen to Beth and her
ideas!", in order to try to stop it happening...I don't take offence at
that, really, because that is always the measure, isn't it?
"You know you're doing something right when everyone keeps attacking you
and trying to discredit you"
[ Unknown ]
Beth :)
.
- References:
- Luxasm news
- From: \\\\o//annabee
- Re: Luxasm news
- From: Johannes Kroll
- Re: Luxasm news
- From: Betov
- Re: Luxasm news
- From: Frank Kotler
- Re: Luxasm news
- From: Betov
- Luxasm news
- Prev by Date: Re: Early fruits of my labour
- Next by Date: Re: Luxasm news
- Previous by thread: Re: Luxasm news
- Next by thread: Re: Luxasm news
- Index(es):
Relevant Pages
|
