Facilities/equipment hire for RISC OS developers' conference 2012

I shan’t elaborate much as it may not be viable (for the moment), but briefly…

• Bounty to cover (or subsidise) venue hire, equipment/internet connections, lunch
• Other costs (transport, overnight accommodation, additional meals) to be borne by developers
  • May be cheaper to consider YHA hire a hostel (some venues do offer catering) as well as traditional hotel venues – some hostels have campsites too, which may suit those who wish to bring a partner/family along
• Possibly timed to coincide with a show? (e.g. ‘fringe’ event on the same day, or the previous/next day – whatever works best)
  • Note, the proposal is not that show organisers volunteer to additionally coordinate such an event
• Encourage ROL to get involved too?
• Rationale:
  • Sometimes people find it useful to put faces to names
  • IRL could help flatten the learning curve for coders new to RISC OS
  • Invite the press and give them an opportunity to speak to a number of developers in one hit

I like the idea of a Developer’s Conference, time to meet and chat with other developers away from the pressures of a Show.

Possibly timed to coincide with a show? (e.g. ‘fringe’ event on the same day, or the previous/next day – whatever works best)

I think that on the same day as a Show would be counter-productive as there will be at least some developers who also need to be be manning a stand at the Show. Maybe the following day after a Show might work, but that would depend on if exhibiting developers were able to stay on, especially if they’ve come to the Show with others who may not want/need to stay the extra day.

I’d probably suggest trying to get a Saturday and/or Sunday sometime away from a Show weekend if possible, although I appreciate that how ever many people would attend you’ll have that many different dates for when they’re available!

A Developer Conference could be held around the London Show, maybe on the Friday beforehand, although Saturday evening or Sunday are also possible. Would have use of the ROUGOL projector and the hotel internet access.

As anyone who has been to the London Show will know, it consists of a main hall with three side conference rooms, so we could extend the hire of one of those rooms.

The show is on Saturday 29th October in case anyone had forgotten :-)

Erm, we were actually kinda thinking about organizing something like this anyway… Hadn’t really finalised the details yet, however. I think they need to be a bit more formal than a show, since this isn’t really a user event, but rather a developer thing – although perhaps they’re one and the same these days? Since there’s no formal registered developer scheme any more, the question is, who should take the lead?

Personally, I’d be happy to organise things, but truthfully, the development lead is coming from the likes of Jeffrey, so it’d be rather crazy to hold such a meeting without his input, and that of the rest of ROOL, and RISCOS Ltd too, if they’re willing.

Co-inciding with a show has its merits, but also disadvantages as some people use shows as a jumping off point for other work or visits. Also, I suspect the London show would be one of the more expensive ones for such an event to take place, just because of the higher prices there. One wonders if the Webbington in Feb might be better, but I don’t know.

It somewhat depends how much needs to be covered – is a full day necessary? There’s a danger of it becoming a glorified “club meet” if there aren’t topics to cover, and with the openness of the Internet, the traditional methods of disseminating info may no longer be as significant as they were before…

Also, semi-related, we’ve talked about holding an “informal” event for people in the north/scotland, as there has been nothing north of Wakefield for a long time.

Personally, I’d be happy to organise things, but truthfully, the development lead is coming from the likes of Jeffrey, so it’d be rather crazy to hold such a meeting without his input, and that of the rest of ROOL, and RISCOS Ltd too, if they’re willing.

Personally I don’t really see the point of developer conferences, mainly for the reason you state of the Internet being so open/available now. But I’ve never been to a developer conference either, so maybe I just don’t know what I’m missing out on.

