Several, bring coffie

 C.R. Chafer wrote:
 > NoDot wrote:
 > > Randy wrote:
 > > > The point is that not that RosAsm crashes. We"d expect this out
 > > > of any product under "continuous development."  The problem is
 > > > that you"ve tied your editor and compiler together so that when
 > > > one crashes, they both die. This exposes your users to greater
 > > > peril. For example, if the editor and compiler had been
 > > > *decoupled*, as is good software engineering practice, then the
 > > > fact that the *compiler* crashes should have little impact on
 > > > the editor. Granted, the *editor* can still crash and the user
 > > > can lose unsaved work, but by coupling the compiler+assembler
 > > > into a monolithic program, you increase the chances that the
 > > > user will lose work.
 > >
 > > I"m sending a copy of this to the LuxAsm-devel list so we can
 > > make sure we don"t (hopefully) have this problem. Randall has a
 > > point, unfortunately.
 >
 > The problem is _not_ either of the problems Randall highlights
 > above, but a more fundamental problem: that a crash causes the
 > user to loose work.  Obviously the best way to prevent this
 > happening is to make an application which never crashes, but,
 > even then, there are events which can cause a crash -- such as
 > a power failure.

What? We"re supposed to also hand out solar panels and UPS systems and such
to prevent power failures now?!?

There may be such an "issue" with RosAsm but there will NOT - I repeat,
NOT - be any such problem with LuxAsm...obviously, a power failure is a
power failure but you can"t do bugger all about that with software...except
to save the work...

 > A better system would not involve changing the design or idea
 > of the integration of the assembler/compiler system, but to
 > automatically backup as the data is entered.  This could be
 > done using a full update (say every 15 minutes) together with
 > a journal of changes.  Implemented properly, such a system
 > would prevent loss of data even in the face of a power failure.
 > (Though drive failure would still be a problem, not much you
 > can do to hedge against that though.)

Okay, people...what part of "incremental" are you not getting? Every single
time you type in a line, it"s passed to the assembler and incrementally
merged into the current project state...

An "autosave" feature? On the contrary, this is not a LuxAsm problem...this
is exactly a LuxAsm _SOLUTION_...every single time you hit a key, it"s
incrementally added to the current project state...EVERY SINGLE KEYPRESS...

 Oh dear! A power failure! We"ve lost all that work of _ONE_ keypress!! Oh,
 terrible! A tragedy!! We"ll all have to abandon the LuxAsm project
 forever!! Boo-hoo! ;)

 Now, in practice, as I said before, saving to the project files for every
 single keypress would be overkill...you know, the disk constantly whirring
 and the whole thing running at 7200rpm (rather than 3GHz marked on the CPU
 itself ;)...also, this would be a touch "inconvenient" for the user, if
 they, in fact, want to "undo" or "revert changes"...

Hence, I propose that it"s all cached via RAM...we assemble to RAM and then
when the user hits "save" (or, yes, an "autosave" option could be added),
that"s when it"s transferred to the actual disk files...temporary files can
also be used, if necessary...

On the contrary - let"s get this straight - if we were implementing
"incremental" in a simple, direct way then, in fact, it would be _SAVED
EVERY SINGLE KEYPRESS_ (or, at least, every source line entered)...but this
is silly and impractical, so it makes sense to do the incremental process
to RAM rather than directly to disk files (when the user hits "save"...and,
yes, you can add in some "autosave" option too)...

LuxAsm does NOT - I repeat NOT - have the stated problem...on the contrary,
LuxAsm"s "problem" is in the reverse direction that saving every single
change would be "overkill" to say the least...which is why it makes sense
to do the process to RAM - a bit like a "disk cache" but manually
controlled by the user (e.g. the user flushes the "cache" to disk by their
"File -> Save" mouse clicking ;)...

