OberonF/BlackBox: XYplane-output-window-size 
Author Message
 OberonF/BlackBox: XYplane-output-window-size

Hi,

I'm trying to enlarge the output-window for graphics of the imported
module XYplane.
The window can be enlarged by setting the variables XYplane.W or
XYplane.H
(from within the importing module),
but the drawing-rectangle (of size about 300 x 300 pixels) is ___ NOT
___ enlarged by this.

How can be done this?

Regards.

Thanx in advance.

Wolfgang Buechel



Mon, 17 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

Quote:
> I'm trying to enlarge the output-window for graphics of the imported
> module XYplane.
> The window can be enlarged by setting the variables XYplane.W or
> XYplane.H
> (from within the importing module),
> but the drawing-rectangle (of size about 300 x 300 pixels) is ___ NOT
> ___ enlarged by this.

> How can be done this?

XYplane.W and XYplane.H can't be changed by client modules, they're
supposed to be read-only. The semantics of module XYplane is defined in
the book Programming in Oberon - Steps beyond Pascal and Modula, by
Reiser & Wirth. The description that goes with the definition says:
  "Variables X, Y, W and H report location and size of the visible
   drawing area. They are defined after a call of procedure Open."
This definition is given in language Oberon; had it been given in
Oberon-2 (which barely existed at the time the book was written) then
the declaration of the variables would have been thus:
  VAR X-, Y-, W-, H-: INTEGER;
and it would have been apparent immediately that they are read-only.

Unfortunately even nowadays systems that use Oberon-2, or a further
development of it like Component Pascal, often give the original Oberon
definition. It would be desirable that they gave the more expressive
Oberon-2 definition. But by the folks who develop the systems module
XYplane, just like modules In and Out, are considered "toy modules",
only to be used by beginning programmers; and these modules are treated
somewhat orfanly by them.

Which is unfortunate because these very modules are the first to be used
by anyone who tries to get acquainted with Oberon-2 / Component Pascal
and also because these are some of the very few modules that are the
same in all systems.

Hans Klaver



Tue, 18 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size


Quote:

> XYplane.W and XYplane.H can't be changed by client modules, they're
> supposed to be read-only. The semantics of module XYplane is defined
in
> the book Programming in Oberon - Steps beyond Pascal and Modula, by
> Reiser & Wirth. The description that goes with the definition says:
>   "Variables X, Y, W and H report location and size of the visible
>    drawing area. They are defined after a call of procedure Open."
> This definition is given in language Oberon; had it been given in
> Oberon-2 (which barely existed at the time the book was written) then
> the declaration of the variables would have been thus:
>   VAR X-, Y-, W-, H-: INTEGER;
> and it would have been apparent immediately that they are read-only.

> Unfortunately even nowadays systems that use Oberon-2, or a further
> development of it like Component Pascal, often give the original
Oberon
> definition. It would be desirable that they gave the more expressive
> Oberon-2 definition. But by the folks who develop the systems module
> XYplane, just like modules In and Out, are considered "toy modules",
> only to be used by beginning programmers; and these modules are
treated
> somewhat orfanly by them.

> Which is unfortunate because these very modules are the first to be
used
> by anyone who tries to get acquainted with Oberon-2 / Component Pascal
> and also because these are some of the very few modules that are the
> same in all systems.

> Hans Klaver

So true!  And I find this to be THE biggest obstacle that Oberon faces
today!  The standard modules simply aren't powerful enough for real
work.  The great thing about them is that they are so EASY to use.
But as soon as someone tries to do something that outstrips the meager
functionality given in those modules, he finds himself needing to
delve into the dirty details of the particular Oberon "system" (or
library for all you 'Oberon as a compiler' folks) and learn build
whatever he needs from scratch.

Two things need to happen :
1) More basic functionality needs to be put into the standard
modules

For example :
XYplane
   -- Ability to resize
   -- Ability to change foreground and background color
   -- Ability to do simply bitmap manipulations (BitBlt -- stetch)

In/Out
   -- Ability to handle formatting
   -- Ability to handle fonts

2) More advanced modules need to use "design patterns" that
let the programmer access them in a "standard" way if desired.

I've seen some attempt at doing this, but I wish it were standard
practice.

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



Sun, 23 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

Quote:

> So true!  And I find this to be THE biggest obstacle that Oberon faces
> today!  The standard modules simply aren't powerful enough for real
> work.  The great thing about them is that they are so EASY to use.
> But as soon as someone tries to do something that outstrips the meager
> functionality given in those modules, he finds himself needing to
> delve into the dirty details of the particular Oberon "system" (or
> library for all you 'Oberon as a compiler' folks) and learn build
> whatever he needs from scratch.

