XML-based object orientated pre-Assembler

[Jure Sah]

Hello,

I have been promising an object orientated ASM IDE for a while now.
Trying to make the best of what is already here, I have made a compiler,
that will parse XML code and output ASM files.

The program still needs an internet interface (will do that tommorow),
but here is an example of what the code looks like, to wet your appetite:

<?xml version="1.0"?>
<code
xml:base="http://my.webspace.com/"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Default xmlns:href="Default.xml"></Default>
<RegisterA xmlns:href="AX.xml">
<RegisterB xmlns:href="BX.xml">
mov ax,00FFh
mov bx,0FF0h
cmp ax,bx
mov cx,ax
</RegisterB>
</RegisterA>
mov ax,cx
</code>

The point is, that since the compiler is W3C XML and XLink compilant,
you can now use whichever XML editor (IDE) to work with your ASM code
(colorfull, named XML tags tend to be lighter on the eyes, when you are
looking for something in the code). The compiler works like this example:

<Whatever xmlns:href="AX.xml">
...
</Whatever>

Relates to this file (AX.xml):

<?xml version="1.0"?>
<Compiler>
<Begin>
push ax<br>
mov ax,0000h
</Begin>
<End>
pop ax
</End>
</Compiler>

To produce this code:

push ax
mov ax,0000h
...
pop ax

And while this example may seem silly, using this and an XML editor, it
becomes much more unlikely for you to end up with an out-of sequence
stack and any of the terrible consequences this usually brings. Not to
mention the segments can be labeled, making the program easier to read.

The XLink-ed XML of course, can be made to point to any ASM code you
choose and best of all, they do not need to be on the machine your are
compiling on, but anywhere on the internet. In this way you can define a
simplified language with these XML objects, then put them on a web
server and you never have to worry about them again, you can create
programs that you share with your friends / coworkers over the internet
and you only have to send them your XML program (which I might add is
also doomed to be much more understanable than the compiled ASM to them)
and if they wish to compile it, the components needed will be downloaded
automatically durring the compilation procedure.

The other good thing about this is that, if there ever will be large
compatible databases of these XML objects online, porting an ASM program
written in this XML language (to another ASM form or to diffirent
hardware / software) will be simply a matter of changing the XML:base
link (xml:base="http://my.webspace.com/") to point to another location,
compile and viola, the code is ported.

I might improove the language used in case it turns out to be too
loosely compilant to W3C standards or if there are other practical
aspects of the XML standard that can be used, but it will be
backwards-compatible and I will avoid fixed high-level features such as
the many in HLA. I have no intention of reinventing hot water.

P.S.: You will notice that the XML compiler can also be used to compile
anything else made up of text, not only ASM programs.

Coming soon! Like... tommorow! Now I got to go to bed. =P

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

[Percival]

On Fri, 04 Mar 2005 00:26:14 +0100, Jure Sah wrote:

[snip]

I'd have to say that it is a very creative assembler you are creating...
Though I do ask, what does XML give me over plain text?

Vi and Emacs, very awesome general purpose text editors, both offer syntax
highlighting, and plenty of assemblers know how to include files.

Though this looks like it could work, I'd have to see the program itself
though to make a decision.

PS. Looks kinda like that Unified model Beth was talking about :)

Percival

[Randall Hyde]

"Jure Sah" <ju******@guest.arnes.si> wrote in message
news:42**************@guest.arnes.si...

Hello,

I have been promising an object orientated ASM IDE for a while now.
Trying to make the best of what is already here, I have made a compiler,
that will parse XML code and output ASM files. ....
And while this example may seem silly, using this and an XML editor, it
becomes much more unlikely for you to end up with an out-of sequence
stack and any of the terrible consequences this usually brings. Not to
mention the segments can be labeled, making the program easier to read.
It really sounds like you're trying to create an XML version of the
fabled "BethTools" system (seach Google for details).

The XLink-ed XML of course, can be made to point to any ASM code you
choose and best of all, they do not need to be on the machine your are
compiling on, but anywhere on the internet. In this way you can define a
simplified language with these XML objects, then put them on a web
server and you never have to worry about them again, you can create
programs that you share with your friends / coworkers over the internet
and you only have to send them your XML program (which I might add is
also doomed to be much more understanable than the compiled ASM to them)
and if they wish to compile it, the components needed will be downloaded
automatically durring the compilation procedure.
And what's the point?

The other good thing about this is that, if there ever will be large
compatible databases of these XML objects online, porting an ASM program
written in this XML language (to another ASM form or to diffirent
hardware / software) will be simply a matter of changing the XML:base
link (xml:base="http://my.webspace.com/") to point to another location,
compile and viola, the code is ported.
Well, if you're going to give up machine dependence, which it sure
seems to me like you're doing this, then why not just use a HLL?

