AcornC/C++ !SetPaths broken

Well, given there are only two of us here at ROOL, and we’re already working every evening and weekend on getting the RPi release done, I’d ask you to give us a chance to do things in the right way. I can understand nemo’s overwhelmingly negative comments about his experiences with the DDE, and it’s useful information for us, but it’s equally somewhat disheartening to face endless gripes about everything that’s not perfect on all fronts 24/7 when this is a voluntary activity within ROOL. Yes, you’ve paid for the DDE, but that cash simply goes towards ROOL operetaing costs, not us paying ourselves for the vast amounts of our time we’re putting into it.

Oh, and don’t forget the DDE came from Acorn, then got bodged about by Castle and we’ve been trying to improve things ever since. It’s always going to be an iterative process given how little time/effort we can realistically dedicate to it.

/end of moan.

You guys are doing a fantastic job on all fronts. It’s very much appreciated. Keep up the good work ;)

Nemo, if you’d like the examples from an earlier Acorn C/C++ just let me know your e-mail address and I can send them to you. I remember noticing the examples had changed last time I upgraded the compiler, but I’ve never tried to build them.

Well, given there are only two of us here at ROOL…

I don’t know how you find the time, I couldn’t. Gratitude and sympathy.

I can understand nemo’s overwhelmingly negative comments about his experiences with the DDE

I can assure you I would far rather have had an overwhelmingly positive experience.

it’s equally somewhat disheartening to face endless gripes about everything that’s not perfect on all fronts

With respect, this is the ‘Bugs’ forum. I would therefore expect its contents to be somewhat skewed towards the critical end of the spectrum if I were you.

And that one of your few paid-for products does not actually work as shipped is slightly more than a perfectionist gripe (with all aforementioned respect, gratitude and sympathy).

And that one of your few paid-for products does not actually work as shipped is slightly more than a perfectionist gripe (with all aforementioned respect, gratitude and sympathy).

If you want the examples to build you could download one of the source code archives and set it up.

I’ll fill you in on some of the “secret details” which might help a bit – we’ve done a significantly different DDE release internally (called version 24) which at the moment is still in the “testing and thinking about more changes” stage. We’ve tried to address a lot of the things which have come up here and general irritations. !SetPaths is a monster which really needs clobbering because it just doesn’t need to be anything like as complex as it seems to be. You’ll be happy to hear we ditched the installer altogether – the next DDE will come as a zip file containing, well, the DDE. As for timescales, we’ll just have to see how much time and enthusiasm we can muster over the coming weeks. Oh, and the next DDE won’t be on a Filecore formatted USB stick!

With respect, this is the ‘Bugs’ forum

Absolutely – but because Ben and I sit in the middle of it all and because I’m always knackered and grouchy, it’s hard not to take these things personally sometimes. Keep them coming in, but don’t be surprised when I shout “woe is me” now and then. :)

You’ll be happy to hear we ditched the installer altogether

What installer?? I just copied from the zip files!!!

!SetPaths is a monster which really needs clobbering because it just doesn’t need to be anything like as complex as it seems to be.

I got so cross with it I wrote my own version, which puts the CSD first, then the 26/32lib, and then the rest of the path. Surely putting the CSD last in the run path is madness? It would certainly be confusing.

You’ll be happy to hear…

I’m happy to hear you’e still talking to me to be honest. ;-)

All sounds good.

because I’m always knackered and grouchy

Oh we all are. Grumpy old men. It’s sad really. <bursts into tears>

On the subject of the DDE, it looks like there are a few issues collecting in the bug tracker that are awaiting fixes (including a couple of reports I’ve only just remembered to migrate from the forums). So if you’re getting ready for a new DDE release in the near future, and haven’t yet checked the bug tracker, now might be a good time to do so, especially as quite a few look like they should be easy fixes.

Cheers, Jeffrey. We have quite a lot more DDE issues in our internal bug tracker, too. :(

On the subject of !SetPaths, a couple of things I’ve noticed are:

1) It doesn’t add all the bundled libraries onto C$Path. Unicode is not added, for example.

2) I discovered a weird bug on the a9home whereby FileSwitch doesn’t ignore directories on Run$Path that don’t contain a !Run. This meant that if I was in a directory with a folder called ‘cmhg’, and I tried to call the cmhg command with *cmhg …, I got a “‘cmhg’ is a directory” error, because !SetPaths appends the Lib32 directory onto the end of Run$Path. My solution was just to strip it off the end and prepend it to Run$Path instead. Then everything works as it should.

Not that I expect ROOL to cater for obscure bugs in OS versions they have nothing to do with, but if it happens to come up in your redesign, having the Libs32 directory before @ on Run$Path would be nice ;) (Unless there’s a good reason not to do this?)

because !SetPaths appends the Lib32 directory onto the end of Run$Path

Well strictly it’s because the Lib32 is after the CSD. I’ve previously suggested that the CSD should be at the start of Run$Path, but this is a good example of when it would be confusing. My concern is the reverse – how do you run a file in the CSD if it happens to have the same name as one in some library somewhere?

ie if I want to run the cmhg in the CSD, I’d have to type */%.cmhg which I’m not sure trips from the tongue.

It is a great pity that *cmhg and *Run cmhg don’t do slightly different things… in other words:

*Set CSD ""
*Set Run$Path ...Lib32.,...OtherLibrary.,<CSD>
*Set ExplicitRun$Path <CSD>,Run:
*something     -> ...Lib32.something ...OtherLibrary.something something
*Run something -> something ...Lib32.something ...OtherLibrary.something