> Two things need to happen :
> 1) More basic functionality needs to be put into the standard
> modules

> For example :
> XYplane
>    -- Ability to resize
>    -- Ability to change foreground and background color
>    -- Ability to do simply bitmap manipulations (BitBlt -- stetch)

> In/Out
>    -- Ability to handle formatting
>    -- Ability to handle fonts

> 2) More advanced modules need to use "design patterns" that
> let the programmer access them in a "standard" way if desired.

> I've seen some attempt at doing this, but I wish it were standard
> practice.

That's exactly my opinion, too. I would have some standard libs like that
the POW people provide with there distribution (e.g. the Colorplane
Module). Exspecially in a scientific environment we often have a lot of
simple write and run once programs with a simple textual and graphical
output and we wan't to deal for that with a big overhead. I've made a
simple port (more or less) of the a.m. Colorplane module to my Power
Oberon (V4) on the Mac but unfortunately if I don't use the Mac specific
Modules it's awfully slow. Nevertheless I was able to port these slow
version to S3 on my Mac and to S3 and V4 on Windows.

At the moment I write a little documentation for that and than I will out
that on my website. I will inform the group than.

But nevertheless: We need a diskussion about the further standard modules
for _all_ Oberon-Systems.

J"org (pls. excuse my bad (d)english)

--
J"org Kantel             Max-Planck-Institute for the History of Science

Wilhelmstr. 44   http://www.mpiwg-berlin.mpg.de/staff/kantel/kantel.html
D-10117 Berlin   fon: +4930-22667-220               fax: +4930-22667-299



Mon, 24 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

Quote:

>> I've seen some attempt at doing this, but I wish it were standard
>> practice.

>That's exactly my opinion, too. I would have some standard libs like that
>the POW people provide with there distribution (e.g. the Colorplane
>Module). Exspecially in a scientific environment we often have a lot of
>simple write and run once programs with a simple textual and graphical
>output and we wan't to deal for that with a big overhead. I've made a
>simple port (more or less) of the a.m. Colorplane module to my Power
>Oberon (V4) on the Mac but unfortunately if I don't use the Mac specific
>Modules it's awfully slow. Nevertheless I was able to port these slow
>version to S3 on my Mac and to S3 and V4 on Windows.

>At the moment I write a little documentation for that and than I will out
>that on my website. I will inform the group than.

>But nevertheless: We need a diskussion about the further standard modules
>for _all_ Oberon-Systems.

Real showstopper is the lack of container libraries, such as GOBO or
Pylon for Eiffel or STL for C++. Without such libraries Oberon will
continue being a toy.

A.L.



Mon, 24 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size


Quote:
> Real showstopper is the lack of container libraries, such as GOBO or
> Pylon for Eiffel or STL for C++. Without such libraries Oberon will
> continue being a toy.

> A.L.

Well I've never found rolling my own link-list objects to be much
of a problem.  I have a generic link-list library that I can post
(though there are some problems with it admittedly.)

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



Tue, 25 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

Quote:



> > Real showstopper is the lack of container libraries, such as GOBO or
> > Pylon for Eiffel or STL for C++. Without such libraries Oberon will
> > continue being a toy.

> > A.L.

> Well I've never found rolling my own link-list objects to be much
> of a problem.  I have a generic link-list library that I can post
> (though there are some problems with it admittedly.)

What I found a problem was not so much writing my own containers,
but objects management in a GUI. Let me explain: writing a linked
list and other such stuff is easy. This topic is covered in any modern
programming textbook. What is not easy, at least to me, is to manage
objects visually on screen, manipulate them, move from one container
to another, getting access to object internals, etc. This topic can
perhaps
be labeled "object management" combined with "browsing". It is far
more complex than just linking a few objects in a list and then iterating
over such list.

I have made a few forays into that realm, at first with V4. My old B2
project
includes object management, lists, containers, and growable tables
of objects, plus a textual object management interface. Then I tried a
less
elaborate approach with System 3 Gadgets. Thanks to built-in Gadgets
mechanisms I wrote a plotting package where you can drag-and-drop
an object onto a X-Y plotter and a nifty thing will happen (namely, it
will
get plotted). That was nifty and perhaps even useful, but it was still too
little
to be truly practical. After trying all this, as well as some BlackBox
programming,
I can only say that visual object management is a difficult art. Yet,
without such
management one cannot develop a truly useful application these days.

There are container document libraries both under System 3 and BlackBox,
and perhaps for other Oberon systems. Learning how to use these tools
is not easy, but if you look at what has been developed by insiders,
ETH and OuS respectively, the power is clearly there.

