[Oberon] XML Parser-API for OBERON

Wed Jan 20 17:00:35 CET 2016

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
>