<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">(email is my preferred communication media)<br>Aubrey McIntosh, Ph.D.</blockquote><div><br></div><div>You earned a PhD  without learning that "media" is plural?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 11:00 AM,  <span dir="ltr"><<a href="mailto:oberon-request@lists.inf.ethz.ch" target="_blank">oberon-request@lists.inf.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Oberon mailing list submissions to<br>
        <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:oberon-request@lists.inf.ethz.ch">oberon-request@lists.inf.ethz.ch</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:oberon-owner@lists.inf.ethz.ch">oberon-owner@lists.inf.ethz.ch</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Oberon digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. 64 bit ARM Kickstarter (<a href="mailto:Aubrey.McIntosh@Alumni.UTexas.Net">Aubrey.McIntosh@Alumni.UTexas.Net</a>)<br>
   2. Re: Non Oberon code in Oberon (J?rg Straube)<br>
   3. Re: Non Oberon code in Oberon / collateral question<br>
      (Chris Burrows)<br>
   4. Re: Non Oberon code in Oberon (Chris Burrows)<br>
   5. Re: XML Parser-API for OBERON (Dieter)<br>
   6. Re: XML Parser-API for OBERON (Dieter)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 19 Jan 2016 17:48:14 -0600<br>
From: <a href="mailto:Aubrey.McIntosh@Alumni.UTexas.Net">Aubrey.McIntosh@Alumni.UTexas.Net</a><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] 64 bit ARM Kickstarter<br>
Message-ID:<br>
        <<a href="mailto:CABbaiY6WzwcPWuR9pP4DeyROOgs8AXDixt39YnTENuzzzE17wg@mail.gmail.com">CABbaiY6WzwcPWuR9pP4DeyROOgs8AXDixt39YnTENuzzzE17wg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
There is a 64 bit Kickstarter project that will fund in a day or so.  I<br>
don't know if it is relevant to Oberon, I want to mention it so that<br>
someone more qualified might comment.<br>
<br>
<a href="https://www.kickstarter.com/projects/pine64/pine-a64-first-15-64-bit-single-board-super-comput" rel="noreferrer" target="_blank">https://www.kickstarter.com/projects/pine64/pine-a64-first-15-64-bit-single-board-super-comput</a><br>
<br>
--<br>
(email is my preferred communication media)<br>
Aubrey McIntosh, Ph.D.<br>
1502 Devon Circle<br>
Austin TX 78723-1814<br>
<a href="tel:%28512%29-348-7401" value="+15123487401">(512)-348-7401</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160119/55d7d4ed/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160119/55d7d4ed/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 20 Jan 2016 08:04:02 +0100<br>
From: J?rg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Non Oberon code in Oberon<br>
Message-ID: <<a href="mailto:46B9B912-0DF0-463D-A4C3-BB60E437FD49@iaeth.ch">46B9B912-0DF0-463D-A4C3-BB60E437FD49@iaeth.ch</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi all<br>
<br>
If you ever have to go that low level that a BIT is your best friend (eg in the case you program a device driver, directly interacting with HW pins like interrupt masks or so), I would use the type SET in Oberon.<br>
Each element in a SET occupies one BIT by definition<br>
Set several bits:  s := {0, 5, 7};  or s := s + {0, 5, 7};<br>
Set one bit            INCL(s, 4);  or   s := s + {4};<br>
Reset one bit       EXCL(s, 3);  or   s := s - {3};<br>
Test a bit               IF 3 IN s THEN (* bit 3 in the set "s" is set *)<br>
Test several bits IF s * {5, 7} = {} THEN (* either bit 5 or bit 7 in "s" is set *)<br>
<br>
For fans of HW and FPGA I can understand the wish to unify Oberon and Lola (or VHDL) but this was not the aim of Project Oberon in the first place. Oberon started with the idea to design a lean high level language that is easily mappable to a CPU to make the compiler construction easy. Unfortunately, today's CPUs have at least two properties not ideally suited for easy compiler construction: the instruction set is huge and complex and the instruction set is not "regular" ( =you can not apply all operations on all registers)<br>
In absence of such an easy, regular CPU NW designed its own Oberon-CPU. The costs to implement his CPU in eg ASIC is obviously forbiddingly high. So he implemented his Oberon-CPU (=RISC5) in FPGA.<br>
Wojtek's idea to apply Oberon also to that level of HW design is tempting but was not the foremost idea of Oberon. Important concepts like eg "clock" is missing.<br>
<br>
br, J?rg<br>
<br>
Am 20.01.2016 um 00:24 schrieb <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>> <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:<br>
<br>
>> BOOLEAN consumes one byte<br>
><br>
> In the FPGA world you would want BOOL to be one bit. Furthermore, you<br>
> would want logic expressions to get translated to hardware (that is VHDL<br>
> or Verilog) and then be compiled to HW modules that would act as<br>
> coprocessors. Such a translation would be optional of course.<br>
><br>
> It is not a pipedream because Xilinx is doing just that with their High<br>
> Level Synthesis.<br>
><br>
> I am throwing this in for an eager grad student as a worthy project. I<br>
> think that NW once had a dream of unifying Oberon with LOLA, but it was<br>
> too far ahead of its time.<br>
><br>
> Wojtek<br>
> ________________________________________<br>
> From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.ethz.ch</a>] on behalf of Douglas G.<br>
> Danforth [<a href="mailto:danforth@greenwoodfarm.com">danforth@greenwoodfarm.com</a>]<br>
> Sent: Tuesday, January 19, 2016 5:48 PM<br>
> To: ETH Oberon and related systems<br>
> Subject: Re: [Oberon] Non Oberon code in Oberon<br>
><br>
>> On 1/19/2016 12:41 PM, Lars O wrote:<br>
>>  Wait, there's BOOLEAN? hmm..<br>
> Yes, but BOOLEAN consumes one byte.<br>
><br>
><br>
> --<br>
> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: smime.p7s<br>
Type: application/pkcs7-signature<br>
Size: 2376 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/3b9830ea/attachment-0001.p7s" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/3b9830ea/attachment-0001.p7s</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 20 Jan 2016 18:44:56 +1030<br>
From: "Chris Burrows" <<a href="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>><br>
To: "'ETH Oberon and related systems'" <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Non Oberon code in Oberon / collateral question<br>
Message-ID: <002701d1535a$a637eca0$f2a7c5e0$@<a href="http://cfbsoftware.com" rel="noreferrer" target="_blank">cfbsoftware.com</a>><br>
Content-Type: text/plain;       charset="us-ascii"<br>
<br>
> -----Original Message-----<br>
> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br>
> Walter Gallegos<br>
> Sent: Wednesday, 20 January 2016 1:36 PM<br>
> To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
> Subject: Re: [Oberon] Non Oberon code in Oberon / collateral question<br>
><br>
> I'm curious, why if most in this mail list use Oberon for software<br>
> try Verilog for hardware descriptions ?<br>
> VHDL is by far more aligned with Pascal, and successors, than<br>
> Verilog.<br>
><br>
<br>
For me the reasons are:<br>
<br>
1. The HDL files in Project Oberon 2013 are 100% Verilog code.<br>
<br>
2. Wirth's Oberon-like Lola-2 HDL that runs on Project Oberon 2013 language<br>
generates Verilog code:<br>
<br>
<a href="http://people.inf.ethz.ch/wirth/Lola/index.html" rel="noreferrer" target="_blank">http://people.inf.ethz.ch/wirth/Lola/index.html</a><br>
<br>
If needed a VHDL that was more aligned with Pascal, and its successors then<br>
I would use Lola-2 as it is more like Oberon.<br>
<br>
3. I had no previous experience with an HDL before I started on<br>
ProjectOberon 2013.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 20 Jan 2016 19:15:03 +1030<br>
From: "Chris Burrows" <<a href="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>><br>
To: "'ETH Oberon and related systems'" <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Non Oberon code in Oberon<br>
Message-ID: <002b01d1535e$db764ed0$9262ec70$@<a href="http://cfbsoftware.com" rel="noreferrer" target="_blank">cfbsoftware.com</a>><br>
Content-Type: text/plain;       charset="UTF-8"<br>
<br>
> -----Original Message-----<br>
> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br>
> J?rg Straube<br>
> Sent: Wednesday, 20 January 2016 5:34 PM<br>
> To: ETH Oberon and related systems<br>
> Subject: Re: [Oberon] Non Oberon code in Oberon<br>
><br>
> Hi all<br>
><br>
> If you ever have to go that low level that a BIT is your best friend<br>
> (eg in the case you program a device driver, directly interacting<br>
> with HW pins like interrupt masks or so), I would use the type SET in<br>
> Oberon.<br>
> Each element in a SET occupies one BIT by definition Set several<br>
> bits:  s := {0, 5, 7};  or s := s + {0, 5, 7};<br>
> Set one bit            INCL(s, 4);  or   s := s + {4};<br>
> Reset one bit       EXCL(s, 3);  or   s := s - {3};<br>
> Test a bit               IF 3 IN s THEN (* bit 3 in the set "s" is<br>
> set *)<br>
> Test several bits IF s * {5, 7} = {} THEN (* either bit 5 or bit 7 in<br>
> "s" is set *)<br>
><br>
<br>
I agree. We use these techniques extensively for programming ARM devices using Oberon-7. You will see a lot of code like this for the device drivers:<br>
<br>
  IF uartNo = UART0 THEN<br>
    pconp := pconp + {3};<br>
    (* P0.2 Bits 5:4 = 01 TXD UART0 *)<br>
    (* P0.3 Bits 7:6 = 01 RxD UART0 *)<br>
    select := select - {5, 7} + {4, 6}<br>
  ELSIF uartNo = UART2 THEN<br>
