[Oberon] Oberon Splines.Mod

thomas.kral at email.cz thomas.kral at email.cz
Wed Apr 6 21:54:46 CEST 2016


Joerg,

I see, when updating Splines I looked at Curves and Rectangles modules, and tried to learn from the coding style.
I realised that Handle really means  Change, doing the message despatch. So I just renamed the method.

Splines and Curves allow changing colour, while Rectangles also width.

It seems to work, I can create splines, move them around the screen.

Tomas

---------- Původní zpráva ----------
Od: Jörg 
Komu: thomas.kral at email.cz
Datum: 6. 4. 2016 16:32:31
Předmět: RE: [Oberon] Oberon Splines.Mod

Hi Tomas

Fine.
Leaving out "Message.handle := Handle" could be problematic, as this is normally the main thing how you extend things in Oberon :-)

A procedure "Handle" handles all messages that are supported on your new object. (mouse moves, mouse clicks, keyboard, whatever...)
Normally you generate a new object as inheritance from a base object.
TYPE NewObject = RECORD (BaseObject) newThings: INTEGER END;

The "Handle" procedure in your new object handles all new stuff (eg. initializing newThings or so) and calls "Handle" of the base object in the end.

br
Jörg

-----Original Message-----
From: thomas.kral at email.cz [mailto:thomas.kral at email.cz] 
Sent: Mittwoch, 6. April 2016 14:52
To: Jörg Straube 
Cc: ETH Oberon and related systems 
Subject: Re: [Oberon] Oberon Splines.Mod

Hi Joerg,

I managed to recompile Graphics.Mod and GraphicFrames.Mod, so I have now .rsc files of both.
Now to the Splines.Mod from Ceres-2 project.

I needed to update the source slightly to go with FPGA Oberon V,  perhaps similar changes to be found in Curves.Mod and Rectangles.Mod made by NW.

Changes I made ...

Printer related code commented out

Display.ReplConstC(f, c ...  => Display.ReplConst(c ... left out frame parameter
Display.DotC(f, c ...  => Display.Dot(c ... left out frame parameter

WITH M ... DO ... replaced by ... CASE M of ... :
SHORTINTEGER => INTEGER
SHORT(ENTIRE()) => FLOOR()

ReadFile () => ReadByte()
WriteFile() => WriteByte()

real assigments := 0.0;

message.handle := Handle;  left out
added message.change := Change;            I believe this handles moving objects on display  

It may not be perfect but it compiles and seems to be doing things.

Tomas

---------- Původní zpráva ----------
Od: Jörg Straube 
Komu: Tomas Kral 
Datum: 5. 4. 2016 9:15:33
Předmět: Re: [Oberon] Oberon Splines.Mod

If you only have the implementation file (rsc) and don't have the corresponding interface file (smb) that was used during compilation, you have to rebuild (=compile) the complete import hierarchy for your application from scratch. (in the correct order)

Mix and match from different Oberon OS sources/versions is sometimes tricky :-)

Jörg

> Am 05.04.2016 um 09:04 schrieb Tomas Kral :
> 
> Joerg,
> 
> Thank you, I already am at PO.Applications, studying compiler
> implementation, code patterns now, just beginning more to understand
> now.
> 
> Thing is, I wanted to recreate Graphics.smb and GraphicFrames.smb that
> are missing on my RISC.img, running a compiler would produce new/old
> symbols, as these are imported by Splines.Mod
> 
> Many thanks so far.
> 
> 
> -- 
> Tomas Kral 
> 
>> On Tue, 2016-04-05 at 08:24 +0200, Jörg Straube wrote:
>> If you change the IMPLEMENTATION of module A, you only have to unload
>> the module (System.Free) and can use the new implementation
>> immediately as the new code will be (re)loaded dynamically.
>> 
>> 
>> But If you change the INTERFACE of module A, and compile with /s, an
>> new symbol file is generated. All modules importing A have to be
>> recompiled as well, as the interface to A (and hence the key in the
>> symbol file) changed.
>> 
>> 
>> --> if you changed the interface of GraphicFrames and generated a new
>> symbol file, then the module Draw has to be recompiled as it imports
>> GraphicFrames (that changed).
>> You might repeat this process until the whole import chain is
>> satisfied.
>> 
>> 
>> /s is dangerous if you dont know the import hierarchy of the module
>> you changed. Only use /s if you know what you do.
>> 
>> Jörg
>> 
>> Anfang der weitergeleiteten E‑Mail:
>> 
>> 
>>> Von: Jörg Straube 
>>> Datum: 5. April 2016 um 07:56:02 MESZ
>>> An: ETH Oberon and related systems 
>>> Betreff: Re: [Oberon] Oberon Splines.Mod
>>> 
>>> 
>>> Tomas
>>> 
>>> 
>>> as a recommendation to you: Study the book(s) explaining all aspects
>>> of the Oberon OS.
>>> Why there are symbol files, under what conditions a new symbol file
>>> is needed and what the (sometimes dangerous) /s flag is doing:
>>> http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf
>>> chapter 12.6.2
>>> 
>>> Jörg
>>> 
>>> Am 04.04.2016 um 22:59 schrieb 
>>> :
>>> 
>>> 
>>>> Hi,
>>>> 
>>>> I found Splines.Mod in the older Ceres-2 sources, and transferred
>>>> to RISC5.
>>>> I also needed to recompile Grphics.mod and GraphicFrames.Mod as
>>>> their symbol .smb files were missing on RISC.img.
>>>> I also needed to remove old .rsc otherwise I was  getting 'bad
>>>> keys' when loading DRAW application.
>>>> 
>>>> I wish to understand why, I guess this is to do with run-time
>>>> loading, can you please explain to me?
>>>> 
>>>> I tested /s compile parameter that seems forbids a new symbol
>>>> file, but my task was recreating original missing symbols based on
>>>> original sources.
>>>> 
>>>> Many thanks in advance.
>>>> Tomas
>>>> 
>>>> 
>>>> ---------- Původní zpráva ----------
>>>> Od: Jörg Straube 
>>>> Komu: ETH Oberon and related systems 
>>>> Datum: 25. 3. 2016 14:36:30
>>>> Předmět: Re: [Oberon] Oberon Splines.Mod
>>>> 
>>>> Hi Tom
>>>> 
>>>> In NativeOberon there was the drawing suite called „Leonardo“.
>>>> Have a look at the source code of LeoSplines.Mod
>>>> 
>>>> br
>>>> Jörg
>>>>> Am 25.03.2016 um 09:56 schrieb Tomas Kral :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Now reading more about Draw.Tool, PO.Application chapters
>>>>> describe
>>>>> basic shape primitives, a line, rectangle, circle, ellipse, also
>>>>> Spline
>>>>> curves.
>>>>> 
>>>>> Splines.Mod however seems missing on RISC.img, I also searched
>>>>> old ETH
>>>>> archives, and not found in sources there nor in Project Oberon
>>>>> 2005.
>>>>> 
>>>>> It seems left as homework for a careful reader, right?
>>>>> 
>>>>> Cheers
>>>>> 
>>>>> -- 
>>>>> Tomas Kral 
>>>>> 
>>>>> --
>>>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>>>>> systems
>>>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon--
>>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>>>> systems
>>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>>> --
>>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>>>> systems
>>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>>>


More information about the Oberon mailing list