one definition of scalar types 
Author Message
 one definition of scalar types

Quote:
> >Michael van Acken a crit:
> ... I did not consider it worthwhile to quote
> it.  Our priorities differ only in some small details, e.g. I expect
> to have a single set of X11 modules for all target platforms, and I
> expect Tim's VisualOberon library to run on all platforms _unchanged_.

You didn't disagree with the fact that OOC does not have any
source base compared to many applications available for the Oberon System.

What applications for OOC do exist now -- except uxcalc and VO?

Quote:
> Therefore OOC puts a much higher priority on not breaking interfaces
> to external (i.e., non-Oberon) parts of the system.  You are sitting
> in your Oberon System cubicle, isolated from the rest of the world,
> celebrating your success.

Wrong! AOS interfaces to 32 bit X11 and to the operating system API.
A2O runs within AOS and stand-alone (with a traditional linker).

Quote:
> OOC needs to integrate with the rest of the
> world, which leads to a different goal and, consequently, different
> design decisions.

I disagree.

Quote:
> Not surprisingly, OOC has reached its goal as well.  So there is
> little need for repeating how well we have done ;-)

Great! Congratulations.

Quote:
> I don't make this distinction.  When I talk about extensions for 64
> bit system, I do mean a 64 bit compiler on a 64 bit machine.

This is not clear from reading your discussions.

Quote:
> > If you need compatibility with existing code, you have to be
> > careful.

> Our code is 100% portable.  This is sufficient for me.

The many applications developed for the Oberon System are portable
within V4 or S3.

Your library is incompatible with other oberon compiler implementations.

The part of your library which is based on the iso m2 lib is not
interface compatible with the iso m2 lib. You even changed
some module names (LRealMath -- n'est pas? is LongRealMath too long?).

Quote:
> Does this code is guaranteed to work for your compiler?

>   ASSERT (SIZE (LONGINT) = 4)

why should it?

In AOS, where LONGINT is _always_ 64 bit, I'd write

  ASSERT (SIZE(LONGINT)=8)

which would not "work" with your compiler.
Only stand-alone A2O gives the choice between 32 or 64 bit LONGINT.

Quote:
> No, it will sometimes work and sometimes not.

as I explained, this is wrong!

Quote:
> ... Yes, I do see your point. No, I do not consider it important.

a politician could not have expressed it better?

Quote:
> After all, the basic idea of SYSTEM is to be system dependent.

yes, but there is no need to introduce artificial incompatibilities.

Quote:

> > >The result type of SYSTEM.ADR is SYSTEM.ADDRESS.  On 32 bit systems
> > >this is an alias to LONGINT, on 64 bit systems an alias to HUGEINT.

> > This is a language change and it breaks existing code.
> > You'd need a variable of type HUGEINT.

> No, you need a variable of type SYSTEM.ADDRESS.

So I'm right and your "No" is wrong.
You said above that SYSTEM.ADDRESS is a synonym of HUGEINT.
So why is it wrong to use a HUGEINT?

Quote:
> A rather trivial
> change, with the additional benefit of marking a system dependent
> piece of code.

Nevertheless, you'd need to make a modification which is avoidable.
And the "piece of code" is already marked system dependent by SYSTEM.ADR()

Quote:
> Unfortunately, your "maximal compatibility" is rather minimal in the
> context of OOC.

Because compatibility was not your goal.

Quote:
> We need to interface cleanly to C code, which
> precludes any "magical" changes to the size of basic types.

In AOS is no magic change of basic types.
The type sizes are fixed.
LONGINT is always 64 bits.

But you could recompile the oberon system and its applications and tools
with 32 bit LONGINT if you wanted. However there is no need to do so.

Quote:
> I am very happy for you.  I only have two gripes with your concept.

> 1) It is not in the spirit of the language (you know, "Keep it as
> simple as possible").

You did not explain where our concept is not simple.

Let me repeat: LONGINT is always 64 bit in AOS.
It's a 64 bit system on a 64 bit machine.
But it compiles 99% of the existing modules [developed for
32 bit compilers on various platforms] for OSV4 without
any change. And any non-low-level application developed
with AOS would be backward compatible with 32 bit compilers --
and I do not consider a module using SYSTEM.ADR() as low-level,
only because it is imported from SYSTEM.

Our design is both portable and compatible
and due to the integration in the Oberon System,
the compiler offers superior functionality
(not only metaprogramming and fine grained object files).
For more details, visit the AOS home-page at http://www.*-*-*.com/

Why is it not in the spirit of the language report when one sticks
to its specification?

The fact that you needed the famous "not in the spirit of" argument,
which was also often used by some members of the the iso m2 committee,
shows me how weak your position is.

Quote:
> 2) It breaks too much.  E.g., the very same program cannot exchange
> binary LONGINT data between two instances of itself if the instances
> happen to be distrinbuted between 32 and 64 bit system.

wrong!
If you really need a specific integer type size,
simply use SYSTEM.SIGNED_32 and SYSTEM.SIGNED_64.

But it is not needed, because the Oberon System's lib allows you to
store any pervasive data type in system independent format.
As far as I know, this even works between big and little endian machines.

Quote:
> 3) It breaks communication to the world outside the Oberon System.

wrong!
In AOS you can call any system service, run-time library,
x11, motif, foreign language libraries, ...
in lower-level modules, exception handling, symbolic run-time
de{*filter*}, metaprogramming, .... And we used such calls in AOS
to implement the modules Display (based on X11), Unix, ...

Quote:
> > We are not pushing our language, because we did not make any
> > language change to Oberon-2.

> I am well aware that you are very convinced of your particular design.
> IMO your design is rather sick.

Same to you!
There is after all no point to defend our solution any longer.
At least not against someone who requires such words like
"sick" and "not in the spirit of".

Good luck and good bye!



Mon, 07 Jan 2002 03:00:00 GMT  
 one definition of scalar types

Quote:

> > Therefore OOC puts a much higher priority on not breaking interfaces
> > to external (i.e., non-Oberon) parts of the system.  You are sitting
> > in your Oberon System cubicle, isolated from the rest of the world,
> > celebrating your success.

> Wrong! AOS interfaces to 32 bit X11 and to the operating system API.

Why the restriction to 32 bit?