I might improove the language used in case it turns out to be too
loosely compilant to W3C standards or if there are other practical
aspects of the XML standard that can be used, but it will be
backwards-compatible and I will avoid fixed high-level features such as
the many in HLA. I have no intention of reinventing hot water.

P.S.: You will notice that the XML compiler can also be used to compile
anything else made up of text, not only ASM programs.

Coming soon! Like... tommorow! Now I got to go to bed. =P

I wish you all the luck in the world, but have you answered a
couple of important questions:

1. "Who is the audience for this product?"
2. "What is the purpose of this product?"
3. "Why would someone use this product over other assemblers (or HLLs)?"

HLA, for example, was designed to support beginning assembly
language programmers. That completely answers the three questions above.
What benefits are you proposing? Being able to edit your assembly programs
with an XML editor isn't a great turn-on to most programmers around here.
Indeed, speaking from experience, I can pretty much assure you that
there are only a tiny fraction of existing assembly programmers who
would be willing to switch to your system, once it's complete. That
leaves beginners as the only large market for such a system. What
benefits does this offer to those wanting to learn assembly? Perhaps
those who already know XML? (I don't know...). Of course, if
you're like Herbert and you just want to create an assembler for
yourself, have at it.
Cheers,
Randy Hyde

[Jure Sah]

Randall Hyde wrote:

And while this example may seem silly, using this and an XML editor, it
becomes much more unlikely for you to end up with an out-of sequence
stack and any of the terrible consequences this usually brings. Not to
mention the segments can be labeled, making the program easier to read.
It really sounds like you're trying to create an XML version of the
fabled "BethTools" system (seach Google for details).

Google does not give any matches on that string.

The XLink-ed XML of course, can be made to point to any ASM code you
choose and best of all, they do not need to be on the machine your are
compiling on, but anywhere on the internet. In this way you can define a
simplified language with these XML objects, then put them on a web
server and you never have to worry about them again, you can create
programs that you share with your friends / coworkers over the internet
and you only have to send them your XML program (which I might add is
also doomed to be much more understanable than the compiled ASM to them)
and if they wish to compile it, the components needed will be downloaded
automatically durring the compilation procedure.

And what's the point?

That it is more readable, easier to organize and change, prevent
doubling-up of work already done for other software and simpler to
costumize to serve another purpose.

The other good thing about this is that, if there ever will be large
compatible databases of these XML objects online, porting an ASM program
written in this XML language (to another ASM form or to diffirent
hardware / software) will be simply a matter of changing the XML:base
link (xml:base="http://my.webspace.com/") to point to another location,
compile and viola, the code is ported.

Well, if you're going to give up machine dependence, which it sure
seems to me like you're doing this, then why not just use a HLL?

XMLc is not exclusive to use, you can quite simply use XMLc to compile
programs which are then to be processed trough your HLL processor. XMLc
is programming-language independent and still maintains it's full list
of potential advantages.
I wish you all the luck in the world, but have you answered a
couple of important questions:

1. "Who is the audience for this product?"
Perhaps, as you later mention, also myself, but generaly it could be either:
1. Any ASM programmer who wishes to keep his code readable and reusable.
2. Anyone who does not have enough experience to be able to smoothly
read ASM code and can utilize a handy graphical representation of the code.
3. Any group of people working togather on one ASM program.
2. "What is the purpose of this product?"
To provide a commonpoint for many diffirent programming languages, thus
create an universal devolopment environment of tools hand for the
devolopers and to make it up to globally accepted standards. For
example: Provide the advantages of using XML editors to ASM programmers.
3. "Why would someone use this product over other assemblers (or HLLs)?"
Pointless question, I think those who are used to other assemblers or
HLLs and find XMLc usable will be in fact using both (since XMLc
produces code, not binaries). But I suppose the prospect of being
object-orientated, internet-level portable and compilant to world
standars, without making sacrafices on the effectivness of the code
itself has got to attract some attention.
HLA, for example, was designed to support beginning assembly
language programmers. That completely answers the three questions above.
What benefits are you proposing? Being able to edit your assembly programs
with an XML editor isn't a great turn-on to most programmers around here.
And you speak for all of them?
Indeed, speaking from experience, I can pretty much assure you that
there are only a tiny fraction of existing assembly programmers who
would be willing to switch to your system, once it's complete. That
leaves beginners as the only large market for such a system. What
benefits does this offer to those wanting to learn assembly? Perhaps
those who already know XML? (I don't know...). Of course, if
you're like Herbert and you just want to create an assembler for
yourself, have at it.

The main idea behind this project was a while ago, when a friend working
in the area of Artificial Inteligence, brought to my attention XML, the
language where meaning can be described (at the time I was working on
poly-dimensional context-based search spheres) in a simple hierarchical
format, where the language is dnyamic and everything is refferenced to
defenition maps that the XML is linked to over the internet.

The point of that refference was that if everything is somewhere on the
internet, and compilant to world standards, it is easy to use and does
not have to be re-made. XML is also a language that enables you to put
various kinds of information that various diffirent programs will be
using, contextfully, in the same XML file. Being XML compilant you gain
a lot and being able to utilize a language on top of another that gives
you standard-compilance also means that the information stored within
your code is:
1. Manipulatable with any XML compilant editor
2. Readable by any XML compilant reader (which may include several
applications not interested in the ASM code within)

So being XML compilant alone has a point.

I suppose many more people have been taught XML than are willing to try
ASM. XML has a future, raw ASM (they say) does not. People will use Java
and simmilar programing languages because they share these
characteristics of XML, but Java is a slow interpreted language. XMLc
gives you all the advantages of being able to utilize modern programming
language standards, it's language has and will continue to have plenty
of usable editors worldwide and at the same time, leaves you with
working, highly efficient and fully costumizable low-level code.

I will, as far as I'm concerned, utilize the XMLc and create my objects
and share them on the internet, perhaps once there are more of them,
people who are new to ASM may seek to utilize those instead of going for
raw ASM rightaway. But I suppose, as W3C says about XML, that it is a
good standard that hopefully everybody will embrace as a part of good
working praxis, and take that as a recomendation.

But I will not force it on you, it is a usable tool and a good idea if
you ask me, and it will be freeware.

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

[Jure Sah]

Percival wrote:

I'd have to say that it is a very creative assembler you are creating...
Though I do ask, what does XML give me over plain text?

Vi and Emacs, very awesome general purpose text editors, both offer syntax
highlighting, and plenty of assemblers know how to include files.
<kidding> More portability in that case (Windows ;). </kidding>

Well but generally:
1. XML allows web-based refferences
2. XML is more globally-accepted as a type simmilar to to
object-orientated text, which leaves you with the poitential of using
graphical-representation tools to display a finnished ASM program,
allowing you to more easily explain the structure of your program to
people who are not yet fammiliar with your code and require to be. I
wonder if vi or emacs can do that. ;)
Though this looks like it could work, I'd have to see the program itself
though to make a decision.
Noteworthily, I've made the devolopment version in MS VB, so if you
can't run that, you're gonna have to wait until a final version when I
translate it to C (or whatever prooves to be most suitable anyway).
PS. Looks kinda like that Unified model Beth was talking about :)

