[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