Building RISC OS
108 posts, 15 voices
Colin (478)
2433 posts
|
Chris. |
Martin Avison (27)
1494 posts
|
Steve… you said on Aug 5th…
… so is the startup splash screen on Iyonix v5.20 correct? |
Chris Hall (132)
3554 posts
|
A final (?) test of version 1.06a1 of UnTarBZ2 using all of the source code archives. Results: Some filenames are different between 7zip and untar but the contents match – the name is therefore unchecked (the files below are all zero length): Some files are left as text by untar but are filetyped by VRPC (,5 is not treated Some files are left as text by untar but are filetyped by VRPC: These failures are all defined as acceptable. There are no other failures and the test is a PASS (again). Incidentally I thought I would check how long it takes to build an OMAP4 rom on VRPC (to compare with the Pandaboard reported as 6min) and it was 35min (including download, decompress, eraseCVS and build rom). Detail below: |
|
Colin (478)
2433 posts
|
Thanks. The odd thing is the LSLv1,5 files where 7zip strips the ,5 the comma isn’t a normal comma, its a top bit set comma. |
|
Chris Hall (132)
3554 posts
|
No it is a comma. It is just shown as character B8 because when my test programme (!Cat) generates an output file which is a CSV file, it translates any commas in a filename to B8 when it outputs the file and translates them back to a comma when reading them in. I chose B8 because it has the right appearance (almost). I also thought there would hardly ever be a comma in a filename anyway as it is such poor practice. PRM 2-10 deprecates top bit set characters in filenames and prohibits the special characters . : * # $ & @ ^ % and \ and so a comma is permitted. It would be interesting to see what would happen if the first character of a filename was an ASCII double quote (")! |
Rick Murray (539)
13840 posts
|
You know that’s a really old document, right? If we don’t move beyond that1, we’ll remain forever stuck in Little England mode with a filesystem that doesn’t “officially” support characters commonly used in other Western European languages, never mind a hope in hell of Unicode support. 1 For what it is worth, I have used various accented characters in file names for decades; the only problems I have are with badly written software that makes too many assumptions about what a filename should be, based no doubt on a working experience of the Acorn 1770 DFS or something equally prehistoric….. |
Sprow (202)
1158 posts
|
PRM 2-10 deprecates top bit set characters in filenames The text in the PRM doesn’t deprecate them, it says “As a general rule, you should not use top-bit-set characters in filenames, This is just a reminder that other non FileCore filing systems may not be able to translate the name to/from when you work with the files – for example creating an ISO9660 backup of the files on a CD-ROM would end up with lots of underscores in the name instead, so the backup is not a faithful copy of the FileCore names.
The problem of storing commas in CSVs is a well solved problem, using quoted strings, top Google hit is RFC4180 which is succinct as any. |
|
Colin (478)
2433 posts
|
Ok this should do it UnTarBz2_106a2.zip so if Steve is watching does this do what you want. |
|
Chris Hall (132)
3554 posts
|
The problem of storing commas in CSVs is a well solved problem, using quoted strings, top Google hit is RFC4180 which is succinct as any. I do know that. It just introduces a level of complication that I have avoided for the moment. It’s something I might get around to later – the purpose of outputting a CSV file is to allow it to be edited (to add formatting) and re-imported and not for any other purpose. A plain text output file (that does not mungle commas) is an option for readable output. |
Chris Evans (457)
1614 posts
|
I use TSV in preference to CSV whenever possible as commas and quotation marks (which also cause problems in CSV files) often occur in files I use but Tabs rarely, unless they are being a separator! |
|
Chris Hall (132)
3554 posts
|
The correct solution for me to pursue is to seek a filetype allocation as the purpose of the (currently CSV file) option is to generate an output file (in a very precise format and internally consistent) that can be edited (any text editor will do) and read back in to add formatting information for the graphic file and directory display window allowing a formatted draw file to be generated. It is only ‘human-readable’ so that it is easy to see where the formatting information (specifying the offset for any particular branch of the ‘tree’) should be added. I will pursue this for the next version. I’ll do some more testing of !UnTarBZ2 version 106a2 on Monday. |
|
Rick Murray (539)
13840 posts
|
Will the file do something if you double click it? If not, do you need a file allocation? |
|
Chris Hall (132)
3554 posts
|
Will the file do something if you double click it? It will do. Also if !Cat is not running, the message to load it will go unanswered and !Cat will be started up to process it. The current fudge is to respond to it if you drag it onto the app window. |
|
Chris Hall (132)
3554 posts
|
A final (?) test of version 1.06a2 of UnTarBZ2 using all of the source code archives shows identical results with 1.06a1. Filetype 1DF now allocated by ROOL and Cat updated to version 0.20 which no longer uses CSV files. Double-clicking a ‘DiscCat’ type file (&1DF) will cause !Cat to load it and display the stored disc directory as a vector graphic. |
|
Chris Hall (132)
3554 posts
|
Did anyone volunteer to give an updated UnTarBZ2 some testing? I’ve not noticed anything. I have reported my test findings to Steve, who AIUI will deal with it on return from holiday. |
nemo (145)
2546 posts
|
Sorry for the time machine, I’ve been on holiday… Chris said:
Jeffrey countered:
Actually there’s nothing wrong with either convention, but they’re not compatible unless at least one of the implementations is aware of the other idiom. I’m not convinced that ‘older’ necessarily means ‘better’, and adding ‘,v’ to the end of a filename is going to mess up extension recognition of all kinds, including .abc — in any case, why are people still using CVS of all things?! However, CVS running within RISC OS wouldn’t see the comma file extension, so foo(&FFF) would become foo,v,fff or foo,v.txt depending on (it appears) the phase of the moon. Equally, HostFS could be persuaded to map foo,fff,v to foo,v(&FFF) and all would be well-ish. However, trying to manipulate HostFS filenames using a non-RISC OS tool that isn’t aware of the HostFS file extension convention is going to fail badly regardless of what the tool is or how venerable it is. As such, it’s a silly idea to try. |
|
nemo (145)
2546 posts
|
Martin asked:
Yes, that’s incorrect, or at least incomplete. In that very very little of it at all will be © 2013. |
|
Chris Hall (132)
3554 posts
|
Did anyone volunteer to give an updated UnTarBZ2 some testing? I’ve not noticed anything. A final test of version 1.06a2 of UnTarBZ2 using all of the source code archives was completed successfully on August 12th but I notice that the flawed version 1.05 (which gets some names wrong) is still the recommended version. |
Steve Revill (20)
1361 posts
|
The versions hosted on the ROOL site should be updated now (finally). Thanks for the efforts with updating and testing the new version! |
Trevor Johnson (329)
1645 posts
|
The rule with Copyright is that you state the first year from which the Copyright extends.… so is the startup splash screen on Iyonix v5.20 correct? (It says ‘© 2013 Castle Technology Ltd’ !) Pace have used Copyright [1999-2001] in the source code. |
|
Rick Murray (539)
13840 posts
|
Just in case anybody is interested – a step-by-step to building on a Pi: |
Martin Bazley (331)
379 posts
|
Fun fact: Did you know it is literally impossible to click on a linked word which happens to be at the extreme right end of one of the wrapped lines in a paragraph, if a stylesheet is in effect which causes the font style of the link, whenever the mouse pointer moves over the latter, to change to a wider one – which has the side-effect of forcing the wrapping to push it to the beginning of the next line instead – and to change back the moment the mouse pointer is no longer positioned over it – which, given that ‘it’ has just vanished and reappeared on the opposite side of the screen, occurs equally instantaneously? Thank goodness for NetSurf… |
|
Rick Murray (539)
13840 posts
|
Just to let you know – http://www.heyrick.co.uk/blog/index.php?diary=20131105 (building RISC OS on a Pi) has been updated to correct a few issues, add more information, etc. Colin: Your UnTarBz2 program (very very useful!) seems to make a bit of a mess in unpacking the daily/weekly CVS archives (lots of CVS headers/gibberish within files, many empty directories, looks like most things have a “,v” suffix?). Are these updates in some sort of different format? Given a full unpack on my machine takes 2~3 hours I was hoping to merge in Jeffrey’s EDID updates without re-unpacking the whole lot. Again. Is this possible, via different options perhaps? |
Jeffrey Lee (213)
6048 posts
|
I’m not Colin, but the CVS archives are copies of the raw folder structure used by the CVS server. The contents only make sense to a CVS server – so in order to use them you’d need to run a CVS server (pointing it at the extracted folder structure), then run a CVS client, connect to the server, and check out the files. |
|
Colin (478)
2433 posts
|
Rick. You needed the ‘CVS repository defaults’ option ticked to decompress properly but as Jeffrey pointed out they are not in the same format as the source code archives. If you know what you want to download from the cvs repository the easiest way I found – if you know nothing of cvs like me – was to put !CVS into a directory and in the same directory create a taskobey file – I called mine ‘cvsfetch’
you replace the path after ‘co’ with the one you want and after double clicking on cvsfetch the path is recreated from the same directory. So after running cvsfetch the directory contains !CVS, cvsfetch and a bsd directory. There’s no need to move the files downloaded to compile them. As long as you have a build environment already set up it will compile where it is. Edit: the ‘*’ in the path name in untarBZ2 is so that it works for all devices. The CVS repository archives don’t use this. |