The only way I can see a conference being useful is if it’s used for the platform leaders (ROOL, ROL (we hope), and myself I guess) to formulate a plan of action on how to best improve the OS, and to talk that plan over with the developers in order to convince them that the effort they’ll have to put in (e.g. to fix application compatability issues with the planned improvements) will be worth it. Or to just hire a hypnotist and brainwash them if they fail to comply. *cough*. And after the direction has been decided, draw up a plan of who’s going to work on what, set up rough dates for when features are expected, etc. But this last part falls apart a bit since (a) the only people working on the OS itself are doing so in their spare time and probably don’t want to be tied down to rigid schedules, and (b) the application developers are either working part-time as well, or are working full time and probably won’t be too interested in wasting time working on the core OS if they’re not going to get any/much money out of it (hence the involvement of the hypnotist). Of course the presence of the bounty scheme might help to sway people towards wanting to work on the roadmap, so an alternate approach might be to have a whip-round and see if enough money can be found within a short timeframe in order to fully fund a certain number of the bounties that would be needed for implementing the roadmap. But that would require the people who accept the bounties to be different from the people who funded the bounties, otherwise the bounty acceptees(?) wouldn’t be getting any money out of the process.

So if anyone has a proper plan for a developers conference (not just “put names to faces”, “teach the newbies”, and “talk to the press” like Trevor suggested!) then I’m willing to be convinced.

Jeffrey touches on the key point – the lack of developers. I haven’t been able to get that out of my head for the past 24 hours.

The single biggest problem we have right now is lack of coders willing/able to do the dev work. It’s crazy, but I have ideas for projects and ports coming out of my ears, but there aren’t people around to do it.

There are many reasons for this – most people do RISC OS stuff in their spare time, as the going RISC OS rate (which can probably be summed up in terms of Happy Meals!) per month is too pitiful for anything else. Whilst I live off that, it is unrealistic to expect others who are used to earning many times that, to give RISC OS a chance.

So many excellent hobby coders have left because they gave up hope. Maybe the progress forwards is enough to re-ignite their interest, but for some reason, ex-RISC OS people tend to have almost an “anger” towards the OS, as if they resent the time they spent using it. I don’t really understand this, but there we go.

Someone suggested that the old RISC OS Connect project could be a way of reaching out to developers. It is certainly worth a shot.

But, again, as Jeffrey says, we need to have a “plan of campaign”.

lack of developers

• This is one reason why I think it’s important to get the hardware to (try to) ensure an early Raspberry Pi port. Although it lacks the power of the likes of the ARMini, many apps could cater for both platforms. Visibility of RISC OS could encourage newcomers.
• Could authors/publishers of programming books be approached with a view to publishing small print runs of revised reprints? (As a last resort, if the necessary electronic masters are unavailable, a facsimile with a few additional new chapters may still be useful.)
• Some people will be deterred by the “shared source” aspect, which also precludes piggy-backing via events such as the Libre Software Meeting. [Edit: Or FOSDEM]
• New developers (especially outside Europe) have little knowledge of the existence of RISC OS, which is absent in recent “alternative OS” pieces, 1, 2.

ROL (we hope)

As developers can cater for both forks, where are Paul Middleton and Aaron Timbrell in this discussion? A unified call to potential developers would be good (as has been said before by others).

a proper plan for a developers conference (not just […]

Good point.

Just to say we’re working from a couple of angles on trying to raise awareness. We’re also trying to get some funding for this, but as many of you know, I don’t ever rely on that kind of stuff, because it rarely materialises.

The recent progress on ARM hardware and RISC OS in general really is quite exciting, more so than we’ve seen in a while, I think. It may be that this will encourage some people back into the fold. The difficulty is breaking the initial reluctance to return. Often people leave thinking “I’m doing the right thing, RISC OS is going nowhere”. To encourage them back first requires a change of heart, which is almost an admission that leaving wasn’t the right thing to do. People don’t like that kind of thinking!

Certainly things that community members can do is to try and dig out any correspondence they had with developers (pd or commercial) back in the day, and casually let them know that progress is being made, and that there are bounties to be had etc. The worst (I think) that can happen is they say “no, you’re an idiot for still using RISC OS”, which we’ve all heard many times before!!!

I should probably add that stuff like the return of Alan Peters and TBA is a great example of the kind of positive thinking/development that we all should be working towards. I just felt that deserved to be singled out as a kind of “Thankyou”, but obviously all the long-standing devs need their fair share of beers/cheers too :)

