Hi Peter,
The ArcEm CVS has been static for quite some time.
Last change 2009-09-25?
Sorry yes. cvs log does things in a unhelpful order. I've been
using SVN too long.
Yes, I found it annoying when I went to look.
$ cvs log |
sed '/^date: /!d; s#/.. .*##; s/.* //;
Hi Chris,
On Tue, 06 Oct 2009 20:26:31 -0700, Peter Naulls wrote:
What I'll likely do then is close down the Sourceforge page. I'll
import the ArcEm CVS into riscos.info SVN for historic value (if
anyone really wants write access, just let me know a user
name/password). It's possible
Hi Jan-Jaap,
I renamed /usr/bin/autoconf to /usr/bin/autoconf2.64 and made
/usr/bin/autoconf a symlink to /usr/bin/autoconf2.59 but I got the
exact same problem.
I then did the same to /usr/bin/autoreconf* but I'm not so sure that
that will have the desired effect.
How about getting the
Hi John,
5. Since several of years there is a new kid around the block in 'free'
compiler land : LLVM http://www.llvm.org/. Basically it is a compile
infrastructure/JIT/code transformer/code analyser/etc of which one of
its usecases is just compile C/C++ with apparently respectful
Hi Jan-Jaap,
while ((read = fscanf(file, %10[^\n]%c, buffer, lastchar)) != EOF)
fscanf(3) here says %[ matches a non-empty sequence. That matches the
behaviour I see on Linux, no gccsdk involved.
$ printf 'foo\nbar\n\nxyz\n' | ./fscanf | sed 4q
read: 2: 'foo', lastchar = 10
Hi Alan,
In the short term is there a workaround I can use to provide the
functionality? I assume I would need to use the kill function and
somehow finding the processes in the same group.
Perhaps the implementation of kill(2) has this already? Linux's
killpg(2) says
On Linux, killpg()
John wrote:
Very bizar, looks like a real bug somewhere but someone needs to dig
into this as I don't think we can just guess it based on above facts
only.
Perhaps there's something up with stderr, file descriptor 2, and that
causes the first signal the handling of which wobbles because it
Hi Gavin,
I am making a serious effort (again) to get to grips with gcc4_1_2r2.
I am trying to assemble a short piece of ARM code with
gcc -o sys.o sys.s
Try one of
gcc -c sys.s
gcc -c -o sys.o sys.s
I keep getting an error:
: In function 'crt1_data':
Hi Matthew,
The telldir function has to return a long int which says where we
currently are in reading the directory and these special
subdirectories. The seekdir function has to take that value and turn
it back into a GBPB position in the directory and in the corresponding
subdirectory if
Hi John,
I think it would be better to derive this from RISC OS filetype,
i.e. test on Obey, Absolute, ELF, Module, Utility (any
others?).
If you allowed Obey, why not BASIC? And then, why not Lua, REXX,
Python etc - how would the code know whether to treat an arbitrary
Hi Ben,
I thought about that too (i.e. check on Alias$@RunType_XYZ), but
then we have text files with execute permission bit set too. I'm
not sure whether it going to be worthwhile.
As you say, most data filetypes has RunType variables assigned, so
that's no use to distinguish
Hi Ron,
My useage here is in fact wrong, it appears that command and args are
wrapped in single quotes for a subshell. (Also done in a shellscript)
No, that's too simplistic. Unix shells like dash follow
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
in their
Hi Lee,
> I have yet to find any documentation on the web that defines the order
> of return.
The order of return after fork(2) is defined as being not determinable,
i.e. correct code has to cope with either order or even simultaneous
return since another CPU might be brought it to run one of
Hi Gavin,
> You are a genius. Thanks.
I'm often told I "full of it". ;-)
But it was not I that pointed this out, but Nick Burrett.
http://www.riscos.info/pipermail/gcc/2015-September/006473.html
> I guess I had not properly appreciated what 'const' meant.
I recommend Chris Lattner's three
Hi Gavin,
> static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];
...
> lua_pushstring(L, (char *)(_buf[6])); /* name */
> lua_pushinteger(L, rdir_buf[5]); /* file type */
> return 2; /* number of returned values */
...
> The 'name' part comes out OK, but the 'ftype' is
Hi Gavin,
> > ^ shouldn't that be static int? Wouldn't the const imply that the
> > buffer never changes
This is the problem.
> The buffer doesn't change. It's its contents that change. I will try
> removing the const.
The buffer is its contents. As an array rather than a pointer the
address
Hi Michael,
> Getting drown by emails from bugzilla.
I emailed a couple of Theo's personal addresses earlier today, and I've
now emailed Peter to turn on list moderation until they stop being
generated. Hopefully, they'll be stemmed soon.
--
Cheers, Ralph. (Just another subscriber.)
Hi Dave,
> ... and, if there is: have I failed to notice it, or did it not
> arrive in my inbox?
http://www.riscos.info/pipermail/gcc/2017-May/thread.html
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
GCCSDK mailing list
Hi Alan,
> I have a mysterious crash in a SDL based program when it attempts to
> do a pthread_wait in an atexit handler. The error is: pthreads:
> ***fatal error, aborting*** pthread_yield called with context
> switching disabled.
>
> My guess is this means that GCC is shutting down the threads
Hi,
Jeremy wrote:
> The pull-request for doing so is already submitted, see link below.
The email is https://curl.haxx.se/mail/archive-2017-05/0004.html and the
PR is https://github.com/curl/curl/pull/1463 with
Hi Theo,
> It is still worth commenting on upstream bug trackers - they won't
> know what RISC OS is, but if the bug is not a RISC OS specific one
> then the bug report is still relevant.
It might be that RISC OS triggers it in a similar way to the odd set up
on that bug report.
src/log.c:
Hi Ronald,
> In trying to implement wget's own support lib there was a requirement
> for an implementation of freading().
Here's glibc's description. https://manned.org/__freading.3
> It looks like some extra system flag would need to be set on every
> read, and negated on a write.
That may
Hi Lee,
> > Does sockets only exist in the current task? If I do
> > "wimp_start_task", can I use my socket in the new task?
>
> No, although the underlining OS socket is I believe system wide,
> Unixlib refers to them by file descriptor and these are allocated
> locally within each task rather
23 matches
Mail list logo
