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
My parser will be using the non-graphic parts of Cocoa GNUStep, so it
should be highly portable.
The printing code I'm writing, on the other hand, will necessarily use
graphics, but I'm hoping it will work on most (and maybe all) systems. On
the Mac, at least, it will output PDF natively -
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
Jack Campin writes:
| So operations on large-scale ABC databases are likely to become more
| important - things like:
|
| - storing the tunes in a database, parsing and indexing them at entry
| time
|
| - distributed versioning, so that an ABC creator could get forwarding
| pointers or editing
Steven Bennett writes:
| You know, it's amazing that people still have this silly impression that
| just because Apple only ships a mouse with one button, that the OS can only
| use one button, something which hasn't been true for many years. I've been
| using multi-button mice on Macs since the
In message [EMAIL PROTECTED], John Chambers
[EMAIL PROTECTED] writes
Actually, doing that would be not just feasible; it would be easy,
except for that one little elephant hiding over there in the corner:
Copyright.
OK, so how do Google get away with storing all those cached web pages
(just
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.
|
Stephen Kellett writes:
| In message [EMAIL PROTECTED], John Chambers
| [EMAIL PROTECTED] writes
| Actually, doing that would be not just feasible; it would be easy,
| except for that one little elephant hiding over there in the corner:
| Copyright.
|
| OK, so how do Google get away with
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
In message [EMAIL PROTECTED], Steven Bennett
[EMAIL PROTECTED] writes
You know, it's amazing that people still have this silly impression that
just because Apple only ships a mouse with one button, that the OS can only
You learn something every day :-) I don't know that its a silly
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
Thats one of my two dislikes of Macs done away with. The other one is
the menuing system. Click and hold is bad for anyone with WRULD / RSI.
The Windows Click, release, mouse/key around as you please then click
when you are ready is good for RSI. Can you configure the Mac to have
menus that
| So operations on large-scale ABC databases are likely to become more
| important [...]
| All of that would be easier if persistent parse trees were available.
| It's a pity the Tune Finder doesn't yet have options to download
| everything it knows about or synchronize your own mirror with it.
From: Jack Campin [EMAIL PROTECTED]
The first mouse - actually bitpad puck - I used had four buttons.
I don't miss the other three, and anybody who puts an asymmetric
two-button mice on a public computer with no instructions on how
to remap the buttons needs to have one hand superglued to
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
till they get the message. (Quick, how *do* you remap the mouse
buttons to use a mouse left-handed for the duration of a catalog
Can't say I've ever thought about it but I am quite used to being a left
hander in a right handed world (and play right handed).
I'm left-handed as well, and
30 matches
Mail list logo