Is that model world standard compilant?

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

[Randall Hyde]

"Jure Sah" <ju******@guest.arnes.si> wrote in message
news:gc*******************@news.siol.net...

Randall Hyde wrote:

And while this example may seem silly, using this and an XML editor, it
becomes much more unlikely for you to end up with an out-of sequence
stack and any of the terrible consequences this usually brings. Not to
mention the segments can be labeled, making the program easier to read.
It really sounds like you're trying to create an XML version of the
fabled "BethTools" system (seach Google for details).

Google does not give any matches on that string.

Try a Google search on this very newsgroup.

And what's the point?

That it is more readable, easier to organize and change, prevent
doubling-up of work already done for other software and simpler to
costumize to serve another purpose.

Thus far, the examples really haven't demonstrated this.
Sure, I know what XML promises, but until you've got
a lot of code working in your system, it's hard to predict
what the impact will be.

As for preventing duplication of effort, I'm afraid you have
far too much faith in your fellow programmer's willingness to
switch from the way they now do things. All that will happen
is that you add yet another way to do things to the mix.
That's not bad, mind you, but...

I wish you all the luck in the world, but have you answered a
couple of important questions:

1. "Who is the audience for this product?"
Perhaps, as you later mention, also myself, but generaly it could be

either: 1. Any ASM programmer who wishes to keep his code readable and reusable.
There are *other* solutions, too.
Most of them don't involve a familiarity with XML as a prerequisite.
Considering the number of people around here who don't even know C
as an indication (and who refuse to learn it), I think you'll find you have
an uphill battle. Sure, when the system is fully functional, you'll be able
to claim that knowing XML is not a prereq, but I doubt many assembly
programmers would believe this (it's their nature to want to know how
things work "under the covers").
2. Anyone who does not have enough experience to be able to smoothly
read ASM code and can utilize a handy graphical representation of the code.