There is NO - I repeat NO - additional disadvantage to this scheme than any
other computer program on the face of planet Earth...while editing text
files in Notepad or HIDE, a "power failure" could happen...and you"d lose
all your work until the last "save", just like any other command-line / GUI
program on the face of this entire planet (logical enough, really: The only
way to preserve data is to store it on a non-volatile storage medium such
as the disk, rather than RAM, which empties when power isn"t
available...sorry, but that"s kind of ALWAYS been the case and if LuxAsm is
now having to account for fracking power failures too, just to please...oh,
that"s right: Just to please those who have their own interests - their own
"agendas" - in promoting their own product and making LuxAsm sound
"dangerous" or "disasterous" (when it in no is such at all) when it"s a
complete and utter lie...trusting the "competition" before your own good
sense?

Look, the purpose of "incremental assembly" isn"t solely to "experiment"
with new and different ways...the whole point of it is that it"s a modern
and progressive concept with many, many advantages...the IDE follows the
_STANDARD GUI METAPHOR_ so it does NOT suffer any additional problems that,
say, ooh, Word or Excel or something suffers...indeed, though, Word does
have an "autosave" option where you can tell it to automatically save every
XX minutes...fine, we can throw that in for the "forgetful" user (though
_OPTIONAL_, as I actually personally don"t like "autosave" because, you
know, it starts automatically overwriting previous versions and can play
havoc trying to keep your "backups" orderly, if you"re rather used to
_DOING IT MANUALLY_...as with, ooh, 99% of all applications on the face of
planet Earth)...

 But, if worried about "power failures", then move the mouse to the "File"
 menu, the "Save" option and click...alternatively, use the shortcut key
 combination of Ctrl + S...make regular backups...as you would with any
 other GUI application in the whole of existence, as has been the case from
 when Xerox invented the GUI until now...

 No wonder Bush manages to frighten everyone so easily with "bogeymen"...if
 someone says anything negative, it"s instantly believed hook, line and
 sinker as being a "terrible problem", even though possibly decades of use
 of computer programs has told you repeatedly every single day that such a
 "bogeyman" does NOT exist...

 Tell me, is Notepad "flawed" or "broken" because you have to choose "Save"
 from the "File" menu to write your changes to the disk? If so, wouldn"t
 that make _EVERY SINGLE GUI PROGRAM THAT EXISTS_ "broken" and "flawed"?

 Oh, go on...put in your "autosave" option, then...have your "traffic light
 terrorist alert" system, if it makes you feel "safe"...but don"t expect me
 to go believing in these "black propoganda" lies...there is NOTHING
 additional that is "wrong" with the LuxAsm design than any other GUI / IDE
 program out there...NONE...if anything, we _IMPROVE_ on this...

In fact, as noted, it _would_ save every single character typed, other than
this is completely and utterly silly...paranoid to the point of
absurdity...impractical to actually use...slows it all down and knackers
out your hard drive after two months of constant use...so, the sensible
approach is to "cache" it...work with RAM and then "flush" that to disk at
the appropriate time (which, surely is logical enough as being when the
user hits "Save" to allow them to decide when is most "appropriate" to
update their files? :)...

 Hence, in fact, the "incremental" approach does not make this "worse"...it
 would be naturally so extreme and "paranoid" without "caching" as to be
 absurdly silly...you could only lose one character or one line at
 most...but one has to compromise between the likelihood of "power failure"
 and the other 99.999999% of the time when the user actually wants it to
 move forward smoothly and quickly...

 You know how all those other command-line tools work? With the "edit ->
 compile" phased nonsense - which actually is the greatest thing
 _jepordising_ people"s data (it"s one of the numerous reasons to "go
 incremental" that it"s _BETTER_ than that backwards, ancient crap)? Well,
 you can totally forget that...

Think of something like Notepad...you start up the program, you select
"open..." and choose a file...this loads the file into RAM...you edit the
file...at any point that the user feels it appropriate, they hit "save" and
the file in RAM is copied to the disk (with "save", it is saved to the same
filename overwriting the previous version, with "save as..." then it is
possible to save it to a different filename and creates multiple versions -
"backups" - and so forth)...when the user hits "close" on the window, if
the current contents has changes that have not been saved, the application
prompts "save file?", to which the user can choose "yes" (saves file), "no"
(closes without saving) or "cancel" (aborts closing the application)...

 You see how that works? This is a "familiar" enough approach, yes?

