Several Updated Modules
Steve Fryatt (216) 2103 posts |
I’ve recently found myself digging through the source code for several of my old modules. In the main these were assembled using ExtBasAsm, and for several years this has meant firing up RISC OS 4.02 on RPCemu in order to do any work on them: as a result, most of the copyright dates showed 2003 when they were 32-bitted for the Iyonix… Anyway, to make them a bit more maintainable, I’ve started converting the sources over to ObjAsm/Asasm format. At the same time I’ve fed the code through ARMalyser, and also looked for any other obvious ARMv7 issues; on some I’ve also started fixing longstanding old bugs and making improvements to the code. All of the new builds are currently in “test” status; I’ll do proper releases once I’ve worked through the longish list of unfixed bugs and issues, and given people chance to feed back any issues. I’ve given most things a cursory test on a Beagleboard, but if anyone else would like a play they can be found here (along with source code which, like most of my other stuff, is supplied configured for use in the GCCSDK): http://www.stevefryatt.org.uk/software/test/ Feedback welcome; I’ll be updating the archives as and when I make changes to the code (as well as adding other things if I find any more source code lurking on the Iyonix’s disc)…
I’ve also transferred IcnClipBrd’s source into the GCCSDK environment to make it easier for me to build in the future; that’s also on the page, but there aren’t (AFAIK) any changes compared to the last stable release. |
Martin Bazley (331) 379 posts |
A few years ago (July 2009, according to my ‘Sent mail’ folder), I sent you a small update to this module, which counted the number of lines in the fortunes file instead of relying on the user manually updating a system variable, and also fixed an (admittedly unlikely) bug in the error handling. I’ve been using my modified version ever since then with no problems, so I think it’s safe to say it works. BTW, could the source archives have proper RISC OS filetypes set? |
Steve Fryatt (216) 2103 posts |
Indeed; as I wrote in the first post, the ExtBasAsm requirement has meant updating things has been a serious pain in the past. I only came across the conversion idea by accident while looking at getting something else to build, and decided to complete it when it became apparent that it wouldn’t actually take that long to do. However, now that it’s done, I might actually make changes given that I don’t have to spend half an hour faffing around before I can start… I was actually going to add your fixes in, until I found that I have the entire chain of emails apart from the first one with the actual attachment. If you’ve still got the changes to hand, feel free to resend them — note that you would be contributing code to a different licence now, though, as I’ve taken the opportunity to relicense the old freeware code as proper open source.
Not easily, no. The zips are all generated on Linux, and while the build environment sets the correct filetypes in the “user” archive, there’s no sane way that I’m aware of to do that for the source without splattering ,xxx extensions all around my files. |
Theo Markettos (89) 919 posts |
Just in case you weren’t aware, the zip that comes with GCC/GCCSDK supports filetype extensions – you do need the ,ffb or whatever extensions, but then zip -, (zip space dash comma) will create a RISC OS format zip with filetypes. You need the autobuilder’s zip on your path to do this (run /home/riscos/env/ro-path or similar) If you don’t want the ,ffb on your files, try making a directory of symlinks pointing to your files and zipping up that. zip doesn’t support symlinks, so it might get the destination files instead. There’s a package in the GCCSDK autobuilder which will do the reverse – preserve RISC OS filetypes to ,xxx when unzipping on Linux. You build the native-unzip package, and then you do “unzip -F” to retain types (the -F flag has actually been in mainline zip since the 1990s but only some distros enable it, hence native-unzip builds a special unzip with it turned on). |
Steve Fryatt (216) 2103 posts |
Yes; that’s how the “user” archive is created.
Wouldn’t that mean that I’d need to maintain two “sets” of source files: the real ones, and the symlinks with RISC OS type extensions? That sounds like a lot of hassle (and would Subversion preserve that setup?)… What might fix things would be to change the default type used by zip when the -, parameter is used: if it were text, then that would solve most of Martin’s problems immediately. Maybe I need to have a look at GCCSDK’s zip sources when I get a bit of free time.
Interesting; I wasn’t aware of that one. Thanks! |
Theo Markettos (89) 919 posts |
Nothing that can’t be solved with a bit of ‘find’ magic . Or, more sensibly, the lns tool (and then a script to rename stuff) I just tried zipping up such a symlink tree and it seems to work.
Looking at the source patch it would seem to do that already, so I’m not quite sure what’s happening here?
It appears that Debian 7 (squeeze) and Ubuntu 12.04 (precise) support ‘unzip -F’ out of the box but CentOS 5 doesn’t, so if you’re on a Debian-based distro you don’t need to install anything. |