Again, the proof is in the final product.
It's a nice idea, but we shall see.
A better product would be something like ASMFlow that takes an
existing assembly program and produces the XML code that will
do what you want, without forcing its initial use on the programmer.
3. Any group of people working togather on one ASM program.
We can do that today, using standard tools.

2. "What is the purpose of this product?"
To provide a commonpoint for many diffirent programming languages, thus
create an universal devolopment environment of tools hand for the
devolopers and to make it up to globally accepted standards. For
example: Provide the advantages of using XML editors to ASM programmers.

Okay, but now you've got to convince everyone that this is a good idea.
I daresay that most assembly programmers wouldn't have a clue why
using an XML editor to edit assembly is a good idea (I sure don't).

3. "Why would someone use this product over other assemblers (or HLLs)?"

Pointless question, I think those who are used to other assemblers or
HLLs and find XMLc usable will be in fact using both (since XMLc
produces code, not binaries). But I suppose the prospect of being
object-orientated, internet-level portable and compilant to world
standars, without making sacrafices on the effectivness of the code
itself has got to attract some attention.
But after the initial attention, who will use it?

HLA, for example, was designed to support beginning assembly
language programmers. That completely answers the three questions above.
What benefits are you proposing? Being able to edit your assembly

programs with an XML editor isn't a great turn-on to most programmers around

here.
And you speak for all of them?
Based on my experiences with the programmers around here,
I probably speak of (rather than 'for') most of them, yes.
The point of that refference was that if everything is somewhere on the
internet, and compilant to world standards, it is easy to use and does
not have to be re-made. XML is also a language that enables you to put
various kinds of information that various diffirent programs will be
using, contextfully, in the same XML file. Being XML compilant you gain
a lot and being able to utilize a language on top of another that gives
you standard-compilance also means that the information stored within
your code is:
1. Manipulatable with any XML compilant editor
2. Readable by any XML compilant reader (which may include several
applications not interested in the ASM code within)

So being XML compilant alone has a point.

Sure.
But will other people accept that point.
That's all I'm asking.
Cheers,
Randy HYde

[Beth]

Percival wrote:

PS. Looks kinda like that Unified model Beth was talking about :)

Well, if it _looks_ like that, then I assure you "appearances are
deceptive" because what Jure is doing here seems to be different...kind
of...there is a similarity in catering for "object-orientated assembly" BUT
that's about as far as it goes, I think, because the "approaches" being
taken appear quite dissimilar to me...Jure is using that whole XML thing
and the subject line says "pre-assembler" (what Rene would call a
"pre-parser" ;) and about using XML editors, so the approach seems very
different...

In essence, we're just going for "hierarchical labels" with the
"block-structured" mechanism...and we're only really adding "{}" to
otherwise ordinary NASM-like assembly code...this XML thing doesn't appear
to be quite as "simplistic" as that from the examples...

Beth :)

[Beth]

Jure Sah wrote:

2. XML is more globally-accepted as a type simmilar to to
object-orientated text, which leaves you with the poitential of using
graphical-representation tools to display a finnished ASM program,
allowing you to more easily explain the structure of your program to
people who are not yet fammiliar with your code and require to be. I
wonder if vi or emacs can do that. ;)

Graphs!!! Of course!! Graphs!!! Why didn't I think of that? Graphical
structural representations...thanks for the suggestion! ;)...

[ snip ]

PS. Looks kinda like that Unified model Beth was talking about :)

Is that model world standard compilant?

<response>
<kidding>
No, it doesn't suffer from being "ruined by committee" in being forced to
be rooted to 1960s technologies for "backwards compatibility" with ENIAC
and so forth ;)
<sarcasm>
XML, you say? Oh, yeah...that's those plain text files littered with
strange punctuation characters, isn't it? Ah, yes...ASCII plain text that
has, for once, a bit of "self-discipline" in its structural
presentation...very "high technology"...they'll be inventing ".ini files"
or something next...
</sarcasm>
</kidding>
<signature>
Beth :)
</signature>
</response>

[Percival]

On Fri, 04 Mar 2005 14:04:58 +0000, Randall Hyde wrote:

Again, the proof is in the final product.
It's a nice idea, but we shall see.
A better product would be something like ASMFlow that takes an
existing assembly program and produces the XML code that will
do what you want, without forcing its initial use on the programmer.

Hmm, sorta reminds me of web and tangle and Knuth's "Literate Programming"
idea. I never tried ASMFlow...

Perhaps the xmlweb program will translate xml to some sort of graphic? And
tangle will be the extractor of the assembly data so you have 3 versions
of the source, 1 you wrote, 1 that is a picture painted by XML, and 1 is
the one that will be compiled.

