[Oberon] Oberon Digest, Vol 140, Issue 14
Søren Renner
soren.renner at gmail.com
Wed Jan 20 13:46:03 CET 2016
>
> (email is my preferred communication media)
> Aubrey McIntosh, Ph.D.
You earned a PhD without learning that "media" is plural?
On Wed, Jan 20, 2016 at 11:00 AM, <oberon-request at lists.inf.ethz.ch> wrote:
> Send Oberon mailing list submissions to
> oberon at lists.inf.ethz.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
> oberon-request at lists.inf.ethz.ch
>
> You can reach the person managing the list at
> oberon-owner at lists.inf.ethz.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
>
>
> Today's Topics:
>
> 1. 64 bit ARM Kickstarter (Aubrey.McIntosh at Alumni.UTexas.Net)
> 2. Re: Non Oberon code in Oberon (J?rg Straube)
> 3. Re: Non Oberon code in Oberon / collateral question
> (Chris Burrows)
> 4. Re: Non Oberon code in Oberon (Chris Burrows)
> 5. Re: XML Parser-API for OBERON (Dieter)
> 6. Re: XML Parser-API for OBERON (Dieter)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 Jan 2016 17:48:14 -0600
> From: Aubrey.McIntosh at Alumni.UTexas.Net
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: [Oberon] 64 bit ARM Kickstarter
> Message-ID:
> <
> CABbaiY6WzwcPWuR9pP4DeyROOgs8AXDixt39YnTENuzzzE17wg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> There is a 64 bit Kickstarter project that will fund in a day or so. I
> don't know if it is relevant to Oberon, I want to mention it so that
> someone more qualified might comment.
>
>
> https://www.kickstarter.com/projects/pine64/pine-a64-first-15-64-bit-single-board-super-comput
>
> --
> (email is my preferred communication media)
> Aubrey McIntosh, Ph.D.
> 1502 Devon Circle
> Austin TX 78723-1814
> (512)-348-7401
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160119/55d7d4ed/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 20 Jan 2016 08:04:02 +0100
> From: J?rg Straube <joerg.straube at iaeth.ch>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Non Oberon code in Oberon
> Message-ID: <46B9B912-0DF0-463D-A4C3-BB60E437FD49 at iaeth.ch>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all
>
> 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.
> Each element in a SET occupies one BIT by definition
> Set several bits: s := {0, 5, 7}; or s := s + {0, 5, 7};
> Set one bit INCL(s, 4); or s := s + {4};
> Reset one bit EXCL(s, 3); or s := s - {3};
> Test a bit IF 3 IN s THEN (* bit 3 in the set "s" is set *)
> Test several bits IF s * {5, 7} = {} THEN (* either bit 5 or bit 7 in "s"
> is set *)
>
> 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)
> 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.
> 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, J?rg
>
> Am 20.01.2016 um 00:24 schrieb <skulski at pas.rochester.edu> <
> skulski at pas.rochester.edu>:
>
> >> BOOLEAN consumes one byte
> >
> > In the FPGA world you would want BOOL to be one bit. Furthermore, you
> > would want logic expressions to get translated to hardware (that is VHDL
> > or Verilog) and then be compiled to HW modules that would act as
> > coprocessors. Such a translation would be optional of course.
> >
> > It is not a pipedream because Xilinx is doing just that with their High
> > Level Synthesis.
> >
> > I am throwing this in for an eager grad student as a worthy project. I
> > think that NW once had a dream of unifying Oberon with LOLA, but it was
> > too far ahead of its time.
> >
> > Wojtek
> > ________________________________________
> > From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Douglas G.
> > Danforth [danforth at greenwoodfarm.com]
> > Sent: Tuesday, January 19, 2016 5:48 PM
> > To: ETH Oberon and related systems
> > Subject: Re: [Oberon] Non Oberon code in Oberon
> >
> >> On 1/19/2016 12:41 PM, Lars O wrote:
> >> Wait, there's BOOLEAN? hmm..
> > Yes, but BOOLEAN consumes one byte.
> >
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2376 bytes
> Desc: not available
> URL: <
> http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/3b9830ea/attachment-0001.p7s
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 20 Jan 2016 18:44:56 +1030
> From: "Chris Burrows" <chris at cfbsoftware.com>
> To: "'ETH Oberon and related systems'" <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Non Oberon code in Oberon / collateral question
> Message-ID: <002701d1535a$a637eca0$f2a7c5e0$@cfbsoftware.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > -----Original Message-----
> > From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> > Walter Gallegos
> > Sent: Wednesday, 20 January 2016 1:36 PM
> > To: oberon at lists.inf.ethz.ch
> > Subject: Re: [Oberon] Non Oberon code in Oberon / collateral question
> >
> > I'm curious, why if most in this mail list use Oberon for software
> > try Verilog for hardware descriptions ?
> > VHDL is by far more aligned with Pascal, and successors, than
> > Verilog.
> >
>
> For me the reasons are:
>
> 1. The HDL files in Project Oberon 2013 are 100% Verilog code.
>
> 2. Wirth's Oberon-like Lola-2 HDL that runs on Project Oberon 2013 language
> generates Verilog code:
>
> http://people.inf.ethz.ch/wirth/Lola/index.html
>
> If needed a VHDL that was more aligned with Pascal, and its successors then
> I would use Lola-2 as it is more like Oberon.
>
> 3. I had no previous experience with an HDL before I started on
> ProjectOberon 2013.
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 20 Jan 2016 19:15:03 +1030
> From: "Chris Burrows" <chris at cfbsoftware.com>
> To: "'ETH Oberon and related systems'" <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Non Oberon code in Oberon
> Message-ID: <002b01d1535e$db764ed0$9262ec70$@cfbsoftware.com>
> Content-Type: text/plain; charset="UTF-8"
>
> > -----Original Message-----
> > From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> > J?rg Straube
> > Sent: Wednesday, 20 January 2016 5:34 PM
> > To: ETH Oberon and related systems
> > Subject: Re: [Oberon] Non Oberon code in Oberon
> >
> > Hi all
> >
> > 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.
> > Each element in a SET occupies one BIT by definition Set several
> > bits: s := {0, 5, 7}; or s := s + {0, 5, 7};
> > Set one bit INCL(s, 4); or s := s + {4};
> > Reset one bit EXCL(s, 3); or s := s - {3};
> > Test a bit IF 3 IN s THEN (* bit 3 in the set "s" is
> > set *)
> > Test several bits IF s * {5, 7} = {} THEN (* either bit 5 or bit 7 in
> > "s" is set *)
> >
>
> 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:
>
> IF uartNo = UART0 THEN
> pconp := pconp + {3};
> (* P0.2 Bits 5:4 = 01 TXD UART0 *)
> (* P0.3 Bits 7:6 = 01 RxD UART0 *)
> select := select - {5, 7} + {4, 6}
> ELSIF uartNo = UART2 THEN
>
> If you look at attempts by C programmers to do something similar the
> results are much more obscure.
>
> We have also used sets to implement an array of bits in a prime number
> generating program:
>
> TYPE
> PrimeArray = ARRAY (MaxPrimes DIV 32)+1 OF SET;
>
> VAR
> Primes: PrimeArray;
>
> PROCEDURE* TestPrime(i: LONGINT): BOOLEAN;
> VAR
> j: INTEGER;
> BEGIN
> j := i MOD 32;
> ASSERT((j >= 0) & (j <= 31));
> RETURN ((j) IN Primes[i DIV 32])
> END TestPrime;
>
> Etc.
>
> Regards,
> Chris Burrows
> CFB Software
> http://www.astrobe.com/
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 20 Jan 2016 10:24:58 +0100
> From: Dieter <d.gloetzel at web.de>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] XML Parser-API for OBERON
> Message-ID: <569F526A.8030203 at web.de>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> 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-0001.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-0001.png
> >
>
> ------------------------------
>
> Message: 6
> Date: Wed, 20 Jan 2016 10:46:40 +0100
> From: Dieter <d.gloetzel at web.de>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] XML Parser-API for OBERON
> Message-ID: <569F5780.80600 at web.de>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Hallo Peter,
>
> could it be that /MaxConstLegth/ also plays a role?
> Or it is a limit of the Object File Format?
>
> from "OPO.Mod"
> ================================================================
> (* code and data length per module *)
> CodeLength* = 65000; (* 64KByte Code Lenght per Module *)
> MaxConstLength* = 64*1024; (* Max Const size allowed, limited
> by Object File Format*)
> ================================================================
>
>
> Regards, Dieter
>
> 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
>
>
> --
> ____________________________________
> 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/d8a2c177/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/png
> Size: 2489 bytes
> Desc: not available
> URL: <
> http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/d8a2c177/attachment-0001.png
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> ------------------------------
>
> End of Oberon Digest, Vol 140, Issue 14
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160120/a53f9ae8/attachment.html>
More information about the Oberon
mailing list