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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
|
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
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
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
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
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...
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
35 matches
Mail list logo