I am not sure if STL concept is applicable to Oberon. From what little
I know of STL, and please correct me if I am wrong, it is based on
compile-time
templates, i.e., a one-time compile time polymorphism. STL is a better,
fancier
impementation of the C preprocessor. An essence of the Oberon programming
model is run-time polymorphism rather than preprocessing, and therefore
STL paradigm does not apply. I have also heard that STL originated
as a remedy for bad run-time C++ performance as far as polymorphism
was concerned.

I cannot comment on GOBO and Pylon. What are they?

Wojtek

  -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
   http://www.newsfeeds.com       The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including  Dedicated  Binaries Servers ==-----



Wed, 26 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

Quote:



>> Real showstopper is the lack of container libraries, such as GOBO or
>> Pylon for Eiffel or STL for C++. Without such libraries Oberon will
>> continue being a toy.

>> A.L.

>Well I've never found rolling my own link-list objects to be much
>of a problem.  I have a generic link-list library that I can post
>(though there are some problems with it admittedly.)

STL, EiffelBase, Pylon or class hierarchy is Smalltalk is quite a bit
more than just linked lists. Take iterators, for example... Not saying
about such things as sorted collection, set, dictionaries,
associations, maps...  Not saying about other features: searching,
sorting, transformations.... In Eiffel world all these librarries
(Including ISE EiffelBase that is commmercially suported) are either
GNU or other form of open source.

A.L.



Wed, 26 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size
On Sat, 10 Jul 1999 01:35:46 -0700, Wojtek Skulski

Quote:

>I am not sure if STL concept is applicable to Oberon. From what little
>I know of STL, and please correct me if I am wrong, it is based on
>compile-time
>templates, i.e., a one-time compile time polymorphism. STL is a better,
>fancier
>impementation of the C preprocessor.

Sorry, totally wrong...

Quote:
>An essence of the Oberon programming
>model is run-time polymorphism rather than preprocessing, and therefore
>STL paradigm does not apply. I have also heard that STL originated
>as a remedy for bad run-time C++ performance as far as polymorphism
>was concerned.

Sorry, also nonsense...

Quote:
>I cannot comment on GOBO and Pylon. What are they?

Container libraries for Eiffel. Have a look on EiffelBase, container
(and not only) library for Eiffel. Would be quite easy to implement in
Oberon. For manual see www.eiffel.com.

A.L.



Wed, 26 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

Quote:

> On Sat, 10 Jul 1999 01:35:46 -0700, Wojtek Skulski

> >I am not sure if STL concept is applicable to Oberon. From what little
> >I know of STL, and please correct me if I am wrong, it is based on
> >compile-time
> >templates, i.e., a one-time compile time polymorphism. STL is a better,
> >fancier
> >impementation of the C preprocessor.

> Sorry, totally wrong...

> >An essence of the Oberon programming
> >model is run-time polymorphism rather than preprocessing, and therefore
> >STL paradigm does not apply. I have also heard that STL originated
> >as a remedy for bad run-time C++ performance as far as polymorphism
> >was concerned.

> Sorry, also nonsense...

These answers aren't particularly helpful.
STL is a template library for C++; it's not based on preprocessing but the
template
capabilities of C++.  It creates template classes such as a 'vector' which
allow you to
make vectors of other data types.  (the names I use are probably wrong)

For example:

vector<int> int_vector;
vector<vector<int>>  int_vector_vector;

(A big-joke-side-note for compiler types is that the second instantiation
is often regarded as a syntax error because '>>' is a multi-character token

which is usually recognized by the lexer.  In this case the parser will be
expecting the token '>' to close the template, but it gets '>>'.
Consequently,
most people will write the declaration as 'vector<vector<int> >'.  Some
compilers
do properly work with the '>>' token; Borland's compiler is one of them, I
believe).

It was created, if memory serves, by some guy at HP to take advantage of
the
template services proposed by the language -- and as a result it caused
quite some
delay in the Ansi C++ standard as the committee bickered over new language
features
for templates to support the STL and including the STL in the standard.

One of the (muted) goals of C++ is to get rid of the preprocessor, but it
will
take a long time before that actually happens.

Taylor "Employed" Hutt
Removing the preprocessor from C++ is like taking the cream out of your
coffee.



Wed, 26 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

Quote:


> > On Sat, 10 Jul 1999 01:35:46 -0700, Wojtek Skulski

> > >I am not sure if STL concept is applicable to Oberon. From what little
> > >I know of STL, and please correct me if I am wrong, it is based on
> > >compile-time
> > >templates, i.e., a one-time compile time polymorphism. STL is a better,
> > >fancier impementation of the C preprocessor.

