Lattice vs. Manx
28 messages in this thread
I won't argue with you… <grin>
Sure, I like to see all this stuff discussed into the ground. While I'm
yelling, I'm learning, all the time. I've never heard an argument for ILAC
that was worth rabbit urine, but most of the other issues I just like to
discuss amd hold up as dartboards.
Incompatability is the least of ILACs evils… there are tens of others,
really a bunch. As for #pragma, you never saw that in MY code! <grin> Nor
that totally idiotic define binary Lattice has, which, if if weren't so
obscure as to be totally unusable, would be worse than ILAC is. At least
ILAC is a language of SOME kind!
I don't remember what the cmd was to do that (the inlline binary) but I'm
sure someone will point it out. Kind of funny, in all this mumbling about
code wars, Mike never pulled that out of his hat – it's more potent than
any of the other stuff he's said.
So I like to argue. <grin>
Ben
Amateur Radio Callsign is A A 7 A S
Since you've reminded me of the inline binary trick, I'll pass along a bug
in Manx 5.0 that makes it darn near unusable… it has to do with
expressions within array subscripts. It chokes on anything more complex
than a variable itself, I think it has to do with array subscripts on
arrays within structures, something like that.
So I'd say if you're really going to complain about non-portability, then
say so, and fight the other dragons, too… otherwise Lattice *will* add
ILAC, just to make you quiet down. 🙂
Bugs… I don't really have a problem with. They get fixed, it wasn't
intentional, and just generally they are a non-issue – they happen, in
other words. I tend to carp about "features" rather than bugs… a _good_
company will have bugs fixed before you ahve a chance to get really
irritated.
And I'm not complaining about non-portability in relation to ILAC. I'm
compliaining about that combined with non-supportability, as in it's
difficult to maintain and more difficult to explain to a new person who is
supposed to maintain the source. There are numerous issues, all of them
valid… the rationale for using ILAC, the _valid_ one that is, is lazyness
in incompetance.
COmpatability, re Manx <-> Lattice is an issue, and my feeling is that
there is an Amiga standard, as was true when Manx introducxed their
product. They choose not to follow it, and so locked themselves out of a
lot of use they would have otherwise gotten. ILAC is just a side issue in
that comparison, but is a strong indication to me that Manx, as a company,
doesn't understand programming and are just in it to sell product.
Ben
Amateur Radio Callsign is A A 7 A S
When you have to throw away something useful for the sake of
'compatability', then perhaps the value of such compatability should be
questioned. As it was, the amiga object format (ALink format, if you will)
was pretty useless for our needs, so we used our own format. Funny thing,
Lattice found it pretty useless as well and added numerous extensions to
make _it_ incompatible w/ ALink. So you should be screaming at Lattice
just as loud as with us, 'cause they broke the Amiga standard here as well.
As for not understanding programming, well I'd be intereted in hearing your
basis for that. And if it has anything to do w/ ILAC, well then I think
we'd all know who has problems understanding things….
-Mike
Yes, it has to do with ILAC, and yes, we know who has the problem.
You.
Ben
Amateur Radio Callsign is A A 7 A S
Mike,
There is a world of difference between "extending" a standard and
totally rewriting a standard. Lattice's object format changes were
evolutionary, in that "old format" object files would work fine with the
new, extended format. Their evolved linker worked with any objects
conforming to the new standard.
Manx's creation of the alternate standard, however, took things in a
totally different direction. Didn't work with anyone else's linker, nor
could you do mixed-language development very easily. IMHO, it is because
of Manx's departure from the original Object-file standard that the Amiga
world is a real Tower of Babel, with little capability to combine the
various programming languages into a single, multi-language project.
Your statement that Lattice "broke the Amiga standard here as well" is
taking things a bit far. Do you consider the changes Manx made in 5.0 to
have "broken the Manx standard"? After all, programs written for 5.0 can't
be compiled by 3.6. To my way of thinking, that's just an evolutionary
growth, much the same as Lattice's _gross distortion of the Amiga object
format standard_.
…BobR
Making a teeny-weeny, itsy-bitsy change to the Amiga object format is
enough to make what you're doing incompatible with everything else. It was
just as impossible to link Lattice object modules using ALink as it was to
link Manx object modules. Even though Lattice modules were 95% there (or
more), that 5% extra was enough to make it unlinkable, and nothing you
could do would make it linkable. So tell me how Lattice didn't break
anything?
-Mike
Mike, Lattice ships BLINK, which links the object from old lattice, with
new lattice, with asm, with etc ad nauseam. Except for Manx, of course. :^)
So, while they may have extended things, they made SURE that the extension
only brought advantage for their users, and didn't "break" anything. You
guys started OUT broken, and slowly became somewhat non-broken. Totally
different situation, and guess who did it right? Not Manx!
Ben
Amateur Radio Callsign is A A 7 A S
Mike,
At the same time that Lattice extended the Amiga object format, they
also extended (significantly) the Amiga object linker (except that they
didn't call it ALink, they called it BLink). Gee, this extended,
evolutionary linker was a full replacement for the original ALink, plus
they significantly enhanced the performance (which was disgraceful with the
original ALink). Your argument doesn't hold water. Sorry.
…BobR
'expressions within array subscripts' Fixed in 5.0b, which will be
available very soon (disk dup is already under way…)
-Mike
Sounds good… what do I have to do to get this update?
You should be automatically notified by mail when it's available. (assuming
you're a registered user – if not, send in your registration card!)
-Mike
Mike,
I JUST received mny 5.0a update. Am I registered, or do I need to send in
the card?
Marcus
You should send in the card, just to make sure.
-Mike
Thanks.
Marcus :^{
One other bug I noticed today. 5.0's 'ls' command is malfunctioning when
it comes to dates, when you say 'ls -l'. For instance, AmigaDOS "LIST"
tells me a file date is March 13, 1990, while your 'ls' tells me the date
is March 13, 1982. One other suggestion: Why does 'cc' bother to tell me
the date and time of when 'cc' was created? Isn't the version number and
copyright line enough? With it removed, the notice would fit on one line,
which would look nicer.
John,
Manx's ls thinks everything on my hard drive was created in 1982 also, so
I just use one of the other 5 or 6 or 7 or … versions of ls ;^).
Peter_S (LeCroy Corp)
"Software means never having to say you're finished"
Known problem – ls dates are 8 years off. This is fixed for the next
rev….
Actually, the compiler startup string uses the ANSI __DATE__ and __TIME__
macros to signify the date/time when it was built. I'm not entirely sure
why __TIME__ was included in the signon myself, as knowing down to the
hundreths of seconds is a bit of overkill. Any one else care either way?
-Mike
I'd say blow them both away… it's not something I need to know. Or, add
a new secret command line option that prints them. Every other product I've
seen is content to display a "3.1" style version number.
I think I'd prefer the date/time the product was made over some number
arbitrarily assigned by a marketing department. I know that the consumer
has been taught to like "3.1" style revision/version identifiers, but
given that no (generally) useful information is available (other than 3.2
_should be_ > 3.1) other than which is more recent, I suspect that
date/time stamps are as useful. Note that date/time stamps are generally
applied automagically by computers, and therefore not likely to be
'accidently mismanaged'.
Victor A. Wagner, Jr.
Come on, we're talking about a product release here, not some hack that's
crafted and recompiled every ten minutes! If Manx can't manage
incrementing the minor number of a version number, or adding an 'a', 'b' or
'c' as appropriate, and/or if they can't keep track of which version went
out when, not to mention the INCREDIBLE hassle it must be to ship out
updates and notices to thousands of people, then they're in big trouble,
and all Manx users are in big trouble. Regardless of what Ben says, :-), I
don't think we're in big trouble, and I'm sure Manx is capable enough to
handle some minimal version control.
John,
I wasn't suggesting that Manx was 'some hack' (I'll leave that to Ben).
Nor was I decrying the 'difficulty' of maintaining version control on a
product (although my experiences in the past with LARGE projects indicate
that it IS a hassle). I was just attempting to point out that Nature has
already given us a mechanism for 'automatically incrementing' a number to
be used for revisions. We even consider this mechanism SO useful that we
make it virtually automatic on all computers in use today. The mechanism
is 'time' (and of course, the date). I fail to see the significance of a
revision system which uses numbers like 5.04 in preference to numbers like
900510.1909.
Victor A. Wagner, Jr.
"Time is Nature's way of keeping everything from happening at once."
What is that, Vic? A Julian date? (hey, I like that! I think I'll start
using Julian Dating for my revision/version numbers!!) –Eet–
If you note the date on some of the early InterFont disks, you'll see we
made them on Christmas day. Another module was released on my birthday. I
think the time stamp is fine, it could be embedded in some other way, or
accessed through a command line option, but 99.9999 percent of the time I
compile, I DON'T WANT TO SEE IT. OK? 5.04 is symbolic enough for me.
Incrementing from 5.0a to 5.0b is not a big hassle at all. However,
putting a date stamp (a time stamp is a bit much) on the compiler is
extremely useful. As a case in point, Lattice accidentally shipped two
versions of 5.04, both of which said '5.04'. In cases like this, having
the compiler give the actual date it was built helps to sort out exactly
what's what. Using the date of the compiler's file isn't generally enough,
since that's easily changed/munged.
-Mike
I'm well aware of those problems! What I'm saying is, Manx 3.6 gives one
line of copyright text, and Manx 5.0 gives two! You're telling me it's
suddenly become important for Manx to know when a version was created?
Look, this is a tiny issue, it annoyed me, and I'd thought I'd tell you.
It's not Lattice vs. Manx, at least…
Yes, 3.6a gave only one line, and 5.0a gives two. However, 3.6a _still_
contained the date it was created, so I don't see where you're coming from
at all. If you don't want to see the signon message at all, then use the
-qq option – that's what its there for. Also, version 5.0b will _not_ have
the time, but only the date, and the signon will be only on one line.
-Mike
Mike,
Given a choice, I prefer no signon at all. I know what I'm running and it
just makes the interesting part of the display (what went wrong) scroll off
the screen faster. A command switch to display license info is just fine.
Peter_S (LeCroy Corp)
"Software means never having to say you're finished"