<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo Peter,<br>
<br>
could it be that <i>MaxConstLegth</i> also plays a role?<br>
Or it is a limit of the Object File Format?<br>
<br>
from "OPO.Mod"<br>
================================================================<br>
(* code and data length per module *)<br>
CodeLength* = 65000; (* 64KByte Code Lenght per Module
*)<br>
MaxConstLength* = 64*1024; (* Max Const size allowed,
limited by Object File Format*)<br>
================================================================<br>
<br>
<br>
Regards, Dieter<br>
<br>
Am 20.01.2016 um 10:24 schrieb Dieter:<br>
</div>
<blockquote cite="mid:569F526A.8030203@web.de" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hallo Peter,<br>
<br>
danke, das scheint ein hilfreicher Tipp zu sein. Nur leider ist
es mir nicht gelungen, ihn zu implementieren.<br>
Was habe ich gemacht?<br>
1. OPO.Obj im Object-Directory unter anderem Namen gesichert.<br>
2. OPO.Mod im Source-Directory gesichert<br>
3. OPO.Mod geändert und kompiliert.<br>
4. OPO.Obj erscheint im Work-Directory.<br>
5. OPO.Obj ins Object-Directory kopiert.<br>
==> Nun funktioniert der Compiler nicht mehr.<br>
Dann habe ich alles rückabgewickelt und den alten Zustand mit
65000 Bytes wiederhergestellt, d.h. den ursprünglichen
Objectfile wiederverwendet.<br>
<br>
Kann es sein, dass die ETH-Truppe irgendwelche Versionsoder
Konsistenzmerkmale abprüft?<br>
<img src="cid:part1.01080302.08000101@web.de" alt=""><br>
Hast Du eine Ahnung, was ich machen muss?<br>
<br>
Gruß Dieter<br>
<br>
Am 19.01.2016 um 22:16 schrieb Peter Matthias:<br>
</div>
<blockquote cite="mid:569EA7BB.7070602@web.de" type="cite">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. <br>
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. <br>
<br>
Regards, <br>
Peter <br>
<br>
Am 19.01.2016 um 09:21 schrieb Dieter: <br>
<blockquote type="cite">Hallo Jörg, <br>
<br>
danke für Dein Interesse. Genauso, wie von dir beschrieben,
bin ich das <br>
Problem auch angegangen und habe es auch erfolgreich gelöst. <br>
<br>
Aber, wie gesagt, schramme ich bei jeder größeren Änderung an
der <br>
64K-Grenze für Module herum, und fange dann an, nach Bytes zu
suchen, <br>
die ich einsparen kann. <br>
<br>
Meine Frage ist, ob es für den lowlayer (Datenbank oder
Objektmodell) <br>
bereits irgendwelche Hilfsmittel in Oberon gibt, mit denen man
mein <br>
Problem eleganter lösen könnte. <br>
<br>
Ich erinnere mich, dass es an der ETHZ z.B.
Compilergeneratoren oder <br>
Ähnliches gibt. Aber ich bin nur Physiker und zuwenig
Informatiker, um <br>
das einschätzen zu können. <br>
<br>
Und vielleicht wäre das auch mit Kanonen auf Spatzen
geschossen. <br>
<br>
Gruß <br>
Dieter <br>
<br>
<br>
<br>
Am 19.01.2016 um 08:37 schrieb Jörg Straube: <br>
<blockquote type="cite">Dieter <br>
<br>
Deine Aufgabe besteht eigentlich aus zwei Teilen <br>
1) Syntax: Lowlayer Ein- und Ausgabe der zwei Sprachen (XML
und TeX) <br>
2) Semantik: Umwandeln bzw Mappen der beiden
unterschiedlichen Datenmodelle beider Sprachen <br>
XML scheint mir nach Stimme bzw Instrument sortiert, TeX
scheint nach Takt sortiert. <br>
<br>
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.
<br>
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. <br>
Im zweiten Schritt liest eine andere Routine das
Objektmodell in der von TeX geforderten Reihenfolge aus und
generiert den TeX-Text. <br>
<br>
Das ist eigentlich vergleichbar mit einem Compiler: Er liest
ASCII-Quelltext ein und gibt RISC5-Assemblercode aus :-) <br>
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) <br>
<br>
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.
<br>
<br>
Gruss <br>
Jörg <br>
<blockquote type="cite">Am 18.01.2016 um 10:44 schrieb
Dieter<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:d.gloetzel@web.de"><d.gloetzel@web.de></a>:
<br>
<br>
Doug, <br>
<br>
you are right. I should express myself more clearly. <br>
<br>
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. <br>
And there is a TeX based musical typesetting system called
"MusiXTeX" with a preprocessor called "PMX". <br>
<br>
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. <br>
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. <br>
<br>
I am looking for something like a database which makes
accessible the contents of the MusicXML file. <br>
<br>
I.e. answering questions like "What is the pitch and
duration of the 25th note in measure 10 of instrument 7?"
<br>
<br>
I attach an example. <br>
<br>
It would be great, if somebody could share his experience
in XML programming with Oberon. <br>
<br>
Regards, <br>
Dieter <br>
<br>
P.S.: I am using ETHOberon 2.5 plugin for Windows. <br>
<br>
<br>
Am 18.01.2016 um 00:28 schrieb Dougls G. Danforth: <br>
<blockquote type="cite">Dieter, <br>
Your question is ambiguous. <br>
Do you mean a parser of Oberon written in XML? <br>
If so what is the output of the parser? <br>
Or do you mean a parser of Oberon that generates XML? <br>
<br>
-Doug Danforth <br>
<br>
On 1/17/2016 7:57 AM, Dieter wrote: <br>
<blockquote type="cite">I wonder wether anybody on this
mailing list knows about the existence of an XML
Parser API for Oberon. <br>
<br>
Thanks and regards, <br>
Dieter Glötzel <br>
<br>
-- <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
-- <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
<br>
-- <br>
____________________________________ <br>
Dr. Dieter Glötzel <br>
Im Rosengarten 27 <br>
64367 Mühltal <br>
Tel.: 06151 / 360 82 72 <br>
<br>
<SchbAvMaSample.xml><AveMariaY.PMX><AveMariaY.pdf>--
<br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
</blockquote>
<br>
<br>
-- <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
</blockquote>
<br>
<br>
-- <br>
____________________________________ <br>
Dr. Dieter Glötzel <br>
Im Rosengarten 27 <br>
64367 Mühltal <br>
Tel.: 06151 / 360 82 72 <br>
<br>
<br>
<br>
-- <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
-- <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
____________________________________
Dr. Dieter Glötzel
Im Rosengarten 27
64367 Mühltal
Tel.: 06151 / 360 82 72</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
____________________________________
Dr. Dieter Glötzel
Im Rosengarten 27
64367 Mühltal
Tel.: 06151 / 360 82 72</pre>
</body>
</html>