Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released

Hi Lee

I understood that the GCC 4.7.2 also has Fortran, is that not the case? I know that the Linux version comes with Fortran.

Best regards

Norman

On Sun., 12 Jul. 2020, 21:32 Lee Noar, <lee.noar@sky.com> wrote:

On 12/07/2020 12:17, alan buckley wrote:
> I�m not sure how the fortran compiler is built. Is it part of the
> build-world process or is it somewhere else?
>
> I didn�t add anything to package it, but if someone can tell me how it�s
> built and where the files are put I can add it to the packages created
> and upload it.

Hi Alan,

The Fortran compiler is actually part of GCC 8 rather than GCC 4.
There is a native RISC OS version of GCC 8 now (autobuilder/develop/gcc),
so perhaps we could look at doing a release of that. It produces a
skeleton !SharedLibs with just the new runtime libraries and this is
merged into to the GCC 4 !SharedLibs (so not standalone).
The two !GCCs would need to be kept separate though I think,
I've not looked at how to run two different versions of the
compiler from the same !GCC.

Thanks,
Lee.

Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released

On 12/07/2020 12:17, alan buckley wrote:
> I�m not sure how the fortran compiler is built. Is it part of the
> build-world process or is it somewhere else?
>
> I didn�t add anything to package it, but if someone can tell me how it�s
> built and where the files are put I can add it to the packages created
> and upload it.

Hi Alan,

The Fortran compiler is actually part of GCC 8 rather than GCC 4.
There is a native RISC OS version of GCC 8 now (autobuilder/develop/gcc),
so perhaps we could look at doing a release of that. It produces a
skeleton !SharedLibs with just the new runtime libraries and this is
merged into to the GCC 4 !SharedLibs (so not standalone).
The two !GCCs would need to be kept separate though I think,
I've not looked at how to run two different versions of the
compiler from the same !GCC.

Thanks,
Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released

I'm not sure how the fortran compiler is built. Is it part of the build-world process or is it somewhere else?

 

I didn't add anything to package it, but if someone can tell me how it's built and where the files are put I can add it to the packages created and upload it.

 

Regards,

Alan

 

From: Norman Lawrence
Sent: 12 July 2020 07:16
To: alan buckley
Cc: gcc@gccsdk.riscos.info
Subject: Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released

 

Hi Alan

Many thanks for all the hard work that you have put into packaging this release and also to all the other people who helped to create the new release.   I was under the impression that this release would include Fortran as part of the new release.  Was I mistaken or is there some more work to be done before it can be released with the GCC 4.6.2 pac

Best wishes

Norman

 

On Mon, 6 Jul 2020 at 06:24, alan buckley <alan_baa@hotmail.com> wrote:

I've finally managed to get all the bits and pieces together and have released GCC 4.7.4 release 4 based on the GCCSDK code this weekend.

 

I believe I've updated all the relevant pages and entries at www.riscos.info (e.g. http://www.riscos.info/index.php/GCC). If anyone want to check these and either edit them or let me know of any mistakes or omissions it would be appreciated.

 

I've also posted to comp.sys.acorn.announce and the ROOL forums that it's available.

 

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

 

Re: [gccsdk] RISC OS GCC 4.7.4 release 4 has been released

Hi Alan

Many thanks for all the hard work that you have put into packaging this release and also to all the other people who helped to create the new release.   I was under the impression that this release would include Fortran as part of the new release.  Was I mistaken or is there some more work to be done before it can be released with the GCC 4.6.2 pac

Best wishes

Norman

On Mon, 6 Jul 2020 at 06:24, alan buckley <alan_baa@hotmail.com> wrote:

I've finally managed to get all the bits and pieces together and have released GCC 4.7.4 release 4 based on the GCCSDK code this weekend.

 

I believe I've updated all the relevant pages and entries at www.riscos.info (e.g. http://www.riscos.info/index.php/GCC). If anyone want to check these and either edit them or let me know of any mistakes or omissions it would be appreciated.

 

I've also posted to comp.sys.acorn.announce and the ROOL forums that it's available.

 

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] GCC 4.7.4 Rel 4: isblank()

On 09/07/2020 11:44, Duncan Moore wrote:
> First of all, many thanks to everyone who's contributed to the latest
> release.
>
> There are a couple of issues with isblank():
>
> 1) In <ctype.h>, isblank() is incorrectly defined the same as isspace():
> �� #� define isspace(c) (__ctype[(int) (c)] & ___ctype_white)
> �� #� define isblank(c) (__ctype[(int) (c)] & ___ctype_white)
>
> 2) When there's a function pointer to isblank(), I get a link failure:
> "undefined reference to `isblank'".
>
> So this program:
>
> #include <stdio.h>
> #include <ctype.h>
> int main(void) {
> � int (*space)(int)=isspace;
> � int (*blank)(int)=isblank;������ // Fails to link.
>
> � printf("%i\n",!!isspace('\n'));
> � printf("%i\n",!!space('\n'));
>
> � printf("%i\n",!!isblank('\n'));
> � printf("%i\n",!!blank('\n'));��� // Fails to link.
>
> � return 0;
> }
>
> should give:
>
> 1
> 1
> 0
> 0
>
> whereas, if the 2 lines with comments are removed, I get:
>
> 1
> 1
> 1
>
> and it fails to link otherwise.

