On 29/04/12 17:20, pdmiller@pdmiller1.plus.com wrote:
> On 25/04/12 19:20,Lee Noar<leenoar@sky.com> wrote:
>>
>> On 25/04/12 17:17, pdmiller@pdmiller1.plus.com wrote:
>>> I've just installed GCC 4.1.2 release 1 onto my VRPC AdjustSA RO 6.20
>>> system, including SharedUnixlib 1.12, and the latest !SharedLibs. I get a
>>> segmentation fault when compiling certain c files. It looks like they are
>>> greater than a certain size in some way. They compile ok with the previous
>>> GCC release. I don't remember getting this error with the previous
>>> release,
>>> or having to do anything to increase a slot size, etc. My next slot is set
>>> to 10240k. Have I missed or forgotten to do something, or is it a real
>>> bug.
>>
>> Could you please post one of the offending files that will demonstrate
>> the problem.
>>
>> Thanks,
>> Lee.
>
> Hmm, not the answer I was hoping for.
Yes, sorry, but unless we can reproduce the same result, it's virtually
impossible to find the cause.
[snip]
> If you still need it I can send a zip file of a peprocessed C file
> containing the problem code I described at the start of this email,
> unfortunately unpreprocessed its 15000 lines long, preprocessed and zipped
> its 115KB.
Yes, I think that's the only way.
> If so, would you prefer it sent to your email address you used
> to reply to this message. Please let me know.
Yes, that should be fine.
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
Monday, 30 April 2012
Re: Conversion from SVN to Git
On 30/04/2012 10:00, Daniel Silverstone wrote:
> We have considered plenty of DVCSs over the years. I've been pushing for a
> move from Subversion for the past four or five years. Until recently, the pain
> of the move outweighed the pain of staying, but nowadays it's too painful to
> stay. Git "won" the argument in the end because it's the one DVCS the majority
> of us are familiar (if not comfortable) with. It has a lot of good
> documentation out there, and while its UI sucks (to say the least) it is
> competently implemented and UI can be improved.
<troll>
Tried fossil <http://www.fossil-scm.org/>? :D
</troll>
François.
> We have considered plenty of DVCSs over the years. I've been pushing for a
> move from Subversion for the past four or five years. Until recently, the pain
> of the move outweighed the pain of staying, but nowadays it's too painful to
> stay. Git "won" the argument in the end because it's the one DVCS the majority
> of us are familiar (if not comfortable) with. It has a lot of good
> documentation out there, and while its UI sucks (to say the least) it is
> competently implemented and UI can be improved.
<troll>
Tried fossil <http://www.fossil-scm.org/>? :D
</troll>
François.
Re: scrolling jerky
On 30/04/2012 00:57, Ole wrote:
> Am Montag, den 30.04.2012, 00:17 +0200 schrieb "Chris Young"
> <chris.young@unsatisfactorysoftware.co.uk>:
>> On Sun, 29 Apr 2012 22:21:31 +0100, Steve Fryatt wrote:
>>
>>> > I suspect rectangle-copy would be a fine addition to the plotter
>>> > interface.
>
> Yes, but the Atari frontend is an On-Screen plotter, and so the caller
> would have to take care of the visible region on screen when calculating
> the
> area which needs to be scrolled / redrawn.
I don't remember exactly how it's done in Haiku but it likely also moves
only the visible parts.
>>> The other addition that I've been wondering about since frames moved
>>> to the
>>> core is a scroll-bar plotter, which frontends could implement if they
>>> didn't
>>> want the core's default look.
>
> On Atari platform this is no problem, the Objects used to display an
> scrollbar can
> also be drawn manually, anywhere.
While this is not the case for BeOS (scrollbars are drawn directly by
app_server), I think the new BControlLook API in Haiku should be able to
do this now.
Guess that'll be one more reason to phase out BeOS support and
concentrate on Haiku, along with the layout kit which will make it
easier to add all the missing dialogs.
François.
> Am Montag, den 30.04.2012, 00:17 +0200 schrieb "Chris Young"
> <chris.young@unsatisfactorysoftware.co.uk>:
>> On Sun, 29 Apr 2012 22:21:31 +0100, Steve Fryatt wrote:
>>
>>> > I suspect rectangle-copy would be a fine addition to the plotter
>>> > interface.
>
> Yes, but the Atari frontend is an On-Screen plotter, and so the caller
> would have to take care of the visible region on screen when calculating
> the
> area which needs to be scrolled / redrawn.
I don't remember exactly how it's done in Haiku but it likely also moves
only the visible parts.
>>> The other addition that I've been wondering about since frames moved
>>> to the
>>> core is a scroll-bar plotter, which frontends could implement if they
>>> didn't
>>> want the core's default look.
>
> On Atari platform this is no problem, the Objects used to display an
> scrollbar can
> also be drawn manually, anywhere.
While this is not the case for BeOS (scrollbars are drawn directly by
app_server), I think the new BControlLook API in Haiku should be able to
do this now.
Guess that'll be one more reason to phase out BeOS support and
concentrate on Haiku, along with the layout kit which will make it
easier to add all the missing dialogs.
François.
[gccsdk] [Bug 232] New: GCC 4.1.2 Rel 2 Dev 2012-04-28, SUL 1.12: system(), Alias and % prefix
http://www.riscos.info/bugzilla3/show_bug.cgi?id=232
Summary: GCC 4.1.2 Rel 2 Dev 2012-04-28, SUL 1.12: system(),
Alias and % prefix
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@ntlworld.com
Estimated Hours: 0.0
GCCSDK GCC 4.1.2 Release 2 Development 2012-04-28
SharedUnixLibrary 1.12
VRPC RISC OS 4.39
ls is previously compiled with gcc.
This code:
#include <stdlib.h>
#include <stdio.h>
int main(void) {
system("Alias Time echo XXXXXXXXXX");
system("Alias ls echo XXXXXXXXXX");
printf("--------------------------------\n");
system("%Time");
printf("--------------------------------\n");
system("%ls");
printf("--------------------------------\n");
system("UnAlias Time");
system("UnAlias ls");
return 0;
}
gives:
*test
--------------------------------
--------------------------------
--------------------------------
It should give something like:
*test
--------------------------------
Mon,30 Apr 2012.13:13:02
--------------------------------
!Run c d Makefile o stat test
--------------------------------
with the % prefix over-riding the aliases.
--
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.1.2 Rel 2 Dev 2012-04-28, SUL 1.12: system(),
Alias and % prefix
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@ntlworld.com
Estimated Hours: 0.0
GCCSDK GCC 4.1.2 Release 2 Development 2012-04-28
SharedUnixLibrary 1.12
VRPC RISC OS 4.39
ls is previously compiled with gcc.
This code:
#include <stdlib.h>
#include <stdio.h>
int main(void) {
system("Alias Time echo XXXXXXXXXX");
system("Alias ls echo XXXXXXXXXX");
printf("--------------------------------\n");
system("%Time");
printf("--------------------------------\n");
system("%ls");
printf("--------------------------------\n");
system("UnAlias Time");
system("UnAlias ls");
return 0;
}
gives:
*test
--------------------------------
--------------------------------
--------------------------------
It should give something like:
*test
--------------------------------
Mon,30 Apr 2012.13:13:02
--------------------------------
!Run c d Makefile o stat test
--------------------------------
with the % prefix over-riding the aliases.
--
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: NetSurf 2.9 released
On Mon, Apr 30, 2012 at 05:47:59PM +1200, Alan & Sally wrote:
>
> I also have NetSurf on my Mac, a G5 with twin PPC processors running OS 10.5.8. I have NetSurf 2.7 and saw that 2.9 was available. However, selecting the Mac option took me to 2.8 for Mac (not 2.9) and after downloading it I found it would not work with the PPC architecture. This was a disappointment. Is 2.9 going to be available for Macs with the Power PC processor?
Unlikely unless an OS X developer turns up and does the work. I believe
one of the issues is that newer toolchains and Xcodes simply can't build
for PPC anymore.
B.
>
> I also have NetSurf on my Mac, a G5 with twin PPC processors running OS 10.5.8. I have NetSurf 2.7 and saw that 2.9 was available. However, selecting the Mac option took me to 2.8 for Mac (not 2.9) and after downloading it I found it would not work with the PPC architecture. This was a disappointment. Is 2.9 going to be available for Macs with the Power PC processor?
Unlikely unless an OS X developer turns up and does the work. I believe
one of the issues is that newer toolchains and Xcodes simply can't build
for PPC anymore.
B.
Re: scrolling jerky
On Sun, Apr 29, 2012 at 10:21:31PM +0100, Steve Fryatt wrote:
> On 27 Apr, Rob Kendrick wrote in message
> <20120427172732.GA20183@pepperfish.net>:
>
> > On Fri, Apr 27, 2012 at 05:59:12PM +0100, Chris Young wrote:
> >
> > > Cache won't help, the issue is that "core" scrolls aren't optimised, so
> > > if you scroll a frame the entire contents of that frame will be redrawn
> > > - even if it is only scrolled a pixel. Conversely, if you scroll using
> > > the window scrollbar, the platform code handles the scroll. Usually the
> > > platform code is optimised, and will "shift" the area and just redraw
> > > the newly-exposed bit.
> > >
> > > Clearly NetSurf would benefit from some scrolling optimisation in the
> > > core, but I'm not sure if it is as easy as telling the frontend code to
> > > move a particular area and then redraw the newly exposed area. (not
> > > least because frontends don't currently have any concept of "move a
> > > particular area")
> >
> > I suspect rectangle-copy would be a fine addition to the plotter
> > interface.
>
> The other addition that I've been wondering about since frames moved to the
> core is a scroll-bar plotter, which frontends could implement if they didn't
> want the core's default look.
I've thought about this a bit in the past, and dismissed it. Certainly
if we ever want to support the horribleness of CSS-styled scroll bars.
I think my preference for now would be they remain rendered by the
core, their visual style is refined somewhat, at the core implements
several behavioral styles, so how they operate is not surprising to
users. (Ie, an option to make them work like RISC OS scroll bars in
regards to adjust clicking in the channel or adjust dragging the handle,
another option to change the positioning of up/down buttons for AmigaOS,
etc.)
B.
> On 27 Apr, Rob Kendrick wrote in message
> <20120427172732.GA20183@pepperfish.net>:
>
> > On Fri, Apr 27, 2012 at 05:59:12PM +0100, Chris Young wrote:
> >
> > > Cache won't help, the issue is that "core" scrolls aren't optimised, so
> > > if you scroll a frame the entire contents of that frame will be redrawn
> > > - even if it is only scrolled a pixel. Conversely, if you scroll using
> > > the window scrollbar, the platform code handles the scroll. Usually the
> > > platform code is optimised, and will "shift" the area and just redraw
> > > the newly-exposed bit.
> > >
> > > Clearly NetSurf would benefit from some scrolling optimisation in the
> > > core, but I'm not sure if it is as easy as telling the frontend code to
> > > move a particular area and then redraw the newly exposed area. (not
> > > least because frontends don't currently have any concept of "move a
> > > particular area")
> >
> > I suspect rectangle-copy would be a fine addition to the plotter
> > interface.
>
> The other addition that I've been wondering about since frames moved to the
> core is a scroll-bar plotter, which frontends could implement if they didn't
> want the core's default look.
I've thought about this a bit in the past, and dismissed it. Certainly
if we ever want to support the horribleness of CSS-styled scroll bars.
I think my preference for now would be they remain rendered by the
core, their visual style is refined somewhat, at the core implements
several behavioral styles, so how they operate is not surprising to
users. (Ie, an option to make them work like RISC OS scroll bars in
regards to adjust clicking in the channel or adjust dragging the handle,
another option to change the positioning of up/down buttons for AmigaOS,
etc.)
B.
Re: Conversion from SVN to Git
On Sun, Apr 29, 2012 at 04:11:33PM +0100, list@aether.me.uk wrote:
> On Sat, 28 Apr 2012 12:55:33 +0100, Daniel Silverstone wrote:
> > * Git doesn't work on my obscure $platform (We'd rather fix Git than
> >hold off getting away from svn)
> I'm not here to complain about the VCS you choose to use, but I am
> interested to know why this change is happening.
And I will be pleased to elucidate.
> I may be reading too much into your wording but it sounds like you're
> not moving *towards* Git, but *away* from Subversion. I've used
> Subversion for a long time and always got on pretty well with it so
> I'd be fascinated to know what it is which makes it so abhorrent in
> the eyes of the core Netsurf developers. Can you point me at the
> discussion where this decision was made?
Yes, the move is much more "away from Subversion" than towards any particular
other VCS. Specifically we're fed up with the abysmal management of merges
which Subversion just can't do well. We're also wanting to make it possible
for anyone to have useful branches of our codebase without having to have
commit rights to any part of our repositories.
> And why Git in particular. Clearly it's growing in popularity but
> there are lots of other options. I'm guessing that the fact that it
> is distributed is relevant but why not Arch, Mercurial, DARCS, Bazaar
> or even SVK?
Arch: Old, slow, clunky. Reliable but just not a sensible option. Very
complex for people to wrap their heads around (consider register
archive etc)
Bazaar: Similar architecture to Arch, better UI, same issue with root
concepts.
Bazaar-NG: Nice UI, my personal favourite, but honestly it's just a little too
slow. Python as a prerequisite also reduces useful portability.
Mercurial: I've not spent a lot of time with this. Horror stories of data
loss and confusing errors from those I know who still love it have
prevented me.
DARCS: I just don't trust it to be predictably performant. I've seen people
wait hours for a commit to complete sometimes. It seems to be a nice
idea in theory, but I don't approve of its reality.
SVK: Yes, in theory it gets us more branching/merging support while staying
on Subversion (which at least one of our developers would prefer) but
it's a huge tottering perl monstrosity, thus overall we don't approve.
We have considered plenty of DVCSs over the years. I've been pushing for a
move from Subversion for the past four or five years. Until recently, the pain
of the move outweighed the pain of staying, but nowadays it's too painful to
stay. Git "won" the argument in the end because it's the one DVCS the majority
of us are familiar (if not comfortable) with. It has a lot of good
documentation out there, and while its UI sucks (to say the least) it is
competently implemented and UI can be improved.
I hope this was helpful/interesting for you.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> On Sat, 28 Apr 2012 12:55:33 +0100, Daniel Silverstone wrote:
> > * Git doesn't work on my obscure $platform (We'd rather fix Git than
> >hold off getting away from svn)
> I'm not here to complain about the VCS you choose to use, but I am
> interested to know why this change is happening.
And I will be pleased to elucidate.
> I may be reading too much into your wording but it sounds like you're
> not moving *towards* Git, but *away* from Subversion. I've used
> Subversion for a long time and always got on pretty well with it so
> I'd be fascinated to know what it is which makes it so abhorrent in
> the eyes of the core Netsurf developers. Can you point me at the
> discussion where this decision was made?
Yes, the move is much more "away from Subversion" than towards any particular
other VCS. Specifically we're fed up with the abysmal management of merges
which Subversion just can't do well. We're also wanting to make it possible
for anyone to have useful branches of our codebase without having to have
commit rights to any part of our repositories.
> And why Git in particular. Clearly it's growing in popularity but
> there are lots of other options. I'm guessing that the fact that it
> is distributed is relevant but why not Arch, Mercurial, DARCS, Bazaar
> or even SVK?
Arch: Old, slow, clunky. Reliable but just not a sensible option. Very
complex for people to wrap their heads around (consider register
archive etc)
Bazaar: Similar architecture to Arch, better UI, same issue with root
concepts.
Bazaar-NG: Nice UI, my personal favourite, but honestly it's just a little too
slow. Python as a prerequisite also reduces useful portability.
Mercurial: I've not spent a lot of time with this. Horror stories of data
loss and confusing errors from those I know who still love it have
prevented me.
DARCS: I just don't trust it to be predictably performant. I've seen people
wait hours for a commit to complete sometimes. It seems to be a nice
idea in theory, but I don't approve of its reality.
SVK: Yes, in theory it gets us more branching/merging support while staying
on Subversion (which at least one of our developers would prefer) but
it's a huge tottering perl monstrosity, thus overall we don't approve.
We have considered plenty of DVCSs over the years. I've been pushing for a
move from Subversion for the past four or five years. Until recently, the pain
of the move outweighed the pain of staying, but nowadays it's too painful to
stay. Git "won" the argument in the end because it's the one DVCS the majority
of us are familiar (if not comfortable) with. It has a lot of good
documentation out there, and while its UI sucks (to say the least) it is
competently implemented and UI can be improved.
I hope this was helpful/interesting for you.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Sunday, 29 April 2012
Re: NetSurf 2.9 released
On Mon, 30 Apr 2012 03:48:31 +1200, Michael Drake <tlsa@netsurf-browser.org> wrote:
>
> The NetSurf developers are happy to announce NetSurf 2.9. This release
> contains many bug fixes and improvements.
>
> It is available to download from http://www.netsurf-browser.org/
>
> Binaries are available now for RISC OS, AmigaOS 4 and Atari systems.
>
> We plan to make binaries for other platforms available soon.
>
> NetSurf 2.9 contains many improvements over the previous release. The most
> significant changes are new multi-tasking behaviour, optimised URL
> handling, fetcher optimisations, cache optimisations, and faster CSS
> selection.
>
> A more detailed and complete list of changes is given below.
>
> [snip]
Downloaded and working well. Many thanks to the team. Seems to be faster than the latest test release of 3.0. It's on my VARPC and my Risc PC with OS 3.5.
I also have NetSurf on my Mac, a G5 with twin PPC processors running OS 10.5.8. I have NetSurf 2.7 and saw that 2.9 was available. However, selecting the Mac option took me to 2.8 for Mac (not 2.9) and after downloading it I found it would not work with the PPC architecture. This was a disappointment. Is 2.9 going to be available for Macs with the Power PC processor?
Thanks, Alan
>
> The NetSurf developers are happy to announce NetSurf 2.9. This release
> contains many bug fixes and improvements.
>
> It is available to download from http://www.netsurf-browser.org/
>
> Binaries are available now for RISC OS, AmigaOS 4 and Atari systems.
>
> We plan to make binaries for other platforms available soon.
>
> NetSurf 2.9 contains many improvements over the previous release. The most
> significant changes are new multi-tasking behaviour, optimised URL
> handling, fetcher optimisations, cache optimisations, and faster CSS
> selection.
>
> A more detailed and complete list of changes is given below.
>
> [snip]
Downloaded and working well. Many thanks to the team. Seems to be faster than the latest test release of 3.0. It's on my VARPC and my Risc PC with OS 3.5.
I also have NetSurf on my Mac, a G5 with twin PPC processors running OS 10.5.8. I have NetSurf 2.7 and saw that 2.9 was available. However, selecting the Mac option took me to 2.8 for Mac (not 2.9) and after downloading it I found it would not work with the PPC architecture. This was a disappointment. Is 2.9 going to be available for Macs with the Power PC processor?
Thanks, Alan
Re: scrolling jerky
Am Montag, den 30.04.2012, 00:17 +0200 schrieb "Chris Young"
<chris.young@unsatisfactorysoftware.co.uk>:
> On Sun, 29 Apr 2012 22:21:31 +0100, Steve Fryatt wrote:
>
>> > I suspect rectangle-copy would be a fine addition to the plotter
>> > interface.
Yes, but the Atari frontend is an On-Screen plotter, and so the caller
would have to take care of the visible region on screen when
calculating the
area which needs to be scrolled / redrawn.
>>
>> The other addition that I've been wondering about since frames moved
>> to the
>> core is a scroll-bar plotter, which frontends could implement if
>> they didn't
>> want the core's default look.
On Atari platform this is no problem, the Objects used to display an
scrollbar can
also be drawn manually, anywhere.
Greets,
Ole
<chris.young@unsatisfactorysoftware.co.uk>:
> On Sun, 29 Apr 2012 22:21:31 +0100, Steve Fryatt wrote:
>
>> > I suspect rectangle-copy would be a fine addition to the plotter
>> > interface.
Yes, but the Atari frontend is an On-Screen plotter, and so the caller
would have to take care of the visible region on screen when
calculating the
area which needs to be scrolled / redrawn.
>>
>> The other addition that I've been wondering about since frames moved
>> to the
>> core is a scroll-bar plotter, which frontends could implement if
>> they didn't
>> want the core's default look.
On Atari platform this is no problem, the Objects used to display an
scrollbar can
also be drawn manually, anywhere.
Greets,
Ole
Re: scrolling jerky
On Sun, 29 Apr 2012 22:21:31 +0100, Steve Fryatt wrote:
> > I suspect rectangle-copy would be a fine addition to the plotter
> > interface.
>
> The other addition that I've been wondering about since frames moved to the
> core is a scroll-bar plotter, which frontends could implement if they didn't
> want the core's default look.
>
> From a RISC OS perspective I think this would be best done by offering
> plotter functions that just plotted the components, instead of telling the
> frontend about the concept of a scroll bar,
Of course, on RISC OS that's easy, as you can just pick the individual
sprites out of Resources: and plot them like any other NetSurf bitmap.
Not sure I can do that here, I'd have to play around with GM_RENDER
and see if it lets me plot the images of arbitrary gadgets without
attaching them to a window.
I see a slight problem in the positioning of the scrollbar arrows. On
RISC OS they are at opposite ends of the scrollbar. On AmigaOS they
are all grouped in the bottom-right hand corner. GTK I think combines
these two approaches (but I suspect that is configurable). The
relative sizes would also need to be taken into account.
> because getting the RISC OS
> Window Manager to put a 'real' bar into a NetSurf window and only show the
> bits that are needed
You mean, like a scrollbar that is half-way off the visible page? I
think that is impossible here too, without defining the entire page as
a virtual gadget to attach it to. That is basically more hassle than
it is worth.
Chris
> > I suspect rectangle-copy would be a fine addition to the plotter
> > interface.
>
> The other addition that I've been wondering about since frames moved to the
> core is a scroll-bar plotter, which frontends could implement if they didn't
> want the core's default look.
>
> From a RISC OS perspective I think this would be best done by offering
> plotter functions that just plotted the components, instead of telling the
> frontend about the concept of a scroll bar,
Of course, on RISC OS that's easy, as you can just pick the individual
sprites out of Resources: and plot them like any other NetSurf bitmap.
Not sure I can do that here, I'd have to play around with GM_RENDER
and see if it lets me plot the images of arbitrary gadgets without
attaching them to a window.
I see a slight problem in the positioning of the scrollbar arrows. On
RISC OS they are at opposite ends of the scrollbar. On AmigaOS they
are all grouped in the bottom-right hand corner. GTK I think combines
these two approaches (but I suspect that is configurable). The
relative sizes would also need to be taken into account.
> because getting the RISC OS
> Window Manager to put a 'real' bar into a NetSurf window and only show the
> bits that are needed
You mean, like a scrollbar that is half-way off the visible page? I
think that is impossible here too, without defining the entire page as
a virtual gadget to attach it to. That is basically more hassle than
it is worth.
Chris
Re: scrolling jerky
On 27 Apr, Rob Kendrick wrote in message
<20120427172732.GA20183@pepperfish.net>:
> On Fri, Apr 27, 2012 at 05:59:12PM +0100, Chris Young wrote:
>
> > Cache won't help, the issue is that "core" scrolls aren't optimised, so
> > if you scroll a frame the entire contents of that frame will be redrawn
> > - even if it is only scrolled a pixel. Conversely, if you scroll using
> > the window scrollbar, the platform code handles the scroll. Usually the
> > platform code is optimised, and will "shift" the area and just redraw
> > the newly-exposed bit.
> >
> > Clearly NetSurf would benefit from some scrolling optimisation in the
> > core, but I'm not sure if it is as easy as telling the frontend code to
> > move a particular area and then redraw the newly exposed area. (not
> > least because frontends don't currently have any concept of "move a
> > particular area")
>
> I suspect rectangle-copy would be a fine addition to the plotter
> interface.
The other addition that I've been wondering about since frames moved to the
core is a scroll-bar plotter, which frontends could implement if they didn't
want the core's default look.
>From a RISC OS perspective I think this would be best done by offering
plotter functions that just plotted the components, instead of telling the
frontend about the concept of a scroll bar, because getting the RISC OS
Window Manager to put a 'real' bar into a NetSurf window and only show the
bits that are needed would probably undo a lot of the benefits of the frames
changes. If other frontends would find it easier to delegate the whole
plotting aspect to their window managers, however, this approach would
obviously be a disadvantage.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 28 April 2012
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
<20120427172732.GA20183@pepperfish.net>:
> On Fri, Apr 27, 2012 at 05:59:12PM +0100, Chris Young wrote:
>
> > Cache won't help, the issue is that "core" scrolls aren't optimised, so
> > if you scroll a frame the entire contents of that frame will be redrawn
> > - even if it is only scrolled a pixel. Conversely, if you scroll using
> > the window scrollbar, the platform code handles the scroll. Usually the
> > platform code is optimised, and will "shift" the area and just redraw
> > the newly-exposed bit.
> >
> > Clearly NetSurf would benefit from some scrolling optimisation in the
> > core, but I'm not sure if it is as easy as telling the frontend code to
> > move a particular area and then redraw the newly exposed area. (not
> > least because frontends don't currently have any concept of "move a
> > particular area")
>
> I suspect rectangle-copy would be a fine addition to the plotter
> interface.
The other addition that I've been wondering about since frames moved to the
core is a scroll-bar plotter, which frontends could implement if they didn't
want the core's default look.
>From a RISC OS perspective I think this would be best done by offering
plotter functions that just plotted the components, instead of telling the
frontend about the concept of a scroll bar, because getting the RISC OS
Window Manager to put a 'real' bar into a NetSurf window and only show the
bits that are needed would probably undo a lot of the benefits of the frames
changes. If other frontends would find it easier to delegate the whole
plotting aspect to their window managers, however, this approach would
obviously be a disadvantage.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 28 April 2012
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
Re: NetSurf 2.9 released
> Thank you Michael and the rest of team
Hear, hear! (at the risk of clogging the list).
--
John Harrison
Website http://jaharrison.me.uk
Hear, hear! (at the risk of clogging the list).
--
John Harrison
Website http://jaharrison.me.uk
Re: NetSurf 2.9 released
In article <52881402f3tlsa@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> The NetSurf developers are happy to announce NetSurf 2.9. This release
> contains many bug fixes and improvements.
> It is available to download from http://www.netsurf-browser.org/
Thank you Michael and the rest of team.
--
Stuart Winsor
Only plain text for emails
http://www.asciiribbon.org
Michael Drake <tlsa@netsurf-browser.org> wrote:
> The NetSurf developers are happy to announce NetSurf 2.9. This release
> contains many bug fixes and improvements.
> It is available to download from http://www.netsurf-browser.org/
Thank you Michael and the rest of team.
--
Stuart Winsor
Only plain text for emails
http://www.asciiribbon.org
Re: Conversion from SVN to Git
On 29/04/12 18:00, Rob Kendrick wrote:
> On Sun, Apr 29, 2012 at 06:22:48PM +0200, Ole wrote:
>> Am Samstag, den 28.04.2012, 13:55 +0200 schrieb Daniel Silverstone
>> <dsilvers@netsurf-browser.org>:
>>
>>> supported and I
>>> am working on a simple client for platforms which currently do not
>>> support git,
>>> but I cannot guarantee it will be ready in time.
>>
>> Maybe http://subgit.com/ is an option to allow svn to access the git
>> repository?
>
> Or, you could use a git client.
And the nice people who develop Git have created a page showing the
equivalent svn commands:
https://git.wiki.kernel.org/articles/g/i/t/GitSvnCrashCourse_512d.html
Paul
--
Paul Waring
http://www.pwaring.com
> On Sun, Apr 29, 2012 at 06:22:48PM +0200, Ole wrote:
>> Am Samstag, den 28.04.2012, 13:55 +0200 schrieb Daniel Silverstone
>> <dsilvers@netsurf-browser.org>:
>>
>>> supported and I
>>> am working on a simple client for platforms which currently do not
>>> support git,
>>> but I cannot guarantee it will be ready in time.
>>
>> Maybe http://subgit.com/ is an option to allow svn to access the git
>> repository?
>
> Or, you could use a git client.
And the nice people who develop Git have created a page showing the
equivalent svn commands:
https://git.wiki.kernel.org/articles/g/i/t/GitSvnCrashCourse_512d.html
Paul
--
Paul Waring
http://www.pwaring.com
Re: Conversion from SVN to Git
On Sun, Apr 29, 2012 at 06:22:48PM +0200, Ole wrote:
> Am Samstag, den 28.04.2012, 13:55 +0200 schrieb Daniel Silverstone
> <dsilvers@netsurf-browser.org>:
>
> >supported and I
> >am working on a simple client for platforms which currently do not
> >support git,
> >but I cannot guarantee it will be ready in time.
>
> Maybe http://subgit.com/ is an option to allow svn to access the git
> repository?
Or, you could use a git client.
> >If anyone has a *very* good reason for not doing this, speak up
> >now. The
> >following are not considered good reasons:
>
> I'm fine with it, I just don't like the github artwork.
> But I guess github server will not be used anyway.
Indeed not.
B.
> Am Samstag, den 28.04.2012, 13:55 +0200 schrieb Daniel Silverstone
> <dsilvers@netsurf-browser.org>:
>
> >supported and I
> >am working on a simple client for platforms which currently do not
> >support git,
> >but I cannot guarantee it will be ready in time.
>
> Maybe http://subgit.com/ is an option to allow svn to access the git
> repository?
Or, you could use a git client.
> >If anyone has a *very* good reason for not doing this, speak up
> >now. The
> >following are not considered good reasons:
>
> I'm fine with it, I just don't like the github artwork.
> But I guess github server will not be used anyway.
Indeed not.
B.
[gccsdk] [Bug 231] New: GCC 4.1.2 Rel 2 Dev 2012-04-28 glob() top-bit char problem.
http://www.riscos.info/bugzilla3/show_bug.cgi?id=231
Summary: GCC 4.1.2 Rel 2 Dev 2012-04-28 glob() top-bit char
problem.
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@ntlworld.com
Estimated Hours: 0.0
GCCSDK GCC 4.1.2 Release 2 Development 2012-04-28
SharedUnixLibrary 1.12
VRPC RISC OS 4.39
Bug fix 229 has sorted some of the problems with top-bit set characters, but
not all of them.
#include <stdio.h>
#include <glob.h>
int main(int argc,char** argv) {
--argc;++argv;
glob_t file_list;
int err=glob(*argv,0,NULL,&file_list);
printf("err = %i\n",err);
printf("file_list->gl_pathc = %lu\n",file_list.gl_pathc);
for (size_t i=0;i<file_list.gl_pathc;++i) {
printf("%lu %s\n",i,file_list.gl_pathv[i]);
}
return 0;
}
With just these 3 files in a directory:
mem
m m hard space
mém
This is correct:
*test m*
err = 0
file_list->gl_pathc = 3
0 mem
1 m m hard space
2 mém
The rest are incorrect:
*test m m hard space
err = -3
file_list->gl_pathc = 0
*test mém
err = -3
file_list->gl_pathc = 0
*test "m m" normal space
err = 0
file_list->gl_pathc = 1
0 m m normal space
--
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: Conversion from SVN to Git
Am Samstag, den 28.04.2012, 13:55 +0200 schrieb Daniel Silverstone
<dsilvers@netsurf-browser.org>:
> supported and I
> am working on a simple client for platforms which currently do not
> support git,
> but I cannot guarantee it will be ready in time.
Maybe http://subgit.com/ is an option to allow svn to access the git
repository?
> If anyone has a *very* good reason for not doing this, speak up now.
> The
> following are not considered good reasons:
I'm fine with it, I just don't like the github artwork.
But I guess github server will not be used anyway.
Greets,
Ole
<dsilvers@netsurf-browser.org>:
> supported and I
> am working on a simple client for platforms which currently do not
> support git,
> but I cannot guarantee it will be ready in time.
Maybe http://subgit.com/ is an option to allow svn to access the git
repository?
> If anyone has a *very* good reason for not doing this, speak up now.
> The
> following are not considered good reasons:
I'm fine with it, I just don't like the github artwork.
But I guess github server will not be used anyway.
Greets,
Ole
Re: [gccsdk] GCC 4.1.2 Release 1 Native Compilation Segmentation Fault
On 25/04/12 19:20,Lee Noar <leenoar@sky.com> wrote:
>
> On 25/04/12 17:17, pdmiller@pdmiller1.plus.com wrote:
>> I've just installed GCC 4.1.2 release 1 onto my VRPC AdjustSA RO 6.20
>> system, including SharedUnixlib 1.12, and the latest !SharedLibs. I get a
>> segmentation fault when compiling certain c files. It looks like they are
>> greater than a certain size in some way. They compile ok with the previous
>> GCC release. I don't remember getting this error with the previous
>> release,
>> or having to do anything to increase a slot size, etc. My next slot is set
>> to 10240k. Have I missed or forgotten to do something, or is it a real
>> bug.
>
> Could you please post one of the offending files that will demonstrate
> the problem.
>
> Thanks,
> Lee.
Hmm, not the answer I was hoping for. I've now had some time to
investigate further and have discovered two things.
1. If I remove the -O2 compiler switch the code compiles successfully.
2. The code at the line GCC 4.12 reports when the failure occcurs is
if (!(s = (char *) mydesk_alloc_from_mwsdda(md,
mcd,
(int) strlen(pwd->stdwkbuffer) + 1)))
{
numwindows = i;
break;
}
If I reorganise the code as
ilen = strlen(pwd->stdwkbuffer);
ilen++;
s = (char *) mydesk_alloc_from_mwsdda(md,
mcd,
(int) ilen);
if (!s)
{
numwindows = i;
break;
}
where ilen is a size_t defined at the beginning of the function,
then the code compiles successfully - with the -O2 switch in the compiler
flags passed to GCC.
However, if I combine the length calculation to
ilen = strlen(pwd->stdwkbuffer) + 1;
the segmentation fault occurs, with GCC reporting the line above as the
point where the failure occurs.
I have some other calculations like this in my code and all are now
triggering the segmentation fault when I yse GCC 4.1.2 to compile it.
I have changed them all with a similar reorganisation of the code as here
and they all now compile ok with GCC 4.1.2, and using the -O2 switch.
For info: pwd is an external pointer to a structure allocated using
malloc, pwd->stdwkbuffer is a char * also allocated using malloc.
I have some other pieces of my program have code with similar calculatons
but don't trigger the segmentaton fault, e.g.
if ((tbuff = drw_alloc_tbuff(
(strlen(pwd->stdwkbuffer) + 1) * 2,
drw_stdwkbuff_tbuff)))
strcpy((drwimpc->incliblistfilename +
strlen(drwimpc->incliblistfilename) + 1),
pwd->wmessageout);
If you still need it I can send a zip file of a peprocessed C file
containing the problem code I described at the start of this email,
unfortunately unpreprocessed its 15000 lines long, preprocessed and zipped
its 115KB. If so, would you prefer it sent to your email address you used
to reply to this message. Please let me know.
Hope this helps.
Regards,
Pete Miller.
pdmiller@pdmiller1.plus.com
_______________________________________________
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 25/04/12 17:17, pdmiller@pdmiller1.plus.com wrote:
>> I've just installed GCC 4.1.2 release 1 onto my VRPC AdjustSA RO 6.20
>> system, including SharedUnixlib 1.12, and the latest !SharedLibs. I get a
>> segmentation fault when compiling certain c files. It looks like they are
>> greater than a certain size in some way. They compile ok with the previous
>> GCC release. I don't remember getting this error with the previous
>> release,
>> or having to do anything to increase a slot size, etc. My next slot is set
>> to 10240k. Have I missed or forgotten to do something, or is it a real
>> bug.
>
> Could you please post one of the offending files that will demonstrate
> the problem.
>
> Thanks,
> Lee.
Hmm, not the answer I was hoping for. I've now had some time to
investigate further and have discovered two things.
1. If I remove the -O2 compiler switch the code compiles successfully.
2. The code at the line GCC 4.12 reports when the failure occcurs is
if (!(s = (char *) mydesk_alloc_from_mwsdda(md,
mcd,
(int) strlen(pwd->stdwkbuffer) + 1)))
{
numwindows = i;
break;
}
If I reorganise the code as
ilen = strlen(pwd->stdwkbuffer);
ilen++;
s = (char *) mydesk_alloc_from_mwsdda(md,
mcd,
(int) ilen);
if (!s)
{
numwindows = i;
break;
}
where ilen is a size_t defined at the beginning of the function,
then the code compiles successfully - with the -O2 switch in the compiler
flags passed to GCC.
However, if I combine the length calculation to
ilen = strlen(pwd->stdwkbuffer) + 1;
the segmentation fault occurs, with GCC reporting the line above as the
point where the failure occurs.
I have some other calculations like this in my code and all are now
triggering the segmentation fault when I yse GCC 4.1.2 to compile it.
I have changed them all with a similar reorganisation of the code as here
and they all now compile ok with GCC 4.1.2, and using the -O2 switch.
For info: pwd is an external pointer to a structure allocated using
malloc, pwd->stdwkbuffer is a char * also allocated using malloc.
I have some other pieces of my program have code with similar calculatons
but don't trigger the segmentaton fault, e.g.
if ((tbuff = drw_alloc_tbuff(
(strlen(pwd->stdwkbuffer) + 1) * 2,
drw_stdwkbuff_tbuff)))
strcpy((drwimpc->incliblistfilename +
strlen(drwimpc->incliblistfilename) + 1),
pwd->wmessageout);
If you still need it I can send a zip file of a peprocessed C file
containing the problem code I described at the start of this email,
unfortunately unpreprocessed its 15000 lines long, preprocessed and zipped
its 115KB. If so, would you prefer it sent to your email address you used
to reply to this message. Please let me know.
Hope this helps.
Regards,
Pete Miller.
pdmiller@pdmiller1.plus.com
_______________________________________________
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
NetSurf 2.9 released
The NetSurf developers are happy to announce NetSurf 2.9. This release
contains many bug fixes and improvements.
It is available to download from http://www.netsurf-browser.org/
Binaries are available now for RISC OS, AmigaOS 4 and Atari systems.
We plan to make binaries for other platforms available soon.
NetSurf 2.9 contains many improvements over the previous release. The most
significant changes are new multi-tasking behaviour, optimised URL
handling, fetcher optimisations, cache optimisations, and faster CSS
selection.
A more detailed and complete list of changes is given below.
Core / All
----------
* Improved internal management of simultaneously occurring operations.
* Rewritten and streamlined URL handling.
* Improved handling of frames and iframes.
* Improved handling of min/max-width on replaced elements.
* Simplified layout object dimension calculations.
* Reduced memory usage in the fetch layer.
* Disabled extraneous fetch debug code when built without debugging.
* Optimised fetchers.
* Updated MIME sniff handling in accordance with evolution of spec.
* Optimised cache layer.
* Enabled yield and resumption of box tree construction.
* Improved resource handling.
* Added new support for favicons.
* Increased default memory cache size.
* Added about:imagecache status page.
* Optimised URL fragment handling.
* Made meta refresh handling more robust.
* Various minor table layout fixes.
* Cleaned up fetch callback API.
* New hotlist entries can be inserted into defined or selected folder.
* Enabled resizing of textarea widget.
* Fixed cookie expiration.
* Improved handling of CSS overflow scrollbars.
* Fixed caret position after deleting selection in textarea widget.
* Enabled mouse wheel scrolling of frames and other scrollable content.
* Improved handling of file drops, e.g. for HTML form file submission.
* Added the beginnings of a gstreamer binding.
* Fixed some content cache layer issues.
* Improved handling of deletion of nodes from treeviews.
* Added options to disable fetching of images.
* Simplified redraw API rendering options.
* Improved support for drag operations.
* Hubbub library (HTML parser):
+ Fixed xmlns attribute handling.
* LibCSS library (CSS parser and selection engine):
+ Avoid interning standard strings for every stylesheet, style
tag and style attribute.
+ Made significant optimisations to style selection.
+ Fixed case where font-family is unspecified in input CSS.
+ Added some support for @font-face.
+ Fixed !important on opacity property.
+ Added support for parsing CSS3 Multi-column layout properties.
RISC OS
-------
* Removed unused and broken plugin handler.
* Removed normalisation of user input URLs.
* Added support for external hotlist utilities.
* Improved signal handling.
* Improved keyboard input handling.
* Various fixes.
* Fixed Drawfile export not to show interactive features.
* Improved scroll event handling.
GTK-specific
------------
* Improved resource handling.
* Cleaned up handling of tabs.
* Made tab bar position configurable.
* Updated plotters to use Cairo surfaces throughout.
* Enabled search-as-you-type of page content.
* Fixed ~/.netsurf directory permissions.
AmigaOS-specific
----------------
* Improved mouse handling.
* Improved multi-tasking behaviour.
* Increased keyboard scroll speed.
* Better MIME type handling.
* Improved contextual menu handling.
* Enabled context menu for frames.
* Enabled context menu for plain text contents.
* Improved aspect ratio handling.
* Consolidated user file operations.
* Fixed scrolling issues.
* Improved resource handling.
* Improved tab bar handling.
* Improved drag handling.
* Improved font handling.
* Improved clipboard support.
Mac OS X-specific
-----------------
* Fixed build.
Atari-specific
--------------
* Added context menu.
* View source support.
* Use favicon when iconified.
* Removed unneeded frames handling code.
* Fixed rectangle plotter.
* Simplified status bar.
* Improved download window.
* Improved URL bar.
* Fixed conversion from local encoding to UTF-8.
* Improved scheduler.
* Added save page support.
* Added settings dialogue.
* Enabled view source feature.
* Added support for 8-bit displays.
Framebuffer-specific
--------------------
* Reduced excessive logging.
* Implemented RAM surfaces, instead of direct blitting.
* Fixed VNC surface.
* Enabled thumbnailing in local history view.
Also included are many smaller bug fixes, improvements and
documentation enhancements.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
contains many bug fixes and improvements.
It is available to download from http://www.netsurf-browser.org/
Binaries are available now for RISC OS, AmigaOS 4 and Atari systems.
We plan to make binaries for other platforms available soon.
NetSurf 2.9 contains many improvements over the previous release. The most
significant changes are new multi-tasking behaviour, optimised URL
handling, fetcher optimisations, cache optimisations, and faster CSS
selection.
A more detailed and complete list of changes is given below.
Core / All
----------
* Improved internal management of simultaneously occurring operations.
* Rewritten and streamlined URL handling.
* Improved handling of frames and iframes.
* Improved handling of min/max-width on replaced elements.
* Simplified layout object dimension calculations.
* Reduced memory usage in the fetch layer.
* Disabled extraneous fetch debug code when built without debugging.
* Optimised fetchers.
* Updated MIME sniff handling in accordance with evolution of spec.
* Optimised cache layer.
* Enabled yield and resumption of box tree construction.
* Improved resource handling.
* Added new support for favicons.
* Increased default memory cache size.
* Added about:imagecache status page.
* Optimised URL fragment handling.
* Made meta refresh handling more robust.
* Various minor table layout fixes.
* Cleaned up fetch callback API.
* New hotlist entries can be inserted into defined or selected folder.
* Enabled resizing of textarea widget.
* Fixed cookie expiration.
* Improved handling of CSS overflow scrollbars.
* Fixed caret position after deleting selection in textarea widget.
* Enabled mouse wheel scrolling of frames and other scrollable content.
* Improved handling of file drops, e.g. for HTML form file submission.
* Added the beginnings of a gstreamer binding.
* Fixed some content cache layer issues.
* Improved handling of deletion of nodes from treeviews.
* Added options to disable fetching of images.
* Simplified redraw API rendering options.
* Improved support for drag operations.
* Hubbub library (HTML parser):
+ Fixed xmlns attribute handling.
* LibCSS library (CSS parser and selection engine):
+ Avoid interning standard strings for every stylesheet, style
tag and style attribute.
+ Made significant optimisations to style selection.
+ Fixed case where font-family is unspecified in input CSS.
+ Added some support for @font-face.
+ Fixed !important on opacity property.
+ Added support for parsing CSS3 Multi-column layout properties.
RISC OS
-------
* Removed unused and broken plugin handler.
* Removed normalisation of user input URLs.
* Added support for external hotlist utilities.
* Improved signal handling.
* Improved keyboard input handling.
* Various fixes.
* Fixed Drawfile export not to show interactive features.
* Improved scroll event handling.
GTK-specific
------------
* Improved resource handling.
* Cleaned up handling of tabs.
* Made tab bar position configurable.
* Updated plotters to use Cairo surfaces throughout.
* Enabled search-as-you-type of page content.
* Fixed ~/.netsurf directory permissions.
AmigaOS-specific
----------------
* Improved mouse handling.
* Improved multi-tasking behaviour.
* Increased keyboard scroll speed.
* Better MIME type handling.
* Improved contextual menu handling.
* Enabled context menu for frames.
* Enabled context menu for plain text contents.
* Improved aspect ratio handling.
* Consolidated user file operations.
* Fixed scrolling issues.
* Improved resource handling.
* Improved tab bar handling.
* Improved drag handling.
* Improved font handling.
* Improved clipboard support.
Mac OS X-specific
-----------------
* Fixed build.
Atari-specific
--------------
* Added context menu.
* View source support.
* Use favicon when iconified.
* Removed unneeded frames handling code.
* Fixed rectangle plotter.
* Simplified status bar.
* Improved download window.
* Improved URL bar.
* Fixed conversion from local encoding to UTF-8.
* Improved scheduler.
* Added save page support.
* Added settings dialogue.
* Enabled view source feature.
* Added support for 8-bit displays.
Framebuffer-specific
--------------------
* Reduced excessive logging.
* Implemented RAM surfaces, instead of direct blitting.
* Fixed VNC surface.
* Enabled thumbnailing in local history view.
Also included are many smaller bug fixes, improvements and
documentation enhancements.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Conversion from SVN to Git
On Sat, 28 Apr 2012 12:55:33 +0100, Daniel Silverstone wrote:
> * Git doesn't work on my obscure $platform (We'd rather fix Git than
> hold off getting away from svn)
I'm not here to complain about the VCS you choose to use, but I am
interested to know why this change is happening.
I may be reading too much into your wording but it sounds like you're
not moving *towards* Git, but *away* from Subversion. I've used
Subversion for a long time and always got on pretty well with it so
I'd be fascinated to know what it is which makes it so abhorrent in
the eyes of the core Netsurf developers. Can you point me at the
discussion where this decision was made?
And why Git in particular. Clearly it's growing in popularity but
there are lots of other options. I'm guessing that the fact that it
is distributed is relevant but why not Arch, Mercurial, DARCS, Bazaar
or even SVK?
--
(\/)atthew
> * Git doesn't work on my obscure $platform (We'd rather fix Git than
> hold off getting away from svn)
I'm not here to complain about the VCS you choose to use, but I am
interested to know why this change is happening.
I may be reading too much into your wording but it sounds like you're
not moving *towards* Git, but *away* from Subversion. I've used
Subversion for a long time and always got on pretty well with it so
I'd be fascinated to know what it is which makes it so abhorrent in
the eyes of the core Netsurf developers. Can you point me at the
discussion where this decision was made?
And why Git in particular. Clearly it's growing in popularity but
there are lots of other options. I'm guessing that the fact that it
is distributed is relevant but why not Arch, Mercurial, DARCS, Bazaar
or even SVK?
--
(\/)atthew
Re: scrolling jerky
On Sun, Apr 29, 2012 at 01:15:50PM +0100, Roger Darlington wrote:
>
> So the conclusion might be:
> Put the scrolling back where it was before and not in the core ??
No, it would never be that.
B.
>
> So the conclusion might be:
> Put the scrolling back where it was before and not in the core ??
No, it would never be that.
B.
Re: scrolling jerky
On 27 Apr 2012, Chris Young wrote:
> On Fri, 27 Apr 2012 08:23:18 +0100, Roger Darlington wrote:
>> On 25 Apr 2012, Michael Drake wrote:
>>> In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
>>> Roger Darlington <rogerarm@freeuk.com> wrote:
>>
>>>> Scrolling very jerky on the vertical slider
>>
>>> Please see my response to your previous scrolling thread:
>>
>>> http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
>>
>>> Your google URL is the scrolling frames issue.
>>
>> Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
>> but there is still a very noticeable difference between scrolling the
>> two versions of the very same page (neither of which get anywhere near
>> 90MB it must be said...)
> Cache won't help, the issue is that "core" scrolls aren't optimised,
> so if you scroll a frame the entire contents of that frame will be
> redrawn - even if it is only scrolled a pixel. Conversely, if you
> scroll using the window scrollbar, the platform code handles the
> scroll. Usually the platform code is optimised, and will "shift" the
> area and just redraw the newly-exposed bit.
> Clearly NetSurf would benefit from some scrolling optimisation in the
> core, but I'm not sure if it is as easy as telling the frontend code
> to move a particular area and then redraw the newly exposed area.
> (not least because frontends don't currently have any concept of "move
> a particular area")
So the conclusion might be:
Put the scrolling back where it was before and not in the core ??
> Regards
> Chris
--
Cheers
Roger
Mortons Fork: Should it be held in the left hand?
> On Fri, 27 Apr 2012 08:23:18 +0100, Roger Darlington wrote:
>> On 25 Apr 2012, Michael Drake wrote:
>>> In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
>>> Roger Darlington <rogerarm@freeuk.com> wrote:
>>
>>>> Scrolling very jerky on the vertical slider
>>
>>> Please see my response to your previous scrolling thread:
>>
>>> http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
>>
>>> Your google URL is the scrolling frames issue.
>>
>> Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
>> but there is still a very noticeable difference between scrolling the
>> two versions of the very same page (neither of which get anywhere near
>> 90MB it must be said...)
> Cache won't help, the issue is that "core" scrolls aren't optimised,
> so if you scroll a frame the entire contents of that frame will be
> redrawn - even if it is only scrolled a pixel. Conversely, if you
> scroll using the window scrollbar, the platform code handles the
> scroll. Usually the platform code is optimised, and will "shift" the
> area and just redraw the newly-exposed bit.
> Clearly NetSurf would benefit from some scrolling optimisation in the
> core, but I'm not sure if it is as easy as telling the frontend code
> to move a particular area and then redraw the newly exposed area.
> (not least because frontends don't currently have any concept of "move
> a particular area")
So the conclusion might be:
Put the scrolling back where it was before and not in the core ??
> Regards
> Chris
--
Cheers
Roger
Mortons Fork: Should it be held in the left hand?
Re: scrolling jerky
On 27 Apr 2012, Chris Young wrote:
> On Fri, 27 Apr 2012 08:23:18 +0100, Roger Darlington wrote:
>> On 25 Apr 2012, Michael Drake wrote:
>>> In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
>>> Roger Darlington <rogerarm@freeuk.com> wrote:
>>
>>>> Scrolling very jerky on the vertical slider
>>
>>> Please see my response to your previous scrolling thread:
>>
>>> http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
>>
>>> Your google URL is the scrolling frames issue.
>>
>> Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
>> but there is still a very noticeable difference between scrolling the
>> two versions of the very same page (neither of which get anywhere near
>> 90MB it must be said...)
> Cache won't help, the issue is that "core" scrolls aren't optimised,
> so if you scroll a frame the entire contents of that frame will be
> redrawn - even if it is only scrolled a pixel. Conversely, if you
> scroll using the window scrollbar, the platform code handles the
> scroll. Usually the platform code is optimised, and will "shift" the
> area and just redraw the newly-exposed bit.
> Clearly NetSurf would benefit from some scrolling optimisation in the
> core, but I'm not sure if it is as easy as telling the frontend code
> to move a particular area and then redraw the newly exposed area.
> (not least because frontends don't currently have any concept of "move
> a particular area")
> Regards
> Chris
--
Cheers
Roger
"I suspect everyone, and yet, I suspect no-one" Inspector Cleuseau
> On Fri, 27 Apr 2012 08:23:18 +0100, Roger Darlington wrote:
>> On 25 Apr 2012, Michael Drake wrote:
>>> In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
>>> Roger Darlington <rogerarm@freeuk.com> wrote:
>>
>>>> Scrolling very jerky on the vertical slider
>>
>>> Please see my response to your previous scrolling thread:
>>
>>> http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
>>
>>> Your google URL is the scrolling frames issue.
>>
>> Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
>> but there is still a very noticeable difference between scrolling the
>> two versions of the very same page (neither of which get anywhere near
>> 90MB it must be said...)
> Cache won't help, the issue is that "core" scrolls aren't optimised,
> so if you scroll a frame the entire contents of that frame will be
> redrawn - even if it is only scrolled a pixel. Conversely, if you
> scroll using the window scrollbar, the platform code handles the
> scroll. Usually the platform code is optimised, and will "shift" the
> area and just redraw the newly-exposed bit.
> Clearly NetSurf would benefit from some scrolling optimisation in the
> core, but I'm not sure if it is as easy as telling the frontend code
> to move a particular area and then redraw the newly exposed area.
> (not least because frontends don't currently have any concept of "move
> a particular area")
> Regards
> Chris
--
Cheers
Roger
"I suspect everyone, and yet, I suspect no-one" Inspector Cleuseau
Saturday, 28 April 2012
Re: Conversion from SVN to Git
On 28/04/2012 18:40, Martin Bazley wrote:
> The following bytes were arranged on 28 Apr 2012 by Daniel Silverstone :
>
>> On Sunday July 1st we will be switching from the Subversion VCS to the Git
>> DVCS. I will be organising test repository copies in the coming couple of
>> weeks and we will be organising access control etc over the subsequent weeks.
>
> [snip]
>
> Will the netsurf-commits mailing list continue to work?
>
Why not?
Haiku did the same migration last year, so if you need hints on commit
hooks...
François.
> The following bytes were arranged on 28 Apr 2012 by Daniel Silverstone :
>
>> On Sunday July 1st we will be switching from the Subversion VCS to the Git
>> DVCS. I will be organising test repository copies in the coming couple of
>> weeks and we will be organising access control etc over the subsequent weeks.
>
> [snip]
>
> Will the netsurf-commits mailing list continue to work?
>
Why not?
Haiku did the same migration last year, so if you need hints on commit
hooks...
François.
[gccsdk] [Bug 229] GCC 4.1.2 Release 2 Dev: glob() ignores files with hardspace.
http://www.riscos.info/bugzilla3/show_bug.cgi?id=229
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from John Tytgat <John.Tytgat@aaug.net> 2012-04-28 10:08:07 PDT ---
Fixed with r5766 (trunk) and r5768 (branches/release_4_1_2).
--
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 #3 from John Tytgat <John.Tytgat@aaug.net> 2012-04-28 10:08:07 PDT ---
Fixed with r5766 (trunk) and r5768 (branches/release_4_1_2).
--
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: Conversion from SVN to Git
The following bytes were arranged on 28 Apr 2012 by Daniel Silverstone :
> On Sunday July 1st we will be switching from the Subversion VCS to the Git
> DVCS. I will be organising test repository copies in the coming couple of
> weeks and we will be organising access control etc over the subsequent weeks.
[snip]
Will the netsurf-commits mailing list continue to work?
--
__<^>__ === RISC OS is a work of art. Some people adore it, ===
/ _ _ \ === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive. ===
\_> <_/ ======================= Martin Bazley ===================
> On Sunday July 1st we will be switching from the Subversion VCS to the Git
> DVCS. I will be organising test repository copies in the coming couple of
> weeks and we will be organising access control etc over the subsequent weeks.
[snip]
Will the netsurf-commits mailing list continue to work?
--
__<^>__ === RISC OS is a work of art. Some people adore it, ===
/ _ _ \ === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive. ===
\_> <_/ ======================= Martin Bazley ===================
Re: Conversion from SVN to Git
On Sat, Apr 28, 2012 at 01:34:55PM +0100, Chris Young wrote:
> > If anyone has a *very* good reason for not doing this, speak up now.
>
> I don't have any particular objections, but I hope you're going to put
> together some sort of guide as how to clone the repository and push
> updates? From what I've heard, the way GIT manages pushes is not
> intuitive at all, and it is easy to screw up if you don't know exactly
> what you are doing (which I will freely admit is true in my case!)
Absolutely we'll have dev-guides written. Mostly to be sure *we* know how it
works.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> > If anyone has a *very* good reason for not doing this, speak up now.
>
> I don't have any particular objections, but I hope you're going to put
> together some sort of guide as how to clone the repository and push
> updates? From what I've heard, the way GIT manages pushes is not
> intuitive at all, and it is easy to screw up if you don't know exactly
> what you are doing (which I will freely admit is true in my case!)
Absolutely we'll have dev-guides written. Mostly to be sure *we* know how it
works.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: Conversion from SVN to Git
On Sat, 28 Apr 2012 12:55:33 +0100, Daniel Silverstone wrote:
> If anyone has a *very* good reason for not doing this, speak up now.
I don't have any particular objections, but I hope you're going to put
together some sort of guide as how to clone the repository and push
updates? From what I've heard, the way GIT manages pushes is not
intuitive at all, and it is easy to screw up if you don't know exactly
what you are doing (which I will freely admit is true in my case!)
Chris
> If anyone has a *very* good reason for not doing this, speak up now.
I don't have any particular objections, but I hope you're going to put
together some sort of guide as how to clone the repository and push
updates? From what I've heard, the way GIT manages pushes is not
intuitive at all, and it is easy to screw up if you don't know exactly
what you are doing (which I will freely admit is true in my case!)
Chris
Re: scrolling jerky
On Fri, 27 Apr 2012 18:27:32 +0100, Rob Kendrick wrote:
> I suspect rectangle-copy would be a fine addition to the plotter
> interface.
We'd need some sort of fallback to a redraw if the copy source area is
determined to be off-screen (or not copiable for some other reason).
Chris
> I suspect rectangle-copy would be a fine addition to the plotter
> interface.
We'd need some sort of fallback to a redraw if the copy source area is
determined to be off-screen (or not copiable for some other reason).
Chris
Conversion from SVN to Git
Hi,
On Sunday July 1st we will be switching from the Subversion VCS to the Git
DVCS. I will be organising test repository copies in the coming couple of
weeks and we will be organising access control etc over the subsequent weeks.
Everyone who wishes to push to the master repositories will need to have ssh
working with git. Anonymous clone with git:// protocol will be supported and I
am working on a simple client for platforms which currently do not support git,
but I cannot guarantee it will be ready in time.
If anyone has a *very* good reason for not doing this, speak up now. The
following are not considered good reasons:
* But I don't understand Git
* Waaah I hate Git
* Git doesn't work on my obscure $platform (We'd rather fix Git than hold off
getting away from svn)
Thanks,
Daniel.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
On Sunday July 1st we will be switching from the Subversion VCS to the Git
DVCS. I will be organising test repository copies in the coming couple of
weeks and we will be organising access control etc over the subsequent weeks.
Everyone who wishes to push to the master repositories will need to have ssh
working with git. Anonymous clone with git:// protocol will be supported and I
am working on a simple client for platforms which currently do not support git,
but I cannot guarantee it will be ready in time.
If anyone has a *very* good reason for not doing this, speak up now. The
following are not considered good reasons:
* But I don't understand Git
* Waaah I hate Git
* Git doesn't work on my obscure $platform (We'd rather fix Git than hold off
getting away from svn)
Thanks,
Daniel.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Friday, 27 April 2012
[gccsdk] Choices$Write, dotfiles, ~, ~/
Referring to gcc4/recipe/files/gcc/libunix/pwd/pwdread.c
The default for setting the home directory
home = getenv("Choices$Write");
returns Boot:Choices which then forces the following unix style
dotfile path to be issued as a RISC OS path (no good)
I am using the following in pwdread as a functional equivalent for
the intended path. It has to know the drive booted from so that if
the csd is changed to another HD it wont try to use that instead.
/* If not, try Boot$Dir to get the booted HD name and zero the
$ so the unix pathname of Choices can be appended */
if (!home)
home = getenv("Boot$Dir");
if (strtok(home, "$") != 0)
strcat(home, "$/!Boot/Choices");
This compiles and works, but I welcome corrections.
While on this topic, I'll suggest the possibility that maybe we
could use a subdir in Choices to accommodate the numerous dotfiles
that could clutter the Choices directory.
In the linux world they seem to be referred to as dotfiles so
perhaps that would be a suitable name for the subdir.
I think most setting files are dotfiles or dotdirs with dotfiles,
but it would mean anything else directed to ~ would be directed to
Choices/dotfiles also.
I think there are people using !UnixHome as a means but I thought
a while ago I read it was to be avoided in the future?
But secondly, using a default, allows ports like Bash and OpenSSH
to work out of the box seamlessly.
This is a different subject really, changes do not necessarily
affect each other.
I have noticed that my 10.04 distro does not recognise cd ~
but requires cd ~/
Bash on RISC OS is happy with cd ~ (1) so Iam guessing that Ubuntu
and maybe others adapt a modifier so that ~/ must be used to
get to the home directory contrary to other policy.
(1) Even though I have made this change to my Recipe's riscosify.c
if (in[0] == '~' && in[1] == '/')
{
char new_buffer[MAXPATHLEN];
const char *home =
#ifdef __TARGET_SCL__
getenv ("UnixEnv$HOME") ? : getenv ("HOME");
#else
__pwddefault ()->pw_dir;
The default for setting the home directory
home = getenv("Choices$Write");
returns Boot:Choices which then forces the following unix style
dotfile path to be issued as a RISC OS path (no good)
I am using the following in pwdread as a functional equivalent for
the intended path. It has to know the drive booted from so that if
the csd is changed to another HD it wont try to use that instead.
/* If not, try Boot$Dir to get the booted HD name and zero the
$ so the unix pathname of Choices can be appended */
if (!home)
home = getenv("Boot$Dir");
if (strtok(home, "$") != 0)
strcat(home, "$/!Boot/Choices");
This compiles and works, but I welcome corrections.
While on this topic, I'll suggest the possibility that maybe we
could use a subdir in Choices to accommodate the numerous dotfiles
that could clutter the Choices directory.
In the linux world they seem to be referred to as dotfiles so
perhaps that would be a suitable name for the subdir.
I think most setting files are dotfiles or dotdirs with dotfiles,
but it would mean anything else directed to ~ would be directed to
Choices/dotfiles also.
I think there are people using !UnixHome as a means but I thought
a while ago I read it was to be avoided in the future?
But secondly, using a default, allows ports like Bash and OpenSSH
to work out of the box seamlessly.
This is a different subject really, changes do not necessarily
affect each other.
I have noticed that my 10.04 distro does not recognise cd ~
but requires cd ~/
Bash on RISC OS is happy with cd ~ (1) so Iam guessing that Ubuntu
and maybe others adapt a modifier so that ~/ must be used to
get to the home directory contrary to other policy.
(1) Even though I have made this change to my Recipe's riscosify.c
if (in[0] == '~' && in[1] == '/')
{
char new_buffer[MAXPATHLEN];
const char *home =
#ifdef __TARGET_SCL__
getenv ("UnixEnv$HOME") ? : getenv ("HOME");
#else
__pwddefault ()->pw_dir;
Re: scrolling jerky
On 27/04/2012 19:27, Rob Kendrick wrote:
>> Clearly NetSurf would benefit from some scrolling optimisation in the
>> core, but I'm not sure if it is as easy as telling the frontend code
>> to move a particular area and then redraw the newly exposed area.
>> (not least because frontends don't currently have any concept of "move
>> a particular area")
>
> I suspect rectangle-copy would be a fine addition to the plotter
> interface.
+1
We have BView::CopyBits() in Haiku to do this.
François.
>> Clearly NetSurf would benefit from some scrolling optimisation in the
>> core, but I'm not sure if it is as easy as telling the frontend code
>> to move a particular area and then redraw the newly exposed area.
>> (not least because frontends don't currently have any concept of "move
>> a particular area")
>
> I suspect rectangle-copy would be a fine addition to the plotter
> interface.
+1
We have BView::CopyBits() in Haiku to do this.
François.
Re: Nervous tick
In article <a647008752.martin@blueyonder.co.uk>, Martin
Bazley <martin.bazley@blueyonder.co.uk> wrote:
> Everyone seeing the flickering is using a real StrongARM
> RiscPC or similar. Everyone not seeing the flickering is
> using an Iyonix or better, or StrongARM VRPC (which has
> an option to go much faster than a real StrongARM).
Well, I tried the link and noticed no flicker, but I use a
release version, 2.8.
*Real* RPC, RO 4.02, 64M RAM
--
Russell Hafter - Mailing Lists
rh.lists@phone.coop
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>
(NB This link needs Firefox to work)
Bazley <martin.bazley@blueyonder.co.uk> wrote:
> Everyone seeing the flickering is using a real StrongARM
> RiscPC or similar. Everyone not seeing the flickering is
> using an Iyonix or better, or StrongARM VRPC (which has
> an option to go much faster than a real StrongARM).
Well, I tried the link and noticed no flicker, but I use a
release version, 2.8.
*Real* RPC, RO 4.02, 64M RAM
--
Russell Hafter - Mailing Lists
rh.lists@phone.coop
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>
(NB This link needs Firefox to work)
Wakefield prep
I cannot find any stock of CD-R singles, alas. Apologies for the
disorganisation; I should have checked and ordered some replacement
stock long before now.
I do, however, have these:
- 50x full-size CD-Rs.
- A metric buttload of CD single laser labels.
- A box of translucent CD cases donated to us a few years
ago.
- A USB-attached CD-RW drive.
- An A9Home with an OS of unknown state, complete with
original PSU and mouse, but no PS/2 keyboard for it.
- A 4:3 LCD monitor (I can't face digging behind my desk
at the moment to detach the larger 16:9 Hyundais I
normally bring.)
- A chauffeur with damaged fingers who may not be able to
carry me to the show in his find chariot in any case.
- Far too much to get done :-/
Hopefully Daniel will know if he'll be able to drive later this
evening. If he is, I'll laser-print the CD labels: they'll look
a bit odd on full-size discs, but meh :)
If anybody has any stock of CD-R singles, it might be nice to
bring them along.
B.
disorganisation; I should have checked and ordered some replacement
stock long before now.
I do, however, have these:
- 50x full-size CD-Rs.
- A metric buttload of CD single laser labels.
- A box of translucent CD cases donated to us a few years
ago.
- A USB-attached CD-RW drive.
- An A9Home with an OS of unknown state, complete with
original PSU and mouse, but no PS/2 keyboard for it.
- A 4:3 LCD monitor (I can't face digging behind my desk
at the moment to detach the larger 16:9 Hyundais I
normally bring.)
- A chauffeur with damaged fingers who may not be able to
carry me to the show in his find chariot in any case.
- Far too much to get done :-/
Hopefully Daniel will know if he'll be able to drive later this
evening. If he is, I'll laser-print the CD labels: they'll look
a bit odd on full-size discs, but meh :)
If anybody has any stock of CD-R singles, it might be nice to
bring them along.
B.
Re: scrolling jerky
On Fri, Apr 27, 2012 at 05:59:12PM +0100, Chris Young wrote:
> Cache won't help, the issue is that "core" scrolls aren't optimised,
> so if you scroll a frame the entire contents of that frame will be
> redrawn - even if it is only scrolled a pixel. Conversely, if you
> scroll using the window scrollbar, the platform code handles the
> scroll. Usually the platform code is optimised, and will "shift" the
> area and just redraw the newly-exposed bit.
>
> Clearly NetSurf would benefit from some scrolling optimisation in the
> core, but I'm not sure if it is as easy as telling the frontend code
> to move a particular area and then redraw the newly exposed area.
> (not least because frontends don't currently have any concept of "move
> a particular area")
I suspect rectangle-copy would be a fine addition to the plotter
interface.
B.
> Cache won't help, the issue is that "core" scrolls aren't optimised,
> so if you scroll a frame the entire contents of that frame will be
> redrawn - even if it is only scrolled a pixel. Conversely, if you
> scroll using the window scrollbar, the platform code handles the
> scroll. Usually the platform code is optimised, and will "shift" the
> area and just redraw the newly-exposed bit.
>
> Clearly NetSurf would benefit from some scrolling optimisation in the
> core, but I'm not sure if it is as easy as telling the frontend code
> to move a particular area and then redraw the newly exposed area.
> (not least because frontends don't currently have any concept of "move
> a particular area")
I suspect rectangle-copy would be a fine addition to the plotter
interface.
B.
Re: scrolling jerky
On Fri, 27 Apr 2012 08:23:18 +0100, Roger Darlington wrote:
> On 25 Apr 2012, Michael Drake wrote:
> > In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
> > Roger Darlington <rogerarm@freeuk.com> wrote:
>
> >> Scrolling very jerky on the vertical slider
>
> > Please see my response to your previous scrolling thread:
>
> > http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
>
> > Your google URL is the scrolling frames issue.
>
> Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
> but there is still a very noticeable difference between scrolling the
> two versions of the very same page (neither of which get anywhere near
> 90MB it must be said...)
Cache won't help, the issue is that "core" scrolls aren't optimised,
so if you scroll a frame the entire contents of that frame will be
redrawn - even if it is only scrolled a pixel. Conversely, if you
scroll using the window scrollbar, the platform code handles the
scroll. Usually the platform code is optimised, and will "shift" the
area and just redraw the newly-exposed bit.
Clearly NetSurf would benefit from some scrolling optimisation in the
core, but I'm not sure if it is as easy as telling the frontend code
to move a particular area and then redraw the newly exposed area.
(not least because frontends don't currently have any concept of "move
a particular area")
Regards
Chris
> On 25 Apr 2012, Michael Drake wrote:
> > In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
> > Roger Darlington <rogerarm@freeuk.com> wrote:
>
> >> Scrolling very jerky on the vertical slider
>
> > Please see my response to your previous scrolling thread:
>
> > http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
>
> > Your google URL is the scrolling frames issue.
>
> Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
> but there is still a very noticeable difference between scrolling the
> two versions of the very same page (neither of which get anywhere near
> 90MB it must be said...)
Cache won't help, the issue is that "core" scrolls aren't optimised,
so if you scroll a frame the entire contents of that frame will be
redrawn - even if it is only scrolled a pixel. Conversely, if you
scroll using the window scrollbar, the platform code handles the
scroll. Usually the platform code is optimised, and will "shift" the
area and just redraw the newly-exposed bit.
Clearly NetSurf would benefit from some scrolling optimisation in the
core, but I'm not sure if it is as easy as telling the frontend code
to move a particular area and then redraw the newly exposed area.
(not least because frontends don't currently have any concept of "move
a particular area")
Regards
Chris
Re: Nervous tick
In article <a647008752.martin@blueyonder.co.uk>,
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> Therefore, the hourglass problem is caused by your processor not being
> fast enough to process whatever it is that page is doing.
Well, yes, but we aim to support really slow systems.
You can reproduce it on an Iyonix. If you go to 256 colours with error
diffused bitmaps, scale the page to 300% or so and fill a 1680x1050 screen
with a NetSurf window showing just that image, then you get the pointer
flicker as reported. (Assuming animations are enabled.)
The issue isn't processor speed but a NetSurf bug. We shouldn't be
redrawing the JPEG over and over but we are because behind it is an
animated throbber GIF, meant to show the image is loading before it loads.
The animation is still there when the page is fully loaded, and it still
requests that area to be redrawn.
We need to avoid redraw requests from obscured content.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> Therefore, the hourglass problem is caused by your processor not being
> fast enough to process whatever it is that page is doing.
Well, yes, but we aim to support really slow systems.
You can reproduce it on an Iyonix. If you go to 256 colours with error
diffused bitmaps, scale the page to 300% or so and fill a 1680x1050 screen
with a NetSurf window showing just that image, then you get the pointer
flicker as reported. (Assuming animations are enabled.)
The issue isn't processor speed but a NetSurf bug. We shouldn't be
redrawing the JPEG over and over but we are because behind it is an
animated throbber GIF, meant to show the image is loading before it loads.
The animation is still there when the page is fully loaded, and it still
requests that area to be redrawn.
We need to avoid redraw requests from obscured content.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Nervous tick
The following bytes were arranged on 26 Apr 2012 by Brian Jordan :
> In article <52869aceb1dhwild@talktalk.net>, David H Wild
> <dhwild@talktalk.net> wrote:
> >
>
> [Snip]
>
> > It does it here on my RPC 6.20 with r13571 as long as the picture is on
> > the screen. Moving the page so that the picture is off the display
> > stops the flicker but moving it back restarts the flickering.
>
> Cat-> pigeons
>
> On my emulated machine (details in sig) and NetSurf r13571 I see no
> evidence of this flickering, just the pointing hand.
Can I just voice what seems to me to be the most screamingly obvious
theory?
Everyone seeing the flickering is using a real StrongARM RiscPC or
similar. Everyone not seeing the flickering is using an Iyonix or
better, or StrongARM VRPC (which has an option to go much faster than a
real StrongARM).
Therefore, the hourglass problem is caused by your processor not being
fast enough to process whatever it is that page is doing.
(PS: I don't see it on this Iyonix either.)
--
__<^>__ === RISC OS is a work of art. Some people adore it, ===
/ _ _ \ === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive. ===
\_> <_/ ======================= Martin Bazley ===================
> In article <52869aceb1dhwild@talktalk.net>, David H Wild
> <dhwild@talktalk.net> wrote:
> >
>
> [Snip]
>
> > It does it here on my RPC 6.20 with r13571 as long as the picture is on
> > the screen. Moving the page so that the picture is off the display
> > stops the flicker but moving it back restarts the flickering.
>
> Cat-> pigeons
>
> On my emulated machine (details in sig) and NetSurf r13571 I see no
> evidence of this flickering, just the pointing hand.
Can I just voice what seems to me to be the most screamingly obvious
theory?
Everyone seeing the flickering is using a real StrongARM RiscPC or
similar. Everyone not seeing the flickering is using an Iyonix or
better, or StrongARM VRPC (which has an option to go much faster than a
real StrongARM).
Therefore, the hourglass problem is caused by your processor not being
fast enough to process whatever it is that page is doing.
(PS: I don't see it on this Iyonix either.)
--
__<^>__ === RISC OS is a work of art. Some people adore it, ===
/ _ _ \ === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive. ===
\_> <_/ ======================= Martin Bazley ===================
[gccsdk] [Bug 230] New: Attempting to compile some C files produces "internal compiler error: Unknown signal"
http://www.riscos.info/bugzilla3/show_bug.cgi?id=230
Summary: Attempting to compile some C files produces "internal
compiler error: Unknown signal"
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: major
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: belles@internode.on.net
Estimated Hours: 0.0
Created attachment 82
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=82
Zip archive containing Taskwindow output and preprocessed source
This fault was found with GCCSDK GCC 4.6.4 Release 1 Development version 4.6.4
20120423 (prerelease) running on Iyonix and BeagleBoard with RISC OS 5.18.
As per the crash report, the attached zip archive contains Taskwindow output
and a preprocessed source that produced the fault. If a file produces the
fault, it does so consistently. I have not found a work-around.
--
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: Attempting to compile some C files produces "internal
compiler error: Unknown signal"
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: major
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: belles@internode.on.net
Estimated Hours: 0.0
Created attachment 82
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=82
Zip archive containing Taskwindow output and preprocessed source
This fault was found with GCCSDK GCC 4.6.4 Release 1 Development version 4.6.4
20120423 (prerelease) running on Iyonix and BeagleBoard with RISC OS 5.18.
As per the crash report, the attached zip archive contains Taskwindow output
and a preprocessed source that produced the fault. If a file produces the
fault, it does so consistently. I have not found a work-around.
--
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 229] GCC 4.1.2 Release 2 Dev: glob() ignores files with hardspace.
http://www.riscos.info/bugzilla3/show_bug.cgi?id=229
--- Comment #2 from Duncan Moore <duncan_moore@ntlworld.com> 2012-04-27 03:47:34 PDT ---
What I wrote was ambiguous. Just to make clear, the hardspace was in the
filenames of files in the current directory, not in the directory name itself.
So for these 3 files in a directory:
m m This has a hardspace in the middle
mem
mém This has an e acute in the middle
With 4.1.2 Release 2 Development, the test program gives:
*test
err = 0
file_list->gl_pathc = 1
0 mem
This does not happen with gcc 4.1.2 Release 1 Dev of Jan 2011 (NB this is the
version dated Jan 2011, not the Mar 2012 version with the same name!). This
gives:
*test
err = 0
file_list->gl_pathc = 3
0 mem
1 m m
2 mém
Exactly the same happens on all of HostFS, RAM, Mem (!Memphis), ArcFS and CDFS
i.e. current version fails, older versions work.
--
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: scrolling jerky
On 25 Apr 2012, Michael Drake wrote:
> In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
> Roger Darlington <rogerarm@freeuk.com> wrote:
>> Scrolling very jerky on the vertical slider
> Please see my response to your previous scrolling thread:
> http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
> Your google URL is the scrolling frames issue.
Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
but there is still a very noticeable difference between scrolling the
two versions of the very same page (neither of which get anywhere near
90MB it must be said...)
--
Cheers
Roger
Never repeat a measurement if you want the same answer
> In article <be1b188652.rogerarm@rogerarm.freeuk.com>,
> Roger Darlington <rogerarm@freeuk.com> wrote:
>> Scrolling very jerky on the vertical slider
> Please see my response to your previous scrolling thread:
> http://www.mail-archive.com/netsurf-users@netsurf-browser.org/msg03976.html
> Your google URL is the scrolling frames issue.
Thanks for that Michael. I have increased the Cache from 20MB to 90MB,
but there is still a very noticeable difference between scrolling the
two versions of the very same page (neither of which get anywhere near
90MB it must be said...)
--
Cheers
Roger
Never repeat a measurement if you want the same answer
Thursday, 26 April 2012
Re: Nervous tick
Hi,
I'm running VARPC with RISC OS Adjust 4.39 using the StrongARM emulation and NetSurf r13571. No Problems. Pointer behaves exactly as expected.
Alan
On Fri, 27 Apr 2012 06:42:23 +1200, Dave Higton <davehigton@dsl.pipex.com> wrote:
> In message <86a88c8652.ricp@user.minijem.plus.com>
> Richard Porter <ricp@minijem.plus.com> wrote:
>
>> On 26 Apr 2012 Tony Moore wrote:
>>
>> > On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>>
>> >> When Netsurf is displaying the following page and others on the same
>> >> site the pointer starts flickering 2 or 3 times a second between a
>> >> pointing hand and an hour glass.
>> >>
>> >> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
>> >> ieving-more/
>>
>> > [snip]
>>
>> >> Currently using r13534.
>>
>> > No problem here with r13571
>>
>> Still doing it for me now with r13571
>
> No such problem for me with r13571.
>
> Dave
>
I'm running VARPC with RISC OS Adjust 4.39 using the StrongARM emulation and NetSurf r13571. No Problems. Pointer behaves exactly as expected.
Alan
On Fri, 27 Apr 2012 06:42:23 +1200, Dave Higton <davehigton@dsl.pipex.com> wrote:
> In message <86a88c8652.ricp@user.minijem.plus.com>
> Richard Porter <ricp@minijem.plus.com> wrote:
>
>> On 26 Apr 2012 Tony Moore wrote:
>>
>> > On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>>
>> >> When Netsurf is displaying the following page and others on the same
>> >> site the pointer starts flickering 2 or 3 times a second between a
>> >> pointing hand and an hour glass.
>> >>
>> >> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
>> >> ieving-more/
>>
>> > [snip]
>>
>> >> Currently using r13534.
>>
>> > No problem here with r13571
>>
>> Still doing it for me now with r13571
>
> No such problem for me with r13571.
>
> Dave
>
Re: Nervous tick
On 26 Apr 2012 Michael Drake wrote:
> In article <5286a279dbdhwild@talktalk.net>,
> David H Wild <dhwild@talktalk.net> wrote:
>>> David/Richard, what's your memory cache size set to?
>> 6.4 meg.
> Could you retry after increasing it to 20 MB or so?
No difference. Brian's fixed page is OK though.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> In article <5286a279dbdhwild@talktalk.net>,
> David H Wild <dhwild@talktalk.net> wrote:
>>> David/Richard, what's your memory cache size set to?
>> 6.4 meg.
> Could you retry after increasing it to 20 MB or so?
No difference. Brian's fixed page is OK though.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: Nervous tick
On 26 Apr 2012 Michael Drake wrote:
> In article <52869aceb1dhwild@talktalk.net>,
> David H Wild <dhwild@talktalk.net> wrote:
>> It does it here on my RPC 6.20 with r13571 as long as the picture is on
>> the screen. Moving the page so that the picture is off the display stops
>> the flicker but moving it back restarts the flickering.
> I don't get this problem here (RO5). Richard, are you on RO6 too?
Yes. (RPC with vPod)
> David/Richard, what's your memory cache size set to?
> (NetSurf iconbar menu, Choices.... Cache, Size)
5MB.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> In article <52869aceb1dhwild@talktalk.net>,
> David H Wild <dhwild@talktalk.net> wrote:
>> It does it here on my RPC 6.20 with r13571 as long as the picture is on
>> the screen. Moving the page so that the picture is off the display stops
>> the flicker but moving it back restarts the flickering.
> I don't get this problem here (RO5). Richard, are you on RO6 too?
Yes. (RPC with vPod)
> David/Richard, what's your memory cache size set to?
> (NetSurf iconbar menu, Choices.... Cache, Size)
5MB.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
[gccsdk] [Bug 229] GCC 4.1.2 Release 2 Dev: glob() ignores files with hardspace.
http://www.riscos.info/bugzilla3/show_bug.cgi?id=229
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2012-04-26 14:35:09 PDT ---
I can't reproduce this using RO6 on RPC (tried hard space and accented
characters for cwd).
It wouldn't surprise me if this is VRPC HostFS specific. Could you try this
using RAMFS directory as cwd ?
--
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> 2012-04-26 14:35:09 PDT ---
I can't reproduce this using RO6 on RPC (tried hard space and accented
characters for cwd).
It wouldn't surprise me if this is VRPC HostFS specific. Could you try this
using RAMFS directory as cwd ?
--
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] GCC 4.1.2 release 1 package won't upgrade from theprevious version
In message <SNT136-ds15802E26036002687CED09F0240@phx.gbl>
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> John Tytgat wrote on Wednesday, April 25, 2012:
>
> > Are you actually saying RiscPkg/PackMan isn't able to deal with filename
> > case changes between two versions of a package ?
>
> Yes I am saying that. The shared back-end (libpkg) to both versions uses
> an exact match to figure out which files it can overwrite during an upgrade
> so sees them as different files, but they won't be on the disc.
Naively I would have thought that an upgrade would be throwing away the
old !GCC application and installing the new !GCC copy. Why does it need
to take the file structure inside the application into account ?
> > If so, any chance to get
> > this fixed in RiscPkg/PackMan itself ?
>
> As it's difficult for you to change, I will email the author of libpkg to
> see if he can get it changed.
Yes please.
> Do you know if it is safe to assume that RISC OS filenames are not
> case sensitive?
I don't think you can assume that. It is at the discretion of the specific
FS. E.g. Sunfish isn't.
BTW, I know that FileSwitch happens to cache file info caseinsensitive,
at least for old versions of RISC OS, I don't know what the current
situation is. This is wrong IMHO. So if you write file 'FOO' and check
for the presence of 'foo' you might get a yes answer, even on caseinsensitve
FS. Probably a test like : create 'FOO', try to delete 'foo' and see if
that results in an error (if so, delete 'FOO').
> In the meantime people will need to uninstall GCC4 and then install it
> again.
>
> I was hoping you had the files on a disc somewhere still so you could
> just rename that one file and rebuild the one package.
If it would be just that, I would just have done this. ;-(
> Is this possible for the current release? If not, would it be OK with
> you if I rebuilt a new version of the package from your version with
> the one files case changed?
Sure feel free. Thanks for the offer.
> I will also pursue what can be done with libpkg to see the same
> problem doesn't occur in a future release.
Excellent.
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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 Wednesday, April 25, 2012:
>
> > Are you actually saying RiscPkg/PackMan isn't able to deal with filename
> > case changes between two versions of a package ?
>
> Yes I am saying that. The shared back-end (libpkg) to both versions uses
> an exact match to figure out which files it can overwrite during an upgrade
> so sees them as different files, but they won't be on the disc.
Naively I would have thought that an upgrade would be throwing away the
old !GCC application and installing the new !GCC copy. Why does it need
to take the file structure inside the application into account ?
> > If so, any chance to get
> > this fixed in RiscPkg/PackMan itself ?
>
> As it's difficult for you to change, I will email the author of libpkg to
> see if he can get it changed.
Yes please.
> Do you know if it is safe to assume that RISC OS filenames are not
> case sensitive?
I don't think you can assume that. It is at the discretion of the specific
FS. E.g. Sunfish isn't.
BTW, I know that FileSwitch happens to cache file info caseinsensitive,
at least for old versions of RISC OS, I don't know what the current
situation is. This is wrong IMHO. So if you write file 'FOO' and check
for the presence of 'foo' you might get a yes answer, even on caseinsensitve
FS. Probably a test like : create 'FOO', try to delete 'foo' and see if
that results in an error (if so, delete 'FOO').
> In the meantime people will need to uninstall GCC4 and then install it
> again.
>
> I was hoping you had the files on a disc somewhere still so you could
> just rename that one file and rebuild the one package.
If it would be just that, I would just have done this. ;-(
> Is this possible for the current release? If not, would it be OK with
> you if I rebuilt a new version of the package from your version with
> the one files case changed?
Sure feel free. Thanks for the offer.
> I will also pursue what can be done with libpkg to see the same
> problem doesn't occur in a future release.
Excellent.
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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 228] SUL 1.12: system()/exec*() ignoring aliases of existing non-module commands.
http://www.riscos.info/bugzilla3/show_bug.cgi?id=228
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2012-04-26 14:17:18 PDT ---
It boils down to an alias not having a priority over an existing file
executable.
This is a consequence of the fix r5025
(http://www.riscos.info/websvn/listing.php?repname=gccsdk&rev=5025). I don't
think that fix is wrong but it looks like an existence check on
"Alias$<sul_exec argument>" is missing. If that alias exists, there should no
canonicalization being done.
--
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 |ASSIGNED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2012-04-26 14:17:18 PDT ---
It boils down to an alias not having a priority over an existing file
executable.
This is a consequence of the fix r5025
(http://www.riscos.info/websvn/listing.php?repname=gccsdk&rev=5025). I don't
think that fix is wrong but it looks like an existence check on
"Alias$<sul_exec argument>" is missing. If that alias exists, there should no
canonicalization being done.
--
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: Nervous tick
In article <5286a279dbdhwild@talktalk.net>,
David H Wild <dhwild@talktalk.net> wrote:
> > David/Richard, what's your memory cache size set to?
> 6.4 meg.
Could you retry after increasing it to 20 MB or so?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
David H Wild <dhwild@talktalk.net> wrote:
> > David/Richard, what's your memory cache size set to?
> 6.4 meg.
Could you retry after increasing it to 20 MB or so?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Nervous tick
In article <52869f2d30tlsa@netsurf-browser.org>, Michael Drake
<tlsa@netsurf-browser.org> wrote:
> > It does it here on my RPC 6.20 with r13571 as long as the picture is
> > on the screen. Moving the page so that the picture is off the display
> > stops the flicker but moving it back restarts the flickering.
> I don't get this problem here (RO5). Richard, are you on RO6 too?
> David/Richard, what's your memory cache size set to?
6.4 meg.
--
David Wild using RISC OS on broadband
www.davidhwild.me.uk
<tlsa@netsurf-browser.org> wrote:
> > It does it here on my RPC 6.20 with r13571 as long as the picture is
> > on the screen. Moving the page so that the picture is off the display
> > stops the flicker but moving it back restarts the flickering.
> I don't get this problem here (RO5). Richard, are you on RO6 too?
> David/Richard, what's your memory cache size set to?
6.4 meg.
--
David Wild using RISC OS on broadband
www.davidhwild.me.uk
Re: Nervous tick
In article <52869aceb1dhwild@talktalk.net>,
David H Wild <dhwild@talktalk.net> wrote:
> It does it here on my RPC 6.20 with r13571 as long as the picture is on
> the screen. Moving the page so that the picture is off the display stops
> the flicker but moving it back restarts the flickering.
I don't get this problem here (RO5). Richard, are you on RO6 too?
David/Richard, what's your memory cache size set to?
(NetSurf iconbar menu, Choices.... Cache, Size)
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
David H Wild <dhwild@talktalk.net> wrote:
> It does it here on my RPC 6.20 with r13571 as long as the picture is on
> the screen. Moving the page so that the picture is off the display stops
> the flicker but moving it back restarts the flickering.
I don't get this problem here (RO5). Richard, are you on RO6 too?
David/Richard, what's your memory cache size set to?
(NetSurf iconbar menu, Choices.... Cache, Size)
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Nervous tick
In article <52869aceb1dhwild@talktalk.net>, David H Wild
<dhwild@talktalk.net> wrote:
>
[Snip]
> It does it here on my RPC 6.20 with r13571 as long as the picture is on
> the screen. Moving the page so that the picture is off the display
> stops the flicker but moving it back restarts the flickering.
Cat-> pigeons
On my emulated machine (details in sig) and NetSurf r13571 I see no
evidence of this flickering, just the pointing hand. The problem seems to
be that the picture is part of a link (on PC Firefox clicking on it
causes an enlarged version of the picture to cover the underlying page)
but there is a missing </span> in the html. After doing a "Full save" on
the page and inserting the </span> appropriately the effect is quite
different; when the image is selected the picture appears in NetSurf, not
on the same page as in Firefox but in a new page. As I didn't see the tic
in the first place I can't confirm whether this has made it go away.
The corrected full save is in
www.btinternet.com/~brian.jordan9/netsurf/page.zip if you want to give it
a try.
Brian
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA
RISC OS 6.20
_____________________________________________________________________
<dhwild@talktalk.net> wrote:
>
[Snip]
> It does it here on my RPC 6.20 with r13571 as long as the picture is on
> the screen. Moving the page so that the picture is off the display
> stops the flicker but moving it back restarts the flickering.
Cat-> pigeons
On my emulated machine (details in sig) and NetSurf r13571 I see no
evidence of this flickering, just the pointing hand. The problem seems to
be that the picture is part of a link (on PC Firefox clicking on it
causes an enlarged version of the picture to cover the underlying page)
but there is a missing </span> in the html. After doing a "Full save" on
the page and inserting the </span> appropriately the effect is quite
different; when the image is selected the picture appears in NetSurf, not
on the same page as in Firefox but in a new page. As I didn't see the tic
in the first place I can't confirm whether this has made it go away.
The corrected full save is in
www.btinternet.com/~brian.jordan9/netsurf/page.zip if you want to give it
a try.
Brian
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA
RISC OS 6.20
_____________________________________________________________________
Re: Nervous tick
In article <df6b988652.davehigton@dsl.pipex.com>,
Dave Higton <davehigton@dsl.pipex.com> wrote:
> > >> When Netsurf is displaying the following page and others on the same
> > >> site the pointer starts flickering 2 or 3 times a second between a
> > >> pointing hand and an hour glass.
> > >>
> > >> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
> > >> ieving-more/
> >
> > > [snip]
> >
> > >> Currently using r13534.
> >
> > > No problem here with r13571
> >
> > Still doing it for me now with r13571
> No such problem for me with r13571.
It does it here on my RPC 6.20 with r13571 as long as the picture is on the
screen. Moving the page so that the picture is off the display stops the
flicker but moving it back restarts the flickering.
--
David Wild using RISC OS on broadband
www.davidhwild.me.uk
Dave Higton <davehigton@dsl.pipex.com> wrote:
> > >> When Netsurf is displaying the following page and others on the same
> > >> site the pointer starts flickering 2 or 3 times a second between a
> > >> pointing hand and an hour glass.
> > >>
> > >> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
> > >> ieving-more/
> >
> > > [snip]
> >
> > >> Currently using r13534.
> >
> > > No problem here with r13571
> >
> > Still doing it for me now with r13571
> No such problem for me with r13571.
It does it here on my RPC 6.20 with r13571 as long as the picture is on the
screen. Moving the page so that the picture is off the display stops the
flicker but moving it back restarts the flickering.
--
David Wild using RISC OS on broadband
www.davidhwild.me.uk
Re: Nervous tick
On 26 Apr 2012 Dave Higton <davehigton@dsl.pipex.com> wrote:
> In message <86a88c8652.ricp@user.minijem.plus.com>
> Richard Porter <ricp@minijem.plus.com> wrote:
>> On 26 Apr 2012 Tony Moore wrote:
>>
>>> On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>>
>>>> When Netsurf is displaying the following page and others on the same
>>>> site the pointer starts flickering 2 or 3 times a second between a
>>>> pointing hand and an hour glass.
>>>>
>>>> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
>>>> ieving-more/
>>
>>> [snip]
>>
>>>> Currently using r13534.
>>
>>> No problem here with r13571
>>
>> Still doing it for me now with r13571
> No such problem for me with r13571.
If you look at at that page in Windows Firefox the top bit looks a bit
different. I have neither the expertise, nor at the moment the time,
to explore that any further, but perhaps an expert among you might
find a clue that way?
With best wishes,
Peter.
--
Peter \ / zfc Hf \ Prestbury, Cheltenham, Glos. GL52
and \/ __ __ \ England.
family / / \ | | |\ | / _ \ http://pnyoung.orpheusweb.co.uk
/ \__/ \_/ | \| \__/ \______________ pnyoung@ormail.co.uk
> In message <86a88c8652.ricp@user.minijem.plus.com>
> Richard Porter <ricp@minijem.plus.com> wrote:
>> On 26 Apr 2012 Tony Moore wrote:
>>
>>> On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>>
>>>> When Netsurf is displaying the following page and others on the same
>>>> site the pointer starts flickering 2 or 3 times a second between a
>>>> pointing hand and an hour glass.
>>>>
>>>> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
>>>> ieving-more/
>>
>>> [snip]
>>
>>>> Currently using r13534.
>>
>>> No problem here with r13571
>>
>> Still doing it for me now with r13571
> No such problem for me with r13571.
If you look at at that page in Windows Firefox the top bit looks a bit
different. I have neither the expertise, nor at the moment the time,
to explore that any further, but perhaps an expert among you might
find a clue that way?
With best wishes,
Peter.
--
Peter \ / zfc Hf \ Prestbury, Cheltenham, Glos. GL52
and \/ __ __ \ England.
family / / \ | | |\ | / _ \ http://pnyoung.orpheusweb.co.uk
/ \__/ \_/ | \| \__/ \______________ pnyoung@ormail.co.uk
Re: Nervous tick
On 26 Apr, Dave Higton wrote:
> No such problem for me with r13571.
Ditto here, same version. I wonder if it's a graphics thing - Dave and
me are using RO5.18, the two reporting flicker are using RO6.nn.
--
Brian Howlett
-----------------------------------------------------------------
Isn't it strange that the same people that laugh at gypsy fortune
tellers take economists seriously?
> No such problem for me with r13571.
Ditto here, same version. I wonder if it's a graphics thing - Dave and
me are using RO5.18, the two reporting flicker are using RO6.nn.
--
Brian Howlett
-----------------------------------------------------------------
Isn't it strange that the same people that laugh at gypsy fortune
tellers take economists seriously?
Re: Nervous tick
In message <86a88c8652.ricp@user.minijem.plus.com>
Richard Porter <ricp@minijem.plus.com> wrote:
> On 26 Apr 2012 Tony Moore wrote:
>
> > On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>
> >> When Netsurf is displaying the following page and others on the same
> >> site the pointer starts flickering 2 or 3 times a second between a
> >> pointing hand and an hour glass.
> >>
> >> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
> >> ieving-more/
>
> > [snip]
>
> >> Currently using r13534.
>
> > No problem here with r13571
>
> Still doing it for me now with r13571
No such problem for me with r13571.
Dave
Richard Porter <ricp@minijem.plus.com> wrote:
> On 26 Apr 2012 Tony Moore wrote:
>
> > On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>
> >> When Netsurf is displaying the following page and others on the same
> >> site the pointer starts flickering 2 or 3 times a second between a
> >> pointing hand and an hour glass.
> >>
> >> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
> >> ieving-more/
>
> > [snip]
>
> >> Currently using r13534.
>
> > No problem here with r13571
>
> Still doing it for me now with r13571
No such problem for me with r13571.
Dave
Re: Nervous tick
On 26 Apr 2012 Tony Moore wrote:
> On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>> When Netsurf is displaying the following page and others on the same
>> site the pointer starts flickering 2 or 3 times a second between a
>> pointing hand and an hour glass.
>>
>> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
>> ieving-more/
> [snip]
>> Currently using r13534.
> No problem here with r13571
Still doing it for me now with r13571
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
>> When Netsurf is displaying the following page and others on the same
>> site the pointer starts flickering 2 or 3 times a second between a
>> pointing hand and an hour glass.
>>
>> http://www.therailengineer.com/2012/04/26/bs11000-working-together-ach
>> ieving-more/
> [snip]
>> Currently using r13534.
> No problem here with r13571
Still doing it for me now with r13571
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
[gccsdk] [Bug 229] New: GCC 4.1.2 Release 2 Dev: glob() ignores files with hardspace.
http://www.riscos.info/bugzilla3/show_bug.cgi?id=229
Summary: GCC 4.1.2 Release 2 Dev: glob() ignores files with
hardspace.
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@ntlworld.com
Estimated Hours: 0.0
GCCSDK GCC 4.1.2 Release 2 Development
VRPC RISC OS 4.39
This program doesn't list filenames in cwd with a hardspace:
#include <stdio.h>
#include <glob.h>
int main(void) {
glob_t file_list;
int flags=0;
int err=glob("*",flags,NULL,&file_list);
printf("err = %i\n",err);
printf("file_list->gl_pathc = %lu\n",file_list.gl_pathc);
for (size_t i=0;i<file_list.gl_pathc;++i) {
printf("%lu %s\n",i,file_list.gl_pathv[i]);
}
return 0;
}
--
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.1.2 Release 2 Dev: glob() ignores files with
hardspace.
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@ntlworld.com
Estimated Hours: 0.0
GCCSDK GCC 4.1.2 Release 2 Development
VRPC RISC OS 4.39
This program doesn't list filenames in cwd with a hardspace:
#include <stdio.h>
#include <glob.h>
int main(void) {
glob_t file_list;
int flags=0;
int err=glob("*",flags,NULL,&file_list);
printf("err = %i\n",err);
printf("file_list->gl_pathc = %lu\n",file_list.gl_pathc);
for (size_t i=0;i<file_list.gl_pathc;++i) {
printf("%lu %s\n",i,file_list.gl_pathv[i]);
}
return 0;
}
--
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: Nervous tick
On 26 Apr 2012, Richard Porter <ricp@minijem.plus.com> wrote:
> When Netsurf is displaying the following page and others on the same
> site the pointer starts flickering 2 or 3 times a second between a
> pointing hand and an hour glass.
>
> http://www.therailengineer.com/2012/04/26/bs11000-working-together-achieving-more/
[snip]
> Currently using r13534.
No problem here with r13571
Tony
> When Netsurf is displaying the following page and others on the same
> site the pointer starts flickering 2 or 3 times a second between a
> pointing hand and an hour glass.
>
> http://www.therailengineer.com/2012/04/26/bs11000-working-together-achieving-more/
[snip]
> Currently using r13534.
No problem here with r13571
Tony
Nervous tick
When Netsurf is displaying the following page and others on the same
site the pointer starts flickering 2 or 3 times a second between a
pointing hand and an hour glass.
http://www.therailengineer.com/2012/04/26/bs11000-working-together-achieving-more/
This only happens when the top part of the page is displayed. If you
scroll down it stops; if you scroll back up so that most of the image
is shown it starts again. If you're working in another window over the
top it stops. If you bring NetSurf to the top it resumes. What's going
on?
Currently using r13534.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
site the pointer starts flickering 2 or 3 times a second between a
pointing hand and an hour glass.
http://www.therailengineer.com/2012/04/26/bs11000-working-together-achieving-more/
This only happens when the top part of the page is displayed. If you
scroll down it stops; if you scroll back up so that most of the image
is shown it starts again. If you're working in another window over the
top it stops. If you bring NetSurf to the top it resumes. What's going
on?
Currently using r13534.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
[gccsdk] [Bug 228] New: SUL 1.12: system()/exec*() ignoring aliases of existing non-module commands.
http://www.riscos.info/bugzilla3/show_bug.cgi?id=228
Summary: SUL 1.12: system()/exec*() ignoring aliases of
existing non-module commands.
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@ntlworld.com
Estimated Hours: 0.0
GCCSDK GCC 4.1.2 Release 2 Development
ShareUnixLibrary 1.12
VRPC RISC OS 4.39
system() and exec*() are ignoring aliases of existing non-module commands.
For example, alias.c:
#include <stdlib.h>
int main(void) {
system("time");
system("ls");
return 0;
}
*gcc -o test alias.c
'ls' is a previously compiled Run$Path command.
*alias ls echo should see this
*alias time echo should see this
*ls
should see this
*time
should see this
*test
should see this
!Run c d Makefile o stat test
Previously, the output was:
should see this
should see 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
Summary: SUL 1.12: system()/exec*() ignoring aliases of
existing non-module commands.
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@ntlworld.com
Estimated Hours: 0.0
GCCSDK GCC 4.1.2 Release 2 Development
ShareUnixLibrary 1.12
VRPC RISC OS 4.39
system() and exec*() are ignoring aliases of existing non-module commands.
For example, alias.c:
#include <stdlib.h>
int main(void) {
system("time");
system("ls");
return 0;
}
*gcc -o test alias.c
'ls' is a previously compiled Run$Path command.
*alias ls echo should see this
*alias time echo should see this
*ls
should see this
*time
should see this
*test
should see this
!Run c d Makefile o stat test
Previously, the output was:
should see this
should see 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
Re: [gccsdk] GCC 4.1.2 release 1 package won't upgrade from theprevious version
John Tytgat wrote on Wednesday, April 25, 2012:
> > When using RiscPkg or PackMan to update the GCC4 it fails
> > with a dialogue files that conflict with the file:
> >
> > Selecting-the-Target-System/html
> >
> > I've tracked this down to a change in the case of this
> file between the two releases.
> >
> > The old version was:
> >
> > Selecting-The-Target-System/html
> >
> > Note the capital 'T' in 'the'.
> >
> > Would it be possible to restore the old case in the
> > packages and upload a new version?
> Those html pages are automatically generated during kit generation so
> a rename afterwards is quite fiddly and I don't see how we can avoid
> similar instances of this problem in the future. I would like to
> avoid that.
> Are you actually saying RiscPkg/PackMan isn't able to deal with filename
> case changes between two versions of a package ?
Yes I am saying that. The shared back-end (libpkg) to both versions uses
an exact match to figure out which files it can overwrite during an upgrade
so sees them as different files, but they won't be on the disc.
> If so, any chance to get
> this fixed in RiscPkg/PackMan itself ?
As it's difficult for you to change, I will email the author of libpkg to
see if he can get it changed.
Do you know if it is safe to assume that RISC OS filenames are not
case sensitive?
In the meantime people will need to uninstall GCC4 and then install it
again.
I was hoping you had the files on a disc somewhere still so you could
just rename that one file and rebuild the one package.
Is this possible for the current release? If not, would it be OK with
you if I rebuilt a new version of the package from your version with
the one files case changed?
I will also pursue what can be done with libpkg to see the same
problem doesn't occur in a future release.
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
> > When using RiscPkg or PackMan to update the GCC4 it fails
> > with a dialogue files that conflict with the file:
> >
> > Selecting-the-Target-System/html
> >
> > I've tracked this down to a change in the case of this
> file between the two releases.
> >
> > The old version was:
> >
> > Selecting-The-Target-System/html
> >
> > Note the capital 'T' in 'the'.
> >
> > Would it be possible to restore the old case in the
> > packages and upload a new version?
> Those html pages are automatically generated during kit generation so
> a rename afterwards is quite fiddly and I don't see how we can avoid
> similar instances of this problem in the future. I would like to
> avoid that.
> Are you actually saying RiscPkg/PackMan isn't able to deal with filename
> case changes between two versions of a package ?
Yes I am saying that. The shared back-end (libpkg) to both versions uses
an exact match to figure out which files it can overwrite during an upgrade
so sees them as different files, but they won't be on the disc.
> If so, any chance to get
> this fixed in RiscPkg/PackMan itself ?
As it's difficult for you to change, I will email the author of libpkg to
see if he can get it changed.
Do you know if it is safe to assume that RISC OS filenames are not
case sensitive?
In the meantime people will need to uninstall GCC4 and then install it
again.
I was hoping you had the files on a disc somewhere still so you could
just rename that one file and rebuild the one package.
Is this possible for the current release? If not, would it be OK with
you if I rebuilt a new version of the package from your version with
the one files case changed?
I will also pursue what can be done with libpkg to see the same
problem doesn't occur in a future release.
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
Wednesday, 25 April 2012
[Rpcemu] Fwd: Fwd: No interface with Networking under Ubuntu 10.04.
Okay have now fixed. I had ufw firewall enabled on my Ubuntu system
-------- Original Message --------
-------- Original Message --------
| Subject: | Fwd: No interface with Networking under Ubuntu 10.04. |
|---|---|
| Date: | Wed, 25 Apr 2012 23:13:48 +0100 |
| From: | Keith Sloan <keith@sloan-home.co.uk> |
| To: | rpcemu@riscos.info |
"I assume that using the system on the ROOL USB stick I don't have to do anything about Install RPCEmu Network driver as this seemed to be already done." Wrong assumption. I have now been able to configure TCPIP under RISC OS. Now I am left with the problem that I can ping the tap0 addresses. Ping the PC's IP address 192.168.1.2, but NOT my router 192.168.1.1
[gccsdk] [Bug 227] GCC 4.1.2 Release 1 getcwd problem
http://www.riscos.info/bugzilla3/show_bug.cgi?id=227
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2012-04-25 18:34:18 PDT ---
Solved with r5757 for branches/release_4_1_2 and r5758 for trunk/gcc4.
--
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> 2012-04-25 18:34:18 PDT ---
Solved with r5757 for branches/release_4_1_2 and r5758 for trunk/gcc4.
--
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 226] GCC 4.1.2 Release 1 strftime problem
http://www.riscos.info/bugzilla3/show_bug.cgi?id=226
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2012-04-25 17:43:11 PDT ---
Solved by Lee with r5754 on branches/release_4_1_2 and 5755 on trunk/gcc4.
--
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> 2012-04-25 17:43:11 PDT ---
Solved by Lee with r5754 on branches/release_4_1_2 and 5755 on trunk/gcc4.
--
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] GCC 4.1.2 release 1 package won't upgrade from the previous version
In message <SNT136-ds102EECB9D7C54D51AC5642F0260@phx.gbl>
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> When using RiscPkg or PackMan to update the GCC4 it fails
> with a dialogue “files that conflict†with the file:
>
> Selecting-the-Target-System/html
>
> I’ve tracked this down to a change in the case of this
> file between the two releases.
>
> The old version was:
>
> Selecting-The-Target-System/html
>
> Note the capital ‘T’ in ‘the’.
>
> Would it be possible to restore the old case in the
> packages and upload a new version?
Those html pages are automatically generated during kit generation so
a rename afterwards is quite fiddly and I don't see how we can avoid
similar instances of this problem in the future. I would like to
avoid that.
Are you actually saying RiscPkg/PackMan isn't able to deal with filename
case changes between two versions of a package ? If so, any chance to get
this fixed in RiscPkg/PackMan itself ?
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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:
> When using RiscPkg or PackMan to update the GCC4 it fails
> with a dialogue “files that conflict†with the file:
>
> Selecting-the-Target-System/html
>
> I’ve tracked this down to a change in the case of this
> file between the two releases.
>
> The old version was:
>
> Selecting-The-Target-System/html
>
> Note the capital ‘T’ in ‘the’.
>
> Would it be possible to restore the old case in the
> packages and upload a new version?
Those html pages are automatically generated during kit generation so
a rename afterwards is quite fiddly and I don't see how we can avoid
similar instances of this problem in the future. I would like to
avoid that.
Are you actually saying RiscPkg/PackMan isn't able to deal with filename
case changes between two versions of a package ? If so, any chance to get
this fixed in RiscPkg/PackMan itself ?
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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
[Rpcemu] Fwd: No interface with Networking under Ubuntu 10.04.
"I assume that using the system on the ROOL USB stick I don't have to do
anything about Install RPCEmu
Network driver as this seemed to be already done."
Wrong assumption.
I have now been able to configure TCPIP under RISC OS.
Now I am left with the problem that I can ping the tap0 addresses.
Ping the PC's IP address 192.168.1.2, but NOT my router 192.168.1.1
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
anything about Install RPCEmu
Network driver as this seemed to be already done."
Wrong assumption.
I have now been able to configure TCPIP under RISC OS.
Now I am left with the problem that I can ping the tap0 addresses.
Ping the PC's IP address 192.168.1.2, but NOT my router 192.168.1.1
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] RPCEmu Title Bar off screen.
When I start RPCEmu the applications Title bar is off the top of my
screen. How do I correct this?
System is Ubuntu 10.04
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
screen. How do I correct this?
System is Ubuntu 10.04
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] No interface with Networking under Ubuntu 10.04.
I am trying to setup TCPIP Networking with RPCEmu under Ubuntu Linux 10.04.
When I try and follow the instructions at
http://www.marutan.net/rpcemu/manual/network.html
I get stuck when I try to configure interfaces as I get told none.
If I ifconfig -a I just get lo0.
I am using RISC OS roms 5.19 as supplied on the ROOL USB stick.
Initially I tried RPCEmu 0.8.8 as supplied on the same USB stick.
I also downloaded RPCEmu 0.8.9 but same result.
If I forget to use sudo to run rpcemu I get an error message about TAP.
When I quit RPCEmu I get shared memory permission errors as follows.
sudo ./rpcemu_0.8.9
Request for unhandled I2C device 00
Request for unhandled I2C device 68
Request for unhandled I2C device 00
Request for unhandled I2C device 68
Request for unhandled I2C device 68
Request for unhandled I2C device 68
shm_unlink(/pulse-shm-4096849270) failed: Permission denied
shm_unlink(/pulse-shm-1622735372) failed: Permission denied
I assume that using the system on the ROOL USB stick I don't have to do
anything about
Install RPCEmu Network driver as this seemed to be already done.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
When I try and follow the instructions at
http://www.marutan.net/rpcemu/manual/network.html
I get stuck when I try to configure interfaces as I get told none.
If I ifconfig -a I just get lo0.
I am using RISC OS roms 5.19 as supplied on the ROOL USB stick.
Initially I tried RPCEmu 0.8.8 as supplied on the same USB stick.
I also downloaded RPCEmu 0.8.9 but same result.
If I forget to use sudo to run rpcemu I get an error message about TAP.
When I quit RPCEmu I get shared memory permission errors as follows.
sudo ./rpcemu_0.8.9
Request for unhandled I2C device 00
Request for unhandled I2C device 68
Request for unhandled I2C device 00
Request for unhandled I2C device 68
Request for unhandled I2C device 68
Request for unhandled I2C device 68
shm_unlink(/pulse-shm-4096849270) failed: Permission denied
shm_unlink(/pulse-shm-1622735372) failed: Permission denied
I assume that using the system on the ROOL USB stick I don't have to do
anything about
Install RPCEmu Network driver as this seemed to be already done.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Subscribe to:
Posts (Atom)