Right, LuxAsm"s design is _EXACTLY THE SAME_...yes, unlike many other IDEs,
in fact, LuxAsm more closely fits this familiar methodology...you load the
file, you edit it, you hit "save"...and that"s it...

 You"ll note, when using, say, Word or Excel, that there is no "compile
 document" button sitting on any "toolbar"...that you alter some kind of
 "source code" with "tags" and then must "compile" this to get yourself a
 WYSIWYG output of the document...Nope: You edit the document WYSIWYG
 directly...LuxAsm"s approach will be closer to this than to the "edit ->
 compile -> test -> edit -> compile -> test" cycle of older, ancient,
 backwards tools...

 > As an example of this being possible, try the VIM text editor.
 > I have known it to recover a file after a power-failure with
 > little more than a few key-strokes loss to the input in progress.
 > Considering the speed I type, this is some achievement.

 Yeah, if you want it to "autosave" all the fracking time, then go right
 ahead and add that as some "option" to the IDE...

 But, really, this is some "invented problem"...what Randy was actually
 talking about was _ROSASM"S DESIGN_...LuxAsm"s design is entirely
 different...in the case of LuxAsm, Randy does NOT have a point, NoDot...

We"ve met our first "phantom book review", people...it seems the "angle"
our "enemies" will be taking is to try to pretend that LuxAsm"s incremental
methodology is "dangerous"...that we should not be trusted because our
methods are "unreliable"...

Utter nonsense...I cannot stress just how much utter nonsense that
is...there is not even the smallest grain of truth anywhere in that
assertion whatsoever...I don"t just mean it"s not a problem: LuxAsm has to,
in fact, "calm down" on saving quite so frequently or it would suffer the
_complete reverse_ of being so "secure" as to become _IMPRACTICAL_ under a
weight of unnecessary "paranoia"...

There is no such problem in LuxAsm"s design...I repeat, there is no such
problem in LuxAsm"s design...I repeat, there is no such problem in LuxAsm"s
design...

Look under the bed...see? No "bogeyman"...shall I leave a night light on
for you, anyway? But I assure you 100% without doubt and without
hesitation: There is NO SUCH PROBLEM in LuxAsm"s design...if anyone
suggests such, then they are misguided or spreading "black propoganda" for
_FEARING_ that LuxAsm has got it _SO RIGHT_ that their backwards tools look
like utter crap in comparison...projecting _THEIR_ faults and fears onto
us...

 Please, NoDot, do NOT feed the "bogeyman" and give credence to what is a
 total falsehood...Randy was talking about _RosAsm_ and our design is NOT,
 NOT, NOT like RosAsm...

 Indeed, this is the whole point: LuxAsm does what RosAsm _SHOULD_ have
 done...

RosAsm _SHOULD_ have been written for an "ethical" operating system
platform, such as Linux...RosAsm _SHOULD_ have used its "integration" to
provide the "familiar" GUI methodology...RosAsm _SHOULD_ have included
"modular support" in order to facilitate large-scale work...RosAsm _SHOULD_
have adopted a decoupled "modular architecture" of a separate tool chain
rather than stuffing it all in one file (the "HLL Pre-parser" demonstrate
the height of this nuttiness: Rene says that RosAsm is an assembler because
it includes no "HLLisms", yet the "HLL pre-parser" _ARE_ inside the RosAsm
executable, whether you use them or not...typical Rene confused and
contradictory design)...RosAsm _SHOULD_ have adopted a "compatible"
approach to "embedded source code" (which we _WILL_ adopt and Randy"s
"scare-mongering" that LuxAsm"s ability to do this will make all programs
explode or not allow other tools to be used is _UTTER CRAP_ you can
completely ignore)...

LuxAsm will be the most seamless and fastest assembler ever...with
unprecedented interactive "feedback" capability that shames the most
capable HLL or IDE out there...with uncompromising modularity and
flexibility and versatility to make your web browser look "weak"...with a
fundamentally robust and reliable and scalable "peer to peer" architecture
(the choice of the military to _SURVIVE NUCLEAR HOLOCAUST_, so "robust" and
"reliable" is this model deemed to be)...

 Beth :)


From: NoDot <nodot@xxxxx>
 Re: Re: RosAsm is a broken pile of crap
2005-04-27 18:40 	

 Beth wrote:
 > ...Randy was talking about _RosAsm_ and our design is NOT,
 > NOT, NOT like RosAsm...

 If you go back and read the exact paragraph I quoted, then you"ll see
 that it *can* be an issue. He"s talking about a case where the assembler
 crashes and the user looses work, not a power failure. This is a case in
 RosAsm because the tools are all in one big program. I don"t see how
 this is any different in LuxAsm, because all the tools are still part of
 the same program, they"re just physically seperated into modules. This
 problem would exist with RosAsm if Betov had used your Module
 Architecture, probably. If this isn"t the case, be it for Linux or both,
 then I apologise for wasting so much time on nothing. Persumably, if a
 DLL or SO crashes, then the program they were attached to crashes as
 well. If this is not the case, then I refer you two sentences back.

 > Beth :)

 --
 The above was written by NoDot.

 Visit the Website of NoDot:
 <www.geocities.com/nodot1989/>













