There seems to be a problem with the Atari test build 1930
When opening any page a dialogue box pops-up saying "CSSBase"
and the page is not rendered.
Peter
Saturday, 31 May 2014
Re: reworked web search
On Fri, May 30, 2014 at 16:53:45 +0100, Vincent Sanders wrote:
> > How about not kicking off the fetch for the real image until the default icon
> > fetch completes? It'll introduce a tiny delay but it also probably simplifies
> > the logic.
>
> Actually, its not that simple. the fetch for the default is started as
> part of the serchweb init. The selection of default provider is not
> done untill the frontend sets the provider from the configured
> value. Both gtk and amiga do this when creating the initial browser
> context.
>
> In theory this creation/fetch is way later than the initialisation but
> it seems the cache is now completing http fetches (when cache hits)
> faster than a resource:default.ico fetch started sometime before can
> complete!
Aah well, it was worth a try :-)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> > How about not kicking off the fetch for the real image until the default icon
> > fetch completes? It'll introduce a tiny delay but it also probably simplifies
> > the logic.
>
> Actually, its not that simple. the fetch for the default is started as
> part of the serchweb init. The selection of default provider is not
> done untill the frontend sets the provider from the configured
> value. Both gtk and amiga do this when creating the initial browser
> context.
>
> In theory this creation/fetch is way later than the initialisation but
> it seems the cache is now completing http fetches (when cache hits)
> faster than a resource:default.ico fetch started sometime before can
> complete!
Aah well, it was worth a try :-)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Friday, 30 May 2014
Re: Amiga nsfont_split
On 19 May 2014 18:39:27 +0100, Chris Young wrote:
> On 19 May 2014 18:35:41 +0100, Chris Young wrote:
>
> > I've scoured through and can't see anything.
>
> Although... I think I may have fixed it. Just filtered out control
> chars from the kerning, even though there shouldn't have been any
> present.
Gah, I really thought that (and initialising some variables to 0) had
fixed it. But it's back:
(44.423848) amiga/font.c nsfont_split 345: Split 129 chars at 550px: Split at char 100 (528px) - With the problem last week, all I did with mine was force it to power off by holding the button, and
(44.424815) amiga/font.c nsfont_split 365: Split 28 chars at 550px: Split at char 28 (153px) - then switch it back on again
(46.156834) amiga/font.c nsfont_split 345: Split 128 chars at 550px: Split at char 100 (528px) - With the problem last week, all I did with mine was force it to power off by holding the button, and
(46.157831) amiga/font.c nsfont_split 365: Split 27 chars at 550px: Split at char 27 (146px) - then switch it back on agai
(47.460726) amiga/font.c nsfont_split 345: Split 129 chars at 550px: Split at char 105 (549px) - With the problem last week, all I did with mine was force it to power off by holding the button, and then
(47.461570) amiga/font.c nsfont_split 365: Split 23 chars at 550px: Split at char 23 (128px) - switch it back on agaim
(52.598375) amiga/font.c nsfont_split 345: Split 128 chars at 550px: Split at char 100 (528px) - With the problem last week, all I did with mine was force it to power off by holding the button, and
(52.599300) amiga/font.c nsfont_split 365: Split 27 chars at 550px: Split at char 27 (146px) - then switch it back on agai
I probably need to check what values I'm getting from
ami_font_width_glyph to confirm if it is that.
Chris
> On 19 May 2014 18:35:41 +0100, Chris Young wrote:
>
> > I've scoured through and can't see anything.
>
> Although... I think I may have fixed it. Just filtered out control
> chars from the kerning, even though there shouldn't have been any
> present.
Gah, I really thought that (and initialising some variables to 0) had
fixed it. But it's back:
(44.423848) amiga/font.c nsfont_split 345: Split 129 chars at 550px: Split at char 100 (528px) - With the problem last week, all I did with mine was force it to power off by holding the button, and
(44.424815) amiga/font.c nsfont_split 365: Split 28 chars at 550px: Split at char 28 (153px) - then switch it back on again
(46.156834) amiga/font.c nsfont_split 345: Split 128 chars at 550px: Split at char 100 (528px) - With the problem last week, all I did with mine was force it to power off by holding the button, and
(46.157831) amiga/font.c nsfont_split 365: Split 27 chars at 550px: Split at char 27 (146px) - then switch it back on agai
(47.460726) amiga/font.c nsfont_split 345: Split 129 chars at 550px: Split at char 105 (549px) - With the problem last week, all I did with mine was force it to power off by holding the button, and then
(47.461570) amiga/font.c nsfont_split 365: Split 23 chars at 550px: Split at char 23 (128px) - switch it back on agaim
(52.598375) amiga/font.c nsfont_split 345: Split 128 chars at 550px: Split at char 100 (528px) - With the problem last week, all I did with mine was force it to power off by holding the button, and
(52.599300) amiga/font.c nsfont_split 365: Split 27 chars at 550px: Split at char 27 (146px) - then switch it back on agai
I probably need to check what values I'm getting from
ami_font_width_glyph to confirm if it is that.
Chris
Re: reworked web search
On Fri, May 30, 2014 at 04:21:02PM +0100, Daniel Silverstone wrote:
> On Fri, May 30, 2014 at 15:59:50 +0100, Vincent Sanders wrote:
> > I am currently trying to figure how to stop the default icon fetch
> > overriding the correct provider image.
>
> How about not kicking off the fetch for the real image until the default icon
> fetch completes? It'll introduce a tiny delay but it also probably simplifies
> the logic.
Actually, its not that simple. the fetch for the default is started as
part of the serchweb init. The selection of default provider is not
done untill the frontend sets the provider from the configured
value. Both gtk and amiga do this when creating the initial browser
context.
In theory this creation/fetch is way later than the initialisation but
it seems the cache is now completing http fetches (when cache hits)
faster than a resource:default.ico fetch started sometime before can
complete!
>
> D.
>
> --
> Daniel Silverstone http://www.netsurf-browser.org/
> PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On Fri, May 30, 2014 at 15:59:50 +0100, Vincent Sanders wrote:
> > I am currently trying to figure how to stop the default icon fetch
> > overriding the correct provider image.
>
> How about not kicking off the fetch for the real image until the default icon
> fetch completes? It'll introduce a tiny delay but it also probably simplifies
> the logic.
Actually, its not that simple. the fetch for the default is started as
part of the serchweb init. The selection of default provider is not
done untill the frontend sets the provider from the configured
value. Both gtk and amiga do this when creating the initial browser
context.
In theory this creation/fetch is way later than the initialisation but
it seems the cache is now completing http fetches (when cache hits)
faster than a resource:default.ico fetch started sometime before can
complete!
>
> D.
>
> --
> Daniel Silverstone http://www.netsurf-browser.org/
> PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: reworked web search
On Fri, May 30, 2014 at 15:59:50 +0100, Vincent Sanders wrote:
> I am currently trying to figure how to stop the default icon fetch
> overriding the correct provider image.
How about not kicking off the fetch for the real image until the default icon
fetch completes? It'll introduce a tiny delay but it also probably simplifies
the logic.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> I am currently trying to figure how to stop the default icon fetch
> overriding the correct provider image.
How about not kicking off the fetch for the real image until the default icon
fetch completes? It'll introduce a tiny delay but it also probably simplifies
the logic.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: reworked web search
On Tue, May 27, 2014 at 06:38:10PM +0100, Chris Young wrote:
> On Tue, 27 May 2014 11:06:20 +0100, Vincent Sanders wrote:
>
> > May I ask if (aside from the dumb mistakes) the feature is working as
> > expected now? It ought to have removed any delays if the network was
> > unable to fetch the search providers icons and made the whole thing
> > more robust.
>
> It seems fine, other than not picking up the icon on some occasions.
> Actually, I had a thought about that - is it fetching, and not
> notifying the frontend when the new icon is ready?
OK done some debugging on gtk and it is always notifying. However I
have discovered something very aggrivating:
- At initialisation it is setting the provider name with null bitmap.
- The cache then quickly supplies the provider icon and that fecth
completes, the callback is called with the provider name and bitmap.
- The default icon fetch then completes and it sets the provider
bitmap back to the default.
I am currently trying to figure how to stop the default icon fetch
overriding the correct provider image.
--
Regards Vincent
http://www.kyllikki.org/
> On Tue, 27 May 2014 11:06:20 +0100, Vincent Sanders wrote:
>
> > May I ask if (aside from the dumb mistakes) the feature is working as
> > expected now? It ought to have removed any delays if the network was
> > unable to fetch the search providers icons and made the whole thing
> > more robust.
>
> It seems fine, other than not picking up the icon on some occasions.
> Actually, I had a thought about that - is it fetching, and not
> notifying the frontend when the new icon is ready?
OK done some debugging on gtk and it is always notifying. However I
have discovered something very aggrivating:
- At initialisation it is setting the provider name with null bitmap.
- The cache then quickly supplies the provider icon and that fecth
completes, the callback is called with the provider name and bitmap.
- The default icon fetch then completes and it sets the provider
bitmap back to the default.
I am currently trying to figure how to stop the default icon fetch
overriding the correct provider image.
--
Regards Vincent
http://www.kyllikki.org/
[gccsdk] [Bug 253] GCC 4.7.4 Rel 1 Dev 2014-05-20: _kernel_osbget() failure
http://www.riscos.info/bugzilla3/show_bug.cgi?id=253
--- Comment #2 from Duncan Moore <duncan.moore@gmx.com> 2014-05-30 07:20:23 PDT ---
(In reply to comment #1)
> If you leave out the system calls and make sure there is already an upfront
> 'input_file' file, I can not reproduce your problem. Can you confirm this ?
No, I get the same problem with an upfront 'input_file'. I only used the system
calls to simplify the test case (i.e. everything is in the C source).
> The issue I see is that "system("Echo ABCDE { > input_file }");" simply leaves
> the input_file open (there is an outstanding RISC OS file handle) preventing
> you from reopening that file (using FileCore FS) or actually reading something
> from that file (used RISC OS 6 for this).
I don't get this issue with RISC OS 4.39. The system call does not leave
'input_file' open. Afterall, when I compile with -mlibscl, the test case gives
the expected output (see my original post).
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
--- Comment #2 from Duncan Moore <duncan.moore@gmx.com> 2014-05-30 07:20:23 PDT ---
(In reply to comment #1)
> If you leave out the system calls and make sure there is already an upfront
> 'input_file' file, I can not reproduce your problem. Can you confirm this ?
No, I get the same problem with an upfront 'input_file'. I only used the system
calls to simplify the test case (i.e. everything is in the C source).
> The issue I see is that "system("Echo ABCDE { > input_file }");" simply leaves
> the input_file open (there is an outstanding RISC OS file handle) preventing
> you from reopening that file (using FileCore FS) or actually reading something
> from that file (used RISC OS 6 for this).
I don't get this issue with RISC OS 4.39. The system call does not leave
'input_file' open. Afterall, when I compile with -mlibscl, the test case gives
the expected output (see my original post).
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
Thursday, 29 May 2014
[gccsdk] [Bug 253] GCC 4.7.4 Rel 1 Dev 2014-05-20: _kernel_osbget() failure
http://www.riscos.info/bugzilla3/show_bug.cgi?id=253
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2014-05-29 06:32:09 PDT ---
I solved the elf2aif a.out problem with r6711.
If you leave out the system calls and make sure there is already an upfront
'input_file' file, I can not reproduce your problem. Can you confirm this ?
The issue I see is that "system("Echo ABCDE { > input_file }");" simply leaves
the input_file open (there is an outstanding RISC OS file handle) preventing
you from reopening that file (using FileCore FS) or actually reading something
from that file (used RISC OS 6 for this).
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2014-05-29 06:32:09 PDT ---
I solved the elf2aif a.out problem with r6711.
If you leave out the system calls and make sure there is already an upfront
'input_file' file, I can not reproduce your problem. Can you confirm this ?
The issue I see is that "system("Echo ABCDE { > input_file }");" simply leaves
the input_file open (there is an outstanding RISC OS file handle) preventing
you from reopening that file (using FileCore FS) or actually reading something
from that file (used RISC OS 6 for this).
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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] [Bug 252] GCC 4.7.4 Rel 1 Dev 2014-05-20: __arm predefine
http://www.riscos.info/bugzilla3/show_bug.cgi?id=252
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2014-05-29 05:30:38 PDT ---
Fixed documentation with r6710.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2014-05-29 05:30:38 PDT ---
Fixed documentation with r6710.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
Wednesday, 28 May 2014
Re: IDNA2008 - take 2
On Wed, 28 May 2014 09:39:45 +0100, Daniel Silverstone wrote:
> > I have a huge backlog of reviews to do and this is one of them. If someone
> > gets to it before me then awesomesauce, otherwise I'm likely to get to it next
> > week when I'm on vacation.
No prob, just checking it hadn't been forgotten.
> I should add, it'd be helpful if you cleanly rebased your work on top of
> current master, to make the review easier. (And verified it still works,
> natch.)
Will do.
Thanks
Chris
> > I have a huge backlog of reviews to do and this is one of them. If someone
> > gets to it before me then awesomesauce, otherwise I'm likely to get to it next
> > week when I'm on vacation.
No prob, just checking it hadn't been forgotten.
> I should add, it'd be helpful if you cleanly rebased your work on top of
> current master, to make the review easier. (And verified it still works,
> natch.)
Will do.
Thanks
Chris
[gccsdk] [Bug 253] New: GCC 4.7.4 Rel 1 Dev 2014-05-20: _kernel_osbget() failure
http://www.riscos.info/bugzilla3/show_bug.cgi?id=253
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-20: _kernel_osbget()
failure
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140520 (prerelease)
[gcc-4_7-branch revision 210657]
http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
#include <stdio.h>
#include <stdlib.h>
#include "kernel.h"
#include "swis.h"
_kernel_oserror *swi_error;
_kernel_swi_regs regs;
int main(void) {
system("Echo ABCDE { > input_file }");
int handle=_kernel_osfind(0x40,"input_file"); // Open file for reading.
if (handle==_kernel_ERROR) {printf("Error opening file - aborting\n");return
1;}
printf("handle = %i\n",handle);
int ch=_kernel_osbget(handle); // Read byte from file.
if (ch==_kernel_ERROR) {
printf("Error reading file\n");
} else {
printf("character read = %c\n",ch);
}
regs.r[0] = 0;
regs.r[1] = handle;
swi_error = _kernel_swi(OS_Find, ®s, ®s); // Close file.
if (swi_error) {
printf("OS Error closing file: %s\n",swi_error->errmess);
} else {
printf("File closed\n");
}
system("Delete input_file");
return 0;
}
I've never used kernel.h much, apart from _kernel_swi(), but presumably the
above code should work? This is what I get:
*gcc err_osbget.c
*a/out
handle = 253
Error reading file
File closed
With the SharedCLibrary, it runs properly (but the default filename trips
elf2aif up):
*gcc -mlibscl err_osbget.c
Failed to open file 'a.out' for reading
collect2: error: elf2aif returned 1 exit status
*a/out
handle = 253
character read = A
File closed
*
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-20: _kernel_osbget()
failure
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140520 (prerelease)
[gcc-4_7-branch revision 210657]
http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
#include <stdio.h>
#include <stdlib.h>
#include "kernel.h"
#include "swis.h"
_kernel_oserror *swi_error;
_kernel_swi_regs regs;
int main(void) {
system("Echo ABCDE { > input_file }");
int handle=_kernel_osfind(0x40,"input_file"); // Open file for reading.
if (handle==_kernel_ERROR) {printf("Error opening file - aborting\n");return
1;}
printf("handle = %i\n",handle);
int ch=_kernel_osbget(handle); // Read byte from file.
if (ch==_kernel_ERROR) {
printf("Error reading file\n");
} else {
printf("character read = %c\n",ch);
}
regs.r[0] = 0;
regs.r[1] = handle;
swi_error = _kernel_swi(OS_Find, ®s, ®s); // Close file.
if (swi_error) {
printf("OS Error closing file: %s\n",swi_error->errmess);
} else {
printf("File closed\n");
}
system("Delete input_file");
return 0;
}
I've never used kernel.h much, apart from _kernel_swi(), but presumably the
above code should work? This is what I get:
*gcc err_osbget.c
*a/out
handle = 253
Error reading file
File closed
With the SharedCLibrary, it runs properly (but the default filename trips
elf2aif up):
*gcc -mlibscl err_osbget.c
Failed to open file 'a.out' for reading
collect2: error: elf2aif returned 1 exit status
*a/out
handle = 253
character read = A
File closed
*
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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] [Bug 252] New: GCC 4.7.4 Rel 1 Dev 2014-05-20: __arm predefine
http://www.riscos.info/bugzilla3/show_bug.cgi?id=252
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-20: __arm predefine
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140520 (prerelease)
[gcc-4_7-branch revision 210657]
http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
#include <stdio.h>
int main(void) {
#if defined(__arm)
printf("__arm is defined\n");
#else
printf("__arm is not defined\n");
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-20: __arm predefine
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140520 (prerelease)
[gcc-4_7-branch revision 210657]
http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
#include <stdio.h>
int main(void) {
#if defined(__arm)
printf("__arm is defined\n");
#else
printf("__arm is not defined\n");
Re: [gccsdk] Tutris crashes when compiled with GCC4.7
Lee Noar wrote on Saturday, May 24, 2014 1:57 PM:
> On 23/05/14 15:03, Alan Buckley wrote:
> > Several games I have recompiled with GCC4.7 crash when I try to run them
> > with:
> > UnixLib detected recursion of signal SIGSEGV. Exiting.
> > Tutris is a good example to look at as it is a relatively small game.
> > It can be built from the autobuilder (name tutris).
> > It seems to be crashing before running any code, so I haven't been
> > able to use my usual printf debugging.
> > Can some one have a look at it? Or if not give me some
> > ideas how I go about debugging it?
> This should be fixed with r6701.
Thanks Lee. I can confirm this is fixed.
Regards,
Alan
_______________________________________________
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
> On 23/05/14 15:03, Alan Buckley wrote:
> > Several games I have recompiled with GCC4.7 crash when I try to run them
> > with:
> > UnixLib detected recursion of signal SIGSEGV. Exiting.
> > Tutris is a good example to look at as it is a relatively small game.
> > It can be built from the autobuilder (name tutris).
> > It seems to be crashing before running any code, so I haven't been
> > able to use my usual printf debugging.
> > Can some one have a look at it? Or if not give me some
> > ideas how I go about debugging it?
> This should be fixed with r6701.
Thanks Lee. I can confirm this is fixed.
Regards,
Alan
_______________________________________________
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: IDNA2008 - take 2
On Wed, May 28, 2014 at 09:38:23 +0100, Daniel Silverstone wrote:
> On Tue, May 27, 2014 at 18:49:14 +0100, Chris Young wrote:
> > Is there any interest in reviewing/merging this now 3.1 is out of the
> > way?
>
> I have a huge backlog of reviews to do and this is one of them. If someone
> gets to it before me then awesomesauce, otherwise I'm likely to get to it next
> week when I'm on vacation.
I should add, it'd be helpful if you cleanly rebased your work on top of
current master, to make the review easier. (And verified it still works,
natch.)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> On Tue, May 27, 2014 at 18:49:14 +0100, Chris Young wrote:
> > Is there any interest in reviewing/merging this now 3.1 is out of the
> > way?
>
> I have a huge backlog of reviews to do and this is one of them. If someone
> gets to it before me then awesomesauce, otherwise I'm likely to get to it next
> week when I'm on vacation.
I should add, it'd be helpful if you cleanly rebased your work on top of
current master, to make the review easier. (And verified it still works,
natch.)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: IDNA2008 - take 2
On Tue, May 27, 2014 at 18:49:14 +0100, Chris Young wrote:
> Is there any interest in reviewing/merging this now 3.1 is out of the
> way?
I have a huge backlog of reviews to do and this is one of them. If someone
gets to it before me then awesomesauce, otherwise I'm likely to get to it next
week when I'm on vacation.
> I'm thinking point 2 above might also tie in with Vince's
> proposed changes to extract escaped path elements from an nsurl, as it
> is a similar challenge.
Vince?
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> Is there any interest in reviewing/merging this now 3.1 is out of the
> way?
I have a huge backlog of reviews to do and this is one of them. If someone
gets to it before me then awesomesauce, otherwise I'm likely to get to it next
week when I'm on vacation.
> I'm thinking point 2 above might also tie in with Vince's
> proposed changes to extract escaped path elements from an nsurl, as it
> is a similar challenge.
Vince?
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Tuesday, 27 May 2014
Re: IDNA2008 - take 2
On 27 Mar 2014 20:54:57 +0100, Chris Young wrote:
> OK, second attempt at international domain name support.
>
> Branch: chris/idna2008
>
> I've had to import some unrestricted code from elsewhere, due to the
> necessity of Unicode normalisation and other things. It is working
> and conforming to the spec, as far as I read it.
>
> A couple of minor issues/todos:
> 1. If an invalid URL is encountered during page layout/box conversion,
> NetSurf gives a BoxConvert warning and the page is never displayed.
> This is caused by my new code making nsurl_create return
> NSERROR_BAD_URL when an IDN fails the compliance checks.
> I've not been able to work out where in the core this error code is
> terminating page layout.
> Page showing this problem:
> http://blogs.msdn.com/b/shawnste/archive/2006/09/14/idn-test-urls.aspx
>
> 2. If a frontend wants to display the UTF-8 version of an IDN then
> currently the URL needs stripping into component parts, the host run
> through idna_decode() and the whole thing put back together again.
> This should probably be handled by nsurl but I'm not sure of the best
> way to implement it.
>
> 3. There are some to-dos noted in code comments for further compliance
> checking. They are optional in the spec, and I don't see any need to
> implement them - anything invalid will be rejected by DNS. Most of
> the mandatory checks seem overkill anyway, given that there is
> stricter checking at DNS registration time.
> I have included the optional decode-reencode check for already encoded
> addresses to weed out any undecodeable nonsense the user might have
> typed in, but it doesn't bother to do normalisation or validity
> checking of the decoded address before re-encoding it (maybe it
> should, I'm not sure, the spec was vague on this point).
Is there any interest in reviewing/merging this now 3.1 is out of the
way?
I'm thinking point 2 above might also tie in with Vince's
proposed changes to extract escaped path elements from an nsurl, as it
is a similar challenge.
Chris
> OK, second attempt at international domain name support.
>
> Branch: chris/idna2008
>
> I've had to import some unrestricted code from elsewhere, due to the
> necessity of Unicode normalisation and other things. It is working
> and conforming to the spec, as far as I read it.
>
> A couple of minor issues/todos:
> 1. If an invalid URL is encountered during page layout/box conversion,
> NetSurf gives a BoxConvert warning and the page is never displayed.
> This is caused by my new code making nsurl_create return
> NSERROR_BAD_URL when an IDN fails the compliance checks.
> I've not been able to work out where in the core this error code is
> terminating page layout.
> Page showing this problem:
> http://blogs.msdn.com/b/shawnste/archive/2006/09/14/idn-test-urls.aspx
>
> 2. If a frontend wants to display the UTF-8 version of an IDN then
> currently the URL needs stripping into component parts, the host run
> through idna_decode() and the whole thing put back together again.
> This should probably be handled by nsurl but I'm not sure of the best
> way to implement it.
>
> 3. There are some to-dos noted in code comments for further compliance
> checking. They are optional in the spec, and I don't see any need to
> implement them - anything invalid will be rejected by DNS. Most of
> the mandatory checks seem overkill anyway, given that there is
> stricter checking at DNS registration time.
> I have included the optional decode-reencode check for already encoded
> addresses to weed out any undecodeable nonsense the user might have
> typed in, but it doesn't bother to do normalisation or validity
> checking of the decoded address before re-encoding it (maybe it
> should, I'm not sure, the spec was vague on this point).
Is there any interest in reviewing/merging this now 3.1 is out of the
way?
I'm thinking point 2 above might also tie in with Vince's
proposed changes to extract escaped path elements from an nsurl, as it
is a similar challenge.
Chris
Re: url and path conversion
On Tue, 27 May 2014 11:28:52 +0100, Vincent Sanders wrote:
> I have converted all uses of conversion to these functions but please,
> please can frontend maintainers check my work. As ChrisY demonstarted
> recently, even if the core change is correct and tested on one
> platform it can mess up elsewhere.
Working fine here in my limited testing.
> It is my hope that frontend maintainers are happy with this move, if
> not can they explain their objections clearly and propose an
> alternative solution.
My opinion is that all URLs should be nsurls, and the less converting
between those and plain strings the better.
Chris
> I have converted all uses of conversion to these functions but please,
> please can frontend maintainers check my work. As ChrisY demonstarted
> recently, even if the core change is correct and tested on one
> platform it can mess up elsewhere.
Working fine here in my limited testing.
> It is my hope that frontend maintainers are happy with this move, if
> not can they explain their objections clearly and propose an
> alternative solution.
My opinion is that all URLs should be nsurls, and the less converting
between those and plain strings the better.
Chris
Re: reworked web search
On Tue, 27 May 2014 11:06:20 +0100, Vincent Sanders wrote:
> May I ask if (aside from the dumb mistakes) the feature is working as
> expected now? It ought to have removed any delays if the network was
> unable to fetch the search providers icons and made the whole thing
> more robust.
It seems fine, other than not picking up the icon on some occasions.
Actually, I had a thought about that - is it fetching, and not
notifying the frontend when the new icon is ready?
> I do not know if you are aware of the search_url_bar boolean option
> which is supposed to control search behaviour on input to the
> search_web_omni() operation.
Yes, I was aware of that. I think I decided against it due to the
inclusion of a separate search bar.
> The heuristics for deciding if a search term is a url are still a
> little inadequate but I am working on them. This should eventually
> allow us to have a url bar which mostly does the right thing and
> perhaps a simple additional button for "search for this term, do not
> try to interpret as a url"
That sounds like a good minimalist NetSurfy approach.
Chris
> May I ask if (aside from the dumb mistakes) the feature is working as
> expected now? It ought to have removed any delays if the network was
> unable to fetch the search providers icons and made the whole thing
> more robust.
It seems fine, other than not picking up the icon on some occasions.
Actually, I had a thought about that - is it fetching, and not
notifying the frontend when the new icon is ready?
> I do not know if you are aware of the search_url_bar boolean option
> which is supposed to control search behaviour on input to the
> search_web_omni() operation.
Yes, I was aware of that. I think I decided against it due to the
inclusion of a separate search bar.
> The heuristics for deciding if a search term is a url are still a
> little inadequate but I am working on them. This should eventually
> allow us to have a url bar which mostly does the right thing and
> perhaps a simple additional button for "search for this term, do not
> try to interpret as a url"
That sounds like a good minimalist NetSurfy approach.
Chris
url and path conversion
I have recently reworked the browsers url to path conversions to come
from teh file operations table and to use nsurl instead of strings for
urls. From this I have eliminated a great deal of duplicated,
problematic, conversion code.
There are two generic helpers available by including utils/file.h
nserror netsurf_nsurl_to_path(struct nsurl *url, char **path_out);
nserror netsurf_path_to_nsurl(const char *path, struct nsurl **url);
I have converted all uses of conversion to these functions but please,
please can frontend maintainers check my work. As ChrisY demonstarted
recently, even if the core change is correct and tested on one
platform it can mess up elsewhere.
This rework now means that almost all the netsurf internal API now
uses our nsurl url functions (missing is launch_url() set_url() and
save_url() which I intend to fix soon)
For many file related url handling this has greatly reduced the number
of string to url to string conversions and made our scheme handling
much more robust.
It is my hope that frontend maintainers are happy with this move, if
not can they explain their objections clearly and propose an
alternative solution.
I also intend to extend the nsurl component API slightly to allow
retrieval of escaped path elements, my eventual thought here is to be
able to remove the old string based URL API (see utils/url.h)
--
Regards Vincent
http://www.kyllikki.org/
from teh file operations table and to use nsurl instead of strings for
urls. From this I have eliminated a great deal of duplicated,
problematic, conversion code.
There are two generic helpers available by including utils/file.h
nserror netsurf_nsurl_to_path(struct nsurl *url, char **path_out);
nserror netsurf_path_to_nsurl(const char *path, struct nsurl **url);
I have converted all uses of conversion to these functions but please,
please can frontend maintainers check my work. As ChrisY demonstarted
recently, even if the core change is correct and tested on one
platform it can mess up elsewhere.
This rework now means that almost all the netsurf internal API now
uses our nsurl url functions (missing is launch_url() set_url() and
save_url() which I intend to fix soon)
For many file related url handling this has greatly reduced the number
of string to url to string conversions and made our scheme handling
much more robust.
It is my hope that frontend maintainers are happy with this move, if
not can they explain their objections clearly and propose an
alternative solution.
I also intend to extend the nsurl component API slightly to allow
retrieval of escaped path elements, my eventual thought here is to be
able to remove the old string based URL API (see utils/url.h)
--
Regards Vincent
http://www.kyllikki.org/
Re: reworked web search
On Sun, May 25, 2014 at 10:34:59AM +0100, Steve Fryatt wrote:
> On 25 May, Vincent Sanders wrote in message
> <20140525001056.GY27671@kyllikki.org>:
>
> > I have completely reworked the web search functionality in the core of the
> > browser. The new API is much simpler and robust. Currently only two
> > frontends (GTK and Amiga) use the functionality but I hope now that it is
> > so much simpler to use other maintainers might implement it for their
> > frontends.
>
> Is this the search field in the toolbar? For some reason I'd got the idea
> from discussions on here or IRC that it had been deprecated, which is why I
> never bothered to implement it on RISC OS. The main reason for re-writing
> the toolbar code was to make it easier to add stuff like this (and tabs, of
> course).
>
> I'll have another look, time permitting.
This was more a combination of utterly awful code and API previously
coupled with the idea we could simply make the url bar input much
smarter about search without having a separate search input consuming
space in the toolbar.
I just explained in the reply to Chris how that might work. If i can
work out a clean way to do this I will be extending the GTK UI to make
the search input box toggle appearance alongside the search_url_bar
option.
Thus you would be able to type urls and search terms into the single
url bar and simply have it do the right thing (a bit like chrome or
firefox)
--
Regards Vincent
http://www.kyllikki.org/
> On 25 May, Vincent Sanders wrote in message
> <20140525001056.GY27671@kyllikki.org>:
>
> > I have completely reworked the web search functionality in the core of the
> > browser. The new API is much simpler and robust. Currently only two
> > frontends (GTK and Amiga) use the functionality but I hope now that it is
> > so much simpler to use other maintainers might implement it for their
> > frontends.
>
> Is this the search field in the toolbar? For some reason I'd got the idea
> from discussions on here or IRC that it had been deprecated, which is why I
> never bothered to implement it on RISC OS. The main reason for re-writing
> the toolbar code was to make it easier to add stuff like this (and tabs, of
> course).
>
> I'll have another look, time permitting.
This was more a combination of utterly awful code and API previously
coupled with the idea we could simply make the url bar input much
smarter about search without having a separate search input consuming
space in the toolbar.
I just explained in the reply to Chris how that might work. If i can
work out a clean way to do this I will be extending the GTK UI to make
the search input box toggle appearance alongside the search_url_bar
option.
Thus you would be able to type urls and search terms into the single
url bar and simply have it do the right thing (a bit like chrome or
firefox)
--
Regards Vincent
http://www.kyllikki.org/
Re: reworked web search
On Sun, May 25, 2014 at 03:12:01PM +0100, Chris Young wrote:
> On Sun, 25 May 2014 11:32:42 +0100, Vincent Sanders wrote:
>
> > > The search is behaving oddly - I'm getting two (and always two)
> > > garbage characters on the end of my search string. So, if I search
> > > for netsurf on Google I get something like:
> > > http://www.google.com/search?q=netsurfO%FC
> >
> > hmm. that is strange (honest i did test this with the gtk frontend!)
> > is this soemthing to do with how the search term is extracted on
> > amiga? search_web_omni() is supposed to take the search term it is
> > given and substitute it into the search url.
>
> I've fixed it, the URL wasn't getting NULL-terminated. I guess on
> your test platform the memory allocation was zeroed, but here it
> wasn't.
>
Thankyou very much Chris!. Dumb error on my part, sorry about
that.
May I ask if (aside from the dumb mistakes) the feature is working as
expected now? It ought to have removed any delays if the network was
unable to fetch the search providers icons and made the whole thing
more robust.
I do not know if you are aware of the search_url_bar boolean option
which is supposed to control search behaviour on input to the
search_web_omni() operation.
The heuristics for deciding if a search term is a url are still a
little inadequate but I am working on them. This should eventually
allow us to have a url bar which mostly does the right thing and
perhaps a simple additional button for "search for this term, do not
try to interpret as a url"
--
Regards Vincent
http://www.kyllikki.org/
> On Sun, 25 May 2014 11:32:42 +0100, Vincent Sanders wrote:
>
> > > The search is behaving oddly - I'm getting two (and always two)
> > > garbage characters on the end of my search string. So, if I search
> > > for netsurf on Google I get something like:
> > > http://www.google.com/search?q=netsurfO%FC
> >
> > hmm. that is strange (honest i did test this with the gtk frontend!)
> > is this soemthing to do with how the search term is extracted on
> > amiga? search_web_omni() is supposed to take the search term it is
> > given and substitute it into the search url.
>
> I've fixed it, the URL wasn't getting NULL-terminated. I guess on
> your test platform the memory allocation was zeroed, but here it
> wasn't.
>
Thankyou very much Chris!. Dumb error on my part, sorry about
that.
May I ask if (aside from the dumb mistakes) the feature is working as
expected now? It ought to have removed any delays if the network was
unable to fetch the search providers icons and made the whole thing
more robust.
I do not know if you are aware of the search_url_bar boolean option
which is supposed to control search behaviour on input to the
search_web_omni() operation.
The heuristics for deciding if a search term is a url are still a
little inadequate but I am working on them. This should eventually
allow us to have a url bar which mostly does the right thing and
perhaps a simple additional button for "search for this term, do not
try to interpret as a url"
--
Regards Vincent
http://www.kyllikki.org/
Monday, 26 May 2014
I want to contribute in development
Hi
I'm Raza ul Haq and I'm studet of computer science at The Islamia University Bahawalpur, Pakistan. I was thinking to make web browser foe my final year project. But then my professor told me that actually web browser is not actually an application which can be developed by one person in a short time, so you just find an open source browser and develop it's any portion for project. I searched about open source browsers I got netsurf, I've joined it's community and now I want to work with you people. So please tell me how can I contribute for you(related to programming), please be detailed as you can I'll be helpfull for me.
Thanks
Regards
Raza ul Haq
Re: HTTP 2.0
On 28 Mar 2014 20:09:55 +0100, Chris Young wrote:
> I've just put a small patch in branch chris/http2 to enable libcurl to
> use HTTP 2.0 if it is the latest version.
>
> libcurl also needs building against nghttp2 for this to do anything
> (there is an equivalent patch in the toolchains chris/http2 branch)
>
> As it is still in draft I've put an option in to enable it, rather
> than it being enabled by default. Certainly Google's server - if not
> connecting over https - returns an error. Over https it works fine
> (and appears to have negotiated http2 to some extent), so I think it's
> probably just not up-to-date with the latest spec.
I've worked around this by only enabling HTTP2 support over https (as
it still fails with draft-12). This is all other web browsers
do anyway, we can revisit it if Google ever fix their server software.
If you turn on curl debug you can see it negotiating HTTP/2 in the
log. (good test server: https://nghttp2.org)
Chris
> I've just put a small patch in branch chris/http2 to enable libcurl to
> use HTTP 2.0 if it is the latest version.
>
> libcurl also needs building against nghttp2 for this to do anything
> (there is an equivalent patch in the toolchains chris/http2 branch)
>
> As it is still in draft I've put an option in to enable it, rather
> than it being enabled by default. Certainly Google's server - if not
> connecting over https - returns an error. Over https it works fine
> (and appears to have negotiated http2 to some extent), so I think it's
> probably just not up-to-date with the latest spec.
I've worked around this by only enabling HTTP2 support over https (as
it still fails with draft-12). This is all other web browsers
do anyway, we can revisit it if Google ever fix their server software.
If you turn on curl debug you can see it negotiating HTTP/2 in the
log. (good test server: https://nghttp2.org)
Chris
Sunday, 25 May 2014
Re: reworked web search
On Sun, 25 May 2014 11:32:42 +0100, Vincent Sanders wrote:
> > The search is behaving oddly - I'm getting two (and always two)
> > garbage characters on the end of my search string. So, if I search
> > for netsurf on Google I get something like:
> > http://www.google.com/search?q=netsurfO%FC
>
> hmm. that is strange (honest i did test this with the gtk frontend!)
> is this soemthing to do with how the search term is extracted on
> amiga? search_web_omni() is supposed to take the search term it is
> given and substitute it into the search url.
I've fixed it, the URL wasn't getting NULL-terminated. I guess on
your test platform the memory allocation was zeroed, but here it
wasn't.
Chris
> > The search is behaving oddly - I'm getting two (and always two)
> > garbage characters on the end of my search string. So, if I search
> > for netsurf on Google I get something like:
> > http://www.google.com/search?q=netsurfO%FC
>
> hmm. that is strange (honest i did test this with the gtk frontend!)
> is this soemthing to do with how the search term is extracted on
> amiga? search_web_omni() is supposed to take the search term it is
> given and substitute it into the search url.
I've fixed it, the URL wasn't getting NULL-terminated. I guess on
your test platform the memory allocation was zeroed, but here it
wasn't.
Chris
Re: reworked web search
On Sun, May 25, 2014 at 10:44:54AM +0100, Chris Young wrote:
> On Sun, 25 May 2014 10:11:39 +0100, Vincent Sanders wrote:
>
> > On Sun, May 25, 2014 at 09:59:30AM +0100, Chris Young wrote:
> > > On Sun, 25 May 2014 01:10:56 +0100, Vincent Sanders wrote:
> > >
> > > > I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> > > > made an error in amiga)
> > >
> > > I have no icon and attempting to search results in an "InitFailed"
> > > error message. Any ideas?
> >
> > This will stem from the search_web_init() not suceeding or being
> > called at all. It should be called once in the initialisation process
> > preferably after the fetchers have been initialised (after
> > netsurf_init). However I thought i did this already for amiga.
>
> Fixed, thanks.
>
> The search is behaving oddly - I'm getting two (and always two)
> garbage characters on the end of my search string. So, if I search
> for netsurf on Google I get something like:
> http://www.google.com/search?q=netsurfO%FC
hmm. that is strange (honest i did test this with the gtk frontend!)
is this soemthing to do with how the search term is extracted on
amiga? search_web_omni() is supposed to take the search term it is
given and substitute it into the search url.
It may be worth adding logging of the pass term and the search url in
search_web_omni() to check where the problem lies.
It is possible that the code that parses the loaded search providers
file (in desktop/searchweb.c) is not parsing the search provider urls
correctly, although it is doing simple strchr calls using | as a field
separator which ought to be more robust than the previous code.
>
> > There may be an issue with retrieving the default icon (now done
> > through a standard resource:default.ico fetch) I thought the init
> > should cope with not having access to the icon but I may be mistaken.
>
> Don't know, but I've mapped it across now. It seems to be using the
> default icon at startup some of the time, so there's some odd timing
> issue there.
The way this is supposed to operate now is that on initialisation the
resource:default.ico is fetched. Whenever a new provider is selected
with a call to search_web_select_provider() the provider_update
callback is called.
If the providers icon has not already been fetched a fetch is started
and the default bitmap is passed to the callback, once the provider
icon fetch successfully completes the callback is again called to
update with the new bitmap.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On Sun, 25 May 2014 10:11:39 +0100, Vincent Sanders wrote:
>
> > On Sun, May 25, 2014 at 09:59:30AM +0100, Chris Young wrote:
> > > On Sun, 25 May 2014 01:10:56 +0100, Vincent Sanders wrote:
> > >
> > > > I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> > > > made an error in amiga)
> > >
> > > I have no icon and attempting to search results in an "InitFailed"
> > > error message. Any ideas?
> >
> > This will stem from the search_web_init() not suceeding or being
> > called at all. It should be called once in the initialisation process
> > preferably after the fetchers have been initialised (after
> > netsurf_init). However I thought i did this already for amiga.
>
> Fixed, thanks.
>
> The search is behaving oddly - I'm getting two (and always two)
> garbage characters on the end of my search string. So, if I search
> for netsurf on Google I get something like:
> http://www.google.com/search?q=netsurfO%FC
hmm. that is strange (honest i did test this with the gtk frontend!)
is this soemthing to do with how the search term is extracted on
amiga? search_web_omni() is supposed to take the search term it is
given and substitute it into the search url.
It may be worth adding logging of the pass term and the search url in
search_web_omni() to check where the problem lies.
It is possible that the code that parses the loaded search providers
file (in desktop/searchweb.c) is not parsing the search provider urls
correctly, although it is doing simple strchr calls using | as a field
separator which ought to be more robust than the previous code.
>
> > There may be an issue with retrieving the default icon (now done
> > through a standard resource:default.ico fetch) I thought the init
> > should cope with not having access to the icon but I may be mistaken.
>
> Don't know, but I've mapped it across now. It seems to be using the
> default icon at startup some of the time, so there's some odd timing
> issue there.
The way this is supposed to operate now is that on initialisation the
resource:default.ico is fetched. Whenever a new provider is selected
with a call to search_web_select_provider() the provider_update
callback is called.
If the providers icon has not already been fetched a fetch is started
and the default bitmap is passed to the callback, once the provider
icon fetch successfully completes the callback is again called to
update with the new bitmap.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: Core browser functionality
On 9 May, Vincent Sanders wrote in message
<20140509104415.GF27671@kyllikki.org>:
> I want to get input on this from everyone, especailly from Chris and Steve
> who have put up with my breaking their frontends with my refactors and
> with whom I do not get to communicate with a great deal on these things.
Like Chris, I've no real objections as long as it doesn't break anything! It
might make completely building the code more complex (as Chris notes), but
should also make working on changes completely within a front-end easier to
handle as well.
It sounds as if it should help differentiate between the core and front-end
functionality, which might even make the code more understandable long-term.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<20140509104415.GF27671@kyllikki.org>:
> I want to get input on this from everyone, especailly from Chris and Steve
> who have put up with my breaking their frontends with my refactors and
> with whom I do not get to communicate with a great deal on these things.
Like Chris, I've no real objections as long as it doesn't break anything! It
might make completely building the code more complex (as Chris notes), but
should also make working on changes completely within a front-end easier to
handle as well.
It sounds as if it should help differentiate between the core and front-end
functionality, which might even make the code more understandable long-term.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: reworked web search
On Sun, 25 May 2014 10:11:39 +0100, Vincent Sanders wrote:
> On Sun, May 25, 2014 at 09:59:30AM +0100, Chris Young wrote:
> > On Sun, 25 May 2014 01:10:56 +0100, Vincent Sanders wrote:
> >
> > > I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> > > made an error in amiga)
> >
> > I have no icon and attempting to search results in an "InitFailed"
> > error message. Any ideas?
>
> This will stem from the search_web_init() not suceeding or being
> called at all. It should be called once in the initialisation process
> preferably after the fetchers have been initialised (after
> netsurf_init). However I thought i did this already for amiga.
Fixed, thanks.
The search is behaving oddly - I'm getting two (and always two)
garbage characters on the end of my search string. So, if I search
for netsurf on Google I get something like:
http://www.google.com/search?q=netsurfO%FC
> There may be an issue with retrieving the default icon (now done
> through a standard resource:default.ico fetch) I thought the init
> should cope with not having access to the icon but I may be mistaken.
Don't know, but I've mapped it across now. It seems to be using the
default icon at startup some of the time, so there's some odd timing
issue there.
Chris
> On Sun, May 25, 2014 at 09:59:30AM +0100, Chris Young wrote:
> > On Sun, 25 May 2014 01:10:56 +0100, Vincent Sanders wrote:
> >
> > > I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> > > made an error in amiga)
> >
> > I have no icon and attempting to search results in an "InitFailed"
> > error message. Any ideas?
>
> This will stem from the search_web_init() not suceeding or being
> called at all. It should be called once in the initialisation process
> preferably after the fetchers have been initialised (after
> netsurf_init). However I thought i did this already for amiga.
Fixed, thanks.
The search is behaving oddly - I'm getting two (and always two)
garbage characters on the end of my search string. So, if I search
for netsurf on Google I get something like:
http://www.google.com/search?q=netsurfO%FC
> There may be an issue with retrieving the default icon (now done
> through a standard resource:default.ico fetch) I thought the init
> should cope with not having access to the icon but I may be mistaken.
Don't know, but I've mapped it across now. It seems to be using the
default icon at startup some of the time, so there's some odd timing
issue there.
Chris
Re: reworked web search
On 25 May, Vincent Sanders wrote in message
<20140525001056.GY27671@kyllikki.org>:
> I have completely reworked the web search functionality in the core of the
> browser. The new API is much simpler and robust. Currently only two
> frontends (GTK and Amiga) use the functionality but I hope now that it is
> so much simpler to use other maintainers might implement it for their
> frontends.
Is this the search field in the toolbar? For some reason I'd got the idea
from discussions on here or IRC that it had been deprecated, which is why I
never bothered to implement it on RISC OS. The main reason for re-writing
the toolbar code was to make it easier to add stuff like this (and tabs, of
course).
I'll have another look, time permitting.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<20140525001056.GY27671@kyllikki.org>:
> I have completely reworked the web search functionality in the core of the
> browser. The new API is much simpler and robust. Currently only two
> frontends (GTK and Amiga) use the functionality but I hope now that it is
> so much simpler to use other maintainers might implement it for their
> frontends.
Is this the search field in the toolbar? For some reason I'd got the idea
from discussions on here or IRC that it had been deprecated, which is why I
never bothered to implement it on RISC OS. The main reason for re-writing
the toolbar code was to make it easier to add stuff like this (and tabs, of
course).
I'll have another look, time permitting.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: reworked web search
On Sun, May 25, 2014 at 09:59:30AM +0100, Chris Young wrote:
> On Sun, 25 May 2014 01:10:56 +0100, Vincent Sanders wrote:
>
> > I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> > made an error in amiga)
>
> I have no icon and attempting to search results in an "InitFailed"
> error message. Any ideas?
This will stem from the search_web_init() not suceeding or being
called at all. It should be called once in the initialisation process
preferably after the fetchers have been initialised (after
netsurf_init). However I thought i did this already for amiga.
There may be an issue with retrieving the default icon (now done
through a standard resource:default.ico fetch) I thought the init
should cope with not having access to the icon but I may be mistaken.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On Sun, 25 May 2014 01:10:56 +0100, Vincent Sanders wrote:
>
> > I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> > made an error in amiga)
>
> I have no icon and attempting to search results in an "InitFailed"
> error message. Any ideas?
This will stem from the search_web_init() not suceeding or being
called at all. It should be called once in the initialisation process
preferably after the fetchers have been initialised (after
netsurf_init). However I thought i did this already for amiga.
There may be an issue with retrieving the default icon (now done
through a standard resource:default.ico fetch) I thought the init
should cope with not having access to the icon but I may be mistaken.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: reworked web search
On Sun, 25 May 2014 01:10:56 +0100, Vincent Sanders wrote:
> I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> made an error in amiga)
I have no icon and attempting to search results in an "InitFailed"
error message. Any ideas?
Chris
> I have fixed up both GTK and Amiga usage (apologies to chrisy if I
> made an error in amiga)
I have no icon and attempting to search results in an "InitFailed"
error message. Any ideas?
Chris
Saturday, 24 May 2014
reworked web search
I have completely reworked the web search functionality in the core of
the browser. The new API is much simpler and robust. Currently only
two frontends (GTK and Amiga) use the functionality but I hope now
that it is so much simpler to use other maintainers might implement it
for their frontends.
I have fixed up both GTK and Amiga usage (apologies to chrisy if I
made an error in amiga) and the GTK frontend "search from the url bar"
functionality now actually works (set in preferences)
--
Regards Vincent
http://www.kyllikki.org/
the browser. The new API is much simpler and robust. Currently only
two frontends (GTK and Amiga) use the functionality but I hope now
that it is so much simpler to use other maintainers might implement it
for their frontends.
I have fixed up both GTK and Amiga usage (apologies to chrisy if I
made an error in amiga) and the GTK frontend "search from the url bar"
functionality now actually works (set in preferences)
--
Regards Vincent
http://www.kyllikki.org/
Re: [gccsdk] Unable to build native RISC OS compiler
In message <DUB120-DS9949D5F1440D8845D111AF03D0@phx.gbl>
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> John Tytgat wrote on Monday, May 19, 2014 8:27 PM:
>
> > Was this a full clean build (either freshly checked out, either after a
> > make clean or make distclean) ? Did you do the build for the
> > cross-compiler
> > with the same set of sources ?
>
> No, I had run svn update on it a few times.
It depends on when the last time your previous update was but asasm and
its sub projects (like elftoolchain) got quite some code reshuffling.
> > Otherwise, I would remove all generated autotools file in the riscos/asasm
> > directory with a:
>
> > for i in riscos/asasm riscos/asasm/decaof/ riscos/asasm/elftoolchain/ ; do
> > svn status --no-ignore $$i | grep "^I " | cut -b 9- | xargs rm -rf ;
> > done
> > and restart the build.
>
> This didn't work. But a make clean followed by make ronative did.
Ok, that's the fix which should always work but is of course the most
costly timewise as it really restarts from scratch.
> It there any way to just rebuild the parts that have changed after an svn
> update?
> It took all morning to rebuild the ronative compilers and I'd like to try
> to keep up to date with the trunk build for the cross-compiler at least
> without it taking so long.
The gccsdk build system (basically the top Makefile) is designed to
avoid doing costly rechecking whether a sub-build step need to be redone
as soon as that sub-build step got finished successfully before. As
soon as one sub-build step is successful, a file gets written in
the buildstepsdir so a next 'make' will skip that step even if you did
get new sources for that step after a 'svn update'. This is (was) just
to avoid lengthy build times when developing and/or fixing a broken build.
If you want to force to redo that buildstep (and automatically also all
other depending buildsteps), just remove its corresponding file in
buildstepsdir.
As a guideline, if you do svn update (and/or 'make updategcc') and
see updates for:
- UnixLib or gcc related patches: remove {cross,ronative}-gcc-built
(one is for the cross-compiler, the other for the native RISC OS
compilter).
- binutils related patches: remove {cross,ronative}-binutils-built
- riscos/*: remove {cross,ronative}-riscostools-built or
execute 'riscos/build-it' to rebuild any which hasn't been built yet
or 'riscos/build-it -f' to force rebuilding all riscos/* tools.
If you want to update the gcc sources in order to get the latest gcc 4.7.x
fixes, do 'make updategcc' followed by the normal 'make'.
Hope this helps a bit.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> John Tytgat wrote on Monday, May 19, 2014 8:27 PM:
>
> > Was this a full clean build (either freshly checked out, either after a
> > make clean or make distclean) ? Did you do the build for the
> > cross-compiler
> > with the same set of sources ?
>
> No, I had run svn update on it a few times.
It depends on when the last time your previous update was but asasm and
its sub projects (like elftoolchain) got quite some code reshuffling.
> > Otherwise, I would remove all generated autotools file in the riscos/asasm
> > directory with a:
>
> > for i in riscos/asasm riscos/asasm/decaof/ riscos/asasm/elftoolchain/ ; do
> > svn status --no-ignore $$i | grep "^I " | cut -b 9- | xargs rm -rf ;
> > done
> > and restart the build.
>
> This didn't work. But a make clean followed by make ronative did.
Ok, that's the fix which should always work but is of course the most
costly timewise as it really restarts from scratch.
> It there any way to just rebuild the parts that have changed after an svn
> update?
> It took all morning to rebuild the ronative compilers and I'd like to try
> to keep up to date with the trunk build for the cross-compiler at least
> without it taking so long.
The gccsdk build system (basically the top Makefile) is designed to
avoid doing costly rechecking whether a sub-build step need to be redone
as soon as that sub-build step got finished successfully before. As
soon as one sub-build step is successful, a file gets written in
the buildstepsdir so a next 'make' will skip that step even if you did
get new sources for that step after a 'svn update'. This is (was) just
to avoid lengthy build times when developing and/or fixing a broken build.
If you want to force to redo that buildstep (and automatically also all
other depending buildsteps), just remove its corresponding file in
buildstepsdir.
As a guideline, if you do svn update (and/or 'make updategcc') and
see updates for:
- UnixLib or gcc related patches: remove {cross,ronative}-gcc-built
(one is for the cross-compiler, the other for the native RISC OS
compilter).
- binutils related patches: remove {cross,ronative}-binutils-built
- riscos/*: remove {cross,ronative}-riscostools-built or
execute 'riscos/build-it' to rebuild any which hasn't been built yet
or 'riscos/build-it -f' to force rebuilding all riscos/* tools.
If you want to update the gcc sources in order to get the latest gcc 4.7.x
fixes, do 'make updategcc' followed by the normal 'make'.
Hope this helps a bit.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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] Tutris crashes when compiled with GCC4.7
In message <53809756.30201@sky.com>
Lee Noar <leenoar@sky.com> wrote:
> On 23/05/14 15:03, Alan Buckley wrote:
> > Several games I have recompiled with GCC4.7 crash when I try to run them
> > with:
> > UnixLib detected recursion of signal SIGSEGV. Exiting.
> > Tutris is a good example to look at as it is a relatively small game.
> > It can be built from the autobuilder (name tutris).
> > It seems to be crashing before running any code, so I haven't been
> > able to use my usual printf debugging.
> > Can some one have a look at it? Or if not give me some
> > ideas how I go about debugging it?
>
> This should be fixed with r6701.
Nice.
I made a new RISC OS build containing this fix at:
<URL:http://www.riscos.info/downloads/gccsdk/testing/4.7.4/>
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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
Lee Noar <leenoar@sky.com> wrote:
> On 23/05/14 15:03, Alan Buckley wrote:
> > Several games I have recompiled with GCC4.7 crash when I try to run them
> > with:
> > UnixLib detected recursion of signal SIGSEGV. Exiting.
> > Tutris is a good example to look at as it is a relatively small game.
> > It can be built from the autobuilder (name tutris).
> > It seems to be crashing before running any code, so I haven't been
> > able to use my usual printf debugging.
> > Can some one have a look at it? Or if not give me some
> > ideas how I go about debugging it?
>
> This should be fixed with r6701.
Nice.
I made a new RISC OS build containing this fix at:
<URL:http://www.riscos.info/downloads/gccsdk/testing/4.7.4/>
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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] [Bug 251] GCC 4.7.4 Rel 1 Dev 2014-04-26: C++ -static segmentation fault
http://www.riscos.info/bugzilla3/show_bug.cgi?id=251
Lee <leenoar@sky.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |leenoar@sky.com
Resolution| |FIXED
--- Comment #1 from Lee <leenoar@sky.com> 2014-05-24 06:07:00 PDT ---
The problem was that libstdc++.a contained PIC code.
Fixed with r6701.
Removed -prefer-pic from configure.ac.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
Lee <leenoar@sky.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |leenoar@sky.com
Resolution| |FIXED
--- Comment #1 from Lee <leenoar@sky.com> 2014-05-24 06:07:00 PDT ---
The problem was that libstdc++.a contained PIC code.
Fixed with r6701.
Removed -prefer-pic from configure.ac.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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] Tutris crashes when compiled with GCC4.7
On 23/05/14 15:03, Alan Buckley wrote:
> Several games I have recompiled with GCC4.7 crash when I try to run them
> with:
> UnixLib detected recursion of signal SIGSEGV. Exiting.
> Tutris is a good example to look at as it is a relatively small game.
> It can be built from the autobuilder (name tutris).
> It seems to be crashing before running any code, so I haven't been
> able to use my usual printf debugging.
> Can some one have a look at it? Or if not give me some
> ideas how I go about debugging it?
This should be fixed with r6701.
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
> Several games I have recompiled with GCC4.7 crash when I try to run them
> with:
> UnixLib detected recursion of signal SIGSEGV. Exiting.
> Tutris is a good example to look at as it is a relatively small game.
> It can be built from the autobuilder (name tutris).
> It seems to be crashing before running any code, so I haven't been
> able to use my usual printf debugging.
> Can some one have a look at it? Or if not give me some
> ideas how I go about debugging it?
This should be fixed with r6701.
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
Friday, 23 May 2014
Re: [gccsdk] Recommended autobuilder/packages/etc distros
In article <73358a0c54.beeb@ron1954.woosh.co.nz>,
Ron <beeb@woosh.co.nz> wrote:
> So I'm guessing that unstable would continue to trickle into testing,
> after the required wait in unstable of 10 days. So there wouldn't be any
> more changes to 'testing' on the changeover day than on any other day.
No, that's not how it works. On November 5th, Testing goes into 'Freeze'
mode, i.e. from that moment on, nothing migrates from Unstable until
Jessie becomes Stable (see link for exceptions). When that happens, the
entire backlog moves into Testing. That will be several months worth.
Regards,
Frank
https://release.debian.org/jessie/freeze_policy.html
_______________________________________________
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
Ron <beeb@woosh.co.nz> wrote:
> So I'm guessing that unstable would continue to trickle into testing,
> after the required wait in unstable of 10 days. So there wouldn't be any
> more changes to 'testing' on the changeover day than on any other day.
No, that's not how it works. On November 5th, Testing goes into 'Freeze'
mode, i.e. from that moment on, nothing migrates from Unstable until
Jessie becomes Stable (see link for exceptions). When that happens, the
entire backlog moves into Testing. That will be several months worth.
Regards,
Frank
https://release.debian.org/jessie/freeze_policy.html
_______________________________________________
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] Recommended autobuilder/packages/etc distros
In message <b821830c54.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> In message <540c7aec44chrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:
>
> > The problem with standardising on 'stable' is what happens when the
> > current 'testing' becomes 'stable'. A whole load of packages will
> > then need updating. It's easier to keep them up to date gradually
> > instead of all in one hit.
> >
>
> That would be true if 'testing' was left empty at change over, but wont
> it be replaced from newer versions from the old 'unstable'?
>
Answering my own question,
I've had a look at a FAQ, and to quote:
"Changes might not be apparent at first but will be evident as soon as
new packages from unstable go over to the testing distribution."
So I'm guessing that unstable would continue to trickle into testing,
after the required wait in unstable of 10 days. So there wouldn't be any
more changes to 'testing' on the changeover day than on any other day.
_______________________________________________
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
Ron <beeb@woosh.co.nz> wrote:
> In message <540c7aec44chrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:
>
> > The problem with standardising on 'stable' is what happens when the
> > current 'testing' becomes 'stable'. A whole load of packages will
> > then need updating. It's easier to keep them up to date gradually
> > instead of all in one hit.
> >
>
> That would be true if 'testing' was left empty at change over, but wont
> it be replaced from newer versions from the old 'unstable'?
>
Answering my own question,
I've had a look at a FAQ, and to quote:
"Changes might not be apparent at first but will be evident as soon as
new packages from unstable go over to the testing distribution."
So I'm guessing that unstable would continue to trickle into testing,
after the required wait in unstable of 10 days. So there wouldn't be any
more changes to 'testing' on the changeover day than on any other day.
_______________________________________________
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] Recommended autobuilder/packages/etc distros
In message <540c7aec44chrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:
> The problem with standardising on 'stable' is what happens when the curent
> 'testing' becomes 'stable'. A whole load of packages will then need
> updating. It's easier to keep them up to date gradually instead of all in
> one hit.
>
That would be true if 'testing' was left empty at change over, but wont
it be replaced from newer versions from the old 'unstable'?
_______________________________________________
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
Chris Gransden <chrisg@care4free.net> wrote:
> The problem with standardising on 'stable' is what happens when the curent
> 'testing' becomes 'stable'. A whole load of packages will then need
> updating. It's easier to keep them up to date gradually instead of all in
> one hit.
>
That would be true if 'testing' was left empty at change over, but wont
it be replaced from newer versions from the old 'unstable'?
_______________________________________________
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] Recommended autobuilder/packages/etc distros
> Given that 'testing' is a moving target, is it better to stabilise on
> something? Has recent package updating work (Alan, Lee, Chris?) been using
> the default sources (ie 'testing')?
Most of the libraries build ok with 'testing'. Any that don't normally only
need minor changes.
chox11 is quite a bit behind the current X libraries so I've been updating
them to build older version that are compatible with chox11.
> There was a suggestion some time ago of standardising on Ubuntu (since it
> has LTS releases), but again I prefer to take the least hassle option - so
> if packages are optimised for Debian sources it would seem to make sense to
> use that. Standardising on Debian stable/wheezy is another option (since
> many of the packages were probably last updated when 'wheezy' /was/ testing
> - or before).
The problem with standardising on 'stable' is what happens when the curent
'testing' becomes 'stable'. A whole load of packages will then need
updating. It's easier to keep them up to date gradually instead of all in
one hit.
_______________________________________________
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
> something? Has recent package updating work (Alan, Lee, Chris?) been using
> the default sources (ie 'testing')?
Most of the libraries build ok with 'testing'. Any that don't normally only
need minor changes.
chox11 is quite a bit behind the current X libraries so I've been updating
them to build older version that are compatible with chox11.
> There was a suggestion some time ago of standardising on Ubuntu (since it
> has LTS releases), but again I prefer to take the least hassle option - so
> if packages are optimised for Debian sources it would seem to make sense to
> use that. Standardising on Debian stable/wheezy is another option (since
> many of the packages were probably last updated when 'wheezy' /was/ testing
> - or before).
The problem with standardising on 'stable' is what happens when the curent
'testing' becomes 'stable'. A whole load of packages will then need
updating. It's easier to keep them up to date gradually instead of all in
one hit.
_______________________________________________
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] Tutris crashes when compiled with GCC4.7
On 23/05/14 15:03, Alan Buckley wrote:
> Several games I have recompiled with GCC4.7 crash when I try to run them
> with:
> UnixLib detected recursion of signal SIGSEGV. Exiting.
> Tutris is a good example to look at as it is a relatively small game.
> It can be built from the autobuilder (name tutris).
> It seems to be crashing before running any code, so I haven't been
> able to use my usual printf debugging.
> Can some one have a look at it? Or if not give me some
> ideas how I go about debugging it?
Some PIC code is finding its way into the static binary. This is also
the cause of bug#251. The function crashing is called:
_GLOBAL_sub_I_eh_globals.cc
which is one of a group of functions whose name starts "_GLOBAL_sub_I"
and they all contain PIC code.
I'm not sure if these functions are compiler generated or come from
the static standard libraries, if the latter, it could indicate a build
problem in libstdc++.
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
> Several games I have recompiled with GCC4.7 crash when I try to run them
> with:
> UnixLib detected recursion of signal SIGSEGV. Exiting.
> Tutris is a good example to look at as it is a relatively small game.
> It can be built from the autobuilder (name tutris).
> It seems to be crashing before running any code, so I haven't been
> able to use my usual printf debugging.
> Can some one have a look at it? Or if not give me some
> ideas how I go about debugging it?
Some PIC code is finding its way into the static binary. This is also
the cause of bug#251. The function crashing is called:
_GLOBAL_sub_I_eh_globals.cc
which is one of a group of functions whose name starts "_GLOBAL_sub_I"
and they all contain PIC code.
I'm not sure if these functions are compiler generated or come from
the static standard libraries, if the latter, it could indicate a build
problem in libstdc++.
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] Tutris crashes when compiled with GCC4.7
Several games I have recompiled with GCC4.7 crash when I try to run them with:
UnixLib detected recursion of signal SIGSEGV. Exiting.
Tutris is a good example to look at as it is a relatively small game.
It can be built from the autobuilder (name tutris).
It seems to be crashing before running any code, so I haven't been
able to use my usual printf debugging.
Can some one have a look at it? Or if not give me some
ideas how I go about debugging it?
Regards,
Alan
Wednesday, 21 May 2014
Re: [Rpcemu] Stuck on installing RPCemu/Mint 16
Further to my earlier reply, I downloaded the sourcefiles you reference
below (http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241 date
2014-02-04) and recompiled, and the error is exactly as I reported.
Sean.
On 18/05/14 21:20, Peter Howkins wrote:
> On Tue, May 13, 2014 at 08:59:57AM +0100, Seán Kelly wrote:
>> Hi,
>>
>> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>>
>> After a few false starts I got Allegro in place and all seemed to be
>> going well (following
>> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
>
>
> Hi Sean, can you tell me which version of rpcemu you're trying to compile
> and where you got it from?
>
> In theory the issue you're reporting was fixed a few years ago, so it
> might be out of date source. [1]
>
> Peter
>
> [1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
>
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
below (http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241 date
2014-02-04) and recompiled, and the error is exactly as I reported.
Sean.
On 18/05/14 21:20, Peter Howkins wrote:
> On Tue, May 13, 2014 at 08:59:57AM +0100, Seán Kelly wrote:
>> Hi,
>>
>> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>>
>> After a few false starts I got Allegro in place and all seemed to be
>> going well (following
>> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
>
>
> Hi Sean, can you tell me which version of rpcemu you're trying to compile
> and where you got it from?
>
> In theory the issue you're reporting was fixed a few years ago, so it
> might be out of date source. [1]
>
> Peter
>
> [1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
>
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [gccsdk] Recommended autobuilder/packages/etc distros
> Theo Markettos wrote on Tuesday, May 20, 2014 11:56 PM:
> On Tue, May 20, 2014 at 09:23:22PM +0100, John Tytgat wrote:
[snip]
> I'm of the opinion that VMs are cheap, so trying to make a setup that will
> have the least hassle, with whatever OS necessary. Your plan sounds like
> a
> good idea. In the meantime, if I pick Debian wheezy and install all the
> auto{conf,make}x.xx packages, will the autobuilder handle using the right
> ones?
I've recently set up a Debian VM and it worked nicely, so I'm confident I
would be able to set up a recommended system if it came to that.
> In message <537BAB40.6080304@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> If I'm reading the
>> fetch-program script correctly, it looks in testing (jessie) first and if
>> it
>> doesn't find the package there, falls back tostable (wheezy).
> Given that 'testing' is a moving target, is it better to stabilise on
> something? Has recent package updating work (Alan, Lee, Chris?) been
> using
>the default sources (ie 'testing')?
I just use whatever came out of the box. So it would be testing falling
back to stable.
I vaguely recall an explanation about why testing was being used,
rather than stable, I think it was something to do with a better
chance of keeping it up to date, can anyone recall the thread?
It used to use unstable, but that was abandoned because of
too many problems.
I not sure if it has any relevance here, but the main problem I'm
having with rebuilding the packages are because a lot of the ports
have moved on since they were last built so the patches no longer work
and there seem to be a few crashes when running some of them
that I will need to track down (not sure if they are GCC4.7 or the
updates yet). I've only managed to update less than 50% of them in
the last few months.
Regards,
Alan
_______________________________________________
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
> On Tue, May 20, 2014 at 09:23:22PM +0100, John Tytgat wrote:
[snip]
> I'm of the opinion that VMs are cheap, so trying to make a setup that will
> have the least hassle, with whatever OS necessary. Your plan sounds like
> a
> good idea. In the meantime, if I pick Debian wheezy and install all the
> auto{conf,make}x.xx packages, will the autobuilder handle using the right
> ones?
I've recently set up a Debian VM and it worked nicely, so I'm confident I
would be able to set up a recommended system if it came to that.
> In message <537BAB40.6080304@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> If I'm reading the
>> fetch-program script correctly, it looks in testing (jessie) first and if
>> it
>> doesn't find the package there, falls back tostable (wheezy).
> Given that 'testing' is a moving target, is it better to stabilise on
> something? Has recent package updating work (Alan, Lee, Chris?) been
> using
>the default sources (ie 'testing')?
I just use whatever came out of the box. So it would be testing falling
back to stable.
I vaguely recall an explanation about why testing was being used,
rather than stable, I think it was something to do with a better
chance of keeping it up to date, can anyone recall the thread?
It used to use unstable, but that was abandoned because of
too many problems.
I not sure if it has any relevance here, but the main problem I'm
having with rebuilding the packages are because a lot of the ports
have moved on since they were last built so the patches no longer work
and there seem to be a few crashes when running some of them
that I will need to track down (not sure if they are GCC4.7 or the
updates yet). I've only managed to update less than 50% of them in
the last few months.
Regards,
Alan
_______________________________________________
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] Fw: Recommended autobuilder/packages/etc distros
> John Tytgat wrote on Tuesday, May 20, 2014 9:23 PM:
> In message <537BAB40.6080304@sky.com>
Lee Noar <leenoar@sky.com> wrote:
> > On 20/05/14 11:20, Theo Markettos wrote:
> > > A few questions regarding the current situation of GCCSDK and the
> > > autobuilder packages, because I haven't been keeping up to date:
> > >
> > > 1. What's the recommended host distro for building GCC and autobuilder
> > > packages? Debian, Ubuntu? What version?
> >
> > I think anything debian based, I currently use Linux Mint 15, which is
> > derived from Ubuntu Raring, without any trouble.
> I'm using Mint 16. Anything debian based is a safe choice. I believe
> we had reported issues for Cygwin and I'm not sure if that's still used
> to build gccsdk by someone. Knowing that Cygwin is pretty slow, I doubt
> this is a viable option.
I use Cygwin still as it means I can build and test programs on a Windows
machine without having to start up an additional virtual machine.
Last week tried to build the gcc4.7 cross compiler on it and it got far
enough that it had built the main compilers, but the tools failed on
the build for asasm. I'd love it to just work out of the box, but appreciate
it's not a supported platform so don't bother reporting errors in it.
It also fails to build many of the packages in the autobuilder, but I do
have a Debian virtual machine which I can use to build them and
then copy the result to Windows.
[snip]
Regards,
Alan
P.S. Sorry John - I sent this just to you by accident first time.
_______________________________________________
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
> In message <537BAB40.6080304@sky.com>
Lee Noar <leenoar@sky.com> wrote:
> > On 20/05/14 11:20, Theo Markettos wrote:
> > > A few questions regarding the current situation of GCCSDK and the
> > > autobuilder packages, because I haven't been keeping up to date:
> > >
> > > 1. What's the recommended host distro for building GCC and autobuilder
> > > packages? Debian, Ubuntu? What version?
> >
> > I think anything debian based, I currently use Linux Mint 15, which is
> > derived from Ubuntu Raring, without any trouble.
> I'm using Mint 16. Anything debian based is a safe choice. I believe
> we had reported issues for Cygwin and I'm not sure if that's still used
> to build gccsdk by someone. Knowing that Cygwin is pretty slow, I doubt
> this is a viable option.
I use Cygwin still as it means I can build and test programs on a Windows
machine without having to start up an additional virtual machine.
Last week tried to build the gcc4.7 cross compiler on it and it got far
enough that it had built the main compilers, but the tools failed on
the build for asasm. I'd love it to just work out of the box, but appreciate
it's not a supported platform so don't bother reporting errors in it.
It also fails to build many of the packages in the autobuilder, but I do
have a Debian virtual machine which I can use to build them and
then copy the result to Windows.
[snip]
Regards,
Alan
P.S. Sorry John - I sent this just to you by accident first time.
_______________________________________________
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
Tuesday, 20 May 2014
Re: [gccsdk] Recommended autobuilder/packages/etc distros
In message <20140520225617.GK11010@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
>
> (It's a VM, so would rather not use a GUI distro that drags in GNOME et al
> and gets confused when starting X since there's no video card)
Peppermint OS four is a CD install sized stable (ubuntu raring) that has
only the basic apps installed and uses a lightweight xfce desktop.
I noticed that a plain Debian 7 (stable) distro also has an xfce option.
Peppermint at least doesn't require any special measures to be taken to
get a basic installation, and the hardware recognition seems to be as
good as Mint/Ubuntu
>
> In message <537BAB40.6080304@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
> >
> > If I'm reading the
> > fetch-program script correctly, it looks in testing (jessie) first and if it
> > doesn't find the package there, falls back tostable (wheezy).
>
I sent a reply to this to Lee by mistake, he may forward it for me, but
basically, why not just use stable, and overide this on a case by case
basis with AB_URL inside the Setvars file where necessary?
_______________________________________________
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
Theo Markettos <theo@markettos.org.uk> wrote:
>
> (It's a VM, so would rather not use a GUI distro that drags in GNOME et al
> and gets confused when starting X since there's no video card)
Peppermint OS four is a CD install sized stable (ubuntu raring) that has
only the basic apps installed and uses a lightweight xfce desktop.
I noticed that a plain Debian 7 (stable) distro also has an xfce option.
Peppermint at least doesn't require any special measures to be taken to
get a basic installation, and the hardware recognition seems to be as
good as Mint/Ubuntu
>
> In message <537BAB40.6080304@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
> >
> > If I'm reading the
> > fetch-program script correctly, it looks in testing (jessie) first and if it
> > doesn't find the package there, falls back tostable (wheezy).
>
I sent a reply to this to Lee by mistake, he may forward it for me, but
basically, why not just use stable, and overide this on a case by case
basis with AB_URL inside the Setvars file where necessary?
_______________________________________________
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] Recommended autobuilder/packages/etc distros
In message <537BAB40.6080304@sky.com>
Lee Noar <leenoar@sky.com> wrote:
>
> If I'm reading the fetch-program script correctly, it looks in testing
> (jessie) first and if it doesn't find the package there, falls back to
> stable (wheezy).
>
Linux distros by default only use one level of packages, I can recall
ruining a Debian install by installing newer packages.
I realise a lot of times, it will work.
I think it would be simpler if the autobuilder defaulted to stable
(wheezy until 2015) and if testing is required the overiding could be
done with AB_URL in any setvars filer.
At the moment, results from autobuilder can vary because if a download
is not successful it will go to the alternative branch, and one person
can get different errors to another, which makes bug reporting
complicated. Debian testing (jessie) wont be frozen until November,
and security updates are only guaranteed for the stable branch,
So it makes me wonder why we use testing by default?
I realise some packages just aren't available yet in stable but
couldn't they be dealt with case by case?
What worries me is if the combination of branches packages doesn't
throw an error when building/linking but then causes the end
binary to error.
If we are moving to newer GCC, would it not be worthwhile to have
everyone installing from the same branch for the purpose of
bug reporting?
I am a relative newby so feel free to correct me on this thing
that has always puzzled me.
_______________________________________________
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
Lee Noar <leenoar@sky.com> wrote:
>
> If I'm reading the fetch-program script correctly, it looks in testing
> (jessie) first and if it doesn't find the package there, falls back to
> stable (wheezy).
>
Linux distros by default only use one level of packages, I can recall
ruining a Debian install by installing newer packages.
I realise a lot of times, it will work.
I think it would be simpler if the autobuilder defaulted to stable
(wheezy until 2015) and if testing is required the overiding could be
done with AB_URL in any setvars filer.
At the moment, results from autobuilder can vary because if a download
is not successful it will go to the alternative branch, and one person
can get different errors to another, which makes bug reporting
complicated. Debian testing (jessie) wont be frozen until November,
and security updates are only guaranteed for the stable branch,
So it makes me wonder why we use testing by default?
I realise some packages just aren't available yet in stable but
couldn't they be dealt with case by case?
What worries me is if the combination of branches packages doesn't
throw an error when building/linking but then causes the end
binary to error.
If we are moving to newer GCC, would it not be worthwhile to have
everyone installing from the same branch for the purpose of
bug reporting?
I am a relative newby so feel free to correct me on this thing
that has always puzzled me.
_______________________________________________
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] Recommended autobuilder/packages/etc distros
On Tue, May 20, 2014 at 09:23:22PM +0100, John Tytgat wrote:
> For building gccsdk, we used to be sensitive to distro flavors because
> gcc/binutils really require exact autotool versions which were then taken
> from the host. That was unpredictable and sometimes required manually
> installing the right versions. Currently we're building the required
> autotools versions ourselves and that solved those gccsdk building issues.
>
> However, for the Autobuilder, some packages do autoreconf (or something
> similar to recreate the autotools files) and that still takes the autotools
> versions installed on the host which makes building with Autobuilder
> unpredictable. We could do the same thing as gccsdk, building the
> required autotool version needed for those packages.
I'm of the opinion that VMs are cheap, so trying to make a setup that will
have the least hassle, with whatever OS necessary. Your plan sounds like a
good idea. In the meantime, if I pick Debian wheezy and install all the
auto{conf,make}x.xx packages, will the autobuilder handle using the right
ones?
(It's a VM, so would rather not use a GUI distro that drags in GNOME et al
and gets confused when starting X since there's no video card)
In message <537BAB40.6080304@sky.com>
Lee Noar <leenoar@sky.com> wrote:
>
> If I'm reading the
> fetch-program script correctly, it looks in testing (jessie) first and if it
> doesn't find the package there, falls back tostable (wheezy).
Given that 'testing' is a moving target, is it better to stabilise on
something? Has recent package updating work (Alan, Lee, Chris?) been using
the default sources (ie 'testing')?
There was a suggestion some time ago of standardising on Ubuntu (since it
has LTS releases), but again I prefer to take the least hassle option - so
if packages are optimised for Debian sources it would seem to make sense to
use that. Standardising on Debian stable/wheezy is another option (since
many of the packages were probably last updated when 'wheezy' /was/ testing
- or before).
Theo
_______________________________________________
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
> For building gccsdk, we used to be sensitive to distro flavors because
> gcc/binutils really require exact autotool versions which were then taken
> from the host. That was unpredictable and sometimes required manually
> installing the right versions. Currently we're building the required
> autotools versions ourselves and that solved those gccsdk building issues.
>
> However, for the Autobuilder, some packages do autoreconf (or something
> similar to recreate the autotools files) and that still takes the autotools
> versions installed on the host which makes building with Autobuilder
> unpredictable. We could do the same thing as gccsdk, building the
> required autotool version needed for those packages.
I'm of the opinion that VMs are cheap, so trying to make a setup that will
have the least hassle, with whatever OS necessary. Your plan sounds like a
good idea. In the meantime, if I pick Debian wheezy and install all the
auto{conf,make}x.xx packages, will the autobuilder handle using the right
ones?
(It's a VM, so would rather not use a GUI distro that drags in GNOME et al
and gets confused when starting X since there's no video card)
In message <537BAB40.6080304@sky.com>
Lee Noar <leenoar@sky.com> wrote:
>
> If I'm reading the
> fetch-program script correctly, it looks in testing (jessie) first and if it
> doesn't find the package there, falls back tostable (wheezy).
Given that 'testing' is a moving target, is it better to stabilise on
something? Has recent package updating work (Alan, Lee, Chris?) been using
the default sources (ie 'testing')?
There was a suggestion some time ago of standardising on Ubuntu (since it
has LTS releases), but again I prefer to take the least hassle option - so
if packages are optimised for Debian sources it would seem to make sense to
use that. Standardising on Debian stable/wheezy is another option (since
many of the packages were probably last updated when 'wheezy' /was/ testing
- or before).
Theo
_______________________________________________
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] Recommended autobuilder/packages/etc distros
In message <537BAB40.6080304@sky.com>
Lee Noar <leenoar@sky.com> wrote:
> On 20/05/14 11:20, Theo Markettos wrote:
> > A few questions regarding the current situation of GCCSDK and the
> > autobuilder packages, because I haven't been keeping up to date:
> >
> > 1. What's the recommended host distro for building GCC and autobuilder
> > packages? Debian, Ubuntu? What version?
>
> I think anything debian based, I currently use Linux Mint 15, which is
> derived from Ubuntu Raring, without any trouble.
I'm using Mint 16. Anything debian based is a safe choice. I believe
we had reported issues for Cygwin and I'm not sure if that's still used
to build gccsdk by someone. Knowing that Cygwin is pretty slow, I doubt
this is a viable option.
For building gccsdk, we used to be sensitive to distro flavors because
gcc/binutils really require exact autotool versions which were then taken
from the host. That was unpredictable and sometimes required manually
installing the right versions. Currently we're building the required
autotools versions ourselves and that solved those gccsdk building issues.
However, for the Autobuilder, some packages do autoreconf (or something
similar to recreate the autotools files) and that still takes the autotools
versions installed on the host which makes building with Autobuilder
unpredictable. We could do the same thing as gccsdk, building the
required autotool version needed for those packages.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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
Lee Noar <leenoar@sky.com> wrote:
> On 20/05/14 11:20, Theo Markettos wrote:
> > A few questions regarding the current situation of GCCSDK and the
> > autobuilder packages, because I haven't been keeping up to date:
> >
> > 1. What's the recommended host distro for building GCC and autobuilder
> > packages? Debian, Ubuntu? What version?
>
> I think anything debian based, I currently use Linux Mint 15, which is
> derived from Ubuntu Raring, without any trouble.
I'm using Mint 16. Anything debian based is a safe choice. I believe
we had reported issues for Cygwin and I'm not sure if that's still used
to build gccsdk by someone. Knowing that Cygwin is pretty slow, I doubt
this is a viable option.
For building gccsdk, we used to be sensitive to distro flavors because
gcc/binutils really require exact autotool versions which were then taken
from the host. That was unpredictable and sometimes required manually
installing the right versions. Currently we're building the required
autotools versions ourselves and that solved those gccsdk building issues.
However, for the Autobuilder, some packages do autoreconf (or something
similar to recreate the autotools files) and that still takes the autotools
versions installed on the host which makes building with Autobuilder
unpredictable. We could do the same thing as gccsdk, building the
required autotool version needed for those packages.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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] Recommended autobuilder/packages/etc distros
On 20/05/14 11:20, Theo Markettos wrote:
> A few questions regarding the current situation of GCCSDK and the
> autobuilder packages, because I haven't been keeping up to date:
>
> 1. What's the recommended host distro for building GCC and autobuilder
> packages? Debian, Ubuntu? What version?
I think anything debian based, I currently use Linux Mint 15, which is
derived from Ubuntu Raring, without any trouble.
> 2. What's the recommended source feed for autobuilder packages? Debian,
> but is it squeeze, wheezy, testing, sid...?
If I'm reading the fetch-program script correctly, it looks in testing
(jessie) first and if it doesn't find the package there, falls back to
stable (wheezy).
> (IIRC the autobuilder will try and use the host distro, but it might be a
> good idea to decouple these)
I think it used to work like that, but it caused too many problems with
different distros having different versions of the same package. Its
patches would apply cleanly for one person but not for someone else.
So it was changed so that Debian was always the target and everyone
then saw the same package version.
> 3. What's the recommended GCC for building autobuilder packages? I'm
> assuming 4.1.2 as the stable compiler - but are there UnixLib patches in 4.7
> that some packages need?
Answered by Alan.
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
> A few questions regarding the current situation of GCCSDK and the
> autobuilder packages, because I haven't been keeping up to date:
>
> 1. What's the recommended host distro for building GCC and autobuilder
> packages? Debian, Ubuntu? What version?
I think anything debian based, I currently use Linux Mint 15, which is
derived from Ubuntu Raring, without any trouble.
> 2. What's the recommended source feed for autobuilder packages? Debian,
> but is it squeeze, wheezy, testing, sid...?
If I'm reading the fetch-program script correctly, it looks in testing
(jessie) first and if it doesn't find the package there, falls back to
stable (wheezy).
> (IIRC the autobuilder will try and use the host distro, but it might be a
> good idea to decouple these)
I think it used to work like that, but it caused too many problems with
different distros having different versions of the same package. Its
patches would apply cleanly for one person but not for someone else.
So it was changed so that Debian was always the target and everyone
then saw the same package version.
> 3. What's the recommended GCC for building autobuilder packages? I'm
> assuming 4.1.2 as the stable compiler - but are there UnixLib patches in 4.7
> that some packages need?
Answered by Alan.
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] Unable to build native RISC OS compiler
John Tytgat wrote on Monday, May 19, 2014 8:27 PM:
> In message <DUB120-DS925A6587EC8ED323D07C1F0320@phx.gbl>
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> > I’ve just tried to build the native RISC OS compiler on a Debian
> > system
> > and it failed with:
>
> > checking whether stripping libraries is possible... yes
> > checking if libtool supports shared libraries... no
> > checking whether to build shared libraries... no
> > checking whether to build static libraries... yes
> > /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928:
> > syntax
> > error near unexpected token `LIBARCHIVE,'
> > /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928:
> > ` PKG_
> > CHECK_MODULES(LIBARCHIVE, libarchive >= $REQ_LIBARCHIVE_VERSION)'
> > configure: error:
> > /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure fa
> > iled for elftoolchain
> > make[1]: *** [ronative-riscostools-built] Error 2
> > make[1]: Leaving directory `/home/alanb/gccsdk/gcc4'
> > make: *** [getenv] Error 2
> Was this a full clean build (either freshly checked out, either after a
> make clean or make distclean) ? Did you do the build for the
> cross-compiler
> with the same set of sources ?
No, I had run svn update on it a few times.
> Otherwise, I would remove all generated autotools file in the riscos/asasm
> directory with a:
> for i in riscos/asasm riscos/asasm/decaof/ riscos/asasm/elftoolchain/ ; do
> svn status --no-ignore $$i | grep "^I " | cut -b 9- | xargs rm -rf ;
> done
> and restart the build.
This didn't work. But a make clean followed by make ronative did.
It there any way to just rebuild the parts that have changed after an svn
update?
It took all morning to rebuild the ronative compilers and I'd like to try
to keep up to date with the trunk build for the cross-compiler at least
without it taking so long.
Thanks,
Alan
_______________________________________________
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] Recommended autobuilder/packages/etc distros
Theo Markettos wrote on Tuesday, May 20, 2014 11:20 AM:
> A few questions regarding the current situation of GCCSDK and the
> autobuilder packages, because I haven't been keeping up to date:
> 1. What's the recommended host distro for building GCC and autobuilder
> packages? Debian, Ubuntu? What version?
> 2. What's the recommended source feed for autobuilder packages? Debian,
> but is it squeeze, wheezy, testing, sid...?
> (IIRC the autobuilder will try and use the host distro, but it might be a
> good idea to decouple these)
I assume someone else will be able to answer these.
> 3. What's the recommended GCC for building autobuilder packages? I'm
> assuming 4.1.2 as the stable compiler - but are there UnixLib patches in
> 4.7
> that some packages need?
I haven't any authority here, but I'd would like to suggest the autobuilder
packages are moved on to use 4.7 from now on. I've already been doing
this after discussion on this group when rebuilding packages as I add
the new components field. I am also in the process of working through
starting to add shared library packages to the autobuilder and to
simplify things these will all need to be generated with 4.7.
As part of this I'm looking at the packaging of the native compiler
for 4.7. So it would be nice if we were able to do a release of that
as well when I'm finished (but other people would know it's current
state).
Regards,
Alan
_______________________________________________
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
> A few questions regarding the current situation of GCCSDK and the
> autobuilder packages, because I haven't been keeping up to date:
> 1. What's the recommended host distro for building GCC and autobuilder
> packages? Debian, Ubuntu? What version?
> 2. What's the recommended source feed for autobuilder packages? Debian,
> but is it squeeze, wheezy, testing, sid...?
> (IIRC the autobuilder will try and use the host distro, but it might be a
> good idea to decouple these)
I assume someone else will be able to answer these.
> 3. What's the recommended GCC for building autobuilder packages? I'm
> assuming 4.1.2 as the stable compiler - but are there UnixLib patches in
> 4.7
> that some packages need?
I haven't any authority here, but I'd would like to suggest the autobuilder
packages are moved on to use 4.7 from now on. I've already been doing
this after discussion on this group when rebuilding packages as I add
the new components field. I am also in the process of working through
starting to add shared library packages to the autobuilder and to
simplify things these will all need to be generated with 4.7.
As part of this I'm looking at the packaging of the native compiler
for 4.7. So it would be nice if we were able to do a release of that
as well when I'm finished (but other people would know it's current
state).
Regards,
Alan
_______________________________________________
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] Recommended autobuilder/packages/etc distros
A few questions regarding the current situation of GCCSDK and the
autobuilder packages, because I haven't been keeping up to date:
1. What's the recommended host distro for building GCC and autobuilder
packages? Debian, Ubuntu? What version?
2. What's the recommended source feed for autobuilder packages? Debian,
but is it squeeze, wheezy, testing, sid...?
(IIRC the autobuilder will try and use the host distro, but it might be a
good idea to decouple these)
3. What's the recommended GCC for building autobuilder packages? I'm
assuming 4.1.2 as the stable compiler - but are there UnixLib patches in 4.7
that some packages need?
Thanks
Theo
_______________________________________________
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
autobuilder packages, because I haven't been keeping up to date:
1. What's the recommended host distro for building GCC and autobuilder
packages? Debian, Ubuntu? What version?
2. What's the recommended source feed for autobuilder packages? Debian,
but is it squeeze, wheezy, testing, sid...?
(IIRC the autobuilder will try and use the host distro, but it might be a
good idea to decouple these)
3. What's the recommended GCC for building autobuilder packages? I'm
assuming 4.1.2 as the stable compiler - but are there UnixLib patches in 4.7
that some packages need?
Thanks
Theo
_______________________________________________
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
Monday, 19 May 2014
Re: [gccsdk] Unable to build native RISC OS compiler
In message <DUB120-DS925A6587EC8ED323D07C1F0320@phx.gbl>
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> I’ve just tried to build the native RISC OS compiler on a Debian system
> and it failed with:
>
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... no
> checking whether to build shared libraries... no
> checking whether to build static libraries... yes
> /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928: syntax
> error near unexpected token `LIBARCHIVE,'
> /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928: ` PKG_
> CHECK_MODULES(LIBARCHIVE, libarchive >= $REQ_LIBARCHIVE_VERSION)'
> configure: error: /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure fa
> iled for elftoolchain
> make[1]: *** [ronative-riscostools-built] Error 2
> make[1]: Leaving directory `/home/alanb/gccsdk/gcc4'
> make: *** [getenv] Error 2
Was this a full clean build (either freshly checked out, either after a
make clean or make distclean) ? Did you do the build for the cross-compiler
with the same set of sources ?
Otherwise, I would remove all generated autotools file in the riscos/asasm
directory with a:
for i in riscos/asasm riscos/asasm/decaof/ riscos/asasm/elftoolchain/ ; do svn status --no-ignore $$i | grep "^I " | cut -b 9- | xargs rm -rf ; done
and restart the build.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> I’ve just tried to build the native RISC OS compiler on a Debian system
> and it failed with:
>
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... no
> checking whether to build shared libraries... no
> checking whether to build static libraries... yes
> /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928: syntax
> error near unexpected token `LIBARCHIVE,'
> /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928: ` PKG_
> CHECK_MODULES(LIBARCHIVE, libarchive >= $REQ_LIBARCHIVE_VERSION)'
> configure: error: /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure fa
> iled for elftoolchain
> make[1]: *** [ronative-riscostools-built] Error 2
> make[1]: Leaving directory `/home/alanb/gccsdk/gcc4'
> make: *** [getenv] Error 2
Was this a full clean build (either freshly checked out, either after a
make clean or make distclean) ? Did you do the build for the cross-compiler
with the same set of sources ?
Otherwise, I would remove all generated autotools file in the riscos/asasm
directory with a:
for i in riscos/asasm riscos/asasm/decaof/ riscos/asasm/elftoolchain/ ; do svn status --no-ignore $$i | grep "^I " | cut -b 9- | xargs rm -rf ; done
and restart the build.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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: Amiga nsfont_split
On 19 May 2014 18:35:41 +0100, Chris Young wrote:
> I've scoured through and can't see anything.
Although... I think I may have fixed it. Just filtered out control
chars from the kerning, even though there shouldn't have been any
present.
Chris
> I've scoured through and can't see anything.
Although... I think I may have fixed it. Just filtered out control
chars from the kerning, even though there shouldn't have been any
present.
Chris
Re: Amiga nsfont_split
On Sun, 18 May 2014 23:07:26 +0100, Michael Drake wrote:
tbh it's only really a problem because NetSurf doesn't redraw the two
lines when it decides to reflow them, is there anything we can do
about that?
> So the Amiga nsfont_split is getting identical inputs but is behaving
> non-deterministically.
>
> I'd look for global variable usage or perhaps some sort of state in the
> glyph measuring library code that you use that needs to be reset.
I've scoured through and can't see anything. ami_open_outline_font()
(re)sets the parameters for that font, the only other places where
parameters are set are in the width and plotting code, where the two
glyphs are set, and they are always reset without fail before anything
is queried.
Chris
tbh it's only really a problem because NetSurf doesn't redraw the two
lines when it decides to reflow them, is there anything we can do
about that?
> So the Amiga nsfont_split is getting identical inputs but is behaving
> non-deterministically.
>
> I'd look for global variable usage or perhaps some sort of state in the
> glyph measuring library code that you use that needs to be reset.
I've scoured through and can't see anything. ami_open_outline_font()
(re)sets the parameters for that font, the only other places where
parameters are set are in the width and plotting code, where the two
glyphs are set, and they are always reset without fail before anything
is queried.
Chris
[gccsdk] Unable to build native RISC OS compiler
I've just tried to build the native RISC OS compiler on a Debian system
and it failed with:
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
/home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928: syntax
error near unexpected token `LIBARCHIVE,'
/home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure: line 11928: ` PKG_
CHECK_MODULES(LIBARCHIVE, libarchive >= $REQ_LIBARCHIVE_VERSION)'
configure: error: /home/alanb/gccsdk/gcc4/riscos/asasm/elftoolchain/configure fa
iled for elftoolchain
make[1]: *** [ronative-riscostools-built] Error 2
make[1]: Leaving directory `/home/alanb/gccsdk/gcc4'
make: *** [getenv] Error 2
Any ideas how to fix this?
Regards,
Alan
Sunday, 18 May 2014
Re: Amiga nsfont_split
On 18/05/14 21:19, Chris Young wrote:
> Yes, it does.
OK.
Well anyway, the first and last state of the log you provided were
identical. Splitting 132 chars ("No it's not. It's licensed nationally
for the transmitters specified in the licence. It's the same multiplex
all over the country."), at 550px. The first time it split at 100
chars, and the second time at 110.
So the Amiga nsfont_split is getting identical inputs but is behaving
non-deterministically.
I'd look for global variable usage or perhaps some sort of state in the
glyph measuring library code that you use that needs to be reset.
> Yes, it does.
OK.
Well anyway, the first and last state of the log you provided were
identical. Splitting 132 chars ("No it's not. It's licensed nationally
for the transmitters specified in the licence. It's the same multiplex
all over the country."), at 550px. The first time it split at 100
chars, and the second time at 110.
So the Amiga nsfont_split is getting identical inputs but is behaving
non-deterministically.
I'd look for global variable usage or perhaps some sort of state in the
glyph measuring library code that you use that needs to be reset.
Re: [Rpcemu] Stuck on installing RPCemu/Mint 16
It's 0.8.11.
I googled and was landed at
http://www.riscos.info/index.php/RPCEmu_Linux_Guide.
I followed the link in the pink box at the top of the page to
http://www.marutan.net/rpcemuspoon/#downloads from where I downloaded
rpcemu-0.8.11.tar.gz, which is what I'm trying to compile.
Sean.
On 18/05/14 21:20, Peter Howkins wrote:
> On Tue, May 13, 2014 at 08:59:57AM +0100, Seán Kelly wrote:
>> Hi,
>>
>> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>>
>> After a few false starts I got Allegro in place and all seemed to be
>> going well (following
>> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
>
>
> Hi Sean, can you tell me which version of rpcemu you're trying to compile
> and where you got it from?
>
> In theory the issue you're reporting was fixed a few years ago, so it
> might be out of date source. [1]
>
> Peter
>
> [1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
>
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
I googled and was landed at
http://www.riscos.info/index.php/RPCEmu_Linux_Guide.
I followed the link in the pink box at the top of the page to
http://www.marutan.net/rpcemuspoon/#downloads from where I downloaded
rpcemu-0.8.11.tar.gz, which is what I'm trying to compile.
Sean.
On 18/05/14 21:20, Peter Howkins wrote:
> On Tue, May 13, 2014 at 08:59:57AM +0100, Seán Kelly wrote:
>> Hi,
>>
>> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>>
>> After a few false starts I got Allegro in place and all seemed to be
>> going well (following
>> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
>
>
> Hi Sean, can you tell me which version of rpcemu you're trying to compile
> and where you got it from?
>
> In theory the issue you're reporting was fixed a few years ago, so it
> might be out of date source. [1]
>
> Peter
>
> [1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
>
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Stuck on installing RPCemu/Mint 16
On Tue, May 13, 2014 at 08:59:57AM +0100, Seán Kelly wrote:
> Hi,
>
> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>
> After a few false starts I got Allegro in place and all seemed to be
> going well (following
> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
Hi Sean, can you tell me which version of rpcemu you're trying to compile
and where you got it from?
In theory the issue you're reporting was fixed a few years ago, so it
might be out of date source. [1]
Peter
[1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Hi,
>
> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>
> After a few false starts I got Allegro in place and all seemed to be
> going well (following
> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
Hi Sean, can you tell me which version of rpcemu you're trying to compile
and where you got it from?
In theory the issue you're reporting was fixed a few years ago, so it
might be out of date source. [1]
Peter
[1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Amiga nsfont_split
On 18 May 2014 21:04:08 BST, Michael Drake <mike@smoothartist.com> wrote:
>
>
>On 18/05/14 20:52, Chris Young wrote:
>
>> I found some troublesome text, removed a full stop from the end of
>the
>> second line, and added a comma.
>
>> Relevant bit attached.
>
>Thanks. Certainly looks odd.
>
>It looks like there's a paragraph, and then a blank line? Does it
>happen when there is no blank line after the paragraph.
Yes, it does.
Chris
>
>
>On 18/05/14 20:52, Chris Young wrote:
>
>> I found some troublesome text, removed a full stop from the end of
>the
>> second line, and added a comma.
>
>> Relevant bit attached.
>
>Thanks. Certainly looks odd.
>
>It looks like there's a paragraph, and then a blank line? Does it
>happen when there is no blank line after the paragraph.
Yes, it does.
Chris
Re: Amiga nsfont_split
On 18/05/14 20:52, Chris Young wrote:
> I found some troublesome text, removed a full stop from the end of the
> second line, and added a comma.
> Relevant bit attached.
Thanks. Certainly looks odd.
It looks like there's a paragraph, and then a blank line? Does it
happen when there is no blank line after the paragraph.
> I found some troublesome text, removed a full stop from the end of the
> second line, and added a comma.
> Relevant bit attached.
Thanks. Certainly looks odd.
It looks like there's a paragraph, and then a blank line? Does it
happen when there is no blank line after the paragraph.
Re: Amiga nsfont_split
On 18/05/14 18:44, Chris Young wrote:
> Me deleting and typing at the end of the second line shouldn't make
> any difference to the pixel count of the first line, but somehow it
> does.
It starts re-flowing text from the start of the line above the line you
edit. (If you reduce the length of the first word on the second line,
it may now be able to fit on the line above.)
I've pushed some logging in nsfont_split, which might show what's
actually happening.
> Me deleting and typing at the end of the second line shouldn't make
> any difference to the pixel count of the first line, but somehow it
> does.
It starts re-flowing text from the start of the line above the line you
edit. (If you reduce the length of the first word on the second line,
it may now be able to fit on the line above.)
I've pushed some logging in nsfont_split, which might show what's
actually happening.
Re: Amiga nsfont_split
On Sun, 18 May 2014 17:03:25 +0100, Michael Drake wrote:
>
>
> On 18/05/14 13:51, Chris Young wrote:
> > On Fri, 16 May 2014 22:52:23 +0100, Michael Drake wrote:
> >
> >> there's a chance I've broken it further if ESetInfo can't handle char2
> >> being 0x0000.
> >
> > I've told it to skip kerning against 0x0000, as that makes no sense
> > anyway.
>
> OK, but if kerning against a space is any different to no kerning, then
> that's the problem. I was hoping that ESetInfo would treat 0x0000 the
> same as space.
Right. I'm getting the same effect with 1887 and 1888 though.
I'm not convinced this is the problem. It seems to be if a
sentence wraps over to the next line, if the last word on the first
line fits on the exact pixel boundary, then NetSurf suddenly decides
it doesn't fit as soon as backspace is pressed. Typing more
characters then resets it back to thinking the original number of
characters fit onto that line (and that last word moves back up).
Me deleting and typing at the end of the second line shouldn't make
any difference to the pixel count of the first line, but somehow it
does.
> Perhaps the best fix would be to set the char2 to a space when the next
> char is 0x0000. That should ensure consistency.
I've just disabled kerning in that function and it makes no difference
whatsoever - even down to the same line causing the problem (even
though it should now have a different width?)
Chris
>
>
> On 18/05/14 13:51, Chris Young wrote:
> > On Fri, 16 May 2014 22:52:23 +0100, Michael Drake wrote:
> >
> >> there's a chance I've broken it further if ESetInfo can't handle char2
> >> being 0x0000.
> >
> > I've told it to skip kerning against 0x0000, as that makes no sense
> > anyway.
>
> OK, but if kerning against a space is any different to no kerning, then
> that's the problem. I was hoping that ESetInfo would treat 0x0000 the
> same as space.
Right. I'm getting the same effect with 1887 and 1888 though.
I'm not convinced this is the problem. It seems to be if a
sentence wraps over to the next line, if the last word on the first
line fits on the exact pixel boundary, then NetSurf suddenly decides
it doesn't fit as soon as backspace is pressed. Typing more
characters then resets it back to thinking the original number of
characters fit onto that line (and that last word moves back up).
Me deleting and typing at the end of the second line shouldn't make
any difference to the pixel count of the first line, but somehow it
does.
> Perhaps the best fix would be to set the char2 to a space when the next
> char is 0x0000. That should ensure consistency.
I've just disabled kerning in that function and it makes no difference
whatsoever - even down to the same line causing the problem (even
though it should now have a different width?)
Chris
Re: Amiga nsfont_split
On 18/05/14 13:51, Chris Young wrote:
> On Fri, 16 May 2014 22:52:23 +0100, Michael Drake wrote:
>
>> there's a chance I've broken it further if ESetInfo can't handle char2
>> being 0x0000.
>
> I've told it to skip kerning against 0x0000, as that makes no sense
> anyway.
OK, but if kerning against a space is any different to no kerning, then
that's the problem. I was hoping that ESetInfo would treat 0x0000 the
same as space.
Perhaps the best fix would be to set the char2 to a space when the next
char is 0x0000. That should ensure consistency.
> On Fri, 16 May 2014 22:52:23 +0100, Michael Drake wrote:
>
>> there's a chance I've broken it further if ESetInfo can't handle char2
>> being 0x0000.
>
> I've told it to skip kerning against 0x0000, as that makes no sense
> anyway.
OK, but if kerning against a space is any different to no kerning, then
that's the problem. I was hoping that ESetInfo would treat 0x0000 the
same as space.
Perhaps the best fix would be to set the char2 to a space when the next
char is 0x0000. That should ensure consistency.
Re: Full save not working
On 18 May 2014, Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 16 May 2014, Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > On 16 May 2014, Brian Jordan <brian.jordan9@btinternet.com> wrote:
> >
> > > I just noticed that full saves of pages doesn't work in v1885, only
> > > !Run, !Sprites and URL files are saved and the accompanying warning
> > > message reads "The file could not be saved due to an error: Is a
> > > directory". A quick look back through the versions I have available
> > > suggests this was introduced between v1841 and v1862. I'll have a
> > > couple more glasses and try to report it on the tracker.
> >
> > I've done that already
> > http://bugs.netsurf-browser.org/mantis/view.php?id=2126
>
> Now fixed. Many thanks to Vincent Sanders
Sorry, Brian. I didn't see your post before I replied.
Tony
> On 16 May 2014, Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > On 16 May 2014, Brian Jordan <brian.jordan9@btinternet.com> wrote:
> >
> > > I just noticed that full saves of pages doesn't work in v1885, only
> > > !Run, !Sprites and URL files are saved and the accompanying warning
> > > message reads "The file could not be saved due to an error: Is a
> > > directory". A quick look back through the versions I have available
> > > suggests this was introduced between v1841 and v1862. I'll have a
> > > couple more glasses and try to report it on the tracker.
> >
> > I've done that already
> > http://bugs.netsurf-browser.org/mantis/view.php?id=2126
>
> Now fixed. Many thanks to Vincent Sanders
Sorry, Brian. I didn't see your post before I replied.
Tony
Re: Full save not working
On 16 May 2014, Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 16 May 2014, Brian Jordan <brian.jordan9@btinternet.com> wrote:
>
> > I just noticed that full saves of pages doesn't work in v1885
[snip]
> http://bugs.netsurf-browser.org/mantis/view.php?id=2126
Now fixed. Many thanks to Vincent Sanders.
Tony
> On 16 May 2014, Brian Jordan <brian.jordan9@btinternet.com> wrote:
>
> > I just noticed that full saves of pages doesn't work in v1885
[snip]
> http://bugs.netsurf-browser.org/mantis/view.php?id=2126
Now fixed. Many thanks to Vincent Sanders.
Tony
Re: Amiga nsfont_split
On Fri, 16 May 2014 22:52:23 +0100, Michael Drake wrote:
> there's a chance I've broken it further if ESetInfo can't handle char2
> being 0x0000.
I've told it to skip kerning against 0x0000, as that makes no sense
anyway.
No idea if the original problem is fixed yet, but it certainly isn't
any worse.
Chris
> there's a chance I've broken it further if ESetInfo can't handle char2
> being 0x0000.
I've told it to skip kerning against 0x0000, as that makes no sense
anyway.
No idea if the original problem is fixed yet, but it certainly isn't
any worse.
Chris
Re: Amiga window data structures
On Sat, 17 May 2014 15:37:31 +0100, Michael Drake wrote:
> So, for example, to set the Amiga front end's scroll offset for the
> window, it starts with a struct gui_window_2 (gw2), which I assume is the
> main window containing all the tabs, then it goes to the bw (representing
> current tab?), then the gw:
Yes, that's correct. It's a bit confused as I had one structure for
everything, and then realised that wouldn't work when I added tabs.
gui_window_2 probably needs a rename to make it clearer. Most of the
frontend code uses gui_window_2 as that represents the window with the
displayed content, and prior to tabs used to be gui_window (which is
why the bw pointer is there rather than in gui_window).
> I suggest that the gw2 be changed to have a pointer to a gw representing
> the current tab, and add a pointer to bw entry in the gw. So to get the
> scroll_y it would be:
>
> gw2->gw->scroll_y
>
> And to use the core browser_window_* functions, you'd be passing the bw
> from:
>
> gw2->gw->bw
>
> Does that seem doable Chris?
Yes, that seems more logical than what we have currently.
Chris
> So, for example, to set the Amiga front end's scroll offset for the
> window, it starts with a struct gui_window_2 (gw2), which I assume is the
> main window containing all the tabs, then it goes to the bw (representing
> current tab?), then the gw:
Yes, that's correct. It's a bit confused as I had one structure for
everything, and then realised that wouldn't work when I added tabs.
gui_window_2 probably needs a rename to make it clearer. Most of the
frontend code uses gui_window_2 as that represents the window with the
displayed content, and prior to tabs used to be gui_window (which is
why the bw pointer is there rather than in gui_window).
> I suggest that the gw2 be changed to have a pointer to a gw representing
> the current tab, and add a pointer to bw entry in the gw. So to get the
> scroll_y it would be:
>
> gw2->gw->scroll_y
>
> And to use the core browser_window_* functions, you'd be passing the bw
> from:
>
> gw2->gw->bw
>
> Does that seem doable Chris?
Yes, that seems more logical than what we have currently.
Chris
Re: Full save not working
In article <88a3ea0854.old_coaster@old_coaster.yahoo.co.uk>,
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 16 May 2014, Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > I just noticed that full saves of pages doesn't work in v1885, only
> > !Run, !Sprites and URL files are saved and the accompanying warning
> > message reads "The file could not be saved due to an error: Is a
> > directory". A quick look back through the versions I have available
> > suggests this was introduced between v1841 and v1862. I'll have a
> > couple more glasses and try to report it on the tracker.
> I've done that already
> http://bugs.netsurf-browser.org/mantis/view.php?id=2126
Thanks Tony, I see this has been fixed in #1886.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 16 May 2014, Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > I just noticed that full saves of pages doesn't work in v1885, only
> > !Run, !Sprites and URL files are saved and the accompanying warning
> > message reads "The file could not be saved due to an error: Is a
> > directory". A quick look back through the versions I have available
> > suggests this was introduced between v1841 and v1862. I'll have a
> > couple more glasses and try to report it on the tracker.
> I've done that already
> http://bugs.netsurf-browser.org/mantis/view.php?id=2126
Thanks Tony, I see this has been fixed in #1886.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Saturday, 17 May 2014
Amiga window data structures
I have been looking at stopping the Amiga front end from #including
desktop/browser_private.h, like I did for the Windows front end earlier
this week.
The big problem with the Amiga code at the moment is that the tabs
implementation seems to depend on being able to dereference struct
browser_window (bw), to get to the struct gui_window (gw).
So, for example, to set the Amiga front end's scroll offset for the
window, it starts with a struct gui_window_2 (gw2), which I assume is the
main window containing all the tabs, then it goes to the bw (representing
current tab?), then the gw:
gw2->bw->gw->scroll_y
The gui management of tabs should not depend on core data structures.
I suggest that the gw2 be changed to have a pointer to a gw representing
the current tab, and add a pointer to bw entry in the gw. So to get the
scroll_y it would be:
gw2->gw->scroll_y
And to use the core browser_window_* functions, you'd be passing the bw
from:
gw2->gw->bw
Does that seem doable Chris?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
desktop/browser_private.h, like I did for the Windows front end earlier
this week.
The big problem with the Amiga code at the moment is that the tabs
implementation seems to depend on being able to dereference struct
browser_window (bw), to get to the struct gui_window (gw).
So, for example, to set the Amiga front end's scroll offset for the
window, it starts with a struct gui_window_2 (gw2), which I assume is the
main window containing all the tabs, then it goes to the bw (representing
current tab?), then the gw:
gw2->bw->gw->scroll_y
The gui management of tabs should not depend on core data structures.
I suggest that the gw2 be changed to have a pointer to a gw representing
the current tab, and add a pointer to bw entry in the gw. So to get the
scroll_y it would be:
gw2->gw->scroll_y
And to use the core browser_window_* functions, you'd be passing the bw
from:
gw2->gw->bw
Does that seem doable Chris?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Subscribe to:
Posts (Atom)