[Oberon] XML Parser-API for OBERON

Wed Jan 20 17:20:19 CET 2016

Hi Peter,

I will try. Meanwhile I looked into my code and discovered that at least 
30 out of the 98 Procedures  can be exported to a separate module.

So I will work in both directions.

Regards, Dieter

Am 20.01.2016 um 17:00 schrieb Peter Matthias:
> Forgot to mention: CodeLength is being exported, so you also have to 
> recompile client modules OPL, OPC, OPV Compiler.
> MaxConstLegth is a different thing. It is only for constants.
>
> Regards,
>     Peter
>
> Am 20.01.2016 um 10:24 schrieb Dieter:
>> Hallo Peter,
>>
>> danke, das scheint ein hilfreicher Tipp zu sein. Nur leider ist es mir
>> nicht gelungen, ihn zu implementieren.
>> Was habe ich gemacht?
>> 1. OPO.Obj im Object-Directory unter anderem Namen gesichert.
>> 2. OPO.Mod im Source-Directory gesichert
>> 3. OPO.Mod geändert und kompiliert.
>> 4. OPO.Obj erscheint im Work-Directory.
>> 5. OPO.Obj ins Object-Directory kopiert.
>> ==> Nun funktioniert der Compiler nicht mehr.
>> Dann habe ich alles rückabgewickelt und den alten Zustand mit 65000
>> Bytes wiederhergestellt, d.h. den ursprünglichen Objectfile 
>> wiederverwendet.
>>
>> Kann es sein, dass die ETH-Truppe irgendwelche Versionsoder
>> Konsistenzmerkmale abprüft?
>>
>> Hast Du eine Ahnung, was ich machen muss?
>>
>> Gruß Dieter
>>
>> Am 19.01.2016 um 22:16 schrieb Peter Matthias:
>>> If object code size is the only real problem you likely can increase
>>> it by increasing the "CodeLength" constant in OPO.Mod and recompiling
>>> and reloading OPO.
>>> ARM and MIPS have 128k default codesize, but the compilers are not
>>> fully source code compatible with your code and code is less dense, so
>>> leaving about 70..90k compared to x86 code.
>>>
>>> Regards,
>>>     Peter
>>>
>>> Am 19.01.2016 um 09:21 schrieb Dieter:
>>>> Hallo Jörg,
>>>>
>>>> danke für Dein Interesse. Genauso, wie von dir beschrieben, bin ich 
>>>> das
>>>> Problem auch angegangen und habe es auch erfolgreich gelöst.
>>>>
>>>> Aber, wie gesagt, schramme ich bei jeder größeren Änderung an der
>>>> 64K-Grenze für Module herum, und fange dann an, nach Bytes zu suchen,
>>>> die ich einsparen kann.
>>>>
>>>> Meine Frage ist, ob es für den lowlayer (Datenbank oder Objektmodell)
>>>> bereits irgendwelche Hilfsmittel in Oberon gibt, mit denen man mein
>>>> Problem eleganter lösen könnte.
>>>>
>>>> Ich erinnere mich, dass es an der ETHZ z.B. Compilergeneratoren oder
>>>> Ähnliches gibt. Aber ich bin nur Physiker und zuwenig Informatiker, um
>>>> das einschätzen zu können.
>>>>
>>>> Und vielleicht wäre das auch mit Kanonen auf Spatzen geschossen.
>>>>
>>>> Gruß
>>>> Dieter
>>>>
>>>>
>>>>
>>>> Am 19.01.2016 um 08:37 schrieb Jörg Straube:
>>>>> Dieter
>>>>>
>>>>> Deine Aufgabe besteht eigentlich aus zwei Teilen
>>>>> 1) Syntax: Lowlayer Ein- und Ausgabe der zwei Sprachen (XML und TeX)
>>>>> 2) Semantik: Umwandeln bzw Mappen der beiden unterschiedlichen
>>>>> Datenmodelle beider Sprachen
>>>>>     XML scheint mir nach Stimme bzw Instrument sortiert, TeX scheint
>>>>> nach Takt sortiert.
>>>>>
>>>>> Du hast das richtig erkannt, dass du eine Art Objektmodell (du
>>>>> nanntest es Datenbank) als temporären Zwischenspeicher brauchst, das
>>>>> die Info aus beiden Datenmodellen beinhaltet.
>>>>> Nehmen wir mal an, das ganze Ave Maria hätte im Hauptspeicher Platz,
>>>>> dann brauchst du eine Routine, die das XML parst und mit der Hilfe
>>>>> vielen NEW()s als Objektmodell mit entsprechend Verlinkungen zum
>>>>> einfachen Navigieren innerhalb des Objektmodells im Hauptspeicher
>>>>> ablegst.
>>>>> Im zweiten Schritt liest eine andere Routine das Objektmodell in der
>>>>> von TeX geforderten Reihenfolge aus und generiert den TeX-Text.
>>>>>
>>>>> Das ist eigentlich vergleichbar mit einem Compiler: Er liest
>>>>> ASCII-Quelltext ein und gibt RISC5-Assemblercode aus :-)
>>>>> Auch da hast du einen Scanner, der die Lowlayer Syntax beherrscht
>>>>> (in dienem Fall XML) und einen Parser, der sich um die Semantik
>>>>> kümmert. (in deinem Fall die Instrumente und Takte)
>>>>>
>>>>> Wenn das Ave Mara nicht im Hauptspeicher Platz findet, wird’s
>>>>> komplizierter, da du dann entweder das Objektmodell in einer Datei
>>>>> zwischenspeichern musst, oder du das XML immer wieder von Beginn weg
>>>>> parst bis du bei dem Takt angelangt bist, den du via TeX gerade
>>>>> rausschreiben willst.
>>>>>
>>>>> Gruss
>>>>> Jörg
>>>>>> Am 18.01.2016 um 10:44 schrieb Dieter<d.gloetzel at web.de>:
>>>>>>
>>>>>> Doug,
>>>>>>
>>>>>> you are right. I should express myself more clearly.
>>>>>>
>>>>>> My overall theme is typesetting musical notes. There exists a
>>>>>> description language called "MusicXML" developed by RECORDARE Inc.,
>>>>>> which can be exported from several musical typesetting systems.
>>>>>> And there is a TeX based musical typesetting system called
>>>>>> "MusiXTeX" with a preprocessor called "PMX".
>>>>>>
>>>>>> I want to convert MusicXML as input to PMX. I have solved my
>>>>>> problem already by brute force Oberon programming, but I wonder
>>>>>> whether there is a more elegant way to do it.
>>>>>> My program is pretty long,  and several times I hit the compiler
>>>>>> limit of 64K for module size already. Also the modular layout may
>>>>>> be less then optimal.
>>>>>>
>>>>>> I am looking for something like a  database which makes accessible
>>>>>> the contents of the MusicXML file.
>>>>>>
>>>>>> I.e. answering questions like "What is the pitch and duration of
>>>>>> the 25th note in measure 10 of instrument 7?"
>>>>>>
>>>>>> I attach an example.
>>>>>>
>>>>>> It would be great, if somebody could share his experience in XML
>>>>>> programming with Oberon.
>>>>>>
>>>>>> Regards,
>>>>>> Dieter
>>>>>>
>>>>>> P.S.: I am using ETHOberon 2.5 plugin for Windows.
>>>>>>
>>>>>>
>>>>>> Am 18.01.2016 um 00:28 schrieb Dougls G. Danforth:
>>>>>>> Dieter,
>>>>>>> Your question is ambiguous.
>>>>>>> Do you mean a parser of Oberon written in XML?
>>>>>>> If so what is the output of the parser?
>>>>>>> Or do you mean a parser of Oberon that generates XML?
>>>>>>>
>>>>>>> -Doug Danforth
>>>>>>>
>>>>>>> On 1/17/2016 7:57 AM, Dieter wrote:
>>>>>>>> I wonder wether anybody on this mailing list knows about the
>>>>>>>> existence of an XML Parser API for Oberon.
>>>>>>>>
>>>>>>>> Thanks and regards,
>>>>>>>> Dieter Glötzel
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> ____________________________________
>>>>>> Dr. Dieter Glötzel
>>>>>> Im Rosengarten 27
>>>>>> 64367 Mühltal
>>>>>> Tel.: 06151 / 360 82 72
>>>>>>
>>>>>> <SchbAvMaSample.xml><AveMariaY.PMX><AveMariaY.pdf>--
>>>>>> 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
>>>>
>>>>
>>>> -- 
>>>> ____________________________________
>>>> Dr. Dieter Glötzel
>>>> Im Rosengarten 27
>>>> 64367 Mühltal
>>>> Tel.: 06151 / 360 82 72
>>>>
>>>>
>>>>
>>>> -- 
>>>> 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
>>>
>>
>>
>> -- 
>> ____________________________________
>> Dr. Dieter Glötzel
>> Im Rosengarten 27
>> 64367 Mühltal
>> Tel.: 06151 / 360 82 72
>>
>>
>>
>> -- 
>> 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
>

-- 
____________________________________
Dr. Dieter Glötzel
Im Rosengarten 27
64367 Mühltal
Tel.: 06151 / 360 82 72