From: Beth <BethStone21@xxxxx>
 Re: Re: Report from the LuxAsm mailing list for Betov
2005-04-27 08:10

Frankie say:
> Randy wrote:
> > NoDot wrote:
> > > I looked back at the section of Randall"s post I sent to the
> > > LuxAsm-devel list. It was stating that if one of the sections failed,
> > > then the entire thing will fall down. I don"t see how the problem
> > > differs from RosAsm to LuxAsm. Unless the assembler module crashing
is
> > > reported back to the IDE or whatever called it by Linux instead of
> > > trashing the whole thing, assembler and all, the problem is the same.
> >
> > If LuxAsm is using *separate* programs for these functions, there
should be
> > no problem. That is, the assembler module could crash during assembly
and it
> > wouldn"t affect the editor (and the file it currently holds). The
problem
> > with RosAsm is that it is all one monolithic program. If one line of
code
> > crashes, the whole system comes down and any unsaved work is lost. This
is
> > true whether the crash occurs in the editor, the assembler, the
> > disassembler, or in the ASCII chart display. But as long as LuxAsm is
simply
> > a "driver" program, that invokes all these other processes
independently, it
> > is sufficiently decoupled that the problem does not exist.
> >
> > As for Rene"s comments about "it"s just another "brick & brock" IDE"
> > (whatever that means, it must mean something in French because it
doesn"t in
> > English),
>
> I think it"s another of Betov"s "made up words". Not quite
> as cool as "full-talking names", but I think I know what he
> means - what I"d call a "shell" (but that terminology
> probably isn"t correct, either).

What I call an "aggregated development environment"...which is also a "made
up word" but one at least somewhat familiar to the actual correct
terminology...

Most IDEs (HIDE, RadAsm, Visual C++, etc.) are, in fact, "aggregated
development environments" by my "made up word" (which I made up to make the
distinction between the "types")...that is, there is a GUI program - the
IDE - which presents a single "face" to the programmer and then it runs
other _EXTERNAL_ programs (via sending "command-lines" to these _SEPARATED_
tools) to do the actual work...

RosAsm is _ALSO_ an "aggregated development environment", even though it
does have the design of placing all the tools _INTERNALLY_ inside RosAsm"s
single executable file (except for the "calculator" option, which can be
set to an external calculator program - though, in fact, you could
technically set it to launch _ANY_ program, really, but no "command-line
arguaments" sent - that weirdly defies the design used elsewhere)...because
though all the "tools" are inside the same executable file (in a sense, it
is just "one tool"), it"s actual mode of behaviour takes NO ADVANTAGE out
of this and still actually operates by the exact same "aggregated
development environment" style of the rest...

 LuxAsm is different; It"s "modular", so that each tool is a separate
 "module" (and can be accessed as such, in the more "traditional"
 command-line fashion)...BUT LuxAsm "modules" are also capable of locating
 each other and "tightly integrating" their functionality...and this is a
 _REAL_ "integrated development environment"...

"Aggregated" means "put side by side", so to speak...while "integrated"
means "working together"...going by these Plain English semantics, most
so-called IDEs are actually ADEs ("aggregated development environments")
where tools are accessible "side by side" using a single GUI
"face"...LuxAsm is a _TRUE_ IDE in that the tools are not merely accessible
"side by side" but are capable of _WORKING TOGETHER_ and, thus, actually
_INTEGRATING_ their behaviour for additional benefits (e.g. "feedback",
100% accurate, fine-grained syntax highlighting, autodependencies,
etc....stuff you will not find anywhere else, as they are a result of _TRUE
INTEGRATION_ of the tools, that mere "aggregation" cannot match)...

 There still seems a lot of confusion on this point, though...how can I
 explain it so that you can all see exactly what I mean and that it is, in
 fact, NOT true that "Randy has a point" with the LuxAsm design whatsoever
 (he may have a point with RosAsm"s design but LuxAsm"s is completely
 different...indeed, LuxAsm _extends_ the "traditional" modular means, it
 does NOT suffer a single "monofile programming" issue in the
 slightest...the fact that it operates through a GUI interface makes NOT an
 ounce of difference to this underlying fundamental point whatsoever)...

 > Of course, LuxAsm isn"t going to crash. Says so right here
 > in the glossy brochure!

 Of course ;)

 > But anyone can experience a power failure...