I can’t see the idea of a developer conference working out. And to be honest I also can’t see the plan “get more developers” to succeed. Even hobbyist developers, if they have ever coded for another OS, take certain things for granted. IDEs, debuggers, languages, libraries, tutorials and other documentation. If someone asks “well, interesting this RISC OS – how can I start develop for it?” – what is your answer? C/C++? And the GUI toolkit – the Toolbox? And where are the tutorials for RISC OS programming?

The hurdles for RISC OS newcomers are plenty, and they are high. There are so many reasons not to use or develop for RISC OS.

The best you can hope for is for some ex-developers becoming interested again (and the BeagleBoard is great for that, because it is cheap and “cool” enough – RPCemu is great for it, too, because along with RO5 it provides the 0 UKP solution for PC users). Pray that they will accept the challenge that RISC OS development is today compared to other systems.

I can’t see the idea of a developer conference working out. And to be honest I also can’t see the plan “get more developers” to succeed.

"Some time after the Summer, we might arrange for a get-together of interested parties to flesh out these ideas further."

C/C++? […] the Toolbox? And where are the tutorials for RISC OS programming?

The hurdles for RISC OS newcomers are plenty, and they are high. There are so many reasons not to use or develop for RISC OS.

Maybe such missing tools should be added to the roadmap. Before any work on tutorials is begun, we’d need to decide what’s the simplest way to develop/maintain it. I guess local HTML docs may be considered a good system but that wouldn’t easily allow searching of all docs. And how would such HTML be generated/maintained? A local copy of wiki pages here? Is the old Acorn hypertext authoring system (what about HyperStudio? Genesis?) available for modification? Would it be a reasonable low-overhead solution? Or a modified NetSurf with multi-file searching? The ARM SDT seems to have metamorphosed into RVDS – how does that relate to RO development?¹

¹ [Edit: Up to SDT v.2.51]

It’s perhaps worth pointing out here that software development on RISC OS is taking small steps forward. Jeffrey’s zero-page protection work (okay, that’s not such a small step!), the new BASIC assembler from TBA (not so small, either!), murmurs of work within ROOL on !DDT, similar murmurs of work on !DeskDebug… I’m not experienced enough with a variety of other software development environments on other platforms to comment much, but at least these are positive moves in the right direction.

As Trevor suggests, let’s map out what development tools we’re missing, and see what we can do to fill the holes, making software development for RISC OS less painful and hence encouraging more people to do it.

Don’t get me wrong. The last three years have seen progress in the RISC OS world that is just amazing. There are a lot of good things happening right now, in a lot of places. For people familiar with RISC OS, this is good news. But IMHO it is just not enough to attract new developers – by far.

It is depressing that the best GUI toolkits we have are based on BBC BASIC. It is also depressing that writing things in BBC BASIC seems to be the only way to write forward-compatible stuff – only BASIC software had a chance to survive the big RISC OS transitions (StrongARM, 32bit, ARMv7).

I agree with Steffen to a point, although truthfully many coders tend to build up their own arsenal of tools etc rather than relying on 3rd party stuff. It is often easier to base a new project on your own existing code, than start from scratch with a new generation of library/UI toolbox each year or two!

Whilst it may seem a bit sad that BASIC represents the best development route, it is also a testimony to the language. People seem pre-disposed to complain about BASIC, but on RISC OS, it scales almost linearly with CPU clock and architecture enhancements, making it suprisingly nippy on more recent hardware. Add in the built-in assembler, and I don’t think we need be ashamed of BASIC. Indeed, I’d argue that the ease by which a new user can begin BASIC programming is a strength of RISC OS!

However, such things do need expansion for the modern world. The VFP/NEON extensions are a great start, and there have been discussions about extending the syntax, too. A modern-ish BASIC, accompanied by quick-start toolkits such as WimpWorks or AppBasic, could be quite a potent way to get started with RISC OS stuff.

