Re: [abcusers] reusable parser
Perhaps this is a good time to bring up the idea of a central set of parser test cases and test case fragments. In the past a number of list members have mentioned the desire to have a corporate body of test cases that could be used during testing and development of abc parsers. Perhaps this open source project could be a forum to officially start collecting those test cases. I've given several developers here copies of my CD-ROMs, as they're large, carefully transcribed collections, intended to be used far into the future, and where any idiosyncrasies are deliberate. The dialect of ABC I use is basically BarFly-with-the-bugs-fixed and without using some of the more arcane stuff. The idea is that if any incompatibilities should arise in futurw, it'll be clear enough what I meant that any musically knowledgeable user can fix the problem. The one important place where I've gone beyond anything BarFly has at present is in using part playing order for multivoice pieces with the same semantic model as in the 1.6 standard for monophonic ones. It's obvious what I mean but no software can interpret it yet; I have no intention of altering it until someone comes up with a syntax that expresses what I want, and meanwhile there are hundreds of CD-ROMs floating about with this construct done my way. There's a sample on my Music of Dalkeith website which has a bunch of ABC tunes with MIDI, QuickTime and GIF tadpole equivalents that I've generated and proofed myself, so the intended semantics is publicly available. I would suggest that test cases be documented the same way. This brings up another design/requirements issue when constructing this parser: to what degree should the parser be lenient with non-standard abc usage? For handling a large corpus (and preferably the entire corpus) you don't just want to be lenient, you want to provide error handling that will help a client disambiguate almost anything the most misinformed newbie might have tried with the aid of the least standard software or none at all. The musical content might still be valuable and the originator might be dead. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On 28 Apr 2004, at 01:52, John Norvell wrote: Perhaps this is a good time to bring up the idea of a central set of parser test cases and test case fragments. In the past a number of list members have mentioned the desire to have a corporate body of test cases that could be used during testing and development of abc parsers.Perhaps this open source project could be a forum to officially start collecting those test cases. I have a collection of tunes in graded levels of difficulty, which I use for this purpose. It covers only abc 1.6, but that's where you want to start anyway. It's at http://www.barfly.dial.pipex.com/testsuite1.6.abc and you are welcome to use it. Hmm, I hope that file name with two full stops doesn't cause problems. It works OK for me. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Tue, 27 Apr 2004, Stephen Kellett wrote: OSX presents an interesting portability challenge: The default file system has caseless file names. If you look around, you might not notice this, because mixed-case names abound. But the case of letters isn't significant when opening files. You have the same problem on Windows. Windows supports both upper and lower case letters in filenames, however filename matching is case insensitive. Try creating textfile.txt and Textfile.txt in the same directory. Can't do it. This thread is getting alittle bit off-topic, but I'm continuing it anyway ;-) I have an Atari Falcon030 computer running the FreeMiNT operating system. (Never heard of ? Never mind :-) It is a sort of hybrid OS a little bit like OSX. It is a mix of the TOS operating system that is in the ROM of classic Atari computers, combined with a Unix-like multitasking OS. I have several partitions on my harddisk with different filesystems. On one partition I have a ext2 system that is really case sensitive. On drive C:\ I need a FAT filesystem with the old fashion 8+3 case-insensitive DOS file names. On another drive I have VFAT: long filenames, with upper- and lowercase, but not really case-sensitive. Some of my old Atari apps have problems with case-sensitive and/or long filenames. These are installed on my old-fashioned C: drive. Other programs, like ported unix-apps, run on my ext2 drive. And I have some apps that need long filenames, but don't like case-sensitivity. I can do it all on my 25 years old Falcon. -- Martin Tarenskeen To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
It's looking promising so far, but as pointed out, maybe not a good idea to parse an entire abc tunebook in one go. It should at least have a selective option. The main idea behind a common parser would be to enforce a single and unambiguous version of the format. Currently, there are many extensions, some incompatible. The consequence is that it MUST be available to all the common languages and platforms, either as a single executable, or multiple instances of the SAME logic, or even source code, Linux style. This does place restrictions on the output format and design. For example, callbacks as suggested in one reply may not be available in the language in use. (I hesitate to suggest it, as I rejected the idea of ASCII output, but MusicXML might be a useful format, at least as an option, as there is already an XML parser available) At 01:15 PM 4/26/04, you wrote: What a coincidence! I recently discovered ABC, and decided that writing an ABC parser would be a great way to get up to speed on Boost's Spirit library. For details on spirit, see http://spirit.sourceforge.net/ I decided to get on this list to see if there were already resources available for parsing. I'm a C++ programmer, so I would want the parser written in C++. I've just started playing with it, but here are my musings so far: I see two tasks: agreeing on the data structure that is the output, and actually writing the parser. I envision a function that looks something like this: bool bSuccess = ParseABC(const char* szSource, CMusic output, CParsingErrors errors); Where output is a complex structure that contains a list of tunes, where each tune is a list of directives, and a list of lines made up of a list of notes, bar lines, etc. Creating the CMusic structure so that anything legal in the current or a future version of ABC can be expressed is crucial. CParsingErrors would be a list of errors it found with enough info that a smart program could help the user identify the problem. If possible, even with a syntax error, CMusic should contain as much as it can figure out safely, perhaps with a marker to the places that have syntax errors. It would be hard for me to envision a way to create the CMusic structure so that it would be readable in C or VB, because it would probably make heavy use of container classes. A wrapper could be provided, though. Anyway, as soon as I started thinking about actually doing something with this, I got very busy. I won't have much time to do anything except discuss until mid summer, but after that point, if I can help, I'd be happy to. Paul Rosen --- Life is a musical, every once in a while the plot stops and you start singing and dancing --- http://home.earthlink.net/~paulerosen/brbb/ http://home.earthlink.net/~theplums/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Paul Rosen [EMAIL PROTECTED] writes Here's a compromise: perhaps the parser can have a function like the above that takes only one tune, that is, takes a string that starts with X:, and ends just before the next X: command. Then there would be a super-parser (trivial to write) that breaks the string on X: boundaries. I'm guessing that most applications would be concerned with just one tune at a time, anyway. OK, we also need a function which can find the total number of tunes in the tune book (ie find the last X:). Also another to very the tune book is in good shape (are all X: markers in order). I think you'd just pass the tune number rather than the tune marker (X:) as that is a detail for the parser. Callback functions are ok, but they complicate the API. I'd rather aim for the simplest API we can get away with. Agreed. I use the Microsoft DbgHelp library a lot. You are forced to use Callbacks for shedloads of stuff, much of which (in my opinion without knowing the datastructures involved :-) shouldn't be necessary. Even to find out the number of symbols you have to iterate all the symbols via the callback. Totally crazy - anyway I wasn't advocating that, I would've asked for a separate function unsigned int numTunes(). Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk RSI Information:http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
From: Neil Jennings [EMAIL PROTECTED]
It's looking promising so far, but as pointed out, maybe not a good idea to
parse an entire abc tunebook in one go.
It should at least have a selective option.
The main idea behind a common parser would be to enforce a single and
unambiguous version of the format.
Currently, there are many extensions, some incompatible.
The consequence is that it MUST be available to all the common languages
and platforms, either as a single executable, or multiple instances of the
SAME logic, or even source code, Linux style.
That is an even stronger restriction than stated. It means that you must be
able to compile the same source code on Windows, Linux, and Macs. Doing it
Windows and Linux is possible in a number of languages. However, throwing
the Mac into the mix is another story because of the non-standard (indeed ,
ruinous IMHO) way the mac os's have been implemented.
By throwing them in, you are restricting things to (probably) either Java or
Python source code.
And of those two, only Python will actually run on all three without source
changed or massive #ifdef'ing depending on operating system.
This does place restrictions on the output format and design. For example,
callbacks as suggested in one reply may not be available in the language in
use.
Ah, yes. What do we output? Once again, the number of output technologies
available in common would seem to indicate either XML or INI format. They
are text based, and portable assuming we ignore the wierd end-of-line marker
problems on Macs.
I would vote for XML.
(I hesitate to suggest it, as I rejected the idea of ASCII output, but
MusicXML might be a useful format, at least as an option, as there is
already an XML parser available)
The only problem with MusicXML is that is will not transcribe many types of
music. Other than that, it works just fine ... sigh/
At 01:15 PM 4/26/04, you wrote:
What a coincidence!
I recently discovered ABC, and decided that writing an ABC parser would be
a
great way to get up to speed on Boost's Spirit library. For details on
spirit, see http://spirit.sourceforge.net/
I decided to get on this list to see if there were already resources
available for parsing.
I'm a C++ programmer, so I would want the parser written in C++.
I've just started playing with it, but here are my musings so far:
I see two tasks: agreeing on the data structure that is the output, and
actually writing the parser. I envision a function that looks something
like
this:
bool bSuccess = ParseABC(const char* szSource, CMusic output,
CParsingErrors errors);
How about a
class CABCSongIterator : public iterator { ... }
class CABCSongBook {
... CABCSongIterator ParseAbc(const char* source) throws
CABCParsingError { ... }
}
That way, errors will not be ignored, you cut down on the number of
parameters for a more efficient call, and you return what you are really
interested in. And, it takes zero code to check for errors.
Where output is a complex structure that contains a list of tunes, where
each tune is a list of directives, and a list of lines made up of a list
of
notes, bar lines, etc.
Creating the CMusic structure so that anything legal in the current or a
future version of ABC can be expressed is crucial.
Why? We already agree that the current standard won't cut it. Seems silly to
perpetuate the misteak, so to speak.
CParsingErrors would be a list of errors it found with enough info that a
smart program could help the user identify the problem. If possible, even
with a syntax error, CMusic should contain as much as it can figure out
safely, perhaps with a marker to the places that have syntax errors.
It would be hard for me to envision a way to create the CMusic structure
so
that it would be readable in C or VB, because it would probably make heavy
use of container classes. A wrapper could be provided, though.
Naw, it's called XML, and there are a half a dozen ways to do it. DOM, SAX,
JDOM, mindom, and so on.
Anyway, as soon as I started thinking about actually doing something with
this, I got very busy. I won't have much time to do anything except
discuss
until mid summer, but after that point, if I can help, I'd be happy to.
Paul Rosen
--- Life is a musical, every once in a while
the plot stops and you start singing and dancing ---
http://home.earthlink.net/~paulerosen/brbb/
http://home.earthlink.net/~theplums/
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
_
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage!
http://join.msn.com/?pgmarket=en-uspage=hotmail/es2ST=1/go/onm00200362ave/direct/01/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
The consequence is that it MUST be available to all the common languages and platforms, either as a single executable, or multiple instances of the SAME logic, or even source code, Linux style. I have a thought to interject here (I apologize if it's been mentioned before). One possibly ideal solution to the multiple languages problem is to express the parser in an intermediate language by which ABC parsers can be generated in several languages. In particular, I'm talking about ANTLR (www.antlr.org), which allows a user to create a parser grammar and then automatically generate lexer/parser/parse tree walkers from that one grammar in C++, Java, and C# (with Python on the way). I'm no expert on compilers, but it seems like the only bad thing about this solution is that ANTLR has a pretty strong learning curve, or so I hear. I've done quite a bit with JavaCC, which is a similar parser generator that has only Java output, and the grammar file for JavaCC is much clearer to understand (very similar to a BNF spec, like Henrik Norbeck's ABC grammar.) Jesse Plymale P.S.: There currently is a JavaCC grammar for basic 1.0 ABC in the ABC sourceforge repository, which might be of interest to those talking here. I was working on a JavaCC 2.0 grammar earlier this year, and still hope to finish it, but got distracted mid-semester and never got anything checked into CVS... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Tuesday, April 27, 2004, at 06:12 am, Stephen Kellett wrote: I think you are discussing a META API that sits on top of the parser API. A parser wouldn't know anything about playing, printing or displaying the tune/tunebook. Yes, I agree. However, once parsed, these Meta API's would provide simple access to the processed music. There is nothing to preclude direct access to the result of parsing. -- The penalty that good men pay for not being interested in politics is to be governed by men worse than themselves. -- Plato, philosopher (427-347 BCE) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Tue, Apr 27, 2004 at 12:01:00PM -0400, Steven Bennett wrote: Here's a compromise: perhaps the parser can have a function like the above that takes only one tune, that is, takes a string that starts with X:, and ends just before the next X: command. Then there would be a super-parser (trivial to write) that breaks the string on X: boundaries. I'm guessing that most applications would be concerned with just one tune at a time, anyway. Actually, this is sort of close to what my parser is doing, but you're missing one *very* important thing -- the file fields. At the beginning of the file (prior to the first X: or T:) and in-between tunes (ie. After the first blank line in a tune, which ends the tune, and before the next X: or T:) there may be a variety of settings which can affect the remaining tunes in the file. In the ABC spec, these are the fields marked Yes for File. Their existence complicates the job considerably. Note that while ABC 1.6 and 1.7.6 explicitly allow these fields in-between tunes, ABC 2.0 draft states they can only be at the beginning of a file. (There really ought to be a note about this in the Deprecated Syntax section... Or the restriction should be lifted.) Yes. One consequence of this restriction is that abc files can become invalid just by being cutpasted together. If you have 2 files, each with file-scope fields at the top, a simple cat file1.abc file2.abc file12.abc will produce a file with headers between tunes. Forbidding this may make life easier for simple parsers, but I don't think it's desirable for users. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Tuesday, April 27, 2004, at 10:25 am, Exu Yangi wrote: That is an even stronger restriction than stated. It means that you must be able to compile the same source code on Windows, Linux, and Macs. Doing it Windows and Linux is possible in a number of languages. However, throwing the Mac into the mix is another story because of the non-standard (indeed , ruinous IMHO) way the mac os's have been implemented. I think you are talking about a version of the Macintosh (OS 9 or Classic) that is no longer supported by Apple. Mac OS X has Unix at its core; FreeBSD 4.4 last time I checked (underneath that is Mach). Anyway, if you can build it for Linux/Unix, the Macintosh port is simple and straightforward especially if you are not using vendor-specific GUI libraries/frameworks. This is even easier with Mac OS 10.3 Panther because of the inclusion of Linux interfaces. Let's see, what are the truly cross platform languages I'm currently aware of: Python, Perl, Ruby, gcc (with C, C++, Obj-C), Java (sans Swing), Squeak/Smalltalk. I'm probably leaving out things like Eiffel, Lisp, and Scheme, but I haven't looked at them lately. jw -- The penalty that good men pay for not being interested in politics is to be governed by men worse than themselves. -- Plato, philosopher (427-347 BCE) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Jeff Szuhay [EMAIL PROTECTED] writes _open open fopen FileOpen OpenFile StandardFileOpen and not a single OpenEx in the lot. ...and absolutely no indication of which one follows on from the other. Typically Ex() is followed by Ex2() then Ex3() or whatever. If you don't like Ex(), fine, choose another extension. But the key thing is if you extending an API you don't think up an unrelated function name. OpenFile/StandardFileOpen - how would you guess they are related? Even the two common words are in reverse order. Stepehn -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk RSI Information:http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
The idea of going towards a common ABC parser is excellent. However it seems more urgent to me to define a ABC object model with its API (like made the W3C for DOM-XML) rather than to discuss choice of an implementation language. It is necessary that parseurs can be developed in various languages; each language is adapted to such or such application. In my university, a group of students worked on a ABC object model and produced a prototype of parser in Python, based on the draft of version 2. They led to the proposal for three object models: 1 - a structural model of the ABC files where the musical notation is not analyzed (considered as a simple string), useful for the reorganization and the indexing of ABC files, 2 - a model where the musical notation is analyzed in the automatic play point of view, 3 - a model where the musical notation is seen in the point of view of the printed partitions production. The distinction between items 2 and 3 was inspired by the approach of Music-XML. I am ready to lodge this project on SourceForge, but it is necessary as a preliminary to translate the documents into English, I am very busy in this moment and I will not be able to work there before July. So some are interested, contact me by then. Best regards Daniel -- Daniel Deveaux 8, rue de Campen - 56610 ARRADON Tel: 02 97 46 05 00 -- mailto:[EMAIL PROTECTED] Pouëvr'et Seu : http://pouevretseu.free.fr/ mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser - Why an Output Format?
In message [EMAIL PROTECTED], Christian M. Cepel [EMAIL PROTECTED] writes Exu Yangi wrote: Snip Ah, yes. What do we output? Once again, the number of output technologies available in common would seem to indicate either XML or INI format. They are text based, and portable assuming we ignore the wierd end-of-line marker problems on Macs. I would vote for XML. Maybe I'm stupid, but I don't understand this bit of the conversation. I would expect that a parser would not have ANY form of structured output for an entire tune, or an entire book of tunes. I don't understand why anyone would want to write a parser to parse a file and then spit out a new file (or buffer) of stuff that then itself has to be re parsed to be used??? Simply because abc is such a mish-mash (read: humanly readable) notation that the production of a structured output from it is the hard part. It's easy to write an XML parser (or other) in comparison. -- Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Steven Bennett writes: | | Actually, this is sort of close to what my parser is doing, but you're | missing one *very* important thing -- the file fields. At the beginning of | the file (prior to the first X: or T:) and in-between tunes (ie. After the | first blank line in a tune, which ends the tune, and before the next X: or | T:) there may be a variety of settings which can affect the remaining tunes | in the file. In the ABC spec, these are the fields marked Yes for File. | Their existence complicates the job considerably. | | Note that while ABC 1.6 and 1.7.6 explicitly allow these fields in-between | tunes, ABC 2.0 draft states they can only be at the beginning of a file. | (There really ought to be a note about this in the Deprecated Syntax | section... Or the restriction should be lifted.) Well, that pretty much eliminates the idea of combining abc files through any simple mechanism! It used to be you could just catenate the files, and optionally renumber the X: lines. But if two files both have such global fields at the start, the resulting file won't be in a legal syntax. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Jeff Szuhay writes: | On Tuesday, April 27, 2004, at 10:25 am, Exu Yangi wrote: | That is an even stronger restriction than stated. It means that you | must be able to compile the same source code on Windows, Linux, and | Macs. Doing it Windows and Linux is possible in a number of languages. | However, throwing the Mac into the mix is another story because of the | non-standard (indeed , ruinous IMHO) way the mac os's have been | implemented. | | I think you are talking about a version of the Macintosh (OS 9 or | Classic) that is no longer supported by Apple. Mac OS X has Unix at | its core; FreeBSD 4.4 last time I checked (underneath that is Mach). OSX presents an interesting portability challenge: The default file system has caseless file names. If you look around, you might not notice this, because mixed-case names abound. But the case of letters isn't significant when opening files. This has had several unfortunate effects in my abc collection. One thing I did in a numer of directories was, when I have versions of tunes in several keys, I've appended the key to the name. I've used the common classical notation in which upper case means major and lower case means minor. There are a few cases of tunes played in both major and minor. One you might like to try: Our klezmer gang discovered that Redwing works really well in minor, and sounds very Russian. Now the local contra crowd is playing it that way. So I have two files: polka/Redwing_G.abc polka/Redwing_g.abc No problem at all on my linux box, or on this FreeBSD machine, or on Solaris, or any other Unixoid system. For half a year or so I've also had a Mac PowerBook. When I copied the above directory to it, I ended up with the worst possible mess: There was just a polka/Redwing_G.abc file, and it contained the *minor* version of the tune. The second copy found that the file name was already in use (with a different capitalization), so instead of creating the polka/Redwing_g.abc file, it just put the new data into the polka/Redwing_G.abc file. Now, this sort of collision didn't happen often. But on my older linux box, I have about 170,000 files, and there were at least 600 such case collisions. Not many, but a real headache to find and fix. Tune files were a minor part of the problem. When they're inside some package that you've downloaded, fixing the filename problems can be nearly impossible. It's interesting how vendors can make tiny changes to standards and produce a real headache for people trying to make their computers behave sanely and sensibly. There are a lot of good ideas in OSX. But, as with Apple's old nonstandard CR as line separator idea, this little thing of caseless filename matching turns out to be a major monkey wrench tossed into the unix machinery. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Any sensible project should start with agreed requirements, which will be
classified as
1. Mandatory
2. Desirable
3. Optional.
I suggest that the first stage should be requirement gathering - initially
high-level.
Details of code should be left to a later stage.
We should also consider a format Change Request process by which changes
can be approved later.
Having these in place will assist in management and control
At 04:30 AM 4/27/04, you wrote:
OK, I usually just shut up and lurk, but (perhaps) I might have a suggestion.
From: Jeff Szuhay [EMAIL PROTECTED]
Here is yet another approach... It is an API which has the concept of
opening a song, getting 1 or more measures from it, and then closing
the song. I think in terms of C and C++ so please forgive the syntactical
stricnine.
ABCSong * pSong;
ABCMeasure * pMeasure;
pSong = new ABCSong( ... ); // allocates ABC song object for header
info, voices, et.c
pSong-Open( file , song_title, ... ); // open file, read song
contents and info.
pSong-Verify(); // parse song to see if its valid // song is
good, process it...
//Now, perhaps another way (More C++ ish. Sorry)
SongBookStreamReader sbs(filename);
while(sbs) {
SongBook sb ;
sbs sb ;
SongStreamReader ssr(sb);
while(ssr) {
Song song ;
ssr song;
Measure measure ;
MeasureStreamReader msr(song); // can also MeasureStreamReader(sb), c
while(msr) {
msr measure;
NoteStreamReader nsr(measure); // same can also here ...
while(nsr) {
Note note ;
nsr note ;
// OK, do something with the note ...
}
}
}
}
while( pSong-MoreNotes() )
{
...
...
pMeasure = pSong-GetMeasure(...);
pMeasure.Play();
pMeasure.Print( window settings, ... );
,,,
,,,
}
pSong-Close();
while(pSong
...
This assumes defined objects ABCSong and ABCMeasure which I've invented
surreptitiously.
I'm thinking along these lines because I want an ABC parser that I can
process a measure
at a time. So this would be my initial stab at these needs; I don't know
if this is ultimately
what I need.
Anyway, this simple model could be used for just playing, just
printing/displaying, or both.
However, the idea of the ABCMeasure as an arbitrary aggregation of notes
could further be
aggregated into a Line for printing and other notation adjustment.
In this manner, the interface is simple and direct. Versioning info can
be embedded in the
objects themselves without the need for that nasty ...Ex() convention.
Instead, there may
be some reflective API's like GetVersion() or GetCapability() on the
parser/player that
would permit many more variants over a longer lifecycle.
--
The penalty that good men pay for not being interested in politics
is to be governed by men worse than themselves.
-- Plato, philosopher (427-347 BCE)
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
_
MSN Toolbar provides one-click access to Hotmail from any Web page FREE
download! http://toolbar.msn.com/go/onm00200413ave/direct/01/
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
We seem to be drifting some way off the topic. (The number of buttons on a mouse, the case-sensitivity of filenames, etc.) Requirements and feasibility should come first The most fundamental requirement is that a single version of abc is parsed in only one way. All dependent programs can then be sure of working with the same information. It is very likely that the work for this would in itself result in a new version of abc, as many of the ambiguities are addressed. This would then be THE definitive version, and be maintained under proper change control. Some notes: Why the need for an output? - as asked earlier It all depends on whether we want to support non-object environments directly, or maybe write some kind of extract process. Do we need a single executable? e.g. Although a common executable would be ideal, executables derived from a common source would be acceptable. C++ or a variant of it still looks the strongest contender Neil To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Tue, Apr 27, 2004 at 09:25:27PM +0100, Neil Jennings wrote: Do we need a single executable? e.g. Although a common executable would be ideal, executables derived from a common source would be acceptable. I think a library would be better. So that other people who want to write programs that need ABC parsing can use it. People using ABC already have their own favourite programs; if you provide just one more ABC executable, it'll have to be extraordinarily all-singing, all-dancing, multi-output, etc etc, to persuade people to switch. If it's a library, other people can do the work of producing whatever behaviour they want from their executables. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
John Chambers wrote: Yeah, but you could argue that it's not as big a problem with Windows, because Windows (and MSDOS) is a separate OS that is its own standard and has never been even minimally compatible with any other system. People expect that porting software to Windows will be a big deal, and will require a lot of rewriting. OSX is, however, a variant of unix. Much unix software runs on it without problems. They even seem to have fixed most of the problems with the aberrant CR line terminators, and switched over to the standard LF terminators. And OSX is pushed as a member of the unix family of systems. So you start using it, and discover this one really nasty little gotcha ... Actually, back in 1982 when I first learned UNIX (actually Idris, the first commercial UNIX lookalike...), it was pounded into me that one should never take the case-dependence of the file system for granted, since there were *already* case-independent file systems out there that could be accessed with the right drivers. (Admittedly, those file systems were mostly on *floppy* disks, but the basic concept is still the same... ;) This was reinforced on the C side of things (which I was learning at the same time), because assuming case dependencies in filenames were considered non-portable in any case. (And back then, writing portable code was considered by us to be even more important than today...) Yes, the case independence of HFS+ (the default Mac OS X filesystem) is an issue if you got in the habit of naming two files the same except for case, but, IMHO, that has ALWAYS been a bad UNIX practice. If you never got into that habit, you shouldn't run into any problems on the Mac. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Tue, Apr 27, 2004 at 12:01:00PM -0400, Steven Bennett wrote: Note that while ABC 1.6 and 1.7.6 explicitly allow these fields in-between tunes, ABC 2.0 draft states they can only be at the beginning of a file. (There really ought to be a note about this in the Deprecated Syntax section... Or the restriction should be lifted.) Yes. One consequence of this restriction is that abc files can become invalid just by being cutpasted together. If you have 2 files, each with file-scope fields at the top, a simple cat file1.abc file2.abc file12.abc will produce a file with headers between tunes. Forbidding this may make life easier for simple parsers, but I don't think it's desirable for users. Actually, that's an issue in all versions of ABC, because the file-scope fields at the top of file1.abc that are not overridden in the header of file2.abc would then apply to all the tunes in file2.abc, even if that would be inappropriate. I actually now believe (having written that part of the parser) that what should be in ABC 2 is either NO file-scope fields allowed, or they should be allowed anywhere outside a tune. The halfway measure of allowing them only at the start of the file can make parsers slightly more simple, but doesn't really simplify things all *that* much, and not at all unless you are parsing *strict* ABC 2.0 only. NO file-scope fields would be the ideal solution, letting you split and merge tune collections seamlessly. But since I doubt that would be accepted (and still has the issue of parsing pre-ABC 2.0 files anyway), I suggest we let those file-scope fields be anywhere outside tunes. IMHO, --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Neil Jennings [EMAIL PROTECTED] writes e.g. Although a common executable would be ideal, executables derived from a common source would be acceptable. I was thinking executable (most likely a library/DLL) derived from a common source. C++ or a variant of it still looks the strongest contender Yes Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk RSI Information:http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Wow, I'm impressed by all the activity since I last checked email! 1) If we stick to standard C++, and depend only on libraries that are also standard, we won't have a porting problem to any OS that has a conforming C++ compiler. 2) We still have a porting issue to VC and C, but that can be overcome by having a set of helper functions in a library that take the output object as an argument. 3) boost and spirit are both ported to all important compilers so would be good libraries to help with the parsing. 4) I think the most important part of the work is specifying the output object. The details of actually doing the coding are not as critical. If we standardize on the output object, though, then everyone could get moving on making their apps compatible. Making an object that is easy to use and handles every case will be difficult, but I'm sure it is possible, especially if there are access functions. 5) I like the idea of having a tune be the atom. The file fields is an issue that needs to be handled, probably by the super parser. We might need to pass both the active file fields and the tune to the parser. Both a play back program and a music printing program are interested in one tune at a time, and they are common types of programs. 6) We could make the super parser part of the package, too, so there are two functions we support: break the file into tunes, and parse the tunes. Paul Rosen --- Life is a musical, every once in a while the plot stops and you start singing and dancing --- http://home.earthlink.net/~paulerosen/brbb/ http://home.earthlink.net/~theplums/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Tuesday, April 27, 2004, at 08:52 pm, John Norvell wrote: Perhaps this is a good time to bring up the idea of a central set of parser test cases and test case fragments. In the past a number of list members have mentioned the desire to have a corporate body of test cases that could be used during testing and development of abc parsers.Perhaps this open source project could be a forum to officially start collecting those test cases. Excellent! This is the best idea yet. -- The penalty that good men pay for not being interested in politics is to be governed by men worse than themselves. -- Plato, philosopher (427-347 BCE) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Richard Robinson [EMAIL PROTECTED] writes (I have the same perception of sourceforge, by the way. I find it difficult and confusing, sometimes impossible, to find my way round it.) That is not reassuring - for me it is reassuring - but sourceforge should be easy to understand. API for 3rd parties to make use of in applications ? Maybe, ideally, a standalone library package ? A library with a published, backwards compatible API. It would be nice. APIs would be added, never removed and not changed once present. If you needed to change an API, you'd create an Ex() version of it, ala Microsoft. My preference is for a library (a DLL or equivalent on Unix boxes), rather than a callable program or source to embed in the app (*). (*) Embedding source in the app prevents you using the LGPL licence (see below), unless someone knows better. ...), so there's mutual ignorance. It _would_ be valuable to have one that could be usable on as many platforms as possible. Apart from Java, WxWidgets seems to be the most viable framework (that I know of), so maybe C++ that would be compatable with this ? If you write in C/C++ you can provide a native interface for Java, Python, .net, etc very easily. I've written Java Native Interface code. Its straightforward. Conversely if you write it in Java, yes the Java is portable, but anyone wishing to use it from another language also has to install the whole Sun (or other vendor) JVM. I do some work for blind people using Java and the last Java download from sun was 36MB (that was the SMALL download, the larger one was 114MB!). And that is just to run the Java app - the 36MB doesn't include the compiler etc, etc. Same for .Net apps, you are relying on the target platform to have the .Net framework installed. Eventually this won't be a problem, even on Linux boxes as the free Rotor project is addressing this. LGPL license would be good. Would allow people to use the library without forcing them to GPL their own code. That would encourage the commercial ABC writers to start using the common ABC engine rather than their own implementation. If you GPL the common ABC engine the commercial vendors won't touch it with a barge pole, thus you'll end up with the same situation as now (multiple implementations with no hope of a common implementation at some point in the future). Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk RSI Information:http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
What a coincidence! I recently discovered ABC, and decided that writing an ABC parser would be a great way to get up to speed on Boost's Spirit library. For details on spirit, see http://spirit.sourceforge.net/ I decided to get on this list to see if there were already resources available for parsing. I'm a C++ programmer, so I would want the parser written in C++. I've just started playing with it, but here are my musings so far: I see two tasks: agreeing on the data structure that is the output, and actually writing the parser. I envision a function that looks something like this: bool bSuccess = ParseABC(const char* szSource, CMusic output, CParsingErrors errors); Where output is a complex structure that contains a list of tunes, where each tune is a list of directives, and a list of lines made up of a list of notes, bar lines, etc. Creating the CMusic structure so that anything legal in the current or a future version of ABC can be expressed is crucial. CParsingErrors would be a list of errors it found with enough info that a smart program could help the user identify the problem. If possible, even with a syntax error, CMusic should contain as much as it can figure out safely, perhaps with a marker to the places that have syntax errors. It would be hard for me to envision a way to create the CMusic structure so that it would be readable in C or VB, because it would probably make heavy use of container classes. A wrapper could be provided, though. Anyway, as soon as I started thinking about actually doing something with this, I got very busy. I won't have much time to do anything except discuss until mid summer, but after that point, if I can help, I'd be happy to. Paul Rosen --- Life is a musical, every once in a while the plot stops and you start singing and dancing --- http://home.earthlink.net/~paulerosen/brbb/ http://home.earthlink.net/~theplums/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Jeff Szuhay [EMAIL PROTECTED] writes On Sunday, April 25, 2004, at 03:47 pm, Stephen Kellett wrote: If you needed to change an API, you'd create an Ex() version of it, ala Microsoft Yuk. Please do not fall prey to the habits of an 800-lb gorilla. Microsoft's bad design habits should not be relied upon as any sort of standard practice. No, that *is* precisely good practice. Have you never written a library of routines for use in several programs? Then for program 7, you improve on of the routines in the library by altering it. Maybe you even fix a bug in it. Then later you come back to change Program 3: maybe you even simply recompile it without improvement. But it's broken because the library has changed. Nope: once frozen in the library, NEVER change it. Always add a new API with a new name. Common sense. -- Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Paul Rosen [EMAIL PROTECTED] writes I see two tasks: agreeing on the data structure that is the output, and actually writing the parser. I envision a function that looks something like this: bool bSuccess = ParseABC(const char* szSource, CMusic output, CParsingErrors errors); There is another approach. I haven't seen it mentioned, so I apologize if I am covering old ground. I have seen ABC files with 17000 tunes in them. They take a long time to parse :-) Just a thought, but --- I like the idea of getting a tune in a single chunk, but I can see how my solution above is not scalable to a large tune book. Here's a compromise: perhaps the parser can have a function like the above that takes only one tune, that is, takes a string that starts with X:, and ends just before the next X: command. Then there would be a super-parser (trivial to write) that breaks the string on X: boundaries. I'm guessing that most applications would be concerned with just one tune at a time, anyway. Callback functions are ok, but they complicate the API. I'd rather aim for the simplest API we can get away with. Paul Rosen --- Life is a musical, every once in a while the plot stops and you start singing and dancing --- http://home.earthlink.net/~paulerosen/brbb/ http://home.earthlink.net/~theplums/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
OK, I usually just shut up and lurk, but (perhaps) I might have a
suggestion.
From: Jeff Szuhay [EMAIL PROTECTED]
Here is yet another approach... It is an API which has the concept of
opening a song, getting 1 or more measures from it, and then closing
the song. I think in terms of C and C++ so please forgive the syntactical
stricnine.
ABCSong * pSong;
ABCMeasure * pMeasure;
pSong = new ABCSong( ... ); // allocates ABC song object for header info,
voices, et.c
pSong-Open( file , song_title, ... ); // open file, read song contents
and info.
pSong-Verify(); // parse song to see if its valid // song is good,
process it...
//Now, perhaps another way (More C++ ish. Sorry)
SongBookStreamReader sbs(filename);
while(sbs) {
SongBook sb ;
sbs sb ;
SongStreamReader ssr(sb);
while(ssr) {
Song song ;
ssr song;
Measure measure ;
MeasureStreamReader msr(song); // can also MeasureStreamReader(sb), c
while(msr) {
msr measure;
NoteStreamReader nsr(measure); // same can also here ...
while(nsr) {
Note note ;
nsr note ;
// OK, do something with the note ...
}
}
}
}
while( pSong-MoreNotes() )
{
...
...
pMeasure = pSong-GetMeasure(...);
pMeasure.Play();
pMeasure.Print( window settings, ... );
,,,
,,,
}
pSong-Close();
while(pSong
...
This assumes defined objects ABCSong and ABCMeasure which I've invented
surreptitiously.
I'm thinking along these lines because I want an ABC parser that I can
process a measure
at a time. So this would be my initial stab at these needs; I don't know if
this is ultimately
what I need.
Anyway, this simple model could be used for just playing, just
printing/displaying, or both.
However, the idea of the ABCMeasure as an arbitrary aggregation of notes
could further be
aggregated into a Line for printing and other notation adjustment.
In this manner, the interface is simple and direct. Versioning info can be
embedded in the
objects themselves without the need for that nasty ...Ex() convention.
Instead, there may
be some reflective API's like GetVersion() or GetCapability() on the
parser/player that
would permit many more variants over a longer lifecycle.
--
The penalty that good men pay for not being interested in politics
is to be governed by men worse than themselves.
-- Plato, philosopher (427-347 BCE)
To subscribe/unsubscribe, point your browser to:
http://www.tullochgorm.com/lists.html
_
MSN Toolbar provides one-click access to Hotmail from any Web page FREE
download! http://toolbar.msn.com/go/onm00200413ave/direct/01/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Jack Campin [EMAIL PROTECTED] writes Resource economy is a non-issue - it's not going to be that big and by the time it's done, any computer that will use it will be much, much bigger and faster than anything now running ABC software. I don't see what you are getting at. Writing the code so that it is maintainable will be more easily done with C++ than C. The amount of memory or speed of the processor is a non-issue and was not what I was referring to. Sharing by reference is a great way to make code less maintainable, and parsers don't need to do it, ever. I didn't say it was. Java and C# are touted as good because everything is pass by reference. Neither truly implement pass by reference. Neither is pass by reference a suitable mechanism by which all data should be passed. I dislike both languages for the very reason they prevent you from making good choices in software design. If they were easier to compile into libraries, SML, Haskell, Lisp or Prolog would be better options - they all have a hell of a lot of accumulated experience in use for parsing refractory syntaxes. Be my guest. I think you'll be able to count the number of volunteers on the fingers of your left hand :-) C++ can do everything C can do, but much better and there are a lot of people capable of using the language well, not to mention many free compilers and linkers around from GNU/Borland and more recently, Microsoft's Visual Studio 7.1 compiler toolchain is also free. Pragmatism dictates either C/C++ or VB, due to the number of people skilled in the language and then who wish to donate their time to such a cause. C/C++ knocks out the VBers, and VB will probably have the same effect of the C/C++ people unless they are interested in cross training to VB. C/C++ give more freedom of expression than VB. Is this a case of if the only tool you have is a hammer, every problem looks like a folk singer? No. I was commenting on the recommended use of C with a sideswipe at the current trendy languages being promoted by the industry. How you could arrive at the comment above from what I wrote is beyond me. A Ferrari will get me from my house to my girlfriends house faster than my car will (much as a one of the languages you cite may write a better parser). Pragmatism dictates I don't have the budget for the Ferrari, so I'll make do with the Volkswagon. Pragmatism likewise dictates for an open source project you go with the programming volunteers and maintainability options available, so C++/VB/Python/etc are the likely candidates, not the languages you cite. Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk RSI Information:http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Top posting (like this) makes it impossible to see which particular point you are replying to. If read my reply to Jack's post you can see clearly which parts of his article I comment on. Top posting is a context free way of replying. So much of the relevant information is lost (or can only be regained by you re-reading the original article, which is a gross waste of time). It really is totally worthless. Which is why I hardly ever do it, except to explain why it is so worthless. Stephen In message [EMAIL PROTECTED], Christian M. Cepel [EMAIL PROTECTED] writes Jack Campin wrote: \[order fixed - please don't top-post] Stephen Kellett wrote: Christian M. Cepel [EMAIL PROTECTED] writes I would assume that such a beast would be written in straight ansi c to make it available to any present or future operating system sporting a c compiler, as well as to make it as small and as resource non-intensive as possible. C++ Surely? C is very restrictive in comparison. Writing object based code in C is hard work (read: un-necessary extra code, and lack of type safety) compared to C++. Resource economy is a non-issue - it's not going to be that big and by the time it's done, any computer that will use it will be much, much bigger and faster than anything now running ABC software. Java and C# are not worthwhile alternatives. Both quite restrictive because nothing is truly passed as a reference (try modifying a string object you pass in and see if it really was changed after the call - if it was really passed as a reference it would be). Makes things trivial in C and C++ a real pain in Java and C#. But, things relevant to this problem? Sharing by reference is a great way to make code less maintainable, and parsers don't need to do it, ever. If they were easier to compile into libraries, SML, Haskell, Lisp or Prolog would be better options - they all have a hell of a lot of accumulated experience in use for parsing refractory syntaxes. Is this a case of if the only tool you have is a hammer, every problem looks like a folk singer? - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html I'm afraid you've lost me once again. I suffer from small brain condition. I'm not sure if you're for or against the idea of an open source shared parsing engine, and for it, what shape you suggest it take. I also fail to see the concern with top posting, but then I spoze people must have their pet peeves. -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk RSI Information:http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Keep it in C++. Anyone can compile and use a C++ program. I would suggest using a GNU based GCC. It can then easily be compiled on about any OS using GCC, MinGW, etc... and the binary can be used by someone who does not have the proper run time. Jeremy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Jeremy Cowgar wrote: Keep it in C++. Anyone can compile and use a C++ program. I would suggest using a GNU based GCC. It can then easily be compiled on about any OS using GCC, MinGW, etc... and the binary can be used by someone who does not have the proper run time. Jeremy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html There seems to be considerable interest in the idea, as well as a lot of differing opinions as to how to implement the idea. No one has yet said anything against the choice of sourceforge to give the project structure and direction. Can anyone offer any reasons this is not a good idea? I'm not sure if that was Jack's intentions, or if he was discussing implementation ideas. Stephen seemed better able to understand the intent, and it left me a bit clearer. Anyways. if anyone is harboring reservations against the idea, please speak up. There ideas that seem good that should still _not_ be implemented. If you have a reason, please share. But... Since most seems positive, even if the details might be left to be hashed out... Does anyone feel up to stepping up to the plate as head of such a project. Bert has made a kind offer, but I must admit that I don't have the knowledge to know quite what he's offering. I guess the job description asks for someone who is more of a systems analyst, than strictly a programmer. Someone who is capable of seeing the project through the long haul, capable of negotiating seas of differing opinions and ideas, capable of understanding the nitty gritty of building such a beast, and capable of arbitrating and encouraging a group of what are typically an egocentric bunch of programmers with vastly different skills and backgrounds. Submit your resumes *laugh*. Guess I need to get me a SourceForge account... And talk the lovely wife into the letting me budget the expense. That is of course assuming the eventual leader will accept me as a contributing team member :) //Christian -- //Christian Christian Marcus Cepel| And the wrens have returned [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again.--Rich Mullins To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
In message [EMAIL PROTECTED], Christian M. Cepel [EMAIL PROTECTED] writes Can anyone offer any reasons this is not a good idea? I've never taken part in a sourceforge project, but every sourceforge project, without exception, that I have visited, I have been left feeling very confused as to which code to download, should I decide to download. I find this confusing, given that my software experience is now entering its 3rd decade. Lord knows how beginners get on with sourceforge. I recently visited the mingw free compiler/gnu for windows site and was so confused about which package I should download I didn't download a thing (I had a choice of about 20 to 30 odd with no decent description of each). That said, there are a lot of projects happening there, so maybe its just a perception thing and I think in different ways to the people that designed sourceforge. typically an egocentric bunch of programmers with vastly different skills and backgrounds. You know your target audience :-) Sadly I can't take part in this. I'm committed to many other projects already. These take up crazy amounts of my time without me trying to do another one. Isn't that nice, the NT box has just BSOD'd. Wonderful. Stephen -- Stephen Kellett Object Media Limitedhttp://www.objmedia.demon.co.uk RSI Information:http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
On Sun, Apr 25, 2004 at 06:15:21PM +0100, Stephen Kellett wrote: typically an egocentric bunch of programmers with vastly different skills and backgrounds. You know your target audience :-) grin These comments aren't really intended to follow on from that, it's just a convenient way of jumping in. Honest. No, really ... (I have the same perception of sourceforge, by the way. I find it difficult and confusing, sometimes impossible, to find my way round it.) Mainly, I'd like to back off from the details - languages, websites, c - and ask, what is the purpose of this project; what are people intending to produce here ? It seems to me that a lot of attempts over the last few years to clarify thing have tended to become part of the situation that subsequent attempts then need to clarify, and it'd be nice if this didn't go the same way ... As an ABC user, with some ability (not huge) to write various languages, I have schemes from time to time, to put together code to do various things to/with ABC files. I took a deliberate decision, quite a long time ago, that I was really going to try and avoid writing an ABC parser. because, the more parsers there are, the more it seems impossible to write one that will deal with everything that all the others collectively deal with; it's too likely that another parser woud just introduce another variant dialect. On the other hand, if somebody is brave enough to try this ... well, if there was one that other coders could then plug into their projects, that would help, in the long run - it would be possible for people to build their own applications around it, that would then all be able to parse in the same, known, way. Is that the idea, here ? Parsing code, with a clear, clearly documented, API for 3rd parties to make use of in applications ? Maybe, ideally, a standalone library package ? Though, languages techniques _are_ relevant :- it seems to me that part of the problem is that, most of the popular ABC applications are specific to one platform (or one way of working - a Windows bod can use abcm2ps, but try explaing a cli program to someone who's never used one ...), so there's mutual ignorance. It _would_ be valuable to have one that could be usable on as many platforms as possible. Apart from Java, WxWidgets seems to be the most viable framework (that I know of), so maybe C++ that would be compatable with this ? And, lastly, I note that the abc-ps family are GPL'ed already. Do any of their people have comments about this ? I think Jeff suggested once that abcm2ps might be a suitable starting point ? -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] reusable parser
Jack Campin wrote: \[order fixed - please don't top-post] Stephen Kellett wrote: Christian M. Cepel [EMAIL PROTECTED] writes I would assume that such a beast would be written in straight ansi c to make it available to any present or future operating system sporting a c compiler, as well as to make it as small and as resource non-intensive as possible. C++ Surely? C is very restrictive in comparison. Writing object based code in C is hard work (read: un-necessary extra code, and lack of type safety) compared to C++. Resource economy is a non-issue - it's not going to be that big and by the time it's done, any computer that will use it will be much, much bigger and faster than anything now running ABC software. Java and C# are not worthwhile alternatives. Both quite restrictive because nothing is truly passed as a reference (try modifying a string object you pass in and see if it really was changed after the method call - if it was really passed as a reference it would be). Makes things trivial in C and C++ a real pain in Java and C#. But, things relevant to this problem? Sharing by reference is a great way to make code less maintainable, and parsers don't need to do it, ever. If they were easier to compile into libraries, SML, Haskell, Lisp or Prolog would be better options - they all have a hell of a lot of accumulated experience in use for parsing refractory syntaxes. Is this a case of if the only tool you have is a hammer, every problem looks like a folk singer? - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html I'm afraid you've lost me once again. I suffer from small brain condition. I'm not sure if you're for or against the idea of an open source shared parsing engine, and for it, what shape you suggest it take. I also fail to see the concern with top posting, but then I spoze people must have their pet peeves. -- //Christian Christian Marcus Cepel| And the wrens have returned [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri - Columbia | born again.--Rich Mullins To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
