Request for community help - improved CCres tool

Hi. I think the easiest thing to do is for everyone to wait for Ben to dig-out his work-in-progress which basically demonstrates the answers to these sorts of question, by the fact it implements this stuff. I would suggest that implementing this as a C component that uses the shared makefiles at least gives the (future) option of building the tool and running it on platforms other than RISC OS. I expect Ben’s prototype was a single C file built with GCC for and on Linux (I guess that from the fact he sent me an ELF file executable to test).

Hi. Has Ben been able to dig-out his work-in-progress?

Just resurrecting this thread to see if Ben’s tool and its sources were ever found and released?

Any sign of Ben’s code yet? CCres is getting a bit crusty (the build on John’s site is using rotated loads), and something to help diagnose WinEdit’s foolishness would be useful.

I can’t help but laugh. Page 506 of the Toolbox manual says that a resource file begins with ‘ReSF’. Yet the first file I looked at, generated with a fairly recent ResEd, starts with ‘RESF’ (capital E). We’re off to a great start!

Edit: Page 508 says RESF.

Daft question, but who’s Ben? And more to the point, why has he not contributed to this thread in the 6 years since it was raised, given his work seems critical to resolving the initial problem?

Has anyone pointed him in the direction of this forum and thread?

Daft question, but who’s Ben?

Ben Avison?

Has anyone pointed him in the direction of this forum and thread?

I’d guess he’s aware of the forum, at least… :-)

Interesting. From what I have been doing with my Oobi project I possible know Res files inside out. I have not used CCres for years. It would be quite possible to make something similar in BASIC, but I suspect that would not meet the requirements.

By the way, I am still using the first edition of the Toolbox manual from 1994 and only ‘RESF’ is mentioned AFAICS.

if a tool was to come forward, wouldn’t a XML file format be the best solution? Does RISC OS have an XML generating & parsing tool that would make it easier?

The only RISC OS XML work I know of was by Gerph, I found this which mentions !ParseXML I don’t think any of his software is still available:-( And I doubt the licence allows redistribution if someone has a copy.

JSON is probably also an option. I’ve used cJSON under RISC OS in the past.

There are a couple of standard XML libraries available on riscos.info.

http://www.riscos.info/packages/ABCIndex.html

Unless you’re trying to do something like use a templated C++ XML library with Norcroft, I wouldn’t expect to run into any problems with using other XML libraries (99.9% of the code will be manipulating data in memory, the 0.1% that deals with I/O can easily be replaced if needed).

JSON is probably also an option

For source control, I think XML would be better – it’s more merge-friendly

For source control, I think XML would be better – it’s more merge-friendly

Really? XML tends to end up horribly unreadable. I would have thought that JSON or YAML would be a much better choice for starting something these days.

Yes, XML can definitely be horribly unreadable. But I think it’s easier for merging by source control systems.

JSON is a nuisance because you aren’t allowed to have trailing commas in lists/objects. So appending a new list element requires the previous line to be modified. If someone else has changed that line then you’ll get a merge conflict.

XML doesn’t suffer from that. And its verbosity means that when things do go wrong, you’ve got a better chance of working out why/where (especially since it has more widespread support for schemas).

YAML is nice, but it’s still built ontop of JSON’s type system, so there are limits to what you can do before you end up needing to add extra metadata that pushes it closer to XML levels of verbosity.

Really? XML tends to end up horribly unreadable. I would have thought that JSON or YAML would be a much better choice for starting something these days.

I always found JSON and YAML to be yet another case of “reinventing the wheel” in IT.

XML is well-aged and proven, parsers are available everywhere in every flavour. There are well-defined things surrounding XML like Schemas, DTDs, XSL, XPath, XQuery, editors with tag completion and syntax check, even databases understanding and storing XML.

Of course, in a JavaScript world, JSON was the easiest to use. And there is now a big ecosystem supporting JSON in nearly every way, botching up the various shortcomings because JSON was originally intended as a format for simple, easily-parsable, human-readable object serialization and not for “everything”. As I said, the wheel has already been successfully reinvented.

JSON is a nuisance because you aren’t allowed to have trailing commas in lists/objects. So appending a new list element requires the previous line to be modified. If someone else has changed that line then you’ll get a merge conflict.

You can work around that by putting the comma at the start of each line except the first one, like this:

{
     "flag": true
     ,"thing": "value"
     ,"content": "detail"
}

YAML is nice, but it’s still built ontop of JSON’s type system, so there are limits to what you can do before you end up needing to add extra metadata that pushes it closer to XML levels of verbosity.

Would that be a problem in this context though? I don’t really know the details enough to have an opinion.

As to Steffen’s comment about it being a case of reinventing the wheel, well yes, software engineers love doing that, but XML is a pretty ugly and over-engineered wheel. For me readability is much more important, if the files end up being incomprehensible by humans you’ve lost most of the benefit of rendering them in a textual format, and looking at the diffs between revisions won’t tell you a lot.

As to Steffen’s comment about it being a case of reinventing the wheel, well yes, software engineers love doing that, but XML is a pretty ugly and over-engineered wheel.

If you like, you can have extremely lean XML – e.g. if you stick to the meagre feature level of JSON.

For me readability is much more important, if the files end up being incomprehensible by humans you’ve lost most of the benefit of rendering them in a textual format, and looking at the diffs between revisions won’t tell you a lot.

I find XML usually a lot easier to read than JSON, so I guess it is just a case of what you’re used to, and you cannot argue taste. Not supporting comments ruins human readability in my book.

Additionally, I like XMLs easy way of dealing with different encodings, true comments and the semantic richness differentiating values, tags and attributes. In addition to the whole raft of technology I mentioned above, which is now retro-fitted to JSON in a very non-standardized way which will take years to settle down on an “industry standard”, if ever.

The only RISC OS XML work I know of was by Gerph, I found this which mentions !ParseXML

Just for information, I tried to create an XML file reader because there are a lot of documents in this form.Using the Expat library I got a result, the program is still in the state of a “model”.There are still bugs, it is strongly advised to change the name by saving an xml file.
XMlEdit

Just for information, I tried to create an XML file reader because there are a lot of documents in this form.

I’ve had a look through your website and you seem to have quite a few good looking and useful apps available. All using the Toolbox controls such as Tabs and TreeView. Your DDETool in particular is in the initial stages of a very useful IDE tool.

I must review the organization of my site, (with Webwonder) and update the programs. I built these applications in order to learn how to use DDE and RISC OS libraries.We can do a lot with these tools.
I also recompile/adapt old programs like Psifs, Pari,Mkdrawf and Rhapsody4, I find it a shame to let these softwares lose (forget).

There’s a set of XML tools by XAT (!eXML) which they like us to include with products, so that programmers can use them. URL here http://www.xat.nl/riscos/sw/xml/index.htm