Meh, literate programming in assembly... Lol. It could work, but I have
yet to see it. (Other than abundance of comments, but thats not exactly
the same)

Percival

[Evenbit]

Jure Sah wrote:

[lots of stuff about an XML-based ASM with graphical, networking, and
machine-independence characteristics]

From my understanding, there are already tools that let you design

software by drawing a flowchart (and here I thought flowcharts became
obsolete along with punchcards) and generating the appropriate source
for your chosen language. Aren't these called CASE tools? If you are
designing for platform-indepedence and using CASE tools, then you are
working at a high-abstraction level -- assembly language has no place
in this environment. Assembly hugs the machine-dependent, low-level,
non-abstraction style side of the programming scale so it would be a
very poor choice for the output of a Flowchart Development Environment
based on networking and platform-independence. Also, where on this
Earth (outside of Redmond, Washington) are you going to find
programmers who willingly severly criple their applications by making
them dependent on code only available on the internet?

Nathan.

[Jure Sah]

Beth wrote:

Graphs!!! Of course!! Graphs!!! Why didn't I think of that? Graphical
structural representations...thanks for the suggestion! ;)...

Is that also sarcasm? I posted the idea of graphs months ago, my
previous attempt was labeled the "MoonLink" program. This one will be
finnished, just give me 2 hours of free time darnit. =P

PS. Looks kinda like that Unified model Beth was talking about :)

Is that model world standard compilant?

<response>
<kidding>
No, it doesn't suffer from being "ruined by committee" in being forced to
be rooted to 1960s technologies for "backwards compatibility" with ENIAC
and so forth ;)
<sarcasm>
XML, you say? Oh, yeah...that's those plain text files littered with
strange punctuation characters, isn't it? Ah, yes...ASCII plain text that
has, for once, a bit of "self-discipline" in its structural
presentation...very "high technology"...they'll be inventing ".ini files"
or something next...
</sarcasm>
</kidding>
<signature>
Beth :)
</signature>
</response>

Well at least you asured that the average kid-with-Aspergers will be
able to understand your, to them un-obvious kidding and sarcasm
combination. And the same goes for just about any other XML-compilant
computer program out there.

BTW, all the software our company works with uses plain text to save
settings and communicate... it's only logical to have it this way (even
with those BASIC52 chips and whatever resident interpreters one might be
using with tiny EPROMs). Having a world standard for that only begs to
become compilant as soon as possible and I think all programmers should
understand why that is good.

I doubt you may speak of the same amount of experience as I do in this case.

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

[Jure Sah]

Evenbit wrote:

From my understanding, there are already tools that let you design
software by drawing a flowchart (and here I thought flowcharts became
obsolete along with punchcards) and generating the appropriate source
for your chosen language. Aren't these called CASE tools? If you are
designing for platform-indepedence and using CASE tools, then you are
working at a high-abstraction level -- assembly language has no place
in this environment. Assembly hugs the machine-dependent, low-level,
non-abstraction style side of the programming scale so it would be a
very poor choice for the output of a Flowchart Development Environment
based on networking and platform-independence. Also, where on this
Earth (outside of Redmond, Washington) are you going to find
programmers who willingly severly criple their applications by making
them dependent on code only available on the internet?

I suppose you haven't considered the purely electronic relevance of flow
charts to Assembly language? It's the (C style) abstractions inbetween
that make it inefficient or OS dependend, smart coding and/or
object-orientation is irrelevant to that. My XML compiler does not bind
with such abstractions unavoidably.

And who said anything would be dependand on code only avaliable on the
internet? I said it was merely an option, the internet is nothing but a
big filesystem from the XML point of view and it allows for ease of
sharing, that's all.

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

[Jure Sah]

> Coming soon! Like... tommorow! Now I got to go to bed. =P

Almost in a day. *g*

Here it is:
http://dustworld.dyndns.org/xml/XMLc.htm

Enjoy.

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"None felt feline, so I discounted copycat syndrome..."
-- Ghost Song

[Beth]

Jure Sah wrote:

Beth wrote:

Graphs!!! Of course!! Graphs!!! Why didn't I think of that? Graphical
structural representations...thanks for the suggestion! ;)...
Is that also sarcasm?

No; You quite seriously made me realise something I hadn't yet
considered...my "mindset" was elsewhere that I'd not considered graphical
representation...

Though, this is well "beyond the scope" of LuxAsm so it won't have anything
to do with that (more an "idea for the future"...a possible "plug-in" for
LuxAsm, well into the future?), the idea of a "CASE tool"-like graphical
representation for an extended kind of "visual programming"...that's a
brilliant kind of idea...