Quote:
> Your library is incompatible with other oberon compiler
> implementations.

Very perceptive of you, although you mix up compiler with library.
The OOC library does not live under the Oberon System (V4, S3, or
whatever).  It was never our intention to produce yet another Oberon
System.

Quote:
> > Unfortunately, your "maximal compatibility" is rather minimal in the
> > context of OOC.

> Because compatibility was not your goal.

Please keep your presumptions to yourself.  I do not like to be called
a liar.  Let me repeat again: your definition of compatibility is
insufficient in the context of OOC and its working environment.  The
keyword here being "context".

Quote:
> [...] I do not consider a module using SYSTEM.ADR() as low-level,
> only because it is imported from SYSTEM.

Now I am curious.  What do you declare low-level, and therefore not
worthy of your attention?  Address arithmetics and memory accesses
through such self-computed values seems very low-level to me.

Quote:
> > 2) It breaks too much.  E.g., the very same program cannot exchange
> > binary LONGINT data between two instances of itself if the instances
> > happen to be distrinbuted between 32 and 64 bit system.

> wrong!
> If you really need a specific integer type size,
> simply use SYSTEM.SIGNED_32 and SYSTEM.SIGNED_64.

I think we differ in our interpretation of "different systems".  I
believe you mean two different Alpha systems running your compiler.
On the other hand, with "different" I mean another Oberon system with
another compiler, possibly running on a different processor
architecture.

Quote:
> But it is not needed, because the Oberon System's lib allows you to
> store any pervasive data type in system independent format.
> As far as I know, this even works between big and little endian
> machines.

Yes.  There are always workarounds for your particular kind of
incompatibility.

Quote:
> > I am well aware that you are very convinced of your particular design.
> > IMO your design is rather sick.

> Same to you!
> There is after all no point to defend our solution any longer.
> At least not against someone who requires such words like
> "sick" and "not in the spirit of".

Please, don't get e{*filter*}d.  I am merely stating my point of view.  And
seen in the whole context of my previous posting, my words were not

mva> I am well aware that you are very convinced of your particular design.
mva> IMO your design is rather sick.  Slavishly sticking to the Oberon
mva> report's SYSTEM appendix does not make it sensible.  Therefore I want
mva> to point out that there are other ways to deal with this particular
mva> problem.

The last sentence still holds.  Let us finish this discussion with a
very short summary: there are at least two ways to deal with the
problem at hand, and both have their advantages and disadvantages.
This statement is obviously correct and vacuous enough, so we will
both be able to agree with it.

Regards,
Michael van Acken



Mon, 07 Jan 2002 03:00:00 GMT  
 one definition of scalar types
Hallo!

Quote:
>You didn't disagree with the fact that OOC does not have any
>source base compared to many applications available for the Oberon System.

OOC is much younger than the various Oberon Systems.

Quote:
>What applications for OOC do exist now -- except uxcalc and VO?

I have written a small number of programs (more or less usefull) as
part of VO. Sorry, I must earn my money with other things. It is up to
other people to add more applications. However I'm sure that this is
possible. Every new and possibly superior technic starts with no user
support and must find is place in the market. Because of that I don't
think that your argument is that valid at that state. Falling back to
existing traditions was always the argument of the non-open minded.

Quote:
>> Therefore OOC puts a much higher priority on not breaking interfaces
>> to external (i.e., non-Oberon) parts of the system.  You are sitting
>> in your Oberon System cubicle, isolated from the rest of the world,
>> celebrating your success.
>Wrong! AOS interfaces to 32 bit X11 and to the operating system API.
>A2O runs within AOS and stand-alone (with a traditional linker).

I do not doubt that, however I want to know if you can compile your
programms using X11 without interface or programm code changes when
your datatype sizes change as result of your type model?

Quote:
>> OOC needs to integrate with the rest of the
>> world, which leads to a different goal and, consequently, different
>> design decisions.
>I disagree.

That makes no sense. One of the authors of OOC states its goal while
devloping the compiler and you "disagree". What do you mean?

Quote:
>> Our code is 100% portable.  This is sufficient for me.
>The many applications developed for the Oberon System are portable
>within V4 or S3.

Once and for all. The Oberon Systems are a research product of various
universities to test new aproaches in operating system design. Cool
stuff. However the commerical effect is nearly zero, nothing.
Oberon(-2) is a general purpose language for developing nearly any
kind of applications on in theory many operating system. I want (and
from reading c.l.o many other people would like to, too) to use Oberon
for developing my real world applications. While I could use technics
developed as part of the various Oberon Systems I likely can not reuse
existing code, since it is not portable to real world. To reuse code
has to be rewritten, so 100% compability with existing oberon code is
of no interst for me. Oberon Systems are a dead end for my purposes.
That does not mean that you imediately stop development, it just means
our are on another mission. The goal of every research  must be the
retranslation of newly developed technics back to real world. This
results in adaptions. The official Oberon people have missed that
badly. They even do not support such retranslation, they even try do
stop such aproach with statements and non-acting like you do with your
news.

Quote:
>Your library is incompatible with other oberon compiler implementations.

Is there are such complete general purpose library under any
Oberon Operating system, which is not tied to exactly this system and
no other? Nice to have file routines when the cannot be maped to Unix
or Windows. Serves the purpose.

Quote:
>> Does this code is guaranteed to work for your compiler?

>>   ASSERT (SIZE (LONGINT) = 4)
>why should it?

>In AOS, where LONGINT is _always_ 64 bit, I'd write

>  ASSERT (SIZE(LONGINT)=8)
>which would not "work" with your compiler.
>Only stand-alone A2O gives the choice between 32 or 64 bit LONGINT.

Porting by rewriting. Sounds not like the optimal way.

Quote:
>> ... Yes, I do see your point. No, I do not consider it important.

>a politician could not have expressed it better?

No more arguments?

Quote:
>> After all, the basic idea of SYSTEM is to be system dependent.
>yes, but there is no need to introduce artificial incompatibilities.

We do not create incompabilities we react on them. Our incompabilities
or force due to the underlying plattform. We dit not for fun, we do it
because we must solve problems.

Quote:
>So I'm right and your "No" is wrong.
>You said above that SYSTEM.ADDRESS is a synonym of HUGEINT.
>So why is it wrong to use a HUGEINT?

