Thank you for the clarification/explanation!
Best wishes,
John
--
| John Williams
| johnrw@ukgateway.net
Saturday, 27 January 2018
Re: Logging of Changes
On Sat, Jan 27, 2018 at 09:50:28AM +0000, John Williams wrote:
>
> Why are there often series of changes which are not specifically logged at:
>
> http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
>
> like in the last 13 builds. Does the information appear somewhere else?
The "gap" builds are simply those triggered by other components
(libraries). There are no code changes in NetSurf itself so no entry
on this list.
Most of the 13 you identify stem from recent fixes and improvements to
librufl, libcss and toolchain updates. Though you may also see builds
triggered from the CI system itself because I have been ensuring the
system can successfully perform repeat builds.
>
> John
>
> --
> | John Williams
> | johnrw@ukgateway.net
>
>
--
Regards Vincent
http://www.kyllikki.org/
>
> Why are there often series of changes which are not specifically logged at:
>
> http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
>
> like in the last 13 builds. Does the information appear somewhere else?
The "gap" builds are simply those triggered by other components
(libraries). There are no code changes in NetSurf itself so no entry
on this list.
Most of the 13 you identify stem from recent fixes and improvements to
librufl, libcss and toolchain updates. Though you may also see builds
triggered from the CI system itself because I have been ensuring the
system can successfully perform repeat builds.
>
> John
>
> --
> | John Williams
> | johnrw@ukgateway.net
>
>
--
Regards Vincent
http://www.kyllikki.org/
Logging of Changes
Why are there often series of changes which are not specifically logged at:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
like in the last 13 builds. Does the information appear somewhere else?
John
--
| John Williams
| johnrw@ukgateway.net
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
like in the last 13 builds. Does the information appear somewhere else?
John
--
| John Williams
| johnrw@ukgateway.net
Friday, 26 January 2018
[gccsdk] Wimpslot oddity
I have a working port of telegram-cli, but compiling with either 4/1/2 or
4/7/4 and when the static binary runs, it doesn't complain about the
wimpslot, but helps itself to 206112000 bytes.
I have never seen a (largish) binary work without a wimpslot specified
before.
I noticed the wimpslot for ld climbing to about 17MB and I approximate that
should be the ballpark wimpslot for the binary to run.
Though the linux equivalent will be using shared libs it is only running
with 2.5MB system memory.
I haven't got a working shared library built yet (TEXTREL) but the shared
version needed an enormous wimpslot, before displaying the error.
I have tryed bypassing the inner_main, loop, netloop functions for the
shell but it only dropped the memory usage by KB's not MB's
Going further back in the main() I only achieved a machine crash.
I am putting in a
while(1) {
}
to get it to stay running so I can observe changes to the memory.
I'd welcome any other ideas, or general info about memory.
Ron M.
Regarding mail holdups, I have been contacted by zoho support, and they
have taken steps to allow posts from this mailing list to get through
greylisting, so I'll be checking this one. A better response than is
possible from gmail, regarding long term builtin spamlisting problems.
_______________________________________________
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
4/7/4 and when the static binary runs, it doesn't complain about the
wimpslot, but helps itself to 206112000 bytes.
I have never seen a (largish) binary work without a wimpslot specified
before.
I noticed the wimpslot for ld climbing to about 17MB and I approximate that
should be the ballpark wimpslot for the binary to run.
Though the linux equivalent will be using shared libs it is only running
with 2.5MB system memory.
I haven't got a working shared library built yet (TEXTREL) but the shared
version needed an enormous wimpslot, before displaying the error.
I have tryed bypassing the inner_main, loop, netloop functions for the
shell but it only dropped the memory usage by KB's not MB's
Going further back in the main() I only achieved a machine crash.
I am putting in a
while(1) {
}
to get it to stay running so I can observe changes to the memory.
I'd welcome any other ideas, or general info about memory.
Ron M.
Regarding mail holdups, I have been contacted by zoho support, and they
have taken steps to allow posts from this mailing list to get through
greylisting, so I'll be checking this one. A better response than is
possible from gmail, regarding long term builtin spamlisting problems.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Tuesday, 23 January 2018
Re: [Rpcemu] RPCEmu pre release test version 0.8.100
I suspect this may have been asked before but are there any plans to merge the functionality of Arculator and RPCEmu? I wonder how different the ARM2/3 based machines are to the RPC based ones. I've found myself trying tech-demos on RPCEmu and then separately on Arculator due to compatibility issues and I think it would be great to have an "all-in-one" solution, both for existing software and development.
On 22 January 2018 at 17:12, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
On Tue, Jan 02, 2018 at 03:01:37AM +0000, J Percival wrote:
> Hi, I did a little more experimentation to see exactly at what point
> RiscOS locks up when running the universal-boot-2 sequence under the
> recompiler.
> It seems to be on execution of !Boot.Utils.BootVars so probably a bug in
> the recompiler code.
To let you know we have reproduced this and are investigating. Initial
looks says it's not a quick fix (nor a regression in 0.8.100), as such
it's unlikely to be fixed before the next release version and the
workaround of choosing 'StrongARM' is probably a good idea here.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] BASIC mouse-pointer issue
Thanks for the workaround!
On 22 January 2018 at 17:08, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
On Sat, Jan 20, 2018 at 03:34:29PM +0000, J Percival wrote:
> RPCEmu Version: 0.8.15 and later
> Config: RPC-StrongARM/16MB/No VRAM/Sound Enabled
> I'm not sure if this is an emulator bug or not but I've noticed that the
> BASIC "MOUSE TO" command under RO3.71 changes the size of the pointer
> instead of its location - specifically the 'x' argument has no effect and
> the 'y' argument modifies the pointer's height.
> To reproduce:
> MOUSE ON:MOUSE TO 0,20
Thanks for this report, I've been able to reproduce it and am
investigating. Oddly the reduction in the size of the pointer is related
to the amount that is offscreen when moving TO the Y coord, e.g. MOUSE TO
0, 2 means you have an even smaller pointer.
This only affects 'Follow host mouse' mode, so if you need a temporary
workaround, use 'Capture Mouse' mode by deselecting 'Follow host mouse'
(0.8.100) or chosing Capture Mouse (0.8.15).
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 22 January 2018
Re: [Rpcemu] RPCEmu pre release test version 0.8.100
On Tue, Jan 02, 2018 at 03:01:37AM +0000, J Percival wrote:
> Hi, I did a little more experimentation to see exactly at what point
> RiscOS locks up when running the universal-boot-2 sequence under the
> recompiler.
> It seems to be on execution of !Boot.Utils.BootVars so probably a bug in
> the recompiler code.
To let you know we have reproduced this and are investigating. Initial
looks says it's not a quick fix (nor a regression in 0.8.100), as such
it's unlikely to be fixed before the next release version and the
workaround of choosing 'StrongARM' is probably a good idea here.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Hi, I did a little more experimentation to see exactly at what point
> RiscOS locks up when running the universal-boot-2 sequence under the
> recompiler.
> It seems to be on execution of !Boot.Utils.BootVars so probably a bug in
> the recompiler code.
To let you know we have reproduced this and are investigating. Initial
looks says it's not a quick fix (nor a regression in 0.8.100), as such
it's unlikely to be fixed before the next release version and the
workaround of choosing 'StrongARM' is probably a good idea here.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Subscribe to:
Posts (Atom)