Re: [abcusers] !Current specification!
Christian M. Cepel wrote: Might it not be interesting to start a project on Sourceforge with CVS tracking for a centralized open source parser module or engine that can be utilized by everyone? Hear, hear. Whoever's interested is free to use the facilities of the abc.sf.net project. Send me your SourceForge user name and I make you a project member and even admin if you want. 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++. Why only writing a parser for one language (either C, C++, C# or Java)? Surely it should be possible to generate a parser for any language from a BNF grammar specification using a parser generator like SLK? Incidentally, SLK is available for both Win32 as Linux. 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#. Java Strings are immutable objects. This allows for some optimisations, but it has its consequences. In general, primitive types are passed by value, while objects (including arrays) are passed by reference. But a String object can't be changed, so, indeed, what you describe here will not work... Cheers, bert -- Bert Van Vreckem http://flanders.blackmill.net/ Te audire non possum. Musa sapientum fixa est in aure. 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] !Current specification!
In message [EMAIL PROTECTED], Stephen Kellett [EMAIL PROTECTED] writes 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++. 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#. Stephen In my opinion any parser should produce ascii code and be self-contained, written as a command-line procedure using stdin and stdout abcparse inputfilename outputfilename The structure of the outputfile would probably obey some sort of XML language (although I hate it). -- 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
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] !Current specification!
Rubbish. To be useful, the parser should be a procedure with an API which can be called from a standard executable program. If you produce an acsii file, you have just replaced one problem with another. - Original Message - From: Bernard Hill [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 25 April 2004 13:29 Subject: Re: [abcusers] !Current specification! In message [EMAIL PROTECTED], Stephen Kellett [EMAIL PROTECTED] writes 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++. 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#. Stephen In my opinion any parser should produce ascii code and be self-contained, written as a command-line procedure using stdin and stdout abcparse inputfilename outputfilename The structure of the outputfile would probably obey some sort of XML language (although I hate it). -- 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 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