SYSTEM.ADDRESS is *not* a synonym for HUGEINT. Come on as a compiler
implementor you should understand the concept. All one defines about
SYSTEM.ADDRESS is that it is maped to an nummerical value of unknown
size. So you can work with addresses (for example when you implement a
gc in Oberon) in a compatible way. However you cannot easily assign
addresses to number and vice versa. However why should you?

Quote:
>Nevertheless, you'd need to make a modification which is avoidable.
>And the "piece of code" is already marked system dependent by SYSTEM.ADR()

These modifications solve the problem once and for all. Why are you so
against code changes?

Quote:
>Because compatibility was not your goal.

Uh? I though you did it all in the name of compability?

Quote:
>Let me repeat: LONGINT is always 64 bit in AOS.
>It's a 64 bit system on a 64 bit machine.
>But it compiles 99% of the existing modules [developed for

Ah. You need to change 1% of your code to get it compile. Homuch of
the code you had to change to include the SYSTEM.ADDRESS language
extention. If it far more than 1% you cod eis badly written because it
makes yuse of SYSTEM all over the place.

Quote:
>Why is it not in the spirit of the language report when one sticks
>to its specification?

You can stick by word or by spirit.

Quote:
>The fact that you needed the famous "not in the spirit of" argument,
>which was also often used by some members of the the iso m2 committee,
>shows me how weak your position is.

Sorry. A would like a laywer more that decides in the spirit of a law
instead in the world of the law as long as it is the reals spirit.

Quote:
>wrong!
>In AOS you can call any system service, run-time library,
>x11, motif, foreign language libraries, ...

Ok. How does the interface looks like. Does it change when switching
to another machine, OS?

Quote:
>Same to you!
>There is after all no point to defend our solution any longer.
>At least not against someone who requires such words like
>"sick" and "not in the spirit of".

Sorry, your argumentation does not convince me. Your arguments or not
logical but political. However unlike you I want to discuss it further
and want to get answers to my question. Lets disscuss not play with
toys.

--
Gru?...
       Tim.



Mon, 07 Jan 2002 03:00:00 GMT  
 one definition of scalar types


Quote:

> > wrong!
> > If you really need a specific integer type size,
> > simply use SYSTEM.SIGNED_32 and SYSTEM.SIGNED_64.

> I think we differ in our interpretation of "different systems".  I
> believe you mean two different Alpha systems running your compiler.
> On the other hand, with "different" I mean another Oberon system with
> another compiler, possibly running on a different processor
> architecture.

I will qualify this with a "I haven't used AOS" but....

I think your wrong here Michael.  If I specified SYSTEM.SIGNED_32 then
I would expect my compiler to give me a 32 bit type regardless of
whether I'm running on an Alpha, or a Pentium or a PowerPC.

Quote:
> > But it is not needed, because the Oberon System's lib allows you to
> > store any pervasive data type in system independent format.
> > As far as I know, this even works between big and little endian
> > machines.

> Yes.  There are always workarounds for your particular kind of
> incompatibility.

> > > I am well aware that you are very convinced of your particular
design.
> > > IMO your design is rather sick.

> > Same to you!
> > There is after all no point to defend our solution any longer.
> > At least not against someone who requires such words like
> > "sick" and "not in the spirit of".

> Please, don't get e{*filter*}d.  I am merely stating my point of view.  And
> seen in the whole context of my previous posting, my words were not


Regardless of the context I don't think comments like "your design is
sick" or "you need to leave your cubicle" help the flow of debate any.
Honestly, all of the Oberon Systems (and yes, I do count OOC/VO as
a system since it's a defined collection of libraries) have various
merits.  Yeah, you can create stand-alone apps with OOC/VO and use a
"command line" compiler, but you could do the same with V4 or System 3
for some time now.  (OFront project)

V4 has the smallest footprint and is the most widely ported.
System 3's UI is an improvement on V4's interface and has a nice
component model.  BlackBox is currently the best suited for Windows
development because of it's support for COM/OLE.  Also BB is the
only option for creating "standard look and feel" apps on the Mac.
Pow is somewhat better at creating stand-alone apps than BB and is
O2 complient. (Although  you can create stand alone apps with BB
and they don't have to be "docu-centric" contrary to popular
belief.)  OOC/VO is probably the best for creating X-windows apps
and OOC is the only Oberon compiler currently available for BeOS.
JOB and Cantebury are options for those that want there Oberon
code to work over the Web.

I know what I'm saying is not "novel" to anyone, but it seems to
me that we waste too much time "downing" the other guy's approach
and not enough time seeing how the various approaches can compliment
each other.  An example of what SHOULD be going on in the Oberon
community IMHO is Project Voyager.  They have a sophisticated
app running on top of V4, System 3, and Oberon/F (I'm not sure if
they've made the switch to BlackBox yet or not.)  The way they've
designed their app, it would probably be trivial to port it to
OOC/VO also.

Quote:
> The last sentence still holds.  Let us finish this discussion with a
> very short summary: there are at least two ways to deal with the
> problem at hand, and both have their advantages and disadvantages.
> This statement is obviously correct and vacuous enough, so we will
> both be able to agree with it.

> Regards,
> Michael van Acken

Well now that I can agree with.  (The summary).

Sent via Deja.com http://www.*-*-*.com/
Share what you know. Learn what you don't.



Mon, 07 Jan 2002 03:00:00 GMT  
 one definition of scalar types

I wish to confess I am a bit displeased with what looks like personal
overtones in this thread. These are not helpful to reach the consensus
on anything. This thread branched from an inquiry on language
extension/unification, and the thread seems to show why unification
is not there.


Quote:

>>What applications for OOC do exist now -- except uxcalc and VO?

> I have written a small number of programs (more or less usefull) as
> part of VO. Sorry, I must earn my money with other things.

No need to be sorry. You have certainly done a lot.

Quote:
> It is up to other people to add more applications.
> However I'm sure that this is possible.

It is certainly possible, but how easy OOC/VO is? These days there are
so many alternative ways to develop applications that user friendliness
matters a lot, as well as marketing and advertising.

Quote:
> Every new and possibly superior technic starts with no user
> support and must find is place in the market. Because of that I don't
> think that your argument [very few applications - WS] is that valid
> at that state.

Do you mean that new superior technology has to be rough edged
(sort of "every medicine should taste bitter")? This approach does
not lead to success any longer. Users expect user-friendliness,
except maybe {*filter*} hackers. Let's separate the core superior
technology from packaging. Packaging sells, while the core technology
does the work once the sale has been made.

Quote:
> Falling back to
> existing traditions was always the argument of the non-open minded.

Disagreed. IMO the motivation behind "existing traditions" is that
people feel safer if they can point out something that works.
(Would you buy a new pollution-free car powered by soda water before
asking for existing user experience? Or do you prefer to be the very
first user?)

IMO the best counter argument in such cases is good quality demo
applications. The very first user has to be yourself, and your own
production and fun stuff becomes the demo. The demo has to be
sophisticated enough to be convincing.

For your reference, I am writing this passage on a business trip whose
aim is to sell our digital signal processors to US national labs.
I am demonstrating benefits of our hardware by connecting their
detectors to our processors and showing them superior quality spectra.
This kind of demo is convincing enough for them to start thinking
whether our technology is superior or not. They will not base their
judgements on my sales pitch. But a working demo will do the job.
Same approach will work with OOC/VO, and for the same reason.
There is an important point though: you are struggling against
heavy competition. The days of DOS and early Unix are now gone.
There are very many slick GUIs out there. People expect flawlessness.
Anything less than perfect is not convincing anymore.

Quote:
>>> OOC needs to integrate with the rest of the
>>> world, which leads to a different goal and, consequently, different
>>> design decisions.

This is an interesting point (written by MVA?) It remains to be clarified
though what he means by "the rest of the world". My understanding
of the OOC/VO goal is "a good Oberon compiler and GUI on top of Unix,
and Windows if possible". Thus, the "rest of the world" is Unix
plus possibly Windows. In other words, your goal is an Oberon programmer
interface on top of existing OSs. These OSs, unfortunately from your
point of view, have been written in a language that you do not like.
Therefore, your goal is backward compatibility with existing C libraries,
plus keeping that compatibility with ongoing Unix C development,
since the C development is not going to stop.
I wonder if I captured your intentions correctly?

We may now have a quick look at Oberon Microsystems. Their goal was
to strengthten the O-2 language to adequately support their two
main products: (A) the BlackBox component framework; and (B) Jbed.
The first goal was served by several new language elements such
as implement-only export. On the occasion they also added some
syntactic sugar to the language, that I personally like.
The second goal was served by making CP scalar types the same
as Java. Please note that what C was to you, Java was to them.
You have not chosen Unix and C, you accepted it. They did the same
with Java. They recognized that neither "Oberon" nor "Pascal"
will sell their Jbed product, while "Java" will do the trick.
They continue to love Pascal as the language and they even support
it in addition to Java, and I believe they use Pascal as their
in-house tool. But their main selling point is Java. Please remeber
they have to survive from sales.  

From that point of view you can perhaps understand their goal,
rather than blame them for being the first to branch out, as you
did in your earlier post? They had their own reasons and motivations,
that look perfectly reasonable to me.

Quote:

> Once and for all. The Oberon Systems are a research product of various
> universities to test new aproaches in operating system design. Cool
> stuff. However the commerical effect is nearly zero, nothing.

I am afraid this is a very good point. Despite hopes and promises
the Oberon System stuff seems to be exactly what you said.
Not denying its great value.

Please notice that (despite hopes and promises) Juice and Oberon Module
Interchange has made no impact at all, though it was a very cool stuff.
However, when you look at Jbed flash compiler, it may become a commercial
hit. There is a practical difference between university supported Juice
and commercially supported Jbed, even though Michael Franz may become
upset by that.  

Quote:
> The goal of every research  must be the
> retranslation of newly developed technics back to real world.

No. The goal of research is to publish papers that hopefully
contain original ideas. The goal of commercial developers
is to take these ideas and develop them into viable products.
There is an awful lot of work to be done before an idea becomes
a viable product. University people often underestimate how much
work that is. They also commonly underestimate how much support
is needed once the product is out the door.  

W.
--
Wojtek Skulski                      
X-ray Instrumentation Associates, 2513 Charleston Rd, Ste 207
Mountain View, CA 94043
phone:  650 903 9980   fax: 650 903 9887

WWW:     http://www.*-*-*.com/ ~skulski



Mon, 07 Jan 2002 03:00:00 GMT  
 one definition of scalar types
Tim Teulings a crit:

Quote:
> OOC is much younger than the various Oberon Systems.

so what? does it prove that it'll get older?

Quote:
> Sorry, I must earn my money with other things.

me too.

Quote:
> Falling back to
> existing traditions was always the argument of the non-open minded.

greetings from the famous Dr. Freud.

Quote:
> I do not doubt that, however I want to know if you can compile your
> programms using X11 without interface or programm code changes when
> your datatype sizes change as result of your type model?

Yes.
The alpha oberon system (AOS) uses X11 in many lower level
modules such as Font and Display.
The whole AOS together with all its tools and applications
can be compiled with LONGINT being 32 bit or 64 bit wide
without any source code change. This was one of the goals of the port.
Just for fun.
Only that you can't use 64 bit addressing in 32 bit AOS,
which is fair enough.
64 bit AOS can compile/run everything 32 bit AOs can,
so there is no need for a 32 bit AOS.

Quote:
> >> OOC needs to integrate with the rest of the
> >> world, which leads to a different goal and, consequently, different
> >> design decisions.

> >I disagree.

> That makes no sense. One of the authors of OOC states its goal while
> devloping the compiler and you "disagree". What do you mean?

I disagreed with the conclusion, because rest of the world _can_ be accessed
with AOS.

MvA's precondition is false, so his conclusion is true?

Quote:
> Once and for all. The Oberon Systems are a research product of various
> universities to test new aproaches in operating system design. Cool
> stuff. However the commerical effect is nearly zero, nothing.

There are real world applications for OS V4 and S3.
I use Gisela's spreadsheet [which she developed for V4] under AOS.
(Too bad that her source package is difficult to find on the web.)
I use Kepler to draw illustrations, and other tools.
I know of someone (other than the author),
who uses Nepros (artificial simulation system)
I use AOS for programming.
My friend plays Tetris under AOS.
These are all really useful, real world,
and Foolish (note the capital "F") and there are more.

What concerns commercialism: I'm no expert in GPL, so
please correct me if I'm wrong in this point:
OOC is GPL, so it will never be a commercial success
even if it became more popular.

Quote:
> of no interst for me. Oberon Systems are a dead end for my purposes.

I have no objections ;-) what is your purpose, by the way?
Oberon System and real world fits well for me (on OpenVMS Alpha
-- I rarely used other implementations).

Quote:
> The official Oberon people have missed that badly.

I don't know any official Oberon people.

Quote:
> Oberon Operating system, which is not tied to exactly this system and
> no other? Nice to have file routines when the cannot be maped to Unix
> or Windows. Serves the purpose.

You can call Unix and Windows API from the respective Oberon System
implementation.

Quote:
> >  ASSERT (SIZE(LONGINT)=8)

> >which would not "work" with your compiler.
> >Only stand-alone A2O gives the choice between 32 or 64 bit LONGINT.

> Porting by rewriting. Sounds not like the optimal way.

what's the problem? There is no need to rewrite anything.
If I wanted a 32 bit assertion, I'd write

ASSERT (SIZE(SYSTEM.SIGNED_32)=4)

truth matters ;-)

Quote:
> >> ... Yes, I do see your point. No, I do not consider it important.

> >a politician could not have expressed it better?

> No more arguments?

no -- just like MvA did not explain why it is not important, even
if MvA did see my point.

Quote:
> >You said above that SYSTEM.ADDRESS is a synonym of HUGEINT.
> >So why is it wrong to use a HUGEINT?

> SYSTEM.ADDRESS is *not* a synonym for HUGEINT.

Let me clarify: MvA said SYSTEM.ADDRESS is an alias for HUGEINT.

So I wrongly assumed that "alias" is the same as "synonym" for the other type?

Please explain: What is an alias?

Quote:
> Come on as a compiler implementor you should understand the concept.

No, I'm sorry, I'm only a Fool ;-)