> > Sorry, totally wrong...

> > >An essence of the Oberon programming
> > >model is run-time polymorphism rather than preprocessing, and therefore
> > >STL paradigm does not apply. I have also heard that STL originated
> > >as a remedy for bad run-time C++ performance as far as polymorphism
> > >was concerned.

> > Sorry, also nonsense...

> These answers aren't particularly helpful.
> STL is a template library for C++; it's not based on preprocessing but the
> template capabilities of C++.

I stand corrected. I should have not used the name "preprocessor".
The gist of my post should have been "templates", which are
compile-time thing. What happens is that you write your code
in terms of <something>, then substitute a concrete "thing" for
<something>, and then the compiler rewrites your code as if
it was written in terms of  "thing" to begin with.
To my taste it looks like preprocessing the text before
actual compilation, and this is what I had in mind.
However, the name "preprocessor" has been
already taken and I should not have mentioned it.
Anyway, AFAIK there are no templates in Oberon
and therefore the whole idea of STL does not apply.

I have read a few articles on templates in "Computers in Physics".
The authors, who were great enthusiasts of templates
and contributors to the C++ standard, stated up front that
templates originated to remedy bad run time performance
of C++ code when run-time polymorphism was used.
This bad performance had something to do with multiple
class inheritance, but I am not sure why multiple inheritance
should cause bad performance.  The template solution is
simply to throw the child with the bath, i.e., to let the compiler
resolve the class references during the compilation
(at the expense of the compilation time), rather than to perform
run-time type tests that apparently caused bad performance
of C++ code.

I furter recall that Mossenbock discussed multiple inheritance
in his book and concluded it was not necessary, though his
main argument against multiple inheritance was not based
on performance but rather on code simplicity (in the "make it
as simple as possible" spirit). I am not sure whether run-time
type tests in Oberon are efficient or not, but I recall people saying
they are very efficient, perhaps thanks to single inheritance.

In case anyone is interested, I recommend an article entitled
"Disambiguated glommable expression templates" published
in "Computers in Physics" about a year ago. The author discusses
the template technology, and ways to make the C++ code efficient
enough for numerical calculations. The gist of the article was that
the standard templates were not good enough for numerics, and
therefore templates had to be made "glommable" and ""disambiguated"
before numerical expression templates could yield efficient code.
After looking at the examples in this article I thought
I would rather run away screaming than use this technology
for my calculations, but maybe I am not expert enough.

As far as containers and iterators are concerned, BlackBox
framework provides building blocks based on very
advanced theory developed by Szyperski in his book. The BB
documentation of these components is quite thorough, though rather
tough to read. The problem is that these are just building blocks
and not many BB applications have been released to public
domain based on these blocks. I found it time consuming to write
my applications starting just from the BB framework. I would rather
prefer to take someone else's code and modify it according to
my needs. This is a problem of critical user mass, as usual with
Oberon. System 3 also defines a framework that looks quite
usable to me, but a System 3 reference manual has not been
written yet, what makes S3 a bit hard to use.

W.

  -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
   http://www.newsfeeds.com       The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including  Dedicated  Binaries Servers ==-----



Wed, 26 Dec 2001 03:00:00 GMT  
 OberonF/BlackBox: XYplane-output-window-size

[Stuff about C++ templates]

C++ Templates are an implementation of parametric polymorphism. This is a
paradigm which simply _does not exist at all_ in Oberon. It is orthogonal
to the inheritance polymorphism as found in Oberon.
As it allows you to build 'types over types', it is a very strong tool
in implementing generic container classes.

I strongly recommend Clemens Szyperski's paper
'Lightweight Parametric Polymorphism for Oberon' found at
http://www.fit.qut.edu.au/~szypersk/pub/JMLC97.ps.gz
which explains the issue much better than I ever can do.

Christian.

--
Christian Luginbuehl



Fri, 28 Dec 2001 03:00:00 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. BlackBox: How to create scrolling output ?

2. Windows MetaFile under Oberonf

3. Scrollbars under windows don't have correct size if created with sizes other than default

4. Oberon V4 2.3 (XYPlane Animation)

5. XYplane compiling problems

6. XYplane

7. Window Size in Windows 3.11

8. 6024E Analog Output FIFO size?

9. 6024E Analog Output FIFO size?

10. How do I determine expected output size for System Exec vi

11. dynamic sizing character function output re-visited

12. (Newbie)Outputting file sizes in a dir. listing

 

 
Powered by phpBB® Forum Software