[ One day, we all will...permanently...but that"s another topic for another
thread of discussion ;) ]

 > I don"t see how you can avoid losing work if the editor
 > crashes... experiences a power failure, I mean... Well, we
 > could save to disk after every keystroke... Obviously,
 > there"s a tradeoff between "performance" and "security" that
 > we"ll have to negotiate (in consultation with the user, of
 > course!). (would saving every N lines make more sense than
 > saving every N minutes?)

 Exactly; No program should ever crash (they do, though, from time to
 time...but this is a "bug"...or, to take the "politeness" out of it to get
 the right attitude: This is a _FAILURE_ of the development...it should be
 rectified as soon as is possible)...

No piece of software can do a single thing about "power failure", as it"s a
reality of the "real world", outside software control...all programs, all
electronic equipment is rendered useless, the second that flow of electrons
(often erroneously called "electricity" ;) ceases to flow through
it...there"s sod all we can do about that...but neither can any other
program...

 The means to prevent "data loss" is through prudent saving and making of
 "backup" files whilst using programs...the disk, unlike RAM, is a
 non-volatile storage medium, so its contents survives power loss (can be
 retrieved once more, when power is restored :)...

LuxAsm will provide the standard "Save" and "Save As..." and "Save all"
menu options on its "File" menu that are used for this purpose..."Save"
flushes the RAM copy of the currently edited file to the disk using the
same filename it was opened with (if the file has no filename - was just
created with the "New" option of the "File" menu - then "Save" defaults to
behaving as "Save as..." transparently)..."Save as" supplies a dialogue box
where the user may select the filename then it acts as "Save" flushing the
RAM copy to the filename specified..."Save all" is a third option provided
because the IDE interface is capable of holding multiple files open
simultaneously...it"s merely a shortcut for choosing "Save" on each of the
opened file simultaneously...

 Please, tell me if I"m going too fast for you here or anything...but this
 is all very much "standard" GUI behaviour that should be familiar from any
 GUI application you"ve ever used in your entire lifetime :)...

If it is deemed "problematic" that the user would be too forgetful or idiot
to make prudent use of these options, then it is, indeed, quite possible to
add an "autosave" feature, which every XXX minutes (or every YYY lines...or
every ZZZ full moons or whatever "unit of measurement" you feel is
appropriate :), the IDE automatically chooses the "save" option on the open
files as necessary...

Frank is quite correct, though, that there is a "trade-off" involved...the
most "simplistic" implementation of the "incremental" approach would, in
fact, automatically "save" and "assemble" every single change that is made
(every character typed)...this, though, is "paranoid" to the extreme and
would cause a serious "performance" issue, as the entire program would be
reduced to constantly operating at "disk speed" (some 7200rpms, by the
usual IDE standards on a "typical" machine :)...also, such constant use of
the disk mechanisms - which are mechanical, let"s not forget - would
introduce greater strain on the hard drive mechanisms...ironically meaning
that such "paranoia" could make the hard drive _FAIL COMPLETELY_ far sooner
than would be natural for typical "wear and tear"...in the lyrics of Bono:
"You can hold onto something so tight, you"ve already lost it"...

It is also fully correct that such a "trade-off" should be made "in
consultation with the user"...this is the concept of the "save" option: The
user chooses the appropriate time themselves...if they wish to be "overly
paranoid", they are fully at Liberty to tap "Ctrl + S" (or "Alt + F +
S"...this combination should be maintained for LuxAsm because, indeed, over
the years, I"ve developed an automatic habit to tap "Alt + F + S" as a
single flowing keystroke whenever I stop typing for five minutes...if
you"ve not personally developed such a habit, then I strongly encourage
doing so)...if they want to never bother with the "inconvenience" of
"saving" their files for a whole 7 days, then they can also select this
option at will...