Not an ounce of sarcasm whatsoever...really...I _meant_ every single one of
those over-used exclamation marks!!! ;)
I posted the idea of graphs months ago, my
previous attempt was labeled the "MoonLink" program. This one will be
finnished, just give me 2 hours of free time darnit. =P
Ah, you've cross-posted this...did you post the "idea of graphs" here (in
the assembly language group) or the XML group? If it was actually here,
then, sorry, I must have missed that...or perhaps I did read it but, you
know, wasn't in the right "thinking mode" to realise properly what I was
reading (reading while half-asleep or something ;)...anyway,
yeah...basically, you might have posted it months ago but, well, it was
"news" to me personally, even if not for others who were paying attention
where I wasn't :)...

PS. Looks kinda like that Unified model Beth was talking about :)

Is that model world standard compilant?

<response>
<kidding>
No, it doesn't suffer from being "ruined by committee" in being forced to be rooted to 1960s technologies for "backwards compatibility" with ENIAC and so forth ;)
<sarcasm>
XML, you say? Oh, yeah...that's those plain text files littered with
strange punctuation characters, isn't it? Ah, yes...ASCII plain text that has, for once, a bit of "self-discipline" in its structural
presentation...very "high technology"...they'll be inventing ".ini files" or something next...
</sarcasm>
</kidding>
<signature>
Beth :)
</signature>
</response>

Well at least you asured that the average kid-with-Aspergers will be
able to understand your, to them un-obvious kidding and sarcasm
combination.

Glad to be of service! :)
And the same goes for just about any other XML-compilant
computer program out there.
Really? Would you care to explain the purpose of "cascading style sheets",
ECMAscript and such in the context of "XML-compliant" XHTML files being
"universally perfect" in all regards?

To require the physical separation of "content" from "presentation" by such
means to allow encapsulated modular development would suggest a deficiency
with regard to the facet that "XML-compliant" documents lack a means of
distinction between source layout and physical layout, which mandates the
physical separation of these two aspects in order to support a more
practical development regime, where "content" and "presentation" are best
dealt with individually...as a typical web-based regime would maintain
"content" somewhat independently from the web-site presentational "look and
feel" style...

And ECMAScript would further suggest an XML deficiency in its lack of a
coherent dynamic model, being solely a static data declaration
facility...an aspect that would be highly relevent and challenging to your
use of a static medium for representation of dynamic quantities...or, in
other words, I'd Love to see how you'd deal with "self-modifying code" in
your XML-based scheme...a bit of a "gotcha", eh?

Although, of course, I'm merely an idiotic philastine with no appreciation
of the obscure subtleties of your vast experiences in this field...so, I
defer to your clear siccophantic over-enthusiasm to the latest "fad" and
"fashion", as it is surely automatically the "authoritative source" by its
implicit, "modern" popularity and the publication of profit-orientated
texts that reflect such an attitude...

[ Ah, if only "tags" weren't inconveniently forced to be "inline" then I
could have added the "<sarcasm></sarcasm>" tags retro-actively to that last
paragraph, eh? But I wouldn't want to be non-XML-compliant in your
presence...oh, well...I can always apply a CSS template ("sarcasm: true;"
:) to it later, I suppose ;) ]

"Few people are capable of expressing with equanimity opinions which differ
from the
prejudices of their social environment. Most people are even incapable of
forming such
opinions."
[ Albert Einstein ]

"Reading, after a certain age, diverts the mind too much from its creative
pursuits. Any man who reads too much and uses his own brain too little
falls into lazy habits of thinking."
[ Albert Einstein ]
BTW, all the software our company works with uses plain text to save
settings and communicate...
Oh, well...so long as it's "popular", then it must be right...

You know, like how the German people voted Hitler into power...or how
people used to believe in a "flat Earth" and "sea monsters" very popularly
too, so they must have been factually correct by sheer force of numbers of
"true believers", yes? ;)...

Why, indeed, Microsoft are clearly a superior software company or they'd
never have become so "popular"...ignore the rumours that it's through
monopolistic anti-competitive practices, "bundling" deals for pre-packaged
unfair advantage and being found _GUILTY_ of bribery charges regards these
exact practices in an American court of law...

Just like McDonald's are clearly where they are for providing good quality,
highly nutrious "health" meals with supreme levels of customer
service...rather than, you know, just being the most "cheap and cheerful"
on the market, scooping up spotty teenagers dirty cheap from unemployment
queues at slave wages to shovel tasteless "soggy cardboard" French fries
down our throats...