Ok, thanks for that, I can see that I failed to provide an isblank()
function to go with the macro.
Some googling shows that isblank() should return true only for a space
character or a tab. I could implement this easily in the function (and
remove the macro) by testing the characters directly, e.g.:

return (c == ' ' || c == '\t');

however, that doesn't go via the territory module like the other
ctype functions/macros do. On the other hand, the territory
module doesn't seem to distinguish this particular combination,
so I may have to cheat as above.
Does anyone know different or do I go with the cheat?

Thanks,
Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] GCC 4.7.4 Rel 4: isblank()

First of all, many thanks to everyone who's contributed to the latest
release.

There are a couple of issues with isblank():

1) In <ctype.h>, isblank() is incorrectly defined the same as isspace():
   #  define isspace(c) (__ctype[(int) (c)] & ___ctype_white)
   #  define isblank(c) (__ctype[(int) (c)] & ___ctype_white)

2) When there's a function pointer to isblank(), I get a link failure:
"undefined reference to `isblank'".

So this program:

#include <stdio.h>
#include <ctype.h>
int main(void) {
  int (*space)(int)=isspace;
  int (*blank)(int)=isblank;       // Fails to link.

  printf("%i\n",!!isspace('\n'));
  printf("%i\n",!!space('\n'));

  printf("%i\n",!!isblank('\n'));
  printf("%i\n",!!blank('\n'));    // Fails to link.

  return 0;
}

should give:

1
1
0
0

whereas, if the 2 lines with comments are removed, I get:

1
1
1

and it fails to link otherwise.

Regards
Duncan Moore

gcc (GCCSDK GCC 4.7.4 Release 4) 4.7.4
SharedUnixLibrary 1.16
VirtualRPC-AdjustSA RISCOS 4.39


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: possible bug: libnsgif does not handle DISPOSE_PREVIOUS correctly

Hi John,

On 06/07/2020 23:31, jcupitt@gmail.com wrote:

> First, line 438 modifies the input buffer:
>
> http://source.netsurf-browser.org/libnsgif.git/tree/src/libnsgif.c?id=8442a27c2bb8df48029ceea6e64c4930106a57fc#n438
>
> This feels a bit ugly to me, and it doesn't work for us, since the
> input buffer can be a mmaped file. I patched this to just return
> GIF_INSUFFICIENT_FRAME_DATA.

That sounds like a good idea. If we run into problems with partial
gifs we can find another way to display what we have that doesn't
involve modifying the input buffer.

> Second, gif_decode_frame(gif, frame_number) seems like the wrong API.
> You can only call this function with frame_number ascending, and you
> must always start from 0 and loop, but this restriction is not obvious
> from the function.

There are a few reasons for this behaviour.

At the moment in NetSurf, if a web page is showing an animated gif, we
schedule a callback with our scheduler to happen when the gif frame
delay has elapsed. When the callback fires, we simply increment the
number of the frame that should be shown inside NetSurf and cause the
gif to notify its users that its area is "dirty" and needs to be redrawn.

When that bit of the screen is redrawn, the gif redraw code decodes
enough frames to get back to where it should be in the animation and
shows that frame.

An advantage of this is that if there's a gif off-screen further down
the page, or on a tab that's not the current tab, we don't have to waste
time decoding frames that aren't getting rendered.

Another point is that the same gif may be used on many open tabs, and
even many times on the same page. NetSurf shares contents, so all these
instances share the same libnsgif instance for the animation.

This keeps all instances of the animation in lock step, which is
visually pleasing as well as efficient.

Finally, the libnsgif code was originally stripped out of NetSurf into a
separate library, and it still contains some some of this legacy in its API.

> How about having frame_number as a member, and renaming it to
> gif_decode_next_frame(gif)? It could handle looping too.
>
> gif_decode_frame() could be marked as deprecated, and just call
> gif_decode_next_frame() without using the frame_number parameter. It
> should be compatible and the API would be simpler and clearer. I may
> well have misunderstood things, of course
NetSurf could be made to work with your proposed change, and I agree
it's a cleaner API.

I probably wouldn't even keep the old `gif_decode_frame()` as
deprecated. Just change it. I think its API needs quite a bit of
cleaning up before we call it 1.0 and stop making breaking changes.

Cheers,

--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org