Okay, people...tell me, so far, what exactly is the big problem with all of
this? And, you know, if it is some "terrible problem" then it"ll be a
"newsflash" for the rest of the entire software industry because _ALL_ GUI
programs follow this "methodology"...

 Also, note that constantly saving automatically can be
 _DETRIMENTAL_...saving too often can also screw up the user"s ability to
 "undo" and "revert"...to manually maintain their own "backups"...I was
 helping a "newbie" before who"d been using Word, it crashed in an odd way
 rendering the file full of junk and the user had hit "close"...when asked
 to "save", they (wrongly) said "yes"...this overwrote the _good_ copy of
 the file...worse, to help them, I"d created a "back up files" desktop icon
 for them to double-click that automatically copies their work files into a
 "backup" folder (which ordinarily works a charm that if they screw things
 up, I can come along and retrieve it from the "backups" folder ;)...they
 also double-clicked on this to "backup" their files (because, due to the
 crash, their "paranoia" made them hit the icon)...utterly defeating the
 purpose of everything I"d put in place, by overwriting _ALL_ the "good"
 copies of the file...

Oops! Needless to say, I"ve now altered the "backup" icon a little bit...it
saves current files as ".bak" then writes the new files, so that it has at
least one "layer" of files before overwriting...also, I advised the newbie
not to choose "save" when the program crashes but to exit without saving
and then start again from the saved version (and, sorry, you may lose
_some_ of your work this way but at least it isn"t the entire bloody thing,
as otherwise happens ;)...

So, "autosave" can be _detrimental_ (and it should at least implement the
".bak" scheme of renaming older files first, so there"s at least a "buffer"
of one file before things are overwritten)...also, at one point, I did
suggest that it might even make sense to put CVS "versioning" capability
into LuxAsm directly...though, yes, that is "more complicated"...but it
would solve this problem...and we"ll need a "diff" for "incremental",
anyway...would it be so difficult to then add another utility that saves
these "diffs" from version to version? Ah, I suppose it depends on how
complicated supporting CVS actually is...but that"s one possible idea...add
CVS functionality - a "CVS" module - that then permits the use of CVS, not
solely over a network to work with SourceForge, for instance (which could
be handy for us too :) but can also create "local CVS repositories" for any
project...integrated with the IDE so that you can "save & commit" with one
option? Maintains "version number / build number" automatically (one thing
I"m absolutely dreadful with, in fact: I just keep editing and never keep
track of any "version numbers"...and, I confess, just "make them up"
after-the-fact in an "informal" capacity, if you know what I mean...and
"build numbers"? How on Earth do people keep track of that? They literally
count every time they hit "compile"?!? ;)...

 On the contrary, though, LuxAsm _does_ differ in one capacity from most
 IDEs...there is no "compile / assemble" button supplied...due to the
 incremental approach, this is all "automatic", as changes are made...

Indeed, ironically considering these "complaints", LuxAsm"s problem is the
_complete reverse_...saving at every change would, as Frank rightly points
out, be a "trade-off" at the other "extreme" of "overly-paranoid" that it
would be _detrimental_ in the other direction (e.g. crap performance, makes
"reverting" to previous versions a nightmare or just plain impossible
because it"s "overwritten" the files enough times to even overwrite
"backups" and the user is no diligent or prudent enough to, you know, make
separate "backups" where they copy the files regularly elsewhere with
different filenames)...hence, instead, LuxAsm "caches" or "buffers" these
changes via RAM until "save" is chosen by the user...this puts it back in
the user"s control where to make the "trade-off" and that they can control
their own "backups" (this is often important for implementing a good
"backup" scheme: "Control" over the process is often beneficial to doing it
well)...

But there is some conselation here...in that the only criticisms others are
able to make of the LuxAsm design always seems to involve this "unrealistic
idiot" using the tools...that, oh dear, LuxAsm is "wrong" because it does
not account for asteroid impacts or alien invasions!! Ummm, sorry, no
software outside nuclear facilities and the military does do that...this is
"inventing problems from nowhere" to create some "black propoganda", I
think, as many realise that the approach LuxAsm is going to be taking is,
in fact, head and shoulders - generations - ahead of the pack...

I repeat that I have thought much of this stuff through already when making
the design...and that it is based on _PRAGMATICS_ more than anything
else...because, to explain it, there"s often a lot of "theory" mentioned,
do not fall i

