RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Bounties →

Request for community help - improved CCres tool

Subscribe to  Request for community help - improved CCres tool 46 posts, 19 voices

Posts per page:

Pages: 1 2

 
Jun 12, 2014 3:27pm
Avatar Steve Revill (20) 1339 posts

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).

 
Feb 11, 2015 10:21am
Avatar Philip J Ludlam (50) 21 posts

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

 
Feb 10, 2017 8:50am
Avatar Alan Robertson (52) 394 posts

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

 
May 7, 2020 11:30pm
Avatar Jeffrey Lee (213) 5850 posts

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.

 
May 8, 2020 2:16am
Avatar Chris Mahoney (1684) 1687 posts

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.

 
May 8, 2020 7:16am
Avatar Jon Abbott (1421) 2138 posts

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?

 
May 8, 2020 8:55am
Avatar Steve Fryatt (216) 1482 posts

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… :-)

 
May 8, 2020 10:10am
Avatar Steve Drain (222) 1338 posts

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.

 
May 10, 2020 8:39pm
Avatar Alan Robertson (52) 394 posts

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?

 
May 10, 2020 9:13pm
Avatar Chris Evans (457) 1562 posts

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.

 
May 10, 2020 9:18pm
Avatar Chris Mahoney (1684) 1687 posts

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

 
May 10, 2020 9:48pm
Avatar Jeffrey Lee (213) 5850 posts

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

 
May 11, 2020 7:44am
Avatar James Byrne (3371) 18 posts

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.

 
May 11, 2020 8:46am
Avatar Jeffrey Lee (213) 5850 posts

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.

 
May 12, 2020 12:26pm
Avatar Steffen Huber (91) 1644 posts

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.

 
May 12, 2020 2:49pm
Avatar James Byrne (3371) 18 posts

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"
}

I appreciate that it’s a bodge, but addresses the issue.

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.

 
May 12, 2020 3:44pm
Avatar Steffen Huber (91) 1644 posts

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.

 
May 20, 2020 5:32pm
Avatar Jean-Michel BRUCK (3009) 37 posts

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

 
May 22, 2020 2:35pm
Avatar Alan Robertson (52) 394 posts

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.

 
May 25, 2020 7:52am
Avatar Jean-Michel BRUCK (3009) 37 posts

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).

 
May 25, 2020 8:54am
Avatar Andrew Rawnsley (492) 1229 posts

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

Pages: 1 2

Reply

To post replies, please first log in.

Forums → Bounties →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Discussion of items in the bounty list.

Voices

  • Steve Revill (20)
  • Philip J Ludlam (50)
  • Alan Robertson (52)
  • Jeffrey Lee (213)
  • Chris Mahoney (1684)
  • Jon Abbott (1421)
  • Steve Fryatt (216)
  • Steve Drain (222)
  • Chris Evans (457)
  • James Byrne (3371)
  • Steffen Huber (91)
  • Jean-Michel BRUCK (3009)
  • Andrew Rawnsley (492)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys