Richard Robinson wrote:
On Sun, Apr 25, 2004 at 06:15:21PM +0100, Stephen Kellett wrote:I think you've described what I envisioned exactly. Further, I agree that there may or may not be a reason to 'start from scratch' here, but rather to take the best out there, rewriting where necessary, combining, and adding to to develop a single reusable engine small enough to be used on any platform with an intuitive and useful API. Further, if the entire ABC community has input on it's design in much the same way as the standards are arrived at (within reason), it may very well meet those goals and eliminate the frustration many programmers/end users feel wondering... ok... I like program X, but I know I'm going to have to go in and change this and this in the ABC to get it to display or play properly... knowing which version of ABC the particular Parser for each software package can handle, and which versions cause it to puke up...
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 ?
--
//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