In RISC OS world, the coders were forced to build up their own libs because those delivered by Acorn (riscoslib anyone?) were mostly inadequate or expensive. The Toolbox was basically OK, but suffered from numerous problems (no free ResEd, manual only with C/C++ package, not enough gadgets, own gadgets not easily integratable into ResEd…) and came much too late.

Talking of BBC BASIC, it should be clear that it is nowadays a completely inadequate programming language. Speed is not the problem, but lack of abstraction is. It was great for the 80s with its integration of procedures and functions, its library concept and local vars and all that. But since the mid 90s, developers are expecting OO capability. Information hiding. Memory management. An IDE with a proper debugger. The complexity of modern software is so immense that you need every tool in your box to keep quality and productivity high. With BBC BASIC, it is just very hard to write complex software. That there are so many pieces of (high quality) software on RISC OS written in BBC BASIC is a testimony of the developers, not of the quakities of BBC BASIC.

I fear that it is nearly impossible to extend BBC BASIC to a point where it becomes a viable software development tool again – just read the TBA blog postings for details.

/blush… still codes via his own version of RISC_OSlib :( Better the devil you know… and have source code to!

BBC BASIC lacks modern features, but that is not it’s main use. Don’t use it for big complex tasks.
Steffen, you, me and many others here have been programming for years and don’t have a lot of use for BASIC any more, but it is still great as a starting point for first time programmers.

RISC_OSlib

Is its Developers’ Guide worth noting?

Wrong library – that’s OSLib you’re looking at there (I think they just named the sourceforge project ro-oslib to avoid conflicting with this OSLib)

RISC_OSLib is just a different build configuration of the Shared C Library, designed for static linking with programs. In fact I have a feeling the static version predates the shared version – Partly because the SCL source is in a “RISC_OSLib” folder in CVS, and partly because there’s little point in Acorn releasing a static version of the library if they’ve already got a perfectly good shared version.

And don’t be tempted to confuse the static RISC_OSLib with the discussion of ROM code being staticly linked to the Shared C Library ;-)

In RISC OS world, the coders were forced to build up their own libs

I remember I took part in this discussion on the net more than a decade ago and ‘we’ started to develop something called the RiscGuiLib, a gui lib in c++. There were a lot of initial discussions and everybody had a lot of good ideas and offered comments that I partly didn’t even understand but nobody submitted any code except me. Maybe I started writing code too early in the discussions, but nobody tried later so probably there was no better time. I added some info to my WIKI: http://www.familie-kall.de/cgi-bin/kall/wiki.cgi?RiscGuiLib

I had a messaging system in mind for passing information and classes that could accept information due to events and had to inherit the functionality from an interface class. I developed using VisualStudio on the PC and the RiscPC in parallel and tried to keep the codebase common. As GCC was not really up to all the concepts of c++ at that time and M$ tended to interpret things a little differently too, some languague parts were not useable.

To have something easy to play with, I programmed my self-made milling machine ( http://www.familie-kall.de/cgi-bin/kall/wiki.cgi?StepperFraese ) with it, and got it working e.g. transferred greyscale pictures into height-maps and milled from that in multi-tasking.

Next step I wanted to keep the multi-OS-Approach and looked for the SDL to fill my windows. It worked well on the PC, also under Linux, But on the RISC PC everything was much too slow, so I stopped that approach – End of the story :-)

The code is still there and the concepts/parts of the code could be included into a new approach.

Future:
I think it would be great to have some coding wizard that scans Files from ResEd, Menu Editors and Sprite Files and builds clearly marked sourcefiles that provide empty routine headers and includes the necessary library headers. To write that wizard, maybe using a different OS (with good debugging facilities) might be the fastest way. This ‘wizard’ approach is creeping through my mind (under the name of !Gandalf) since some years now, but I most probably won’t start this alone ;-)

But I’ve never been to a developer conference either, so maybe I just don’t know what I’m missing out on.

<groan> Hopefully nothing like these General In Da 80s NSFW linked images. </groan>

RiscGuiLib, !Gandalf

Sounds interesting – I hope there’s someone around here who has the time & skills to help you.