Recent Posts by Martin Bazley (331)
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 ... 16
Jul 30, 2013
Martin Bazley (331)
379 posts
|
Topic: Aldershot / Audiophiles "Who made this circuit up for you anyway? Bought it in a shop? What a horrible, shoddy job they fobbed you off with. I'm surprised they let you have it in here! The acoustics are all wrong. Raise the ceiling four feet, put the fireplace from that wall to that wall, and you'll still only get the stereophonic effect if you sit in the bottom of that cupboard. What a horrible shoddy job they've fobbed you off with ... ! You've got your negative feedback coupled in with your push-pull input-output; take that across your red-head pickup to your tweeter, and if you're modding more than eight you're going to get wow on your top-try to bring that down through your rumble filter to your woofer. And what'll you get? Flutter on your bottom!" |
Jul 23, 2013
Martin Bazley (331)
379 posts
|
Topic: Announcements / Several Updated Modules
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? |
Jul 10, 2013
Martin Bazley (331)
379 posts
|
Topic: Announcements / How To ... My personal justification for ‘program’ over ‘programme’ is that the former is more commonly used by people who know what they’re talking about, and the latter is more commonly used by people who don’t have a clue. Therefore, if you use ‘programme’, I have a statistical reason not to pay attention to you. |
Jun 18, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / RPi & NOOB - Clicks funny The obvious question to ask here is: What happens if you click on stuff using the button you would normally right-click with, assuming the mouse has one? Some more tests you can try to confirm your mouse really is generating right-clicks: double-click on a file in a Filer window (if the Filer window closes, it was a right-click); click a scroll button on any window (if the scrollbar moves in the opposite direction to that you expected, it was a right-click); click the back button on any window (if the window moves to the front instead of the back, it was a right-click); click on NetSurf’s icon bar icon (if your hotlist opens instead of your home page, it was a right-click). |
Jun 17, 2013
Martin Bazley (331)
379 posts
|
Topic: General / wimp_poll_idle
|
Jun 17, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / RPi & NOOB - Clicks funny
Wrong – they are saved, at least unless you’re using some really funny applications.
Er, you mean NetSurf, right?
Well, you should have done – at least if you had ever tried right-clicking on things instead of left-clicking on them. All of your symptoms suggest that, when you think you’re left-clicking on something, you’re actually right-clicking on it. What type of mouse are you using? How many buttons does it have? Are you sure you haven’t configured it to some sort of left-handed mode by mistake? |
Jun 15, 2013
Martin Bazley (331)
379 posts
|
There are many, many programs which will deal with this problem for you properly. You should never, ever need to use *Shut. http://www.starfighter.acornarcade.com/mysite/utilities.htm#wimpdrain |
May 26, 2013
Martin Bazley (331)
379 posts
|
Topic: Code review / Patience That’s looking a bit better. One minor thing I noticed during playtesting was that the area in which you were expected to drop a card in order for the drag to register seemed a bit too small for my tastes – on a couple of occasions I thought I’d dragged something off the deck when I had in fact failed to do so, and only noticed in the split second before turning over another three cards. I’ve probably been playing the KDE version of Patience too much. Otherwise, this is definitely an improvement over the old version, particularly the new sprites. |
May 20, 2013
Martin Bazley (331)
379 posts
|
Topic: General / A modern mum tries out Risc OS 3.11 from 1992 A lot of rather obvious clangers dropped (“shutting down wipes your hard disc”, indeed!), but the one which stuck with me was the statement that Maestro couldn’t play the music you wrote with it. You’ve got a real blind spot for middle-clicking, huh? The backdrop changing mechanism was rather convoluted back in RISC OS 3.11. It was improved for RISC OS 4 in 1999, which also fixed the problem of the backdrop not staying put when you restart the computer. The things you deride as taking ‘too many steps’ are actually oft-underappreciated advantages. For example, think of the process you would go through to save a text document from Notepad. You’d have to open the Save dialogue and navigate through your hard disc to the place you’d want to put it, wouldn’t you? You’re not actually saving any steps overall by not having to open the directory display first. But more to the point, the drag-and-drop system lets you drag files – even as-yet unsaved files – directly into other applications which can open the same types of file, without any need for temporary files. And as for applications not (usually) opening windows when you initially load them, you neglect to mention the flipside – when you close the last window belonging to an application, the application doesn’t quit. If you want to use it again, you don’t have to load it again. This isn’t really noticeable with apps like Edit which load instantaneously, but it becomes a major advantage with things like web browsers which can take ages to start up. |
May 17, 2013
Martin Bazley (331)
379 posts
|
I am curious. Did you just mean to imply that there are now so many people voluntarily maintaining the RISC OS codebase and submitting patches and bugfixes that the admin staff have become overworked just dealing with it all? Haven’t we been waiting and wishing for exactly this situation for, like, six years? |
Apr 16, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / Forum software on !WebJames John: I’m clutching at straws a bit here, but just on the off-chance, are you using an encrypted (sftp or https style) connection? Furthermore, are any of the programs you’re using calling R-Comp’s SecureSockets module? I’ve found that that module is very prone to corrupting files during transmission (oddly, receiving seems fine). It depends on the protocol used – I had very different results from two different SMTP servers, but both were internally consistent – but as a rule, it’ll successfully transmit the first N bytes (where N varies; it was consistently around 100KB for one server) but then accidentally miss out a block of 1000 or so bytes. This pattern repeats cyclically if the file is longer than 2N bytes in total. I was testing with sending emails rather than transferring data, which introduced interesting complications. For example, the effects of base64 encoding meant that when the file was decoded at the other end, sometimes all the remaining bytes after a ‘jump’ would be 4 bits out of alignment! What exactly do you mean when you say “corruption”, anyway? Might be worth comparing your symptoms to mine, although I don’t know the internal details of the protocols you’re using, so further advice on what to look for may not be very useful. |
Apr 10, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / Assembler Interrupt Examples Wanted
No, it does not, with particular emphasis on the (or similar) part. I don’t think the format’s editor has survived either. Like I said, it isn’t very useful. |
Apr 9, 2013
Martin Bazley (331)
379 posts
|
Topic: General / Official Release - CMOS
Coincidentally, I covered this in my latest reply to the Usenet thread as well. (Having a split discussion like this is very annoying!) This is one of the areas which I’m less familiar with, as it’s more of an implementation detail than inherent to the package format. The Policy Manual states only the following:
There are a number of packages distributed which “claim ownership” of Alias$@RunType_XXX, some of which conflict with each other, so I’d hope this was configurable. There’s also a Sprites subdirectory which IconSprites’s sprite files on bootup. Again, if you really want this, it should be part of ‘Look at’, and strictly optional. The existence of these two parts of the specification play a major part in my conviction that it was designed for a Linux-like system, and not a RISC OS-like one. |
Apr 9, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / Assembler Interrupt Examples Wanted I have an interrupt-driven music player, which is an interesting curiosity but not all that much use without the relevant music files. |
Apr 8, 2013
Martin Bazley (331)
379 posts
|
Topic: General / Official Release - CMOS
That’s basically my multiple-categories suggestion by another name. I got the idea from PlingStore, which already does this. When I saw it, I couldn’t believe RiscPkg hadn’t thought of it. With regards to Theo’s challenge, believe me, I’d love to. In fact, I believe I threatened to do just that at the conclusion of last year’s epic Usenet discussion, but I never got around to it. You can actually see a couple of my thoughts for how I’d have written the system in my latest post on the Usenet thread steaming on in parallel to this one. I don’t need any encouragement to spontaneously burst into specs! The main problem is that doing the job properly would require a lot of careful thought, and I’d really rather not commit myself to anything until after my exams finish in May. That said, you couldn’t go far wrong with starting from my list of demands on page 4. |
Apr 8, 2013
Martin Bazley (331)
379 posts
|
Topic: General / Official Release - CMOS By the way, if you want nested quotes, <notextile> and dropping to vanilla HTML are your friends.
It was specifically this quote which I found most enlightening:
This strongly suggested that he preferred the idea of attempting to mould the users to the system instead of moulding the system to the users. An unrealistic goal for any piece of software, let alone something as fundamental as a package manager. We’ve banged our heads together many times on this particular point and we’re plainly never going to agree. Over multiple years, threads and online mediums, I’ve been as specific and precise as I think I ever can be on exactly which bits of RiscPkg were lifted from Debian and why some of those bits shouldn’t have been, and all I’ve been rewarded with are blanket flat contradictions alternated with “well it works for me”. This isn’t an argument worth continuing.
Ah, the old ‘argument from faith in humanity’ fallacy. As a committed misanthrope, I’ve run up against this particular brick wall in many previous forum arguments. My number one rule for dealing with people (or indeed life in general) is to expect the worst and you’ll never be disappointed, but sadly people will insist on believing that most humans aren’t fundamentally selfish and stupid. Nevertheless, I will attempt to debunk it anyway. Here is the complete list of categories defined in the Policy Manual:
Tell me there’s never going to be any overlap between any of those. Tell me there’s no possible way someone could write an application which applied equally well to, say, the ‘Document’ and ‘Spreadsheet’ categories (oh hello there Fireworkz, available for free now, are we?). Funnily enough, I see you’ve deployed this exact same line before, in reply to Vince Hudd. Featuring a cameo by my own software. Tell me, did you ever decide whether Cogs was a “toy”, a “game” or a “graphics program”? The supply of counterexamples to your position that (a) RiscPkg’s list of categories isn’t bloated and (b) there is no room for ambiguity between any of them doesn’t seem to have made much of an impression on you back then either, so I won’t get my hopes up. That’s one fascinating Usenet thread, actually. Vince made some good points, but I still think David Holden’s post can’t be beaten for succinctness.
Good. This is a step considerably further in the right direction than the implementation of package moving was. It only deals with one source of control-freakery as yet (albeit a very common one, which most users will encounter while setting up packaging for the first time), but I hope more can be added. Not that I imagine you’re interested, but this is yet another respect in which the design of LibPkg focused rather too heavily on writing a Linux package manager and porting it to RISC OS, rather than starting out with the aim of writing a package manager for RISC OS. Linux, with its sudo and its root and its new-fangled half-decent standards of basic security, to speak nothing of its mainframe heritage, operates on the philosophy that users should be allowed to do as little as possible (see above re. faith in humanity). RISC OS, on the other hand, will happily stand aside and let you do something completely idiotic – which is probably a bad idea if you don’t know what you’re doing, but at least it makes things less frustrating for those of us who do. It’s quite obvious on which side of this debate LibPkg has aligned itself.
Smart move. How can I possibly refute your arguments if they don’t even make any sense?
But it doesn’t matter if I’m correct or not. Obviously I think my opinions are correct, otherwise I wouldn’t have them, but far more pertinent to my point is that I can name at least two people (thus far) who agreed with them sufficiently to write long and eloquent posts explaining their own viewpoints, which broadly align with mine. Every person who does that – plus unknown numbers of other people who read those posts and silently agree – is lost to your cause until the things they dislike have been satisfactorily dealt with.
Oh never mind, you’ve just degenerated into strawmen now. Drifting off into the realms of whimsy for a moment, I think my ideal package manager would have the user interface of PlingStore and the features of PackMan. PlingStore was originally developed as an answer to what I’m tempted to call the ‘David Holden question’ (you really should check out those links up there), designed on a blank slate with nothing more in mind than how a RISC OS store might work, with no hang-ups about how other systems do it. Unfortunately, unless it’s been considerably improved since I last saw it (I don’t have a copy, so I’m working off hazy memories here), its technical side leaves much to be desired. I don’t think it does either dependency resolution or update checking, which are two of the most important reasons we need a package manager in the first place. PackMan, on the other hand, has a (fairly) stable, thoroughly tested back-end with lots of handy features, but it just doesn’t look, feel, or work like a RISC OS application, and that same fancy back-end is prone to some rather foreign ideas about how things should work. We need the things it does, it’s just really annoying it does them in such an idiosyncratic manner. PlingStore is a much neater, slicker, more carefully considered system, but the functionality just isn’t there. PackMan is a shambles in several respects, but is the only system attempting to do the job which actually needs to be done. One represents the extremist viewpoint that RISC OS should be made as much like Linux as possible because Linux is brilliant, and the other represents the equally extremist viewpoint that RISC OS should steer clear of anything forrin-sounding just to be contrary, without giving any consideration to what would be useful to have in practice. I repeat my oft-repeated and progressively more futile-sounding plea: can we not just have the right tool for the right job? |
Apr 8, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / Basic Support Double-click on the !GCC application. You can now use the gcc, g++, make, etc. commands. You can automate this process to happen on bootup by adding !GCC to the list of applications to be run on startup (Configure window, Boot section, drag the app into the list). Oh, and welcome back! |
Apr 5, 2013
Martin Bazley (331)
379 posts
|
Topic: General / Official Release - CMOS Chris Gransden has a point in that some of this argument is redundant now that PackMan can move the installation location of packages, eliminating the need for stubs. (WTF was the guy who invented those thinking? Actually, don’t answer that, because I directly asked him what he was thinking a couple of years ago. The answer made as much sense as you might expect.)I expect it made a lot of sense, you just didn’t agree with what he was saying. Let's study a few selected quotes from a 2010 email conversation with Graham Shaw, shall we? Comparable situation with GNU/Linux. When it was normal practice to compile from source, people installed more or less wherever they wanted. When you start using a package manager, you just don't do that. As on GNU/Linux, package management works just fine when used as intended, but if you try to fight it then it is liable to fight back. My personal experience is that the urge to tinker soon passes after you've had to reinstall a few times. I fully agree that the nature of RISC OS demands more flexibility than Linux, however there is a difference between flexibility and anarchy. It may be worth asking whether a package manager is really the right solution to your requirements. An installer would be much simpler, and probably much faster too. Just like a flesh-and-blood manager, there's no point employing one unless you are prepared to delegate most of the detailed decision-making and switch your attention to setting high-level strategy. I'm not saying you shouldn't be able to step in and override it occasionally, but if you're doing that as a matter of course then it probably isn't the right tool for you. These were mostly in the context of trying to persuade him that catering for the possibility of users moving installed applications might be a good idea. This was before I fully appreciated the ramifications of having the manager automatically dump stuff in a fixed location in the first place. Anyway, to cut a long story short, it didn't happen. I hope it is now somewhat clearer why, and on what basis, I believe that the design of LibPkg was slavishly copied from Linux without sufficient regard for how that system differs at both a technical and a cultural level from RISC OS. Well the locations are not random, they’ve been considered by the application authors. That is exactly the same thing. They've been considered... by many very different application authors, each of whom have very different ideas of how things should be done, and different ideas about how RiscPkg works and what it's for, and different ideas about how the English language works. With minimal central coordination. Have you considered taking up a position herding cats instead? You might find it easier. Also... Cut down that ridiculous list of categories! And take a leaf out of !Store’s very sensible book and allow packages to be filed under more than one, because really, trying to slice reality into that many discrete non-overlapping black and white chunks is inviting chaos and confusion.Reasonable suggestions, I haven’t any plans to fix this though, Sections are decided by Package authors using the guidance of the Policy Manual and not really under my control. That is incredibly specious. It was the guidance of the Policy Manual which I was suggesting needed alteration! And there's nothing stopping you from permitting packages with more than one section. Never force an installation or update to fail, even if it thinks it’s a bad idea. This includes package conflicts, and overwriting of non-managed files. By all means warn the user and recommend against it, but if they know what they’re doing, don’t stop them! I hate control-freak software in general, but especially where it clashes with RISC OS’s general attitude that an experienced user knows best.I think this may be harder to achieve as the Package manager probably doesn’t want the system in a bad state, but I’m not sure. The latest PackMan alleviates this a bit by prompting to back up any conflicting files and then retrying the install. Rick said it better: PackMan needs an 'expert mode'. Like it or not, this is one of the most important remaining problems with RISC OS packages. Those of you playing Forum Bingo can cross off your "Martin slags off RPMs" square now, because the lack of an override button - no matter whether the package manager thinks it's a bad idea or not - is also one of the most infuriating things about that system. One thing Linux has taught me is that, the more established a package system becomes, the more severely its deficiencies are magnified. I have had so many fake RPM conflicts, often stemming from nothing more significant than the same library being available from more than one repository, that I want to throttle the person who thought "the manager always knows best" was a sensible philosophy. Remember when I said Linux packages had made maintaining my system an order of magnitude more awkward? Yeah. That. I meant that. I will not tolerate this malaise invading my home turf. I’m sure there are edge cases where it can make things more awkward, I just haven’t come across them yet. These are not "edge cases". There are doubtless some of those, but these are great gaping holes which nigh on everybody who you are hoping to convince of the advantages of package management will stumble into sooner or later - probably before they've even finished setting up, so eclectic is the average RISC OS hard disc, nurtured by two and a half decades of "anarchy". Interestingly we both have looked at the existing Packaging system and have seen it completely different ways. I think it is well designed and thought out and you seem to believe it is slavishly copied from Linux. I'm going to tell you something rather harsh, but which needs to be said: What you think doesn't actually matter here. You have set yourself up for the unenviable task of convincing a sufficiently great proportion of the RISC OS userbase to switch to packaging for packaging itself to be viable - which means at least a majority. The incentive for them to spend all this upfront time and effort is practically zero - the onus is on you to convince them, which will never happen for as long as something which will play such a major part in their lives has such large perceived flaws in it. You can't hope they'll look past the aspects of the system they'll dislike, because if there's nothing in it for them, they won't use it, and thus the whole foundation of the packaging project collapses. Not capitulating to demands, however unreasonable they may seem to you, is only ever going to hurt your own cause. |
Apr 3, 2013
Martin Bazley (331)
379 posts
|
Topic: General / UTF8 outside the desktop Interestingly, I can view the image from a Windows computer which is also logged into the Dropbox website, but not from a RISC OS computer which isn’t. I have not yet determined which of these two facts is relevant. Further experimentation required tomorrow. |
Apr 2, 2013
Martin Bazley (331)
379 posts
|
I think this is another case of “Unix did it this way, and everything everywhere should unconditionally imitate Unix in every possible way, because it is The Best.” See also: packages. |
Mar 17, 2013
Martin Bazley (331)
379 posts
|
Topic: Wish lists / Extensions to Theme Support
That’s because the tool sprites are stored separately. There should be another sprite file in the same location as wherever you got the sprite file you were looking at from. The command to load a new set of icons, from an appropriate sprite file, is:
This will load the contents of a sprite file into the Wimp sprite pool, overwriting any sprites with the same name which are already there. (In particular, any sprite in the Wimp pool called !appname or similar will appear as the icon of an application directory called !AppName.) To replace the toolset:
To see the default system sprites, middle-click over the ‘Apps’ icon, select “Open ‘$’”, and open Resources.Wimp. |
Mar 17, 2013
Martin Bazley (331)
379 posts
|
Topic: Announcements / RISC OS assembler book
Apart from here, you mean? |
Mar 16, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / [BBC Basic] INSTALL question
I am curious. What would you personally classify BBC BASIC as, if not a scripting language? FWIW, I consider it to be very much a scripting language on RISC OS too. The big differences between BASIC’s situation on RISC OS and that on Windows are:
It is, in short, actually important. That said, I’ll admit that part of the reason I wrote that paragraph was just to see if you’d pop up to get all defensive again. You’re treading a very fine line between contributing to this forum and being to the detriment of it. |
Mar 13, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / [BBC Basic] INSTALL question
You can’t do the in-the-same-directory thing from within BASIC, though. Either enter the full pathname or use the ‘Set directory’ option from the Filer’s menu. Oh, and: BBC BASIC for Windows is a very different language, incompatible in multiple exciting ways (like this one). Learning both at once is probably an exercise best left unattempted. I’d recommend dropping it and sticking to RISC OS, since BASIC is actually useful in many situations on RISC OS, and there are very few real alternatives, whereas it’s just another scripting language on Windows (and with highly icky syntax at that). I’ve never understood what people see in BASIC for other systems (other than nostalgia) when the likes of Python and Ruby are available, and come with all the whizz-bang stuff built into their syntax rather than bolted onto an unstructured, barely procedural language from fifty years ago. |
Mar 13, 2013
Martin Bazley (331)
379 posts
|
Topic: Community Support / OSCLI problem in Basic
That’s two words. :-P
Or you could take the infinitely simpler option and call Wimp_Initialise. This will make the Wimp do all the work for you. You don’t even need to call Wimp_Poll at any point – your program can still single-task, you just have to remember to call Wimp_CloseDown at the end. There are, of course, caveats. You can no longer use command windows or TaskWindows to display output, and you can’t change screen mode, or issue any other VDU commands that RISC OS would normally clean up for you after you ‘press SPACE or click mouse to continue’. Also, you can only call other single-tasking programs this way, otherwise control will pass back to you before the child task has finished. The latter problem can be worked around by using Wimp_StartTask instead of OSCLI, but then you have to write a poll loop to wait for the task to quit. It all depends on how comfortable you feel about RISC OS programming. |