Bart: I was wondering, how important is it to be popular?
Homer: I'm glad you asked, son. Being popular is the most important thing
in the world!
[ From episode "the tell-tale head", the Simpsons ]
it's only logical to have it this way (even with those BASIC52 chips
and whatever resident interpreters one might be using with tiny EPROMs).
Ah, that's a highly obscure, completely-irrelvent-to-the-context reference
there...so, by extension, you _MUST_ be very intelligent and experienced!
Now, _that_ is the popular-brand of "logical" for you ;)...

What's "logical" about it? ASCII is a _BINARY_ format, in the end, just
like any other...indeed, it's only strictly defined in 7-bits, so the 8th
bit is an ambiguous mystery...the control characters aren't universally
interpreted or even applicable to most contexts...Windows / DOS is
character return line feed, UNIX is line feed, Apple Mac is character
return...goodness knows what "line feed / character return" is supposed to
mean on any of them!

I mean, when you say "plain text", do you mean ASCII, ANSI, ISO, code page
#8596, IBM's "box drawing" character set (of which there are two versions),
Japanese double-byte character set, UTF-8, UTF-16, UTF-32, UCS-2, UCS-4,
Shift-JIK, EBCDIC, etc., etc....?

Yeah, what a great "world standard"! On the contrary, Jure, perhaps it's
you who needs to be using the "<sarcasm></sarcasm>" tags here ;)...
Having a world standard for that only begs to
become compilant as soon as possible and I think all programmers should
understand why that is good.
Oh, for frack's sake...it's an ASCII file with a few ugly, verbose "<tags>"
inserted into it! It's NOT Edison inventing the lightbulb or
anything...*sigh* snow to the bloody eskimoes, I tell you, it's just snow
to the eskimoes...

"World standard"? Yes, the _AMERICAN_ standard code for information
interchange is such a useful "world standard" for the third of the entire
human population in China who speak Mandarin Chinese...bloody hell, English
_originates_ from this very isle and I can't even find our currency symbol
there...

Yes, indeed, it _NEEDS_ to "beg" to become a "world standard" because it's
not going to get anywhere on "merit", that's for sure!

"I think all programmers should understand why that is good"? Well, stick
around a little longer...some programmers have seen _PLENTY_ of "useless
fads" pass, like water round the U-bend...and comprehend when yet another
useless fudging limited "standard" that'll still be haunting us three
decades later is about to be formed...

It's NOT a "technology"...and certainly not "new"...it's just a fracking
ASCII file with some "self-discipline" applied to its structure! I think
all programmers, for sure, will understand why that's hardly worth getting
over-excited about...after all, what you think most source files for
programs _are_ exactly?

Wow! "Hierarchical .INI files"! Woo-hoo! Just what the software industry
needs: Even more _REGRESSION_ back to the Stone Age!! Woo-hoo! They'll be
"inventing" punch cards and "type in listings" all over again next!

Most computer "standards" these days are solely successful at demonstrating
how disorganised and disagreeable the industry is to do anything
_properly_...not when there's "cheap and cheerful" awaiting around a
corner!
I doubt you may speak of the same amount of experience as I do in this

case.

Yeah, of course...it's "logical" enough, right? You are "god" (you have a
paper certificate to prove it! :) and I disagree with you...so, I'm clearly
"ignorant"...stands to reason...you must forgive my smaller, puny female
mind for its stupidity in believing it could form an independent
opinion...and, yes, the "sarcasm" sign is being lifted high, so as to
"assist" you in comprehending basic "world standard" human communication,
"Einstein"...

It would be "vulgar" to simply counter-list over 20 years of experience,
immersed in the practice from childhood that I live and breath the subject,
could entail...and would prove fruitless, as, of course, the underlying
point is that _quality_ counts, not quantity, anyway...so I'll spare you
the indignity...

"An error does not become truth by reason of multiplied propagation, nor
does truth become error because nobody sees it."
[ Mahattma Gandhi ]
Beth :)

[Betov]

"Beth" <Be*********@hotmail.NOSPICEDHAM.com> écrivait
news:Ra****************@newsfe4-gui.ntli.net:

Jure Sah wrote:

Beth wrote:

> Graphs!!!

By the way (while talking of stupid toys... :))

I seem to recall that the origin of the graphing
Tool of IDA (was it IDA?...) was "stolen" from a
GPLed ancestor, or something like this.

Does someone know if this is true? If yes, where
is that original GPLed Graph thingie Page located?
(i am 75% sure i really saw it, in the past...).
Betov.

< http://rosasm.org/ >

[Alex McDonald]

http://dustworld.dyndns.org/c:/xml/default.xml isn't XML.

--
Regards
Alex McDonald