From: NoDot <nodot@xxxxx>
 Re: Re: Report from the LuxAsm mailing list for Betov
2005-04-27 19:51

Beth wrote:
>>But anyone can experience a power failure...
>
> [ One day, we all will...permanently...but that"s another topic for another
> thread of discussion ;) ]

 <rant size="mini">
 Psionic power, that"s the next step!
 </rant>

> Indeed, if C is happy to make the "interface" slightly more complex, then
> this problem can be _completely eradicated_...currently, I"ve been
> designing the "interfaces" to work single-threaded..._IF_ made fully
> "multi-tasking", then each "module" would live in its own address space and
> one of them crashing CANNOT bring down the others (the standard
> "protections" of a concurrent design there :)...and they could be
> programmed to "detect" error conditions in other "modules" - as, when
> "integrating", they"ll be "aware" of the other "modules", anyway - so as to
> "shutdown in a safe and orderly fashion" should one component crash...

 [takes notes]

 > Beth :)

 --
 The above was written by NoDot.

 Visit the Website of NoDot:
 <www.geocities.com/nodot1989/>


From: C.R. Chafer <crchafer@xxxxx>
 Re: Re: Report from the LuxAsm mailing list for Betov
2005-04-28 01:59 	

  --- Beth <BethStone21@xxxxx> wrote:

 [snip]

 > If it is deemed "problematic" that the user would be too forgetful
 > or idiot to make prudent use of these options, then it is, indeed,
 > quite possible to add an "autosave" feature, which every XXX minutes
 > (or every YYY lines...or every ZZZ full moons or whatever "unit of
 > measurement" you feel is appropriate :), the IDE automatically
 > chooses the "save" option on the open files as necessary...

 There is auto the possibility of saving using a log of changes.
 So that, instead of saving the whole file, we only save a log
 of where the changes are -- similar to a cvs diff, though using
 a different format.  This would allow recovery from _even_ a
 power failure, while not requiring the overhead of a whole file
 autosave every XXX minutes.  Such a save could run from a
 parallel task/job (so not to cause delays).  Due to Luxasm"s
 modular architecture, this should be fairly easy to implement
 -- we only need to monitor and log the interface between the
 editor and the text highlight portion of the assemble module.
 Using this method Luxasm would not only be unlikely to crash,
 as we would programme it using proper exception handling, but
 a crash -- for any reason -- would not result in data loss.
 Hence we change a potential (minor) problem into a major
 advantage -- the cost being little more than a few hours worth
 of coding.

 Also, though I did not think of this originally, such a feature
 could be used to implement an undo function which could undo
 every change since the last save in a fine grained manner.

 [snip]

 > Indeed, if C is happy to make the "interface" slightly more
 > complex, then this problem can be _completely eradicated_...
 > currently, I"ve been designing the "interfaces" to work
 > single-threaded..._IF_ made fully "multi-tasking", then each
 > "module" would live in its own address space and one of them
 > crashing CANNOT bring down the others (the standard
 > "protections" of a concurrent design there :)...and they could
 > be programmed to "detect" error conditions in other "modules"
 > - as, when "integrating", they"ll be "aware" of the other
 > "modules", anyway - so as to "shutdown in a safe and orderly
 > fashion" should one component crash...

 We have an interface design?  I think that is a bit too generous
 for the sketch we have at the moment :-)

 The trouble with implementing Luxasm as truely seperate multiple
 jobs (multi-tasking as opposed to just multi-threading) is that
 communicating between the jobs is none-trivial (has to use pipes
 or shared memory, both of which have problems).  As we do not
 require Luxasm"s components to be distrubuted across multiple
 systems, such an architecture is likely to have too many
 disadvantages.  (Though certain components, such as the logging
 feature highlighted above, would benifit from full seperation.)

 I would recommend designing Luxasm to be fail-safe rather than
 fail-active and then encorage the writing of good execption
 handlers and internal checks to either recover from an error or
 revert to a known good state.  In the (likely very rare) event
 that Luxasm crashes, then the logging module (highlighted above)
 could save its log, allowing Luxasm to recover the data after a
 restart.

 You"re right, with true integration and a modular architecture,
 we have a number of advantages and therefore can do things like
 this without massive code bloat.

 C
 2005-04-28

 Send instant messages to your online friends
.