Quote:
> These modifications solve the problem once and for all. Why are you so
> against code changes?

because the number of applications and tools that exist for
the Oberon System is to large and life is too short
to even look at them. I compiled and used them (the applications and tools)
on a 64 bit oberon system and they worked.
This proves that our 64 bit concept (you might call it 64 bit extension) works.

Quote:
> >Because compatibility was not your goal.

> Uh? I though you did it all in the name of compability?

What? I said "your goal". So what are you questioning?

Quote:
> >Let me repeat: LONGINT is always 64 bit in AOS.
> >It's a 64 bit system on a 64 bit machine.
> >But it compiles 99% of the existing modules [developed for

> Ah. You need to change 1% of your code to get it compile.

I should better stop discussion now. This is too much for me.
Please read again. Find out that I expressed clearly what I wanted to say.

To give you a clue: 1% of the modules is not 1% of the code.

And in the 1% of the modules concerned, usually only a few lines
of the source code must be changed. Such changes can be made
such that it would still would compile with 32 bit LONGINT size.

Quote:
> Howmuch of
> the code you had to change to include the SYSTEM.ADDRESS language
> extention.

Last try:
we (in A2O) don't have SYSTEM.ADDRESS. We don't need it
and it does not exist in the oberon[-2] language report.
In Oberon[-2] there is only SYSTEM.PTR.

Here is a quote from the 64 bit Oberon article which
describes the 64 bit Oberon System port at
http://modulaware.com/mdlt73.htm
(I thought you've read the article.)

Quote:
> Module SYSTEM got two additional address types:
> ADDRESS_32 and ADDRESS_64, with ADDRESS_64 being synonym
> with SYSTEM.PTR.

In A2O, you have the choice to map either the 32 or 64 bit address type
to PTR which also defines the corresponding LONGINT width.
(A2O is only used in 64 bit mode when called from AOS. The above
article is about 64 bit Oberon System and hence it does not describe
the 32 bit compilation options.)

Quote:
> >Why is it not in the spirit of the language report when one sticks
> >to its specification?

> You can stick by word or by spirit.

Sorry, I doubt that you know the spirit of Oberon. I also don't know it.

Our solution works independent of the knowledge of the spirit of Oberon.
The famous one phrase Einstein quote attributes maybe 1% to this spirit,
but anyway, our solution is simpler than yours, nearly fully compatible
and portable.

If via-C and/or the outside world and/or "your" real-wordl and/or
Unix gives you problems, then maybe via-C is not a suitable way
achieve 32/64 bit portability of [existing] source.
32/64 bit portability was our goal. We achieved it. Forward and backward.

Quote:
> >In AOS you can call any system service, run-time library,
> >x11, motif, foreign language libraries, ...

> Ok. How does the interface looks like. Does it change when switching
> to another machine, OS?

X11? X11 is standardized! Isn't it?
The procedure calling conventions might be different on different
operating system or processors, but this does not change
the interface seen by the Oberon programmer, except if you talk
different releases of x11 (each time they changed a lot).

Because not all Oberon System implementations are based on X11,
module X11 is normally not directly used in Oberon System.
Such programs would not be portable.
X11 is used to implement the modules Display, Font, etc.
on Oberon Systems based on X11 (linux/unix and openvms ports).

Last time I checked X11 was still 32 bit only (pointers etc.).
I guess this is because a 64 bit version of X11 would break too much
existing C/C++ code. So they can't come-up with a 64 bit X11 version.
This is the reason why 64 bit OpenVMS has a 32 bit X11 implementation.
(which also answers MvA's question)

In AOS global variables and heap which are always located
above the 32 bit address space. The full 32 bit address space is
reserved for the main and coroutines stack (OpenVMS stack restriction).

Because of the 32 bit X11 restrictions, AOS copies all data
which goes to or comes from X11 via 32 bit memory, which
is allocated on the local procedure stack (auxiliary local variables).
For open array formal parameters, the procedute stack
is enlarged dynamically.
(This extra copying is not noticable even on the slowest
existing Alpha workstation.)

The copying must be done for all modules directly making data
transfers to/from X11.

By the way, everything in AOS is written in O2.
Not a single line of assembly, C language or any other
foreign language is used -- in the case of AOS,
even the primary Oberon System bootstrap loader is written in O2.

Using A2O to generate code for stand-alone programs,
which by the way means that our concept even works for
so-called command line compilers, i.e. out-side the Oberon System
-- and yes, we can also use X11 in stand-alone 64 bit Oberon-2 programs
-- in what you call the "real world" and we can also import the 64 bit
ISO Modula-2 library modules in Oberon-2.
I forgot to say that in my last post (in my reply to MvA).

We used the same concept in our 64 bit OpenVMS Alpha Modula-2 compiler
(8 byte sized INTEGER/CARDINAL/subranges and SYSTEM.[UN]SIGNED_32 and _64).

VO: Last year I looked for a student who would port VO to AOS
in the summer vacancies, just for curiosity and in order
to prove that it is possible, but I couldn't find one.
Most of the work would have been attributed to overcome the 32 bit X11 restrictions.

(I offered travelling cost, small salary and free food and lodging,
eventhough the resulting port would again be under GPL of course,
although I always had and still have mixed feelings about of GPL in general.)

Quote:
> Sorry, your argumentation does not convince me. Your arguments or not
> logical but political.

Dr. Freud is back again. It's a Reflection of your own behaviour onto others.

Quote:
>not play with toys.

sorry, what toys are you talking about?

I better ask myself a more productive question such as
"Why is the sky so blue?"

J'en ...

read more »



Tue, 08 Jan 2002 03:00:00 GMT  
 one definition of scalar types
Hallo!

Quote:
>> It is up to other people to add more applications.
>> However I'm sure that this is possible.

>It is certainly possible, but how easy OOC/VO is? These days there are
>so many alternative ways to develop applications that user friendliness
>matters a lot, as well as marketing and advertising.

If it goes to installation, OOC/VO is certainly easy. Michael has done
a lot in the past time to get both packages running by simply doing

./configure
make
make install

I think you cannot get it simpler for a source package.

OOC also comes with an good documentation, which not only describes
the compiler but also much of the library.

VO handling is simple as soon as you have understood the concepts. It
is not a GUI builder but uses a hierachical layouting engine similar
to Java stuff. It uses the model viewer concept, which IMHO is very
simple as soon as you have understood the concepts, too. VO current
main problems are:

Lack of documentation (there is one, but it is definitely not
complete). There xists a mailinglist and I tried to answer all
questions comming in in fully detail, but that seems not enough.

More people who write programs and send patches to fix some rough
edges. It is somehow difficult to understand, why not more people work
with VO, since it fills a gap: Portable GUIs between Unix and Windows.
Ok, the windows port is not yet released but I often claimed that it
is 80% ready and there may be only 2-4 weeks left for a expirienced
Windows programmer to finish it. The 20% missing are a result of me
lacking good documentation about GUI internas of window. I think the
screenshots and the demos show that even complex applications are
possible. Of course you will have work work, because VO is not
finished, but it is good enough IMHO.

Quote:
>Do you mean that new superior technology has to be rough edged
>(sort of "every medicine should taste bitter")? This approach does

No. It is normal, that in the beginning that there are rough edges but
it is definitely not a "must". Michael expecially has done a great job
to make OOC smooth. I tried the same, but I had not enough time.
However I'm sure, that smootheing VO is rather simple, too. It is just
that I currently cannot make it myself in any resonable time.

Quote:
>not lead to success any longer. Users expect user-friendliness,
>except maybe {*filter*} hackers. Let's separate the core superior
>technology from packaging. Packaging sells, while the core technology
>does the work once the sale has been made.

True.

Quote:
>Disagreed. IMO the motivation behind "existing traditions" is that
>people feel safer if they can point out something that works.
>(Would you buy a new pollution-free car powered by soda water before
>asking for existing user experience? Or do you prefer to be the very
>first user?)

Correct. However you will not get improvement if you are not willing
to change. I do not think that OOC/VO is that radical, that you can't
do the next step. In fact I personaly find it rather traditional, too.

Quote:
>IMO the best counter argument in such cases is good quality demo
>applications. The very first user has to be yourself, and your own
>production and fun stuff becomes the demo. The demo has to be
>sophisticated enough to be convincing.

Correct. There are some good demos. Perhaps not good enough!?

Quote:
>There is an important point though: you are struggling against
>heavy competition. The days of DOS and early Unix are now gone.

The goal is to implement a portable Oberon compiler, that runs and can
interact on "every" OS/machine and rather traditional GUI system with
is portable to "every" GUI system. There is no competition there. The
various Oberon systems or the only competition and there are very
different, too.

Quote:
>There are very many slick GUIs out there. People expect flawlessness.
>Anything less than perfect is not convincing anymore.

Not written or currently useable in Oberon with regards to portability.

Quote:
>>>> OOC needs to integrate with the rest of the
>>>> world, which leads to a different goal and, consequently, different
>>>> design decisions.

>This is an interesting point (written by MVA?) It remains to be clarified
[...]
>I wonder if I captured your intentions correctly?

Sounds good.

Quote:
>We may now have a quick look at Oberon Microsystems. Their goal was
[...]
>they have to survive from sales.

No problem with it. However I think they made a big mistake when they
made their language incompatible because they split the rather small
oberon community in to reducing the number of potential customers. If
their language was compatible they (or even me) could have ported VO.

Quote:
>From that point of view you can perhaps understand their goal,
>rather than blame them for being the first to branch out, as you
>did in your earlier post? They had their own reasons and motivations,
>that look perfectly reasonable to me.

I did not blame them. I did blame the argumentation why we all schould
switch to the CP language without discussion.

Quote:
>Please notice that (despite hopes and promises) Juice and Oberon Module
>Interchange has made no impact at all, though it was a very cool stuff.

Bad marketing. Not enough supported plattforms. No visible enhancement
after the initial release for a long time.

Quote:
>No. The goal of research is to publish papers that hopefully
>contain original ideas. The goal of commercial developers
>is to take these ideas and develop them into viable products.

Ok, but communication or even support from the researches would be
nice. In the case of Oberon this was (not enough) the case.

Quote:
>There is an awful lot of work to be done before an idea becomes
>a viable product. University people often underestimate how much
>work that is. They also commonly underestimate how much support
>is needed once the product is out the door.

Correct.

--
Gru?...
       Tim.



Tue, 08 Jan 2002 03:00:00 GMT  
 one definition of scalar types

Quote:

> > I think we differ in our interpretation of "different systems".  I
> > believe you mean two different Alpha systems running your compiler.
> > On the other hand, with "different" I mean another Oberon system with
> > another compiler, possibly running on a different processor
> > architecture.

> I will qualify this with a "I haven't used AOS" but....

> I think your wrong here Michael.  If I specified SYSTEM.SIGNED_32 then
> I would expect my compiler to give me a 32 bit type regardless of
> whether I'm running on an Alpha, or a Pentium or a PowerPC.

This is true.  But how many compilers define a SYSTEM.SIGNED_32 type?
It has been years since I looked at an ETH O2 compiler, and they did
not know such a type back then.  Interoperability should include
different compilers, IMO.

-- Michael van Acken



Tue, 08 Jan 2002 03:00:00 GMT  
 one definition of scalar types

Quote:

> >>> OOC needs to integrate with the rest of the
> >>> world, which leads to a different goal and, consequently, different
> >>> design decisions.

> This is an interesting point (written by MVA?) It remains to be clarified
> though what he means by "the rest of the world". My understanding
> of the OOC/VO goal is "a good Oberon compiler and GUI on top of Unix,
> and Windows if possible". Thus, the "rest of the world" is Unix
> plus possibly Windows. In other words, your goal is an Oberon programmer
> interface on top of existing OSs. These OSs, unfortunately from your
> point of view, have been written in a language that you do not like.
> Therefore, your goal is backward compatibility with existing C libraries,
> plus keeping that compatibility with ongoing Unix C development,
> since the C development is not going to stop.
> I wonder if I captured your intentions correctly?

An excellent summary.  If I had written this down, I would have chosen
the term "existing software" instead of "existing OS", but this does
not change the gist of the statement.  In the past years, the open
source community has produced a great mass of high quality, free
software.  Most of this software is targeted towards Unix (mostly
Linux, although most are portable to other Unixes), and, to a lesser
degree, towards Win32.  And this software is written in C.

Being able to use existing C libraries can be a big plus for any
Oberon environment.  For example, Tim's VO library simply uses an
'imlib' to deal with images, allowing him to use different image file
format (JPEG, GIF, PNG, and the like) with very little effort.  For
this reason OOC offers fairly elaborate mechnisms to easily interface
to existing C code.

Regards,
Michael van Acken



Tue, 08 Jan 2002 03:00:00 GMT  
 one definition of scalar types

Quote:

> Last time I checked X11 was still 32 bit only (pointers etc.).
> I guess this is because a 64 bit version of X11 would break too much
> existing C/C++ code. So they can't come-up with a 64 bit X11 version.
> This is the reason why 64 bit OpenVMS has a 32 bit X11 implementation.
> (which also answers MvA's question)

I am not an expert on this field, either, but I am surprised that you
claim X11 to be "32 bit restricted".  I used oo2c to run a X11
application on a DEC Alpha system without any problems.  Because the
compiler only knew about 64 bit address values, the X11 functions were
definitively called with 64 bit pointer values.  And I know that the
X11 header files do use "long" types, which map to 64 bit values on
such systems.  That is, the interface was wholly 64 bit.

Could it be that the X11 "32 bit restriction" you are talking about is
restriction of your particular environment?

-- Michael van Acken



Tue, 08 Jan 2002 03:00:00 GMT  
 one definition of scalar types
Hallo!

Quote:
>> OOC is much younger than the various Oberon Systems.
>so what? does it prove that it'll get older?

It is normal for a young system that there do not exist as much
sources then for an old system.

Quote:
>> Falling back to
>> existing traditions was always the argument of the non-open minded.
>greetings from the famous Dr. Freud.

You cannot make Freud responsible for everything. In mind opinion
traditions has something to do with looking more to the past than into
the future, while an open-minded (aka open for something new) tries to
look more into the future than to history (which does not mean that he
does not look at all to history, of course he tries to leran from it!).
I find this statement somehow logical, while it is not a real proof
most people will think it is ok.

Quote:
>> I do not doubt that, however I want to know if you can compile your
>> programms using X11 without interface or programm code changes when
>> your datatype sizes change as result of your type model?
>Yes.

[...]

The question was "...without source or interface changes..." do did
not answer this part here. I have no doubt that you can interface it
is just a question of effort.

Quote:
>I disagreed with the conclusion, because rest of the world _can_ be accessed
>with AOS.

>MvA's precondition is false, so his conclusion is true?

Yes, but he (implicitly?) stated that he wants to make it as easy as
possible. For Michael accessing the rest of the world is more
important than compability and we have found out that this two goal
somehow interfer. Note, nobody ha sdoubts that you can access the
rest of the world, we only somehow think it is easier the way we do.

Quote:
>> Once and for all. The Oberon Systems are a research product of various
>> universities to test new aproaches in operating system design. Cool
>> stuff. However the commerical effect is nearly zero, nothing.
>There are real world applications for OS V4 and S3.

I have spoken of commerical effects not of real world application. I
have no doubt that useable application exist in the context of the
various oberon systems however I doubt that the developement of the
systems had wide-spread commercial success for anybody as a result.
The reason for this have been discussed in this newsgroup many times
(veray different interface...).

Quote:
>What concerns commercialism: I'm no expert in GPL, so
>please correct me if I'm wrong in this point:
>OOC is GPL, so it will never be a commercial success
>even if it became more popular.

Difficult topic. You can use OOC for commerical programs, however you
cannot use the library if you do not want to publish sources. If you
publish the sources you can sell the programm without any problems.
However we are not talking about "use OOC", we talk about an language
and library standard which allows use to start developing with OOC an
then switch to a commercial compiler if we want to sell it.

Quote:
>> of no interst for me. Oberon Systems are a dead end for my purposes.
>I have no objections ;-) what is your purpose, by the way?

(Commercial/non commercial) appliations with are accepted by the
masses, for example they must integrate into the used desktop and must
have a "normal " GUI. They applications must be able to use all
features I could use with C. I want to use CORBA and Databases using
Oberon for example. I want to develop applications for Linux (GNOME;
KDE) with run also under Windows (text editor for example). OOC/VO
makes it possible, Oberon System not.

Quote:
>> The official Oberon people have missed that badly.
>I don't know any official Oberon people.

The developer of the language, the ETHZ people. That are the offocials
in my opinion because they somehow "own" the language.

Quote:
>> >  ASSERT (SIZE(LONGINT)=8)

>> >which would not "work" with your compiler.
>> >Only stand-alone A2O gives the choice between 32 or 64 bit LONGINT.

>> Porting by rewriting. Sounds not like the optimal way.

>what's the problem? There is no need to rewrite anything.
>If I wanted a 32 bit assertion, I'd write

>ASSERT (SIZE(SYSTEM.SIGNED_32)=4)

>truth matters ;-)

You forgot that LONGINT is used here as a type for a variable to store
addresses in. If the pointer size differs you had to change the assert.

Quote:
>> >You said above that SYSTEM.ADDRESS is a synonym of HUGEINT.
>> >So why is it wrong to use a HUGEINT?

>> SYSTEM.ADDRESS is *not* a synonym for HUGEINT.

>Let me clarify: MvA said SYSTEM.ADDRESS is an alias for HUGEINT.

>So I wrongly assumed that "alias" is the same as "synonym" for the other type?

>Please explain: What is an alias?

No, he did not say that. He said that SYSTEM.ADDRESS maps to HUGEINT
on 64 bit systems and maps to LONGINT on 32 bit systems. That is
different, and in fact that is the clue of the thing.

Quote:
>> These modifications solve the problem once and for all. Why are you so
>> against code changes?
>because the number of applications and tools that exist for
>the Oberon System is to large and life is too short
>to even look at them. I compiled and used them (the applications and tools)
>on a 64 bit oberon system and they worked.
>This proves that our 64 bit concept (you might call it 64 bit extension) works.

Yes, but is the alternative (SYSTEM.ADDRSES) really so much mor
effort? I tried to get some number from you, but you somehow refused:

Quote:
>> >Because compatibility was not your goal.

>> Uh? I though you did it all in the name of compability?

>What? I said "your goal". So what are you questioning?

Sorry. My mistake.

Quote:
>> >Let me repeat: LONGINT is always 64 bit in AOS.
>> >It's a 64 bit system on a 64 bit machine.
>> >But it compiles 99% of the existing modules [developed for
>> Ah. You need to change 1% of your code to get it compile.
>I should better stop discussion now. This is too much for me.
>Please read again. Find out that I expressed clearly what I wanted to say.
>To give you a clue: 1% of the modules is not 1% of the code.

Correct. So here we are again: You must change 1% of your modules to
get the stuff running.

Quote:
>And in the 1% of the modules concerned, usually only a few lines
>of the source code must be changed. Such changes can be made
>such that it would still would compile with 32 bit LONGINT size.
>> Howmuch of
>> the code you had to change to include the SYSTEM.ADDRESS language
>> extention.

>Last try:
>we (in A2O) don't have SYSTEM.ADDRESS. We don't need it
>and it does not exist in the oberon[-2] language report.
>In Oberon[-2] there is only SYSTEM.PTR.

Fine. Now I ask again: How much time would it take and how much code
or modules would you have to change to get the stuff running if your
compiler implemented SYSTEM.ADDRESS and you would rewrite all "LONGINT
used to store pointers" stuff to use SYSTEM.ADDRESS? Would it be far
more. You know: If your effort would be the nearly same for both
solutions and we would have much less effort when using the second
solution why do we do not use the second one?

Quote:
>> You can stick by word or by spirit.

>Sorry, I doubt that you know the spirit of Oberon. I also don't know it.

I have read so much about various languages and even have used msome
of them that *I* somehow know what Oberon makes different. Mayb I
cannot express it easyly in words but...

Quote:
>Our solution works independent of the knowledge of the spirit of Oberon.
>The famous one phrase Einstein quote attributes maybe 1% to this spirit,
>but anyway, our solution is simpler than yours, nearly fully compatible
>and portable.

Simpler in which sense? Simpler for the compiler, the compiler
implementor...?

Quote:
>X11? X11 is standardized! Isn't it?

Yes.

Quote:
>The procedure calling conventions might be different on different
>operating system or processors, but this does not change
>the interface seen by the Oberon programmer, except if you talk
>different releases of x11 (each time they changed a lot).

Ok. For example, some routine uses an 32 bit value as argument. We
defines this parameter as LONGINT within our X11.Mod. This will
compile on all systems. AFAIK you cannot do this, because LONGINT has
32 or 64 bit size depending of the machine. so AFAIK you have to
change the interface by replacing LONGINT with something diffrent like
SYSTEM.LONGINT_32. Or you can always use SYSTEM.XXX in such interfaces
but then you have a type conversion somewhere in your program when
passing "normal" oberon typed variables to this method. So how do you
work aoround it?

Quote:
>Last time I checked X11 was still 32 bit only (pointers etc.).

Correct. X11 datatype sizes IMHO must be all the same, since client
and server could be of different archetectur.

Quote:
>VO: Last year I looked for a student who would port VO to AOS
>in the summer vacancies, just for curiosity and in order
>to prove that it is possible, but I couldn't find one.

That is sad. However astonishly you did not asked me nor did you ask
on the VO or OOC mailinglist. Why not. There is/was someone who did
port VO to XDS by the way....perhaps you could have made the AOS port,
too? Also I woul dgues sthat this is not a VO specific problem. You
would have this problem with most other Oberon software, too.

Quote:
>(I offered travelling cost, small salary and free food and lodging,
>eventhough the resulting port would again be under GPL of course,
>although I always had and still have mixed feelings about of GPL in general.)

Cool. If I had time, I would do it. If you still want VO ported,
please ask on the mentioned mailing list.

Quote:
>I better ask myself a more productive question such as
>"Why is the sky so blue?"

Has something to do with light, refraction etc...

--
Gru?...
       Tim.



Tue, 08 Jan 2002 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. One file definition - multiple DOS files

2. Another one: strings in method definitions?

3. Script definition any one ?

4. One paragraph definition of Object Oriented Design

5. CLHS: Fill pointer definition: off by one?

6. Numeric Type Definition HELP???

7. Determining definition type

8. Type Definition : A Style Question?

9. Values escaping their type definition

10. waveform data type definition in C

11. C definition of LabView6i "waveform" type

12. type definitions within record scopes

 

 
Powered by phpBB® Forum Software