operator new [] syntax?
Matt
class function using cfront. I had no problems writing the 'non-array'
version like so.
class myclass
{
public:
void* operator new ( size_t n );
}
but
void* operator new [] ( size_t n );
and other variants that I tried would not work.
Will I have to make do with the auto-default function?
Please excuse my terrible terminology, there's too much of it for my
brain these days...
Thanking you in advance,
Matt
Peter Naulls
> Does anyone know the syntax ( if there is one ), to the 'new array'
> class function using cfront. I had no problems writing the 'non-array'
> version like so.
>
> class myclass
> {
> public:
>
> void* operator new ( size_t n );
> }
>
> but
> void* operator new [] ( size_t n );
>
> and other variants that I tried would not work.
If you want to use even remotely modern C++, then you should really
be looking at GCC instead. Look for a new release very shortly.
Rob Kendrick
Matt <matt...@live.co.uk> wrote:
> Does anyone know the syntax ( if there is one ), to the 'new array'
> class function using cfront.
Stop right there. cfront is laughable. If you insist on using C++,
the *only* compiler you should be using is GCC. And yes, that also
excludes EasyC++.
B.
Matt
> > Does anyone know the syntax ( if there is one ), to the 'new array'
> > class function using cfront.
>
> Stop right there. cfront is laughable. If you insist on using C++,
> the *only* compiler you should be using is GCC. And yes, that also
> excludes EasyC++.
>
> B.
!!! Please !!!
Every bloody time I ask for help using cfront I get 'use GCC'. What
you think I've never used it? It is free.
And while your having a poke at EasyC++, at least it has a DEBUGGER,
which is a reason I am using Cfront for part of my current project.
Seriously, do you expect me to write back in a months time, saying
"Wow thank you, GCC's changed my life!!"
I shouldn't have to explain my reasons for using whatever tool I
choose,
and if you really feel the need to reply to a question you don't know,
a
"Sorry, I don't know." I would find far more useful.
Matt
Matt
>
> > Does anyone know the syntax ( if there is one ), to the 'new array'
> > class function using cfront.
>
> Stop right there. cfront is laughable. If you insist on using C++,
> the *only* compiler you should be using is GCC. And yes, that also
> excludes EasyC++.
>
> B.
!!! Please !!!
Peter Naulls
> On 24 Dec, 00:47, Rob Kendrick <n...@rjek.com> wrote:
>> On Wed, 23 Dec 2009 13:06:40 -0800 (PST)
>>
>> Matt <matta...@live.co.uk> wrote:
>>> Does anyone know the syntax ( if there is one ), to the 'new array'
>>> class function using cfront.
>> Stop right there. cfront is laughable. If you insist on using C++,
>> the *only* compiler you should be using is GCC. And yes, that also
>> excludes EasyC++.
>>
>> B.
>
> !!! Please !!!
Do you think shouting is conducive to reasonable discussion? Not
really, no.
> Every bloody time I ask for help using cfront I get 'use GCC'. What
> you think I've never used it? It is free.
I don't know; you didn't mention it, nor your reasons for not using it,
and I cannot recall all conversions on csa.p on this matter.
> And while your having a poke at EasyC++, at least it has a DEBUGGER,
"you're", FWIW, which perhaps isn't much in your excited state. EasyC++
is not, IMCO, a serious compiler. There is actually a port of remote GDB
for RISC OS, but it definitely needs some work. And the Acorn C/C++
debugger will work with GCC generated binaries - at least, as well as it
works with anything, which isn't that great.
> which is a reason I am using Cfront for part of my current project.
> Seriously, do you expect me to write back in a months time, saying
> "Wow thank you, GCC's changed my life!!"
No, why would I expect that? But I do know that G++ is the only
remotely modern C++ compiler on RISC OS, and is being actively
developed right now.
> I shouldn't have to explain my reasons for using whatever tool I
> choose,
No, you don't have to, but if you are getting so worked up about it,
and saying you don't like it, then you should at least justify your
answer.
> and if you really feel the need to reply to a question you don't know,
> a
> "Sorry, I don't know." I would find far more useful.
I don't know the exact reasons that CFront doesn't support what you
want, except that it's very old. Your implication here is that there's
some kind of magic work around for this very old piece of software. But
that doesn't preclude suggesting alternatives. I'm certainly not going
to apologize for providing an answer that differs from one you had
already decided upon.
I'm happy to discuss the merits of various development options on RISC
OS, but let's try for a little calmness.
druck
> Every bloody time I ask for help using cfront I get 'use GCC'. What
> you think I've never used it? It is free.
Every time you ask why (the ancient, archaic and hideous even back in
the day) CFront doesn't support even the simpliest C++ features,
people quite rightly advise you to use a proper C++ compiler.
> And while your having a poke at EasyC++, at least it has a DEBUGGER,
> which is a reason I am using Cfront for part of my current project.
If you want to use the abysmally unreliable DDT then you are better
off writing in plain C and not trying to fathon the assembly which is
the result of the excruitiating C code that CFront spits out.
If you want to use C++ and a debugger, then RISC OS not a suitable
platform. Many many ex-RISC OS developers would tell you this, but
they are no longer around for precisely that reason.
> Seriously, do you expect me to write back in a months time, saying
> "Wow thank you, GCC's changed my life!!"
> I shouldn't have to explain my reasons for using whatever tool I
> choose, and if you really feel the need to reply to a question you
> don't know, a "Sorry, I don't know." I would find far more useful.
Bug we do know the answer and it is; YOU CANT DO IT WITH CFRONT!
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page - http://www.armclub.org.uk/32bit/
Matt
OK, now for some calmness. I apologize for my ranting and language -
and maybe
my grammer even :)
I had just got exasperated that my questions were going unanswered and
that I seemed
judged that my choice of tool was born from ignorance.
I am not much of a c++ programmer, I much prefer assembler. My choice
to use C++
is for portabilitly. My current project (an ARM based 3D engine), is
for RISC OS, Symbian,
Windows Mobile and maybe PalmOS, and C++ is the popular (if not only)
choice for these
platforms.
As for cfront (I hear the screams).. I use for one reason only,
Deskdebug. I was sorely
disappointed to find it didn't work with GCC. I wrote many e-mails to
Weiss Niklaus in the
hope he would change this, but all the same I think Deskdebug is a
fantastic program,
and for 'some' situations, I find the option of using a great debugger
with a limited c++ compiler
( with the little C++ I use - and know for that matter ) more
advantageous than just a great
compiler. And also, (as when using anything with limitations) I will
still want to learn the most
about what tool use.
To hear there has been progress for RISC OS on the GDB front is great
news, but when you
said 'remote', do you mean software for a PC debugging over JTAG or
similar? If not please
explain, but also is there a JTAG connection in an Iyonix? Has anyone
out there hooked their's
up?
Once again my apologies, and I wish you all a carm and serene new
year. :)
Matt
amount of C++ I use - and know ) more
Rob Kendrick
Matt <matt...@live.co.uk> wrote:
> I am not much of a c++ programmer, I much prefer assembler. My choice
> to use C++
> is for portabilitly. My current project (an ARM based 3D engine), is
> for RISC OS, Symbian,
> Windows Mobile and maybe PalmOS, and C++ is the popular (if not only)
> choice for these
> platforms.
C++ is not a portable language; everybody's implementations lack a
different set of features. If you want portability, write good-quality
C.
> As for cfront (I hear the screams).. I use for one reason only,
> Deskdebug. I was sorely
> disappointed to find it didn't work with GCC. I wrote many e-mails to
> Weiss Niklaus in the
> hope he would change this, but all the same I think Deskdebug is a
> fantastic program,
> and for 'some' situations, I find the option of using a great debugger
> with a limited c++ compiler
> ( with the little C++ I use - and know for that matter ) more
> advantageous than just a great
> compiler. And also, (as when using anything with limitations) I will
> still want to learn the most
> about what tool use.
If you want to debug, and work with C++, while writing code to run on
multiple platforms;
a) develop the code on the other platforms. The tools are so
much better it's incredible, and
b) use GCC under RISC OS. For bonus points, cross-compile from
a Linux box.
> To hear there has been progress for RISC OS on the GDB front is great
> news, but when you
> said 'remote', do you mean software for a PC debugging over JTAG or
> similar? If not please
> explain, but also is there a JTAG connection in an Iyonix? Has anyone
> out there hooked their's
> up?
Last I heard, running a module under RISC OS, and gdb under Linux on a
foreign host.
B.
druck
> If you want to debug, and work with C++, while writing code to run on
> multiple platforms;
> a) develop the code on the other platforms. The tools are so
> much better it's incredible, and
> b) use GCC under RISC OS. For bonus points, cross-compile from
> a Linux box.
That's what I had to do for both DiscKnight and ARMalyser. There is just
no way I'd have been able to debug these moderately complex programs
with the megre tools available under RISC OS. I wrote the code at home
on Zap, compiled it with an OS_Lib compatiblity library and debugged
it mainly with Visual Studio and gdb on Linux for the 64 bit version.
---druck
Matt
> > explain, but also is there a JTAG connection in an Iyonix? Has anyone
> > out there hooked their's
> > up?
>
> Last I heard, running a module under RISC OS, and gdb under Linux on a
> foreign host.
>
> B.
Please if anyone can elaborate. i.e which connector, software, OS
etc...
Peter Naulls
[snip excess quoting - please trim appropriately]
>
> To hear there has been progress for RISC OS on the GDB front is great
> news, but when you
> said 'remote', do you mean software for a PC debugging over JTAG or
> similar? If not please
> explain, but also is there a JTAG connection in an Iyonix? Has anyone
> out there hooked theirs up?
JTAG has many applications, but most of those are nothing to do with
application or even OS-level development. On Iyonix, its main
use is reflashing stuff.
GDB for RISC OS was developed mainly to help debug NetSurf (AIUI), so
its use outside of that may be largely untested, although I have
briefly tried it. The "remote" part means you need to run the
GDB server on another machine. See the GCCSDK documentation
for more details - as perhaps you should have already.
Matt
Please could you explain exactly what you did and with what software
etc.
Were you compiling just ARM binaries, or were you just using C (no
assembler) ?
With linux were you debugging using an emulator (running embedded
linux maybe) or
compiling x86 binarys? What about Visual Studio, what was your target
device/emulator?
Which libraries did you use? Is there an ARM emulator you can use with
Visual Studio?
I only have a PC linux boot disc at the moment, but was thinking about
a full
installation. Would I be better off (debugging) with ARM linux on my
iyonix,
or with ARM emulation on PC linux?
At the moment I debug using Deskdebug with RISCOS, Visual Studio with
a pocketPC,
and Carbide (eclipse-gcc) with an S60 mobile phone.
My main issues with the latter two IDE's is that the emulators (I know
of) use x86 binaries,
and so I am always using a device to debug.
So any advice on cross-compiling, remote debugging, platform porting,
etc would be
appreciated.
Ideally I would be using RealView if anyone fancies buying me a
copy.. :)
Thanking you in advance,
Matt
Oh one more thing, Adrian Lees are you out there, what happened to
the Ultimate
Debugger'. http://adrianl.drobe.co.uk/udp.html Every so often I visit
the page in the hope
of any sort of release...
Peter Naulls
> On 27 Dec, 11:29, druck <n...@druck.org.uk> wrote:
>> That's what I had to do for both DiscKnight and ARMalyser. There is just
>> no way I'd have been able to debug these moderately complex programs
>> with the megre tools available under RISC OS. I wrote the code at home
>> on Zap, compiled it with an OS_Lib compatiblity library and debugged
>> it mainly with Visual Studio and gdb on Linux for the 64 bit version.
>>
>> ---druck
>
> Please could you explain exactly what you did and with what software
> etc.
> Were you compiling just ARM binaries, or were you just using C (no
> assembler) ?
> With linux were you debugging using an emulator (running embedded
> linux maybe) or
> compiling x86 binarys? What about Visual Studio, what was your target
> device/emulator?
> Which libraries did you use? Is there an ARM emulator you can use with
> Visual Studio?
Hm, broken wrapping ;-(
This doesn't directly answer any of your questions, but in a nutshell:
* Cross compile almost anything RISC OS with GCCSDK
http://www.riscos.info/index.php/GCCSDK on Linux, Cygwin or anything
that provides a UNIX environment. Debian or Ubuntu will be
your most pain-free solutions here.
* Editing can be done with on RISC OS over NFS/Samba or whatever native
editor/IDE you want - after all, it's just files in the end.
* A limited selection of RISC OS command line applications can be run
under Linux under QEMU - http://www.riscos.info/index.php/QEMU
Its main purpose is really to help the GCC compiler test cases.
Almost everything you see on riscos.info is developed like this.
druck
> On 27 Dec, 11:29, druck <n...@druck.org.uk> wrote:
>> Rob Kendrick wrote:
>>> If you want to debug, and work with C++, while writing code to
>>> run on multiple platforms; a) develop the code on the other
>>> platforms. The tools are so much better it's incredible, and b)
>>> use GCC under RISC OS. For bonus points, cross-compile from a
>>> Linux box.
>> That's what I had to do for both DiscKnight and ARMalyser. There is
>> just no way I'd have been able to debug these moderately complex
>> programs with the megre tools available under RISC OS. I wrote the
>> code at home on Zap, compiled it with an OS_Lib compatiblity
>> library and debugged it mainly with Visual Studio and gdb on Linux
>> for the 64 bit version.
>>
> etc. Were you compiling just ARM binaries, or were you just using C
> (no assembler) ?
>> With linux were you debugging using an emulator (running embedded
>> linux maybe) or compiling x86 binarys? What about Visual Studio,
>> what was your target device/emulator?
I was compling the C code to a native binary on each platform, and
debugging with the integrated or command line debuggers.
> Which libraries did you use?
The only interaction the programs had with RISC OS were via OSLib calls,
so I wrote my own limited implementation of OSLib using portable POSIX
code which would run on all target platforms.
> Is there an ARM emulator you can use with Visual Studio?
There is, but that is for developing Windows CE implementations. But
there is no need for that as I'm debugging the C code, not ARM
assembler. I just compiled as an x86 command line binary and ran that
under the integrated debugger.
> I only have a PC linux boot disc at the moment, but was thinking
> about a full installation. Would I be better off (debugging) with ARM
> linux on my iyonix, or with ARM emulation on PC linux?
It all depends what you are doing, if using a high level language such
as C or C++, you don't need to bother what the instruction set of the
binary is.
> So any advice on cross-compiling, remote debugging, platform porting,
> etc would be appreciated.
The most important thing was the programs I'm talking about were command
line applications, with a very trivial desktop front end on RISC OS.
This allows the core command line application to be run and debugged on
any system. If the were desktop apps, it wouldn't be possible to do this
as easily.
---druck
Mr John FO Evans
<ne...@druck.freeuk.com> wrote:
> If you want to use the abysmally unreliable DDT then you are better
> off writing in plain C and not trying to fathon the assembly which is
> the result of the excruitiating C code that CFront spits out.
I am amazed that DDT is so unpopular. Having used it for a long time I
would suggest that it is reliable but feature short. At least it is
available.
The main feature shortages I would identify are.
a) Only simple variables can be changed and/or the fetures provided
are undocumented.
b) Repeat runs cannot be run using a command file.
John
--
_ _________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
Peter Naulls
> In article <ac3cd8ce...@druck.freeuk.net>, druck
> <ne...@druck.freeuk.com> wrote:
>> If you want to use the abysmally unreliable DDT then you are better
>> off writing in plain C and not trying to fathon the assembly which is
>> the result of the excruitiating C code that CFront spits out.
>
> I am amazed that DDT is so unpopular. Having used it for a long time I
> would suggest that it is reliable but feature short. At least it is
> available.
> The main feature shortages I would identify are.
> a) Only simple variables can be changed and/or the fetures provided
> are undocumented.
> b) Repeat runs cannot be run using a command file.
c) Hasn't been developed for a very long time.
Yes, I don't doubt the usefulness of DDT in a certain class of RISC OS
programs on certain versions of RISC OS for certain users. That doesn't
mean others haven't found it unstable, and prone to locking the machine.
Never mind that RISC OS itself doesn't offer any credible help for
debugging (beyond *memory and the disassembler anyway).
Does DDT work well with modern debug information (DWARF), on threaded
and possible shared-library using applications? Not so much, I think.
Never mind its RISC OS 2 era user interface.
And DeskDebug is laudable, but having not used it myself, I can't really
comment, but concerns about its support for C++, ELF and GCC debug in
general are valid, and although IMO, probably very easily added, despite
the author's (IIRC) reservations about such things.
Martin Wuerthner
Peter Naulls <pe...@chocky.org> wrote:
> And DeskDebug is laudable, but having not used it myself, I can't really
> comment, but concerns about its support for C++, ELF and GCC debug in
> general are valid, and although IMO, probably very easily added, despite
> the author's (IIRC) reservations about such things.
I do not share that view. As far as I can see Niklaus is keen to add
support for debugging information generated by GCC, but achieving that
looks very difficult to me.
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
ArtWorks 2 -- Designing stunning graphics has never been easier
spam...@mw-software.com [replace "spamtrap" by "info" to reply]
Peter Naulls
> In message <hhdan0$8ou$1...@news.eternal-september.org>
> Peter Naulls <pe...@chocky.org> wrote:
>
>> And DeskDebug is laudable, but having not used it myself, I can't really
>> comment, but concerns about its support for C++, ELF and GCC debug in
>> general are valid, and although IMO, probably very easily added, despite
>> the author's (IIRC) reservations about such things.
>
> I do not share that view. As far as I can see Niklaus is keen to add
> support for debugging information generated by GCC, but achieving that
> looks very difficult to me.
On what basis? Now, I don't pretend that ELF/DWARF is a walk in the
park, but what are the technical problems? I believe I've offered help
on a number of occasions, and certainly the other GCCSDK developers
would most likely do so too.
druck
> <ne...@druck.freeuk.com> wrote:
>> If you want to use the abysmally unreliable DDT then you are better
>> off writing in plain C and not trying to fathon the assembly which is
>> the result of the excruitiating C code that CFront spits out.
>
> I am amazed that DDT is so unpopular. Having used it for a long time I
> would suggest that it is reliable but feature short. At least it is
> available.
Assuming it doesn't just hang the machine, it's just excruciatingly
painful to use compared to any modern debugger. I'd only ever use it as
an absolute last resort when everything you could do with tracef's have
failed.
A debugger like Visual Studio is a joy to use, and I often just step
through through a first run of my code to verify it's behaviour, without
actually needing to debug anything.
---druck
Matt
> In article <ac3cd8ce50.dr...@druck.freeuk.net>, druck
>
> <n...@druck.freeuk.com> wrote:
> > If you want to use the abysmally unreliable DDT then you are better
> > off writing in plain C and not trying to fathon the assembly which is
> > the result of the excruitiating C code that CFront spits out.
I don't.
> I am amazed that DDT is so unpopular. Having used it for a long time I
> would suggest that it is reliable but feature short. At least it is
> available.
> The main feature shortages I would identify are.
> a) Only simple variables can be changed and/or the fetures provided
> are undocumented.
> b) Repeat runs cannot be run using a command file.
>
> John
>
I'm amazed that Deskdebug is not more popular. I rarely hear
it's mention. I couldn't work without it.
A free demo is available to try, and the support is good.
Matt
Indeed V.S was my first experience of a proper debugger, and a joy it
was.
Being able to view any bit of memory/register as any struct/type/
whatever is great.
The 'mouse over' info is a big time-saver too.
And a big thanks for pointing out that the new PocketPC emulator now
uses
ARM code. yipee.
Matt
druck
> I'm amazed that Deskdebug is not more popular. I rarely hear
> it's mention. I couldn't work without it.
> A free demo is available to try, and the support is good.
It is good, and very clever to overcome the challenge of debugging in a
multitasking environment on RISC OS. It is a bit rough around the edges
in places as Nik is an assembler programmer, so the C handling isn't as
quite as natural as it would be if that's what he used himself.
While I was a beta tester unfortunately I was working on command line
projects at the time, which couldn't take any advantage of the clever
multitasking stuff.
---druuck
Rob Kendrick
druck <ne...@druck.org.uk> wrote:
> Matt wrote:
> > I'm amazed that Deskdebug is not more popular. I rarely hear
> > it's mention. I couldn't work without it.
> > A free demo is available to try, and the support is good.
>
> It is good, and very clever to overcome the challenge of debugging in
> a multitasking environment on RISC OS. It is a bit rough around the
> edges in places as Nik is an assembler programmer, so the C handling
> isn't as quite as natural as it would be if that's what he used
> himself.
What put me off, purely as a hobbyist, was the 60 quid asking price.
Sorry, for the amount of debugging I do that has to be done under RISC
OS (rather than under Linux using gdb, which a surprisingly large
amount of RISC OS code can be with a little effort) can be done in DDT
or via printf.
B.
Mr John FO Evans
<pe...@chocky.org> wrote:
> Yes, I don't doubt the usefulness of DDT in a certain class of RISC OS
> programs on certain versions of RISC OS for certain users. That doesn't
> mean others haven't found it unstable, and prone to locking the machine.
The only time DDT has locked my machine is when attempting to display
certain windows structures (not counting my own stupid mistakes!) - they
appear to contain pointers to undefined variables somewhere in the icon
area. This means it is necessary to display only single items from the
structure. It happens so rarely that I have never examined the problem in
detail.
It can run out of memory but that again happens rarely and only on megabyte
sized programs.
I must confess that I have never tried to use it in privileged mode.
What I find far more of a worry is that it has never been updated and is,
as far as I can tell, completely missing under RO6. All the debugging systems
that I have been involved with emulate the immediate area of the program
counter and any jump locations and hence do not need any dedicated system
calls which, I am told, are missing in RO6 and given as the reason for
debugging not being available.
I wish the appropriate owner would release the source so that some of the
worst holes could be at least patched.
Peter Naulls
> I wish the appropriate owner would release the source so that some of the
> worst holes could be at least patched.
>
But it'd still be hopelessly archaic. The effort would be far better
spent on improving DeskDebug. Yes, I know that it's a commercial
product, but it's so obviously superior to DDT.
Mr John FO Evans
<pe...@chocky.org> wrote:
> But it'd still be hopelessly archaic. The effort would be far better
> spent on improving DeskDebug. Yes, I know that it's a commercial
> product, but it's so obviously superior to DDT.
I would suggest that DeskDebug is more suitable for assembly level work and
DDT for Higher level Langauges. Access to structures and arrays in high
lever languages is, in my opinion, far better under DDT - even though its
C-syntax for this is impenetrable!!!!
However as far as I know neither work under RO6!!!!!!!!!
PS Please sombody tell me why DDT is archaic? It loads, sets breakpoints
at any function, single steps and traces. Programs can be easily
configured using MAKE and it only fails for me on indeterminate
indirections in the depths of windows structures.
PPS Please also tell me why Desk Debug is so infuriatingly complex for
doing the simplest things? To me it is completely non-intuitive.
Peter Naulls
> <pe...@chocky.org> wrote:
>> But it'd still be hopelessly archaic. The effort would be far better
>> spent on improving DeskDebug. Yes, I know that it's a commercial
>> product, but it's so obviously superior to DDT.
>
> I would suggest that DeskDebug is more suitable for assembly level work and
> DDT for Higher level Langauges. Access to structures and arrays in high
> lever languages is, in my opinion, far better under DDT - even though its
> C-syntax for this is impenetrable!!!!
I have no idea what this is supposed to mean - an example
would do wonders. However, perhaps your keyboard needs a clean, the !
key appears stuck.
> PS Please somebody tell me why DDT is archaic?
When was the last time it was seriously developed? Compare it to
debug environments on other platforms. druck has already mentioned
Visual Studio, although I personally wouldn't go near any Windows
programming, no matter the quality of the dev environment.
Never mind support for threading, ELF, shared libraries, C++.
> PPS Please also tell me why Desk Debug is so infuriatingly complex for
> doing the simplest things? To me it is completely non-intuitive.
Again, an example would do wonders.
Mr John FO Evans wrote:
> In my opinion many of the correspondants on this topic are doing RISCOS a
> grave disservice by asking for the moon.
>
You have started a new thread, and not replying to anything that
was actually said, so I'm not sure, again, what examples you are
referring to. But the only moon asking I'm sure of is your
insistence on DDT being updated.
> If any new programs are to emerge new talent us needed which in turn will
> need a straightforward development environment which works over the
range of
> new RISC OS hardware. What is not needed is a stalling of any updating of
> the working enviroment by asking for something which works with all the
> latest programming gizmos.
I have no idea what this is supposed to mean. Your argument here is
so vague is to not mean anything at all.
> So why are we not getting the minimum - which is DDT and/or DeskDebug
under
> RISCOS 4,5 and 6? Together with some upgrades to unplug some of their
> current problems ?
Because RISC OS is a minority platform, where all the interested
developers are otherwise engaged, and others have left due to
various bullying. In any case, substantial work *is* on going
in developing GCC/UnixLib/Shared lirbaries, all of which critical to
any development at all. There's even been work on GDB.
> Reading Archive I would suggest that C++ is far from a standard
> build under RISCOS so why not settle for Assembler and C?
Sorry, what? I have read the Archive column, and it contains
much waffle, IMO. He often uses an old version, and very
obscure ill-defined stuff. But what, exactly, is non-standard
about C++ on RISC OS? And are you *seriously* suggesting that
substantial future development be done in assembler? Why are
we "settling"?
> RISCOS development thrived on part-time programmers with good ideas
> but who were not necessarily computer scientists.
Yes, but what has this to do with anything, except the pervasiveness
of BASIC debates in this group?
Martin Wuerthner
Peter Naulls <pe...@chocky.org> wrote:
> Martin Wuerthner wrote:
>> In message <hhdan0$8ou$1...@news.eternal-september.org>
>> Peter Naulls <pe...@chocky.org> wrote:
>>
>>> And DeskDebug is laudable, but having not used it myself, I can't really
>>> comment, but concerns about its support for C++, ELF and GCC debug in
>>> general are valid, and although IMO, probably very easily added, despite
>>> the author's (IIRC) reservations about such things.
>>
>> I do not share that view. As far as I can see Niklaus is keen to add
>> support for debugging information generated by GCC, but achieving that
>> looks very difficult to me.
> On what basis?
Mainly on the basis that the current DeskDebug implementation has no
abstraction from the ASD debug information created by the Acorn/Castle
C compiler. DeskDebug loads the ASD information into memory and uses
it directly. Therefore, handling a different format would require that
format to be converted to ASD on the fly or it would require a major
rewrite of almost anything referring to debug information.
> Now, I don't pretend that ELF/DWARF is a walk in the
> park, but what are the technical problems?
Probably none, except that it looks like a huge amount of work, even
more so if it has to be done from assembler.
Peter Naulls
>
> Mainly on the basis that the current DeskDebug implementation has no
> abstraction from the ASD debug information created by the Acorn/Castle
> C compiler. DeskDebug loads the ASD information into memory and uses
> it directly. Therefore, handling a different format would require that
> format to be converted to ASD on the fly or it would require a major
> rewrite of almost anything referring to debug information.
>
>> Now, I don't pretend that ELF/DWARF is a walk in the
>> park, but what are the technical problems?
>
> Probably none, except that it looks like a huge amount of work, even
> more so if it has to be done from assembler.
Is written in BASIC assembler, or Acorn C assembler? This would be
significant for potential C integration. I appreciate that Nikalus's
English may not be that great, and he might be a lot more comfortable
talking to you in German.
As an alternative, it might be possible to provide facilities for
ELF in a module. But certainly I can only guess at the internals
of DD. Obviously it's one of the largest assembler programs
written for RISC OS.
Mr John FO Evans
I did say assembler and C. For the average programmer we are not settling
for anything and as a result leaving them high and dry. No wonder they fall
away and look only at ready-made solutions.
C++ as described in Archive is a language for dedicated computer
scientists and not for the average hobby programmer. We had a similar
debate years ago when ADA was being promoted in many circles. In my opinion
both ADA and C++ take the average programmer so far from the machine that
they can detract from the quality of the code rather than enhancing it.
For many then I contend that a simple straightfoward language is the best
option and we should leave complex environments to the dedicated
specialists.
What is happening now is that because dedicated specialists wrangle over
which of the latest gizmos is best, nothing is being done to provide full
support at lower levels.
Acorn thrived initially on hobby programmers who mostly worked in BASIC
with a few migrating to C and Assembler. Today the rapidly growing group of
hobby programmers using BB4W (BBC Basic for Windows) shows how a simplistic
environment is still appreciated, workable and useful.
So again I suggest that if we were to develop and 'settle' for a
straightforward, well documented, environment with a good set of support
tools we would find increasing interest in the platform. This of course
is what ACORN were trying to do - I can see no later attempts to do
anything better for the platform - so why not tidy up what we have?
>
> > RISCOS development thrived on part-time programmers with good ideas
> > but who were not necessarily computer scientists.
>
> Yes, but what has this to do with anything, except the pervasiveness
> of BASIC debates in this group?
As I said before it has to do with the survival of the platform as we move
into the new miniature hardware age.
John
PS What did you mean by the 'pervasiveness of BASIC debates?
Peter Naulls
> <pe...@chocky.org> wrote:
>> But what, exactly, is non-standard
>> about C++ on RISC OS? And are you *seriously* suggesting that
>> substantial future development be done in assembler? Why are
>> we "settling"?
>
> I did say assembler and C. For the average programmer we are not settling
> for anything and as a result leaving them high and dry. No wonder they fall
> away and look only at ready-made solutions.
I don't know how you reach that conclusion. The implication is that we
are lacking something on RISC OS - certainly a comprehensive debugger
is obvious, but I have no idea what you are saying.
> C++ as described in Archive is a language for dedicated computer
> scientists and not for the average hobby programmer.
I'm not interested in what Archive (or rather, Rob Johnson) thinks it
says. *I* don't like C++, but it's nevertheless a popular (if I can use
that term with so few developers) language on RISC OS, and it's heavily
used in some programs I support. And so I need to support it, and make
use of it. As do the other GCCSDK developers, at least one of who
favours it. This doesn't have anything to do with computer science.
You are essentially trying to argue that it doesn't get supported on
RISC OS.
We had a similar
> debate years ago when ADA
"Ada". But this topic has nothing to do with language advocacy - that's
been done to death and is simply not interesting, and I won't engage you
over this.
> What is happening now is that because dedicated specialists wrangle over
> which of the latest gizmos is best, nothing is being done to provide full
> support at lower levels.
Nothing of the sort is happening for RISC OS. If you think it is, then
your understanding of matters is very narrow.
> Acorn thrived initially on hobby programmers who mostly worked in BASIC
> with a few migrating to C and Assembler. Today the rapidly growing group of
> hobby programmers using BB4W (BBC Basic for Windows) shows how a simplistic
> environment is still appreciated, workable and useful.
So, at which point did the topic change to IDEs? We done this all
before. If you are hoping for a comprehensive development environment
for RISC OS, then you need to do more than just demand one. There's
at least one IDE for RISC OS that is being actively developed.
> So again I suggest that if we were to develop and 'settle' for a
> straightforward, well documented, environment with a good set of support
> tools we would find increasing interest in the platform.
I have no idea what this is supposed to mean in practice nor what kind
of tools you are talking about.
> This of course is what ACORN were trying to do - I can see no later attempts to do
> anything better for the platform - so why not tidy up what we have?
I find this deeply offensive - not for myself, but of the 10 years plus
work that John Tytgat, Lee Noar, Alan Buckley, John-Mark Bell and
many many others have put into improving tools for RISC OS.
>> > RISCOS development thrived on part-time programmers with good ideas
>> > but who were not necessarily computer scientists.
>>
>> Yes, but what has this to do with anything, except the pervasiveness
>> of BASIC debates in this group?
>
> As I said before it has to do with the survival of the platform as we move
> into the new miniature hardware age.
I fear getting anything less vague out of you is going to be impossible.
I still have no idea what this means.
>
> PS What did you mean by the 'pervasiveness of BASIC debates?
What do you *think* I mean. BASIC has exceptionally high use on
RISC OS, for better or for worse. A review of the last few years
of this group makes that plain.
At this point I'm wishing for a short retort from druck.
Jeremy Nicoll - news posts
> In article <hhnsb4$dau$1...@news.eternal-september.org>, Peter Naulls
> <pe...@chocky.org> wrote:
> > But what, exactly, is non-standard
> > about C++ on RISC OS? And are you *seriously* suggesting that
> > substantial future development be done in assembler? Why are
> > we "settling"?
>
> I did say assembler and C. For the average programmer we are not settling
> for anything and as a result leaving them high and dry. No wonder they
> fall away and look only at ready-made solutions.
When you say "average programmer" I have no idea what you mean.
Hobbyist? Professional? Working in embedded applications? Commercial DP?
> C++ as described in Archive is a language for dedicated computer
> scientists
I would say that those articles are clearly written by someone who likes
comparing things... but there's little sign of anything that I'd call
'Science' in that (though there's clearly a methodical approach), let alone
anything that reminds me of my (early 1980s) Comp Sci degree.
I'm not very sure why the articles are published - or whether anyone (who
knows what they're about) bothers to read them... but Archive needs people
to write to fill the pages to sell the mag.
> and not for the average hobby programmer.
I'm sure you have some specific attributes in mind for your average hobby
programmer, but I don't know how you expect the rest of us to know what they
are.
> We had a similar debate years ago when ADA was being promoted in many
> circles. In my opinion both ADA and C++ take the average programmer so far
> from the machine that they can detract from the quality of the code rather
> than enhancing it.
Was Ada not specified/developed for a very specific sort of programming task
- not the kind that any "average programmer" would be likely to be doing,
certainly not a hobby one?
> Today the rapidly growing group of hobby programmers using BB4W (BBC Basic
> for Windows) shows how a simplistic environment is still appreciated,
> workable and useful.
I think that's a red herring. Writing a windows app in BB4W would cease to
be easy at the point where you need to know lots about the Windows API and
COM and so on. That's the same place where you'd come unstuck writing in VB
or Javascript or any number of other languages. Come to think of it, the RO
APIs don't fall into people's laps either. One needs to read the PRMs, look
at other people's code, and ask for help. In some ways it's much harder on
RO as there's hardly any books, online tutorials and so on.
> So again I suggest that if we were to develop and 'settle' for a
> straightforward, well documented, environment with a good set of support
> tools we would find increasing interest in the platform.
Would you? The people who'd find this interesting can already get their
intellectual challenges on other platforms, where there's the big advantage
of better tools, better environments, faster boxes, much bigger communities
of like-minded people, and so on. Who'd want to put time & effort writing
here when they could write something elsewhere that will run on multiple
platforms?
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "nnn" by "284".
Peter Naulls
> Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
>
>> In article <hhnsb4$dau$1...@news.eternal-september.org>, Peter Naulls
>> <pe...@chocky.org> wrote:
>>> But what, exactly, is non-standard
>>> about C++ on RISC OS? And are you *seriously* suggesting that
>>> substantial future development be done in assembler? Why are
>>> we "settling"?
>> I did say assembler and C. For the average programmer we are not settling
>> for anything and as a result leaving them high and dry. No wonder they
>> fall away and look only at ready-made solutions.
>
> When you say "average programmer" I have no idea what you mean.
>
> Hobbyist? Professional? Working in embedded applications? Commercial DP?
Yes, thank-you Jeremy. All we can conclude is that every developer
does things differently. Trying to enforce hobbyist developers
(which all RO developers essentially are) to do the same narrow thing is
pointless and counter-productive.
> Was Ada not specified/developed for a very specific sort of programming task
> - not the kind that any "average programmer" would be likely to be doing,
> certainly not a hobby one?
Why not? ;-) Any language has its proponents. On RISC OS it is
Steffen Huber, and it worked out pretty well for him (CDBurn).
Unfortunately because Steffen was the only real user of Ada,
it proved impractical to produce a later version of the Ada compiler
some years ago when we moved to later versions of GCC. Perhaps with
more recent changes that John Tytgat is presently working on, it
might again be possible.
> Would you? The people who'd find this interesting can already get their
> intellectual challenges on other platforms, where there's the big advantage
> of better tools, better environments, faster boxes, much bigger communities
> of like-minded people, and so on. Who'd want to put time & effort writing
> here when they could write something elsewhere that will run on multiple
> platforms?
Well, yes. But on RISC OS you have a better chance of doing stuff no
one has done before. And whilst I've used Linux extensively - perhaps
done more development on it than RISC OS (much of it *for* RISC OS),
it can sometimes lack some of the "funness"
druck
> At this point I'm wishing for a short retort from druck.
Abandon hope all yee that cling to crap tools, for you'll spend more
time fighting them than writing software, and there resteth RISC OS.
---druck
Mr John FO Evans
<pe...@chocky.org> wrote:
> I find this deeply offensive - not for myself, but of the 10 years plus
> work that John Tytgat, Lee Noar, Alan Buckley, John-Mark Bell and
> many many others have put into improving tools for RISC OS.
>
I really am sorry if I caused offense, all these people have done great
work - but despite that we lack a complete development environment which can
be used on the new hardware. Maybe we need to look at RISCOS to gather it
all together and perhaps explain why they limited RISC OS 6 in the way that
they did.
Apart from that I must shut up - I am clearly out of touch with peoples
aspirations and ideas.
John
Rob Kendrick
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> I really am sorry if I caused offense, all these people have done
> great work - but despite that we lack a complete development
> environment which can be used on the new hardware. Maybe we need to
> look at RISCOS to gather it all together and perhaps explain why they
> limited RISC OS 6 in the way that they did.
What do you think we are missing, other than a modern native debugger?
NetSurf's source code is large and extensive, and yet a very large
proportion can be debugged on other platforms, making use of the
excellent tools there that RISC OS has no hope of ever obtaining.
Writing software that way seems to be the sensible route, to me.
B.
Peter Naulls
> we lack a complete development environment which can
> be used on the new hardware.
Or old hardware.
> Maybe we need to look at RISCOS to gather it
> all together and perhaps explain why they limited RISC OS 6 in the way that
> they did.
This doesn't make sense - are you suggesting that ROL deliberately
limited RO6 (or for that matter, Castle/RO5) so that DDT didn't run?
Moving to new hardware or making OS improvements ultimately means
compromises will be made, or reshuffling done. And things that
poke deeply inside the OS without using well-defined APIs often
break - DDT is certainly one of those.
> Apart from that I must shut up - I am clearly out of touch with peoples
> aspirations and ideas.
No, you are out of touch with stuff that has actually gone on, or is
still going on.
Mr John FO Evans
Kendrick <nn...@rjek.com> wrote:
> What do you think we are missing, other than a modern native debugger?
> NetSurf's source code is large and extensive, and yet a very large
> proportion can be debugged on other platforms, making use of the
> excellent tools there that RISC OS has no hope of ever obtaining.
> Writing software that way seems to be the sensible route, to me.
Writing software on other systems is fine for major developments. but ACORN
thrived originaly on work from individuals who would never had had either
the equipment or the knowledge to work that way.
My sole complaint is that at this moment there is no native debug system
which can be used on anything later than R4 (or possibly 5) and certainly
not on RO6. As one of the original advocates of a debug system way back in
RO2 days I find it amazing that this particular facility has been lost.
Rob Kendrick
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> In article <20100104195...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> wrote:
> > What do you think we are missing, other than a modern native
> > debugger? NetSurf's source code is large and extensive, and yet a
> > very large proportion can be debugged on other platforms, making
> > use of the excellent tools there that RISC OS has no hope of ever
> > obtaining. Writing software that way seems to be the sensible
> > route, to me.
>
> Writing software on other systems is fine for major developments.
> but ACORN thrived originaly on work from individuals who would never
> had had either the equipment or the knowledge to work that way.
But now PCs are so cheap it's not an excuse, and it's easy enough to do.
> My sole complaint is that at this moment there is no native debug
> system which can be used on anything later than R4 (or possibly 5)
> and certainly not on RO6. As one of the original advocates of a debug
> system way back in RO2 days I find it amazing that this particular
> facility has been lost.
Debuggers are difficult. Especially when the underpinnings of ones OS
are being meddled with so.
B.
Mr John FO Evans
<pe...@chocky.org> wrote:
> This doesn't make sense - are you suggesting that ROL deliberately
> limited RO6 (or for that matter, Castle/RO5) so that DDT didn't run?
My understanding is that there is a missing system interrupt which prevents
debugging systems like DDT and Desk Debug from running on RO6.
>
> Moving to new hardware or making OS improvements ultimately means
> compromises will be made, or reshuffling done. And things that
> poke deeply inside the OS without using well-defined APIs often
> break - DDT is certainly one of those.
>
> > Apart from that I must shut up - I am clearly out of touch with peoples
> > aspirations and ideas.
>
> No, you are out of touch with stuff that has actually gone on, or is
> still going on.
>
Please then show me a full development system for RO6. Meanwhile I will
stick with the tried and trusted ACORN/CASTLE C/C++ and DDT on RO4.
Mr John FO Evans
<pe...@chocky.org> wrote:
> Never mind that RISC OS itself doesn't offer any credible help for
> debugging (beyond *memory and the disassembler anyway).
>
> Does DDT work well with modern debug information (DWARF), on threaded
> and possible shared-library using applications? Not so much, I think.
> Never mind its RISC OS 2 era user interface.
>
> And DeskDebug is laudable, but having not used it myself, I can't really
> comment, but concerns about its support for C++, ELF and GCC debug in
> general are valid, and although IMO, probably very easily added, despite
> the author's (IIRC) reservations about such things.
Yes but it is perfectly possible to write and debug programs on RO4 using
ACORN's C/C++ and DDT. All these newer development options are fine but they
don't currently make up a full system.
We are entering a new world of RISCOS compatible boards running RO6 or
similar and cannot offer new users a full set of native tools to work with
them.
When will it change?
Rob Kendrick
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> Please then show me a full development system for RO6. Meanwhile I
> will stick with the tried and trusted ACORN/CASTLE C/C++ and DDT on
> RO4.
It's called GCCSDK running on Linux. Sure, it's not a native one, but
it targets it, thus classifies as "for RO6" :)
Honestly, it's so much less pain and almost a delight to develop for
RISC OS under Linux, I'm amazed everybody doesn't do it. It's
especially useful in large projects; NetSurf takes upwards of 20
minutes to build on RISC OS, and about 15 seconds on my modest Linux
box.
B.
Rob Kendrick
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> We are entering a new world of RISCOS compatible boards running RO6
> or similar and cannot offer new users a full set of native tools to
> work with them.
That's fine; RO6 doesn't run on any new boards; only RiscPCs. :)
B.
Steffen Huber
> C++ as described in Archive is a language for dedicated computer
> scientists and not for the average hobby programmer.
It really depends on what you are trying to achieve. If you want to
really master a programming language, it is almost always hard work
and being a CS helps a lot.
But if you only want to write good software, it is usually good
enough to have a firm grasp of a reasonable subset of the programming
language of your choice. And this includes C++, although C++ makes
it rather hard to see that reasonable subset...
> We had a similar
> debate years ago when ADA was being promoted in many circles. In my opinion
> both ADA and C++ take the average programmer so far from the machine that
> they can detract from the quality of the code rather than enhancing it.
It's Ada, not ADA (being a name rather than an acronym). The usual joke
in comp.lang.ada is to ask why that question is related to american
dentists (ADA is the American Dentist Association).
Ada is a very well-designed language (especially in its latest
incarnation, Ada 2005). It allows you to learn things step-by-step,
since many of its features are completely orthogonal. You can choose
whether to use its multi-threading feature (called "tasking"). You
can choose whether to use its object-oriented features.
It is easily possible to write Ada in a very low-level manner.
It supports bit specifications for simple types and record layouts,
it allows you to use all the unsafe low-level C stuff in a very
safe manner. If you could compare the CDVDBurn source code with
its C equivalent on Linux, cdrecord, or its C++ equivalent cdrdao,
you would be surprised how much Ada helps when writing clean
low-level code.
Actually, I think that many BBC Basic developers could change
to Ada easily. I once started to write a "From BBC Basic to Ada"
primer and was surprised how easy it really is. And even if you
end up programming BASIC in Ada, it has so many advantages due
to its strong typing system when it comes to detect errors
early.
Unfortunately, the only available Ada compiler on RISC OS is
in a pretty bad shape (26bit only, relies on heavily hacked
runtime stuff to create 32bit neutral code, has a ton of
known compiler bugs), so at the end of the day it is not
really a good alternative.
Steffen
--
Steffen Huber
hubersn Software - http://www.hubersn-software.com/
Steffen Huber
>> We had a similar debate years ago when ADA was being promoted in many
>> circles. In my opinion both ADA and C++ take the average programmer so far
>> from the machine that they can detract from the quality of the code rather
>> than enhancing it.
>
> Was Ada not specified/developed for a very specific sort of programming task
> - not the kind that any "average programmer" would be likely to be doing,
> certainly not a hobby one?
Ada was specified as "the language to end all other languages". The DoD
wanted to unify its software to be written in only one language instead
of the 1300 different ones they found when analysing their legacy
software.
So the original idea was that Ada should be the last general purpose
language to be needed - ever.
While this goal was clearly not achieved (and it was really quite
arrogant of those 70s guys that it could be achieved), what we
ended up with is a very well-specified general purpose language
that could be used instead of C, C++, C#, Java, VB, Delphi,
<insert your favourite compiled language here> in nearly all cases.
Peter Naulls
>> Moving to new hardware or making OS improvements ultimately means
>> compromises will be made, or reshuffling done. And things that
>> poke deeply inside the OS without using well-defined APIs often
>> break - DDT is certainly one of those.
>>
>>> Apart from that I must shut up - I am clearly out of touch with peoples
>>> aspirations and ideas.
>> No, you are out of touch with stuff that has actually gone on, or is
>> still going on.
>>
>
> Please then show me a full development system for RO6. Meanwhile I will
> stick with the tried and trusted ACORN/CASTLE C/C++ and DDT on RO4.
I don't know why you are arbitrary putting caps in "Acorn" and "Castle"
neither of which are acronyms. No, I never claimed any such thing
exists - it never has for RISC OS. My responses here are to question
what seems to be your incredibly naive/narrow understanding of what
*has* been going on with RISC OS development tools. If there weren't
so many obvious problems, then we wouldn't be spending so much time
trying to address the problems.
As for "development environment", it's nice of you to try any
conflate this with a debugger, but that's just one piece of
many. You'd do well to actually try and define the problem
before running your mouth off.
The Castle tools constitute a modern C compiler, but in
practice, little else, and certainly not any number of
things that go along with a C compiler in a modern environment.
Fortunately, GCC *does* support most of them.
> "...for RO6."
RO6 doesn't run on, and may never run on, any remotely modern
hardware.
> We are entering a new world of RISCOS compatible boards running RO6
> or similar and cannot offer new users a full set of native tools to
> work with them.
Well, to the extent that RO6 is similar to RO5. But again, let's not
fool ourselves that RO6 is relevant here.
> When will it change?
When someone does something about what ever problem you have yet to
define in any detail. Not you, presumably.
[GCCSDK]
> Writing software on other systems is fine for major developments. but
> ACORN (sic) thrived originaly on work from individuals who would never
> had either the equipment or the knowledge to work that way.
Disingenuous and pointlessly backwards looking. Neither the hardware
nor software systems that are used for GCCSDK really existed in the days
of Acorn. Are we going to endlessly look to the "good old times", or
perhaps we can actually for once look forward and define the real
problems that need to be solved.
Meanwhile, in terms of "development environments" (although not a
debugger), there is one system that is being actively developed.
http://www.reallysmall.co.uk/Pages/normal/software/development/sourcery/sourcery.html
But I expect you to trash this too as not fitting into your
personal view of how things should be.
FWIW, I have never used Sourcery - it doesn't fit with the kind of
development I would generally do.
Peter Naulls
> It is easily possible to write Ada in a very low-level manner.
> It supports bit specifications for simple types and record layouts,
> it allows you to use all the unsafe low-level C stuff in a very
> safe manner. If you could compare the CDVDBurn source code with
> its C equivalent on Linux, cdrecord, or its C++ equivalent cdrdao,
> you would be surprised how much Ada helps when writing clean
> low-level code.
Well, maybe. Your point is probably justified, but having looked
at the sources for both of those tools, they are particularly
messy, even for the languages in question. Some of this is
due to having to support endless hardware variations, and
some is obviously due to having any number of maintainers,
but even so, it is really bad code.
Of course, you might argue that using a better language would help
enforce better code in the first place, and certainly there is
a lot to be said for strong language enforcement (esp typing)
for low-level stuff, but it is *usually* possible to do
clear C for this kind of stuff - but it's not something I
would expect everyone to just be able to do.
Steve Potts
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
[snip]
> PS Please sombody tell me why DDT is archaic? It loads, sets breakpoints
> at any function, single steps and traces. Programs can be easily
> configured using MAKE and it only fails for me on indeterminate
> indirections in the depths of windows structures.
* Stops all desktop activity when it hits breakpoints, not just the program
being debugged. This may be a side effect of RISC OS's single threaded
nature or general design - I don't know enough to comment, but it severely
limits usefulness.
* RISC OS 2 style windows (which I guess are not normal windows anyway).
* It's been so long since I used it, I can't truely remember the limitations,
but I remember hitting them whenever I tried doing anything moderately
complicated with TCP sockets. I admit I wasn't then an expert user of it.
> PPS Please also tell me why Desk Debug is so infuriatingly complex for
> doing the simplest things? To me it is completely non-intuitive.
Never used it but would do if I could debug C on RISC OS 6. Never looked
into it if I'm honest.
Cheers
Steve.
--
StevePotts at blastzone DOT demon STOP co DOT uk (www.blastzone.demon.co.uk/)
Written on RISC OS.
http://www.riscos.com/
Martin Wuerthner
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> In article <hhtk7s$nek$1...@news.eternal-september.org>, Peter Naulls
> <pe...@chocky.org> wrote:
>> This doesn't make sense - are you suggesting that ROL deliberately
>> limited RO6 (or for that matter, Castle/RO5) so that DDT didn't run?
> My understanding is that there is a missing system interrupt which prevents
> debugging systems like DDT and Desk Debug from running on RO6.
I do not think it is anything like that. How did you arrive at that
conclusion?