Re: Report from the LuxAsm mailing list for Betov

Randall Hyde wrote:
>
> "NoDot" <no_dot@xxxxxxx> wrote in message
> news:1114477381.523760.63500@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > 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).

Of course, LuxAsm isn't going to crash. Says so right here
in the glossy brochure! But anyone can experience a power
failure...

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?)

As far as the "ASCII chart" (or "unicode chart" or any other
module) bringing the whole shebang down... Ideally, we'll be
"decoupled" enough so that this doesn't happen, but
"coupled" tightly enough to enjoy the advantages of being a
"fully integrated" environment. Beth thinks we can have
"both". I suspect we'll end up in a situation where certain
modules crashing *will* bring the whole mess down, but we
can arrange it so that not "much" work is lost, even in the
"worst case".

If what we wanted was a "brick & brock" IDE, that would be a
*lot* simpler to implement. And it would have the advantage
that you could use any editor you like - vi, emacs, or
something else, any assembler you like - Nasm, Fasm, Gas...
even that "not an assembler", HLA :) I don't think there's
much choice in linkers... (besides not using one at all).

Despite the advantages, I don't think that's what we have in
mind. Initially, at least, we'll probably want to run
certain modules as "separate" processes. Not everything
needs to be "fully integrated" to be useful. But the idea of
LuxAsm is that it will, ultimately, be "fully integrated" in
much the same way RosAsm is. If we can find a more robust
way to go about it, so much the better.

I don't see that we need separate error messages for "That's
a Limerick", "That's a Sonnet", "That's a Dictionary", but
hopefully we can give a more graceful response to totally
malformed input than crashing. We shall see...

Best,
Frank
.

Relevant Pages

  • Re: From the LuxAsm list.
    ... >> I don't think that it would be possible to add an IDE to an assembler ... > have all incorporated the editor and assembler in the same program. ... be taken advantage of, from the LuxAsm IDE, in doing so:)... ... There is, of course, a _LOGICAL_ dependency between the editor and the ...
    (alt.lang.asm)
  • Re: Rene is a hypocrite (OK, what else is new?)
    ... If the LuxAsm project comes up with any Xlib ... when put to the test, you _cower_ behind an assembler, daring not to ... programming just because it isn't jealous old you who's managed to do ... Shine on, you crazy diamond! ...
    (alt.lang.asm)
  • From the LuxAsm list.
    ... > Is the LuxAsm module interface going to be using ... That was actually a "part of the plan"...the LuxAsm IDE will actually ... assembler first instead...doesn"t make any difference at all in the long ... > have LuxAsm invoked from the command line as well. ...
    (alt.lang.asm)
  • From the LuxAsm list.
    ... I am reposting this from the LuxAsm list for anyone interessted. ... LuxAsm will be a low level assembler in its most ... "incrementally" as the programmer types out the program into the GUI ... argument Randy makes that using macros everywhere would slow things down - ...
    (alt.lang.asm)
  • Re: RosAsm - right click
    ... If free form syntax is desired the line continuation operator '\' ... reset the assembler to allow this -- but this is only a half ... which Luxasm inherits many features ... (The idea for the double oblique itself was inherited from ...
    (alt.lang.asm)