Acorn Arcade forums: Programming: Thanks, DDEUtils.
| |
Thanks, DDEUtils. |
| |
monkeyson2 (05:55 6/3/2005)
monkeyson2 (06:12 6/3/2005)
Phlamethrower (06:47 6/3/2005)
Phlamethrower (06:51 6/3/2005)
jmb (13:23 6/3/2005)
monkeyson2 (13:39 6/3/2005)
|
| |
|
Phil Mellor |
Message #62939, posted by monkeyson2 at 05:55, 6/3/2005 |
 Please don't let them make me be a monkey butler
Posts: 12380
|
Thutils.
I've been scuppered by a rather annoying bug. The culprits are a combination of:
DDEUtils 1.63 (4 Feb 2000), 1.64 (5 Nov 2002)
GCC 3.4.1 (yes, I know there's 3.4.4 available now, I'm currently downloading it at 3K/sec...)
SharedUnixLib 1.02
My random code.
My random code is:
int new_size = 14;
char* new_font = "\\FTrinity.Medium.Italic";
rin.r[1] = new_font;
rin.r[2] = new_size * 16;
rin.r[3] = new_size * 16;
rin.r[4] = 0;
rin.r[5] = 0;
kerr = _kernel_swi(0x40081, &rin, &rout); // Font_FindFont
if (kerr != NULL)
{
fprintf(stderr, "%s\n", kerr->errmess);
}
And the error reported is:
'ADFS::HardDisc4.$.Games.Magnetic.src.RISCOS' is a directory.
(This CSD and <Obey$Dir>)
It works fine with a font that has already been claimed somewhere, eg. the desktop font, or start draw, pick a font, type some text.
After various shift-booting and reloads, I've tracked it down to the DDEUtils module. The error always occurs with DDEUtils loaded, and never without it.
I think it must be because Font$Path contains the word "Prefix", and DDEUtils provides the command "Prefix":
Font$Path(Macro) : ADFS::HardDisc4.$.!BOOT.Resources.!Fonts.,<Font$Prefix>.,Resources:$.Fonts.
==> Help on keyword Prefix
*Prefix selects a directory as the current directory unique to the currently executing task. *Prefix with no arguments sets the current directory back to the
systemwide default (as set with *Dir).
Syntax: *Prefix [<directory>]
Isn't that fun? |
| |
 [ Log in to reply ] |
| |
|
Phil Mellor |
Message #62940, posted by monkeyson2 at 06:12, 6/3/2005, in reply to message #62939 |
Please don't let them make me be a monkey butler
Posts: 12380
|
Hmm. Works OK using the Shared C Library instead of UnixLib. Maybe it's the filename translation... |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #62941, posted by Phlamethrower at 06:47, 6/3/2005, in reply to message #62940 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Yes - I remember reading about that bug on the GCC mailing list. However the list archives for pre-2005 have vanished, and I no longer have a copy of the mails myself 
As a very rough guess, I think it was to do with a symbol such as @ causing problems with the filename translation. I can't see any obvious sign of the bug on the bug tracker, but I think it got fixed for 3.4.4. There are several mentions of improvements to the filename translation in the changelog, to support this view. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #62942, posted by Phlamethrower at 06:51, 6/3/2005, in reply to message #62941 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
==> Help on keyword Prefix
*Prefix selects a directory as the current directory unique to the currently executing task. *Prefix with no arguments sets the current directory back to the
systemwide default (as set with *Dir).
Syntax: *Prefix [<directory>] Hmm, actually that might be related to a problem I was having with the Dark Matter source tree on GCC 3.4.1 release 1. It was using *Dir to change directories, but not having any effect on the compiler. The source works with 3.4.4, so I think that the bug has been fixed. |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #62945, posted by jmb at 13:23, 6/3/2005, in reply to message #62940 |
Member
Posts: 467
|
Hmm. Works OK using the Shared C Library instead of UnixLib. Maybe it's the filename translation...
UnixLib was patched to work around the issue. ROL's DDEUtils has had this issue fixed, anyway. Castle's hasn't. The issue is that DDEUtils is incorrectly interfering with OS_File,14 etc calls.
So, your options are:
a) Update to a later UnixLib (the one in the GCC 3.4.4 release should do)
b) Get Castle to fix their DDEUtils (given that I reported it in January 2004, you'd have thought they might have got around to fixing it by now...)  |
| |
[ Log in to reply ] |
| |
|
Phil Mellor |
Message #62946, posted by monkeyson2 at 13:39, 6/3/2005, in reply to message #62945 |
Please don't let them make me be a monkey butler
Posts: 12380
|
UnixLib was patched to work around the issue. So, the time I've saved since December not downloading 3.4.4 has been overshadowed by the time taken for me to discover that I should have done! 
ROL's DDEUtils has had this issue fixed, anyway. Castle's hasn't. Hurrah for split-reponsibility over OS development.
So, your options are:
a) Update to a later UnixLib (the one in the GCC 3.4.4 release should do)
b) Get Castle to fix their DDEUtils (given that I reported it in January 2004, you'd have thought they might have got around to fixing it by now...) or
c) use libscl.
Currently on option 3 because it's working OK, but will probably switch back to UnixLib.  |
| |
[ Log in to reply ] |
| |
|
Acorn Arcade forums: Programming: Thanks, DDEUtils. |
