[Oberon] XML Parser-API for OBERON

Wed Jan 20 10:24:58 CET 2016

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/e45547ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcfijddj.png
Type: image/png
Size: 2489 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/e45547ae/attachment.png>