[Evenbit]

Jure Sah wrote:
[snip]

I suppose you haven't considered the purely electronic relevance of flow charts to Assembly language?
Actually, I have. Not actually flowcharts, but rather boolean algebra.
Either grab an introductory digital electronics text from the local
university library or take a look at Volume 2, Chapter 3 of the 32-bit
version of Art of Assembly <http://www.artofasm.com> to discover a very
Natural Language-style, very logical, programming language.

[snip] And who said anything would be dependand on code only avaliable on the internet? I said it was merely an option, the internet is nothing but a big filesystem from the XML point of view and it allows for ease of
sharing, that's all.

A "big filesystem" that isn't always reliably connected. :)

Nathan.

[Evenbit]

Evenbit wrote:

Actually, I have. Not actually flowcharts, but rather boolean algebra. Either grab an introductory digital electronics text from the local
university library or take a look at Volume 2, Chapter 3 of the 32-bit version of Art of Assembly <http://www.artofasm.com> to discover a very Natural Language-style, very logical, programming language.

I forgot to mention something that _is_ closer to flowcharting...

Ladder Logic and Programmable Logic Controllers.

For an introduction to ladder logic:

http://www.ibiblio.org/obp/electricC...al/DIGI_6.html

And ladder logic simulators:

http://www.tri-plc.com/trilogi3.htm
http://world.keyence.com/topics/plc_...ing/logic.html

Nathan.

[Beth]

Evenbit wrote:

Jure wrote:

And who said anything would be dependand on code only avaliable on
the internet? I said it was merely an option, the internet is
nothing but a big filesystem from the XML point of view and it
allows for ease of sharing, that's all.

A "big filesystem" that isn't always reliably connected. :)

<bad joke>

"mount /dev/internet"

Nope; It's not working...

They obviously haven't written a "file system driver" for the internet on
UNIX yet or something ;)...

</bad joke>

Beth :)

[Beth]

Rene wrote:

Beth wrote:

Jure Sah wrote:

Beth wrote:
> Graphs!!!

By the way (while talking of stupid toys... :))

I seem to recall that the origin of the graphing
Tool of IDA (was it IDA?...) was "stolen" from a
GPLed ancestor, or something like this.

Ah, I think you'll find it was a fellow Frenchman - Descartes - who
implicitly "invented" graphs when he came up with his "Cartesian
co-ordinate system"...apparently, he wanted to track the path of a fly
buzzing around in his tent, of all things...I don't believe he took out any
"patents" on the concept ;)...

Beth :)

[\\\\]

På Mon, 14 Mar 2005 04:48:14 GMT, skrev Beth
<Be*********@hotmail.NOSPICEDHAM.com>:

Evenbit wrote:

Jure wrote:

> And who said anything would be dependand on code only avaliable on
> the internet? I said it was merely an option, the internet is
> nothing but a big filesystem from the XML point of view and it
> allows for ease of sharing, that's all.
A "big filesystem" that isn't always reliably connected. :)

<bad joke>

"mount /dev/internet"

Nope; It's not working...

They obviously haven't written a "file system driver" for the internet on
UNIX yet or something ;)...

</bad joke>

Seem to me a serious sign of decay, when you prefer posting HTML in an asm
NG, as supposed to posting some of your private work. Hows LuxAsm going
Beth ?

Any progress on SourceFrauds ?

Project UNIX name: luxasm
Registered: 2004-01-20 18:30
Activity Percentile (last week): 0%

View project activity statistics
(Better not, too depressing, they havent done zilch in MONTHS)

Beth :)

--
I am shy

[Beth]

Alex McDonald wrote:

http://dustworld.dyndns.org/c:/xml/default.xml isn't XML.

And, picking up on much the same point, on the website Jure linked to, he
says:

"'<br></br>' indicate a linebreak, where your code requires it."

It is quite possible to have "lone" tags in XML, which should take the form
"<br/>"...and is equivalent to "<br></br>" but less typing...

Whereas, the lone "<br>" without an end tag in the page Alex just linked
to? Invalid XML, sorry...all start tags _MUST_ have an end tag unless in
the "<tag/>" form, which indicates it's a "lone" tag...

If XMLc produces or accepts that lone "<br>" tag like that, then it isn't
really "W3C XML compliant"...you do ask on the website that you be
informed, if this is the case...I've only taken a quick glance, though,
just because of Alex's post here...if I find anything else "problematic",
then I'll let you know...

Beth :)

P.S. Unrelated to the XML, that webpage could do with a "spell check"
too...you've got "this is only the devolopment version of the
compiler"...that should be "development" rather than "devolopment", yes? :)