<br>
If you look at attempts by C programmers to do something similar the results are much more obscure.<br>
<br>
We have also used sets to implement an array of bits in a prime number generating program:<br>
<br>
TYPE<br>
  PrimeArray = ARRAY (MaxPrimes DIV 32)+1 OF SET;<br>
<br>
VAR<br>
  Primes: PrimeArray;<br>
<br>
PROCEDURE* TestPrime(i: LONGINT): BOOLEAN;<br>
VAR<br>
  j: INTEGER;<br>
BEGIN<br>
  j := i MOD 32;<br>
  ASSERT((j >= 0) & (j <= 31));<br>
  RETURN ((j) IN Primes[i DIV 32])<br>
END TestPrime;<br>
<br>
Etc.<br>
<br>
Regards,<br>
Chris Burrows<br>
CFB Software<br>
<a href="http://www.astrobe.com/" rel="noreferrer" target="_blank">http://www.astrobe.com/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 20 Jan 2016 10:24:58 +0100<br>
From: Dieter <<a href="mailto:d.gloetzel@web.de">d.gloetzel@web.de</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] XML Parser-API for OBERON<br>
Message-ID: <<a href="mailto:569F526A.8030203@web.de">569F526A.8030203@web.de</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
Hallo Peter,<br>
<br>
danke, das scheint ein hilfreicher Tipp zu sein. Nur leider ist es mir<br>
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<br>
Bytes wiederhergestellt, d.h. den urspr?nglichen Objectfile wiederverwendet.<br>
<br>
Kann es sein, dass die ETH-Truppe irgendwelche Versionsoder<br>
Konsistenzmerkmale abpr?ft?<br>
<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>
> If object code size is the only real problem you likely can increase<br>
> it by increasing the "CodeLength" constant in OPO.Mod and recompiling<br>
> and reloading OPO.<br>
> ARM and MIPS have 128k default codesize, but the compilers are not<br>
> fully source code compatible with your code and code is less dense, so<br>
> 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>
>> 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>
>>> 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<br>
>>> Datenmodelle beider Sprachen<br>
>>>     XML scheint mir nach Stimme bzw Instrument sortiert, TeX scheint<br>
>>> nach Takt sortiert.<br>
>>><br>
>>> Du hast das richtig erkannt, dass du eine Art Objektmodell (du<br>
>>> nanntest es Datenbank) als tempor?ren Zwischenspeicher brauchst, das<br>
>>> die Info aus beiden Datenmodellen beinhaltet.<br>
>>> Nehmen wir mal an, das ganze Ave Maria h?tte im Hauptspeicher Platz,<br>
>>> dann brauchst du eine Routine, die das XML parst und mit der Hilfe<br>
>>> vielen NEW()s als Objektmodell mit entsprechend Verlinkungen zum<br>
>>> einfachen Navigieren innerhalb des Objektmodells im Hauptspeicher<br>
>>> ablegst.<br>
>>> Im zweiten Schritt liest eine andere Routine das Objektmodell in der<br>
>>> von TeX geforderten Reihenfolge aus und generiert den TeX-Text.<br>
>>><br>
>>> Das ist eigentlich vergleichbar mit einem Compiler: Er liest<br>
>>> ASCII-Quelltext ein und gibt RISC5-Assemblercode aus :-)<br>
>>> Auch da hast du einen Scanner, der die Lowlayer Syntax beherrscht<br>
>>> (in dienem Fall XML) und einen Parser, der sich um die Semantik<br>
>>> k?mmert. (in deinem Fall die Instrumente und Takte)<br>
>>><br>
>>> Wenn das Ave Mara nicht im Hauptspeicher Platz findet, wird?s<br>
>>> komplizierter, da du dann entweder das Objektmodell in einer Datei<br>
>>> zwischenspeichern musst, oder du das XML immer wieder von Beginn weg<br>
>>> parst bis du bei dem Takt angelangt bist, den du via TeX gerade<br>
>>> rausschreiben willst.<br>
>>><br>
>>> Gruss<br>
>>> J?rg<br>
>>>> Am 18.01.2016 um 10:44 schrieb Dieter<<a 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<br>
>>>> description language called "MusicXML" developed by RECORDARE Inc.,<br>
>>>> which can be exported from several musical typesetting systems.<br>
>>>> And there is a TeX based musical typesetting system called<br>
>>>> "MusiXTeX" with a preprocessor called "PMX".<br>
>>>><br>
>>>> I want to convert MusicXML as input to PMX. I have solved my<br>
>>>> problem already by brute force Oberon programming, but I wonder<br>
>>>> whether there is a more elegant way to do it.<br>
>>>> My program is pretty long,  and several times I hit the compiler<br>
>>>> limit of 64K for module size already. Also the modular layout may<br>
>>>> be less then optimal.<br>
>>>><br>
>>>> I am looking for something like a  database which makes accessible<br>
>>>> the contents of the MusicXML file.<br>
>>>><br>
>>>> I.e. answering questions like "What is the pitch and duration of<br>
>>>> 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<br>
>>>> 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>
>>>>> 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>
>>>>>> I wonder wether anybody on this mailing list knows about the<br>
>>>>>> existence of an XML Parser API for Oberon.<br>
>>>>>><br>
>>>>>> Thanks and regards,<br>
>>>>>> Dieter Gl?tzel<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>  mailing list for ETH Oberon and related<br>
>>>>>> systems<br>
>>>>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>>>>><br>
>>>>> --<br>
>>>>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>  mailing list for ETH Oberon and related<br>
>>>>> systems<br>
>>>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>>>><br>
>>>><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 href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>  mailing list for ETH Oberon and related<br>
>>>> systems<br>
>>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>><br>
>>><br>
>>> --<br>
>>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>  mailing list for ETH Oberon and related<br>
>>> systems<br>
>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>><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 href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>><br>
> --<br>
> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
><br>
<br>
<br>
--<br>
____________________________________<br>
Dr. Dieter Gl?tzel<br>
Im Rosengarten 27<br>
64367 M?hltal<br>
Tel.: 06151 / 360 82 72<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/e45547ae/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/e45547ae/attachment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: jcfijddj.png<br>
Type: image/png<br>
Size: 2489 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/e45547ae/attachment-0001.png" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/e45547ae/attachment-0001.png</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 20 Jan 2016 10:46:40 +0100<br>
From: Dieter <<a href="mailto:d.gloetzel@web.de">d.gloetzel@web.de</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] XML Parser-API for OBERON<br>
Message-ID: <<a href="mailto:569F5780.80600@web.de">569F5780.80600@web.de</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
Hallo Peter,<br>
<br>
could it be that /MaxConstLegth/ 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<br>
by Object File Format*)<br>
================================================================<br>
<br>
<br>
Regards, Dieter<br>
<br>
Am 20.01.2016 um 10:24 schrieb Dieter:<br>
> Hallo Peter,<br>
><br>
> danke, das scheint ein hilfreicher Tipp zu sein. Nur leider ist es mir<br>
> 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<br>
> Bytes wiederhergestellt, d.h. den urspr?nglichen Objectfile<br>
> wiederverwendet.<br>
><br>
> Kann es sein, dass die ETH-Truppe irgendwelche Versionsoder<br>
> Konsistenzmerkmale abpr?ft?<br>
><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>
>> If object code size is the only real problem you likely can increase<br>
>> it by increasing the "CodeLength" constant in OPO.Mod and recompiling<br>
>> and reloading OPO.<br>
>> ARM and MIPS have 128k default codesize, but the compilers are not<br>
>> fully source code compatible with your code and code is less dense,<br>
>> 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>
>>> 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>
>>>> 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<br>
>>>> Datenmodelle beider Sprachen<br>
>>>>     XML scheint mir nach Stimme bzw Instrument sortiert, TeX<br>
>>>> scheint nach Takt sortiert.<br>
>>>><br>
>>>> Du hast das richtig erkannt, dass du eine Art Objektmodell (du<br>
>>>> nanntest es Datenbank) als tempor?ren Zwischenspeicher brauchst,<br>
>>>> das die Info aus beiden Datenmodellen beinhaltet.<br>
>>>> Nehmen wir mal an, das ganze Ave Maria h?tte im Hauptspeicher<br>
>>>> Platz, dann brauchst du eine Routine, die das XML parst und mit der<br>
>>>> Hilfe vielen NEW()s als Objektmodell mit entsprechend Verlinkungen<br>
>>>> zum einfachen Navigieren innerhalb des Objektmodells im<br>
>>>> Hauptspeicher ablegst.<br>
>>>> Im zweiten Schritt liest eine andere Routine das Objektmodell in<br>
>>>> der von TeX geforderten Reihenfolge aus und generiert den TeX-Text.<br>
>>>><br>
>>>> Das ist eigentlich vergleichbar mit einem Compiler: Er liest<br>
>>>> ASCII-Quelltext ein und gibt RISC5-Assemblercode aus :-)<br>
>>>> Auch da hast du einen Scanner, der die Lowlayer Syntax beherrscht<br>
>>>> (in dienem Fall XML) und einen Parser, der sich um die Semantik<br>
>>>> k?mmert. (in deinem Fall die Instrumente und Takte)<br>
>>>><br>
>>>> Wenn das Ave Mara nicht im Hauptspeicher Platz findet, wird?s<br>
>>>> komplizierter, da du dann entweder das Objektmodell in einer Datei<br>
>>>> zwischenspeichern musst, oder du das XML immer wieder von Beginn<br>
>>>> weg parst bis du bei dem Takt angelangt bist, den du via TeX gerade<br>
>>>> rausschreiben willst.<br>
>>>><br>
>>>> Gruss<br>
>>>> J?rg<br>
>>>>> Am 18.01.2016 um 10:44 schrieb Dieter<<a 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<br>
>>>>> description language called "MusicXML" developed by RECORDARE<br>
>>>>> Inc., which can be exported from several musical typesetting systems.<br>
>>>>> And there is a TeX based musical typesetting system called<br>
>>>>> "MusiXTeX" with a preprocessor called "PMX".<br>
>>>>><br>
>>>>> I want to convert MusicXML as input to PMX. I have solved my<br>
>>>>> problem already by brute force Oberon programming, but I wonder<br>
>>>>> whether there is a more elegant way to do it.<br>
>>>>> My program is pretty long,  and several times I hit the compiler<br>
>>>>> limit of 64K for module size already. Also the modular layout may<br>
>>>>> be less then optimal.<br>
>>>>><br>
>>>>> I am looking for something like a  database which makes accessible<br>
>>>>> the contents of the MusicXML file.<br>
>>>>><br>
>>>>> I.e. answering questions like "What is the pitch and duration of<br>
>>>>> 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<br>
>>>>> 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>
>>>>>> 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>
>>>>>>> I wonder wether anybody on this mailing list knows about the<br>
>>>>>>> existence of an XML Parser API for Oberon.<br>
>>>>>>><br>
>>>>>>> Thanks and regards,<br>
>>>>>>> Dieter Gl?tzel<br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related<br>
>>>>>>> systems<br>
>>>>>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>>>>>><br>
>>>>>> --<br>
>>>>>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related<br>
>>>>>> systems<br>
>>>>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>>>>><br>
>>>>><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 href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related<br>
>>>>> systems<br>
>>>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related<br>
>>>> systems<br>
>>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>><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 href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related<br>
>>> systems<br>
>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>>><br>
>> --<br>
>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
>><br>
><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>
> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br>
<br>
--<br>
____________________________________<br>
Dr. Dieter Gl?tzel<br>
Im Rosengarten 27<br>
64367 M?hltal<br>
Tel.: 06151 / 360 82 72<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/d8a2c177/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/d8a2c177/attachment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: image/png<br>
Size: 2489 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/d8a2c177/attachment-0001.png" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/d8a2c177/attachment-0001.png</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Oberon Digest, Vol 140, Issue 14<br>
***************************************<br>
</blockquote></div><br></div>