RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Announcements →

Otter Browser

Subscribe to Otter Browser 181 posts, 42 voices

Posts per page:

Pages: 1 2 3 4 5 6 7 8

 
Sep 12, 2015 9:08am
Avatar Chris Gransden (337) 1058 posts

A test release of Otter Browser is now available for download.
It uses the RISC OS port of Qt5 (v5.4.1) which includes the WebKit backend.
Only the Javascript interpreter is turned on at the moment.

Otter browser 0.9.8

You’ll also need to download,

unixfont.zip

!UnixFC and !UnixFont need to be seen by the filer before !Otter-browser is
run otherwise you’ll get squares instead of text.
Merge the !Boot folder contained in unixfont.zip.
Copying !UnixFC and !UnixFont to a ram disc helps speed things up a bit.

SharedLibs.zip

Just drop the !SharedLibs folder into !Boot.Resources.

It seems to run ok on a Pandaboard ES and IGEPv5. Anything slower may stuggle a bit.
There are still lots of problems and it can be slow to load pages.
Most sites containing Javascript load and display ok. More complex sites cause a crash or lock up.
Routers should be configurable on RISC OS and the RISC OS OPEN Wiki is now editable.

When Otter Browser starts up the window is minimised. To resize just click and hold anywhere in the window
and hold down shift while moving the mouse.

 
Sep 12, 2015 10:57am
Avatar rob andrews (112) 200 posts

Hi Chris on 5432EVM get this back trace
Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0×518a78 (Main Thread)
( 1007f34) pc: cd402a24 lr: cd402e40 sp: 1007f38 __write_backtrace()
( 1007fa0) pc: cd402b74 lr: cd4049f8 sp: 1007fa4 __unixlib_raise_signal()
( 1007fb0) pc: cd4048ac lr: e5ef8 sp: 100634c __h_cback()

Register dump at 01007fb4: a1: 10065e4 a2: 0 a3: 0 a4: 0 v1: 5c13f0 v2: 6032a8 v3: 6032aa v4: 603288 v5: 50e174 v6: 100634c sl: f07208 fp: 1006634 ip: 100634c sp: 100634c lr: e5ef8 pc: 4 cpsr: 20000010 000e5ee4 : ¦.‰â : e2891fa6 : ADD R1,R9,#&0298 ; =664 000e5ee8 : .. á : e1a00001 : MOV R0,R1 000e5eec : .. á : e1a01003 : MOV R1,R3 000e5ef0 : .à á : e1a0e00f : MOV R14,PC 000e5ef4 : .ð á : e1a0f002 : MOV PC,R2 000e5ef8 : ‰?‰â : e2893f89 : ADD R3,R9,#&0224 ; =548 000e5efc : .. á : e1a00003 : MOV R0,R3 000e5f00 : LYýë : ebfd594c : BL &0003C438 000e5f04 : ">‰â : e2893e22 : ADD R3,R9,#&0220 ; =544 ( 1006634) pc: e5c00 lr: 27b190 sp: 1006638 Otter::UpdateChecker::runUpdateCheck() ( 1006664) pc: 27b120 lr: cbd36210 sp: 1006668 Otter::UpdateChecker::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ( 1006728) pc: cbd35f00 lr: cbd36b88 sp: 100672c QMetaObject::activate(QObject*, int, int, void**) ( 1006744) pc: cbd36b58 lr: cc4e7ffc sp: 1006748 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ( 1006754) pc: cc4e7fd4 lr: cc43de18 sp: 1006758 QNetworkReply::finished() ( 10067d8) pc: cc43dcb8 lr: cc43e354 sp: 10067dc QNetworkReplyHttpImplPrivate::finished() ( 10067e8) pc: cc43e33c lr: cc4e90e4 sp: 10067ec QNetworkReplyHttpImplPrivate::replyFinished() ( 1006838) pc: cc4e89f4 lr: cbd32bf0 sp: 100683c QNetworkReplyHttpImpl::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ( 1006860) pc: cbd32b54 lr: cbd375a8 sp: 1006864 QMetaCallEvent::placeMetaCall(QObject*) ( 10068e8) pc: cbd372d4 lr: cc8faf94 sp: 10068ec QObject::event(QEvent*) ( 100690c) pc: cc8faee4 lr: cc8fe38c sp: 1006910 QApplicationPrivate::notify_helper(QObject*, QEvent*) ( 1006c58) pc: cc8fda2c lr: cbcf2838 sp: 1006c5c QApplication::notify(QObject*, QEvent*) ( 1006c88) pc: cbcf27c4 lr: cbcf5eec sp: 1006c8c QCoreApplication::notifyInternal(QObject*, QEvent*) ( 1006cf4) pc: cbcf5c80 lr: cd4824a4 sp: 1006cf8 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ( 1006d10) pc: cd48247c lr: cbcefcc0 sp: 1006d14 QRiscosEventDispatcher::processEvents(QFlags) ( 1006d24) pc: cbcefc8c lr: cbcf02c4 sp: 1006d28 QEventLoop::processEvents(QFlags) ( 1006d6c) pc: cbcf01bc lr: ccb33428 sp: 1006d70 QEventLoop::exec(QFlags) ( 1006db8) pc: ccb331a8 lr: 3f810 sp: 1006dbc QDialog::exec() ( 1006fec) pc: 3f2ec lr: cd4197c4 sp: 1006ff0 main()

Thread 0×64c330 (JavaScriptCore::BlockFree)
( 1007f14) pc: cd3e60b0 lr: cd3e30c8 sp: f01eac __pthread_yield_return()
( f01eb8) pc: cd3e6018 lr: cd3e30c8 sp: f01ebc pthread_yield()
( f01ee0) pc: cd3e2fac lr: c9ca4138 sp: f01ee4 pthread_cond_timedwait()
( f01f08) pc: c9ca4090 lr: c9a56e68 sp: f01f0c WTF::ThreadCondition::timedWait(WTF::Mutex&, double)
( f01f28) pc: c9a56e1c lr: c9a56edc sp: f01f2c JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock(double)
( f01f48) pc: c9a56eac lr: c9a56f60 sp: f01f4c JSC::BlockAllocator::waitForRelativeTime(double)
( f01f6c) pc: c9a56f2c lr: c9a57120 sp: f01f70 JSC::BlockAllocator::blockFreeingThreadMain()
( f01f7c) pc: c9a57114 lr: c9c8afd4 sp: f01f80 JSC::BlockAllocator::blockFreeingThreadStartFunc(void*)
( f01f98) pc: c9c8af8c lr: c9ca3920 sp: f01f9c WTF::threadEntryPoint(void*)
( f01fac) pc: c9ca3900 lr: cd3e35f8 sp: f01fb0 WTF::wtfThreadEntryPoint(void*)
( f01fbc) pc: cd3e35e0 lr: 0 sp: f01fc0 __pthread_create()

Thread 0×5de8e8 (Thread (pooled))
( 1007f14) pc: cd3e60b0 lr: cd3e30c8 sp: f03eac __pthread_yield_return()
( f03eb8) pc: cd3e6018 lr: cd3e30c8 sp: f03ebc pthread_yield()
( f03ee0) pc: cd3e2fac lr: cba5f8f4 sp: f03ee4 pthread_cond_timedwait()
( f03f38) pc: cba5f78c lr: cba5a62c sp: f03f3c QWaitCondition::wait(QMutex*, unsigned long)
( f03f80) pc: cba5a370 lr: cba5dfdc sp: f03f84 QThreadPoolThread::run()
( f03fbc) pc: cba5de74 lr: cd3e35f8 sp: f03fc0 QThreadPrivate::start(void*)
( f03fcc) pc: cd3e35e0 lr: 80000018 sp: f03fd0 __pthread_create()

Thread 0×60f358 (Qt HTTP thread)
( 1007f14) pc: cd3e60b0 lr: cbcefcc8 sp: f05ef4 __pthread_yield_return()
( f05f00) pc: cd3e6018 lr: cbcefcc8 sp: f05f04 pthread_yield()
( f05f14) pc: cbcefc8c lr: cbcf02c4 sp: f05f18 QEventLoop::processEvents(QFlags)
( f05f5c) pc: cbcf01bc lr: cba5870c sp: f05f60 QEventLoop::exec(QFlags)
( f05f80) pc: cba5865c lr: cba587d8 sp: f05f84 QThread::exec()
( f05f90) pc: cba587cc lr: cba5dfdc sp: f05f94 QThread::run()
( f05fcc) pc: cba5de74 lr: cd3e35f8 sp: f05fd0 QThreadPrivate::start(void*)
( f05fdc) pc: cd3e35e0 lr: 6c6e7520 sp: f05fe0 __pthread_create()

Thread 0×60e810 (Qt bearer thread)
( 1007f14) pc: cd3e60b0 lr: cd427758 sp: f06c40 __pthread_yield_return()
( f06c4c) pc: cd3e6018 lr: cd427758 sp: f06c50 pthread_yield()
( f06dec) pc: cd427378 lr: cbd5f734 sp: f06df0 select()
( f06e38) pc: cbd5f57c lr: cbd5ff00 sp: f06e3c qt_safe_select(int, __fd_set*, __fd_set*, __fd_set*, timespec const*)
( f06e4c) pc: cbd5fed8 lr: cbd615d4 sp: f06e50 QEventDispatcherUNIX::select(int, __fd_set*, __fd_set*, __fd_set*, timespec*)
( f06ed8) pc: cbd614e4 lr: cbd61a8c sp: f06edc QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*)
( f06f08) pc: cbd619c4 lr: cbcefcc0 sp: f06f0c QEventDispatcherUNIX::processEvents(QFlags)
( f06f1c) pc: cbcefc8c lr: cbcf02c4 sp: f06f20 QEventLoop::processEvents(QFlags)
( f06f64) pc: cbcf01bc lr: cba5870c sp: f06f68 QEventLoop::exec(QFlags)
( f06f88) pc: cba5865c lr: cba587d8 sp: f06f8c QThread::exec()
( f06f98) pc: cba587cc lr: cba5dfdc sp: f06f9c QThread::run()
( f06fd4) pc: cba5de74 lr: cd3e35f8 sp: f06fd8 QThreadPrivate::start(void*)
( f06fe4) pc: cd3e35e0 lr: 63002c sp: f06fe8 __pthread_create()

 
Sep 12, 2015 11:09am
Avatar Chris Gransden (337) 1058 posts

I should’ve disabled that. It’s falling over because it’s trying to check for updates which makes no sense for RISC OS. A quick work around is to change !Boot.Choices.Qt5.config.otter.otter/conf. Just set the date far in the future.

[Updates]
LastCheck=2020-01-01

 
Sep 12, 2015 12:03pm
Avatar rob andrews (112) 200 posts

That worked but had to create otter/conf

 
Sep 12, 2015 12:21pm
Avatar Leo Smiers (245) 54 posts

I can confirm it also works on a PI with 512 MByte. You have to be (a little) patience though.

 
Sep 12, 2015 1:02pm
Avatar John Ballance (21) 70 posts

Not so much luck on iMx6 ..

I think it is still the update check. tried future datestamp on !Boot.choices.Qt5.config.otter.otter/conf to no avail

Any further thoughts?

debug file:


Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0×518a88 (Main Thread)
( 1007f34) pc: 48bd9a24 lr: 48bd9e40 sp: 1007f38 __write_backtrace()
( 1007fa0) pc: 48bd9b74 lr: 48bdb9f8 sp: 1007fa4 __unixlib_raise_signal()
( 1007fb0) pc: 48bdb8ac lr: e5ed4 sp: 100633c __h_cback()

Register dump at 01007fb4: a1: 0 a2: 51c4bc a3: e59ff4c0 a4: 0 v1: 5eee30 v2: 606988 v3: 60698a v4: 606968 v5: 50e184 v6: 100633c sl: f07208 fp: 1006624 ip: 100633c sp: 100633c lr: e5ed4 pc: e5ee8 cpsr: 20000110 000e5ed4 : .0 á : e1a03000 : MOV R3,R0 000e5ed8 : . “å : e5932000 : LDR R2,[R3,#0] 000e5edc : 8 ‚â : e2822038 : ADD R2,R2,#&38 ; =“8” 000e5ee0 : . ’å : e5922000 : LDR R2,[R2,#0] 000e5ee4 : ¦.‰â : e2891fa6 : ADD R1,R9,#&0298 ; =664 000e5ee8 : .. á : e1a00001 : MOV R0,R1 000e5eec : .. á : e1a01003 : MOV R1,R3 000e5ef0 : .à á : e1a0e00f : MOV R14,PC 000e5ef4 : .ð á : e1a0f002 : MOV PC,R2 ( 1006624) pc: e5c00 lr: 27b190 sp: 1006628 Otter::UpdateChecker::runUpdateCheck() ( 1006654) pc: 27b120 lr: 4750d210 sp: 1006658 Otter::UpdateChecker::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ( 1006718) pc: 4750cf00 lr: 4750db88 sp: 100671c QMetaObject::activate(QObject*, int, int, void**) ( 1006734) pc: 4750db58 lr: 47cbeffc sp: 1006738 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ( 1006744) pc: 47cbefd4 lr: 47c14e18 sp: 1006748 QNetworkReply::finished() ( 10067c8) pc: 47c14cb8 lr: 47c15354 sp: 10067cc QNetworkReplyHttpImplPrivate::finished() ( 10067d8) pc: 47c1533c lr: 47cc00e4 sp: 10067dc QNetworkReplyHttpImplPrivate::replyFinished() ( 1006828) pc: 47cbf9f4 lr: 47509bf0 sp: 100682c QNetworkReplyHttpImpl::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ( 1006850) pc: 47509b54 lr: 4750e5a8 sp: 1006854 QMetaCallEvent::placeMetaCall(QObject*) ( 10068d8) pc: 4750e2d4 lr: 480d1f94 sp: 10068dc QObject::event(QEvent*) ( 10068fc) pc: 480d1ee4 lr: 480d538c sp: 1006900 QApplicationPrivate::notify_helper(QObject*, QEvent*) ( 1006c48) pc: 480d4a2c lr: 474c9838 sp: 1006c4c QApplication::notify(QObject*, QEvent*) ( 1006c78) pc: 474c97c4 lr: 474cceec sp: 1006c7c QCoreApplication::notifyInternal(QObject*, QEvent*) ( 1006ce4) pc: 474ccc80 lr: 48c594a4 sp: 1006ce8 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ( 1006d00) pc: 48c5947c lr: 474c6cc0 sp: 1006d04 QRiscosEventDispatcher::processEvents(QFlags) ( 1006d14) pc: 474c6c8c lr: 474c72c4 sp: 1006d18 QEventLoop::processEvents(QFlags) ( 1006d5c) pc: 474c71bc lr: 474d0cf8 sp: 1006d60 QEventLoop::exec(QFlags) ( 1006d98) pc: 474d0c68 lr: 477d2664 sp: 1006d9c QCoreApplication::exec() ( 1006da8) pc: 477d263c lr: 480cf0ac sp: 1006dac QGuiApplication::exec() ( 1006db8) pc: 480cf0a0 lr: 3fd24 sp: 1006dbc QApplication::exec() ( 1006fec) pc: 3f2ec lr: 48bf07c4 sp: 1006ff0 main()

Thread 0×686f18 (JavaScriptCore::BlockFree)
( 1007f14) pc: 48bbd0b0 lr: 48bba0c8 sp: f01eac __pthread_yield_return()
( f01eb8) pc: 48bbd018 lr: 48bba0c8 sp: f01ebc pthread_yield()
( f01ee0) pc: 48bb9fac lr: 4547b138 sp: f01ee4 pthread_cond_timedwait()
( f01f08) pc: 4547b090 lr: 4522de68 sp: f01f0c WTF::ThreadCondition::timedWait(WTF::Mutex&, double)
( f01f28) pc: 4522de1c lr: 4522dedc sp: f01f2c JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock(double)
( f01f48) pc: 4522deac lr: 4522df60 sp: f01f4c JSC::BlockAllocator::waitForRelativeTime(double)
( f01f6c) pc: 4522df2c lr: 4522e120 sp: f01f70 JSC::BlockAllocator::blockFreeingThreadMain()
( f01f7c) pc: 4522e114 lr: 45461fd4 sp: f01f80 JSC::BlockAllocator::blockFreeingThreadStartFunc(void*)
( f01f98) pc: 45461f8c lr: 4547a920 sp: f01f9c WTF::threadEntryPoint(void*)
( f01fac) pc: 4547a900 lr: 48bba5f8 sp: f01fb0 WTF::wtfThreadEntryPoint(void*)
( f01fbc) pc: 48bba5e0 lr: 610040 sp: f01fc0 __pthread_create()

Thread 0×56abe8 (Thread (pooled))
( 1007f14) pc: 48bbd0b0 lr: 48bba0c8 sp: f03eac __pthread_yield_return()
( f03eb8) pc: 48bbd018 lr: 48bba0c8 sp: f03ebc pthread_yield()
( f03ee0) pc: 48bb9fac lr: 472368f4 sp: f03ee4 pthread_cond_timedwait()
( f03f38) pc: 4723678c lr: 4723162c sp: f03f3c QWaitCondition::wait(QMutex*, unsigned long)
( f03f80) pc: 47231370 lr: 47234fdc sp: f03f84 QThreadPoolThread::run()
( f03fbc) pc: 47234e74 lr: 48bba5f8 sp: f03fc0 QThreadPrivate::start(void*)
( f03fcc) pc: 48bba5e0 lr: 6f0040 sp: f03fd0 __pthread_create()

Thread 0×60fba8 (Qt HTTP thread)
( 1007f14) pc: 48bbd0b0 lr: 48bfe758 sp: f05c00 __pthread_yield_return()
( f05c0c) pc: 48bbd018 lr: 48bfe758 sp: f05c10 pthread_yield()
( f05dac) pc: 48bfe378 lr: 48bfd518 sp: f05db0 select()
( f05de4) pc: 48bfd4a8 lr: 47536610 sp: f05de8 pselect()
( f05e30) pc: 4753657c lr: 47536f00 sp: f05e34 qt_safe_select(int, __fd_set*, __fd_set*, __fd_set*, timespec const*)
( f05e44) pc: 47536ed8 lr: 475385d4 sp: f05e48 QEventDispatcherUNIX::select(int, __fd_set*, __fd_set*, __fd_set*, timespec*)
( f05ed0) pc: 475384e4 lr: 47538af8 sp: f05ed4 QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*)
( f05f00) pc: 475389c4 lr: 474c6cc0 sp: f05f04 QEventDispatcherUNIX::processEvents(QFlags)
( f05f14) pc: 474c6c8c lr: 474c72c4 sp: f05f18 QEventLoop::processEvents(QFlags)
( f05f5c) pc: 474c71bc lr: 4722f70c sp: f05f60 QEventLoop::exec(QFlags)
( f05f80) pc: 4722f65c lr: 4722f7d8 sp: f05f84 QThread::exec()
( f05f90) pc: 4722f7cc lr: 47234fdc sp: f05f94 QThread::run()
( f05fcc) pc: 47234e74 lr: 48bba5f8 sp: f05fd0 QThreadPrivate::start(void*)
( f05fdc) pc: 48bba5e0 lr: 0 sp: f05fe0 __pthread_create()

Thread 0×60f0e0 (Qt bearer thread)
( 1007f14) pc: 48bbd0b0 lr: 48bfe758 sp: f06c40 __pthread_yield_return()
( f06c4c) pc: 48bbd018 lr: 48bfe758 sp: f06c50 pthread_yield()
( f06dec) pc: 48bfe378 lr: 47536734 sp: f06df0 select()
( f06e38) pc: 4753657c lr: 47536f00 sp: f06e3c qt_safe_select(int, __fd_set*, __fd_set*, __fd_set*, timespec const*)
( f06e4c) pc: 47536ed8 lr: 475385d4 sp: f06e50 QEventDispatcherUNIX::select(int, __fd_set*, __fd_set*, __fd_set*, timespec*)
( f06ed8) pc: 475384e4 lr: 47538a8c sp: f06edc QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*)
( f06f08) pc: 475389c4 lr: 474c6cc0 sp: f06f0c QEventDispatcherUNIX::processEvents(QFlags)
( f06f1c) pc: 474c6c8c lr: 474c72c4 sp: f06f20 QEventLoop::processEvents(QFlags)
( f06f64) pc: 474c71bc lr: 4722f70c sp: f06f68 QEventLoop::exec(QFlags)
( f06f88) pc: 4722f65c lr: 4722f7d8 sp: f06f8c QThread::exec()
( f06f98) pc: 4722f7cc lr: 47234fdc sp: f06f9c QThread::run()
( f06fd4) pc: 47234e74 lr: 48bba5f8 sp: f06fd8 QThreadPrivate::start(void*)
( f06fe4) pc: 48bba5e0 lr: 5ffd90 sp: f06fe8 __pthread_create()

 
Sep 12, 2015 1:12pm
Avatar Chris Gransden (337) 1058 posts

If you download just Otter Browser again. I’ve changed it so it doesn’t do the update check.

 
Sep 12, 2015 2:02pm
Avatar John Ballance (21) 70 posts

Thanks
Runs up on iMx6. looking good, though I’ve already managed to crash it .

Is there a simple answer to the complaint that an issuer certificate for something locally looked up cannot be found?

 
Sep 12, 2015 2:47pm
Avatar Chris Gransden (337) 1058 posts

You get used to which sites crash after a while. It’s normally due to the Javascript engine. Also if you’re not using a RISC OS rom with the latest ‘PMP’ changes it could be due to running out of logical address space.

I’ve got a fix for the certificate complaints. Qt5 is using hard coded unix paths to look for the certificate authority file. I’ll upload an updated library which points to a valid RISC OS path and the ca-certificates.crt file from debian once I’ve done a bit more testing.

 
Sep 12, 2015 3:37pm
Avatar Rick Murray (539) 11793 posts

it could be due to running out of logical address space.

It uses that much memory? Safari (a WebKit browser) runs fairly nicely on my iPad Mini with only 512MiB RAM onboard.

 
Sep 12, 2015 4:19pm
Avatar Chris Gransden (337) 1058 posts

It uses that much memory? Safari (a WebKit browser) runs fairly nicely on my iPad Mini with only 512MiB RAM onboard.

Used logical address space != used physical memory.

Before ‘PMP’ most of the logical address space was used up on machines with 2GB memory. Even with 1GB it could run out if several programs used Dynamic areas.

 
Sep 12, 2015 4:20pm
Avatar Chris Gransden (337) 1058 posts

Is there a simple answer to the complaint that an issuer certificate for something locally looked up cannot be found?

The fixed library and included CA bundle is available here. Just merge it with !Boot.

 
Sep 12, 2015 5:04pm
Avatar David Pitt (102) 743 posts

The fixed library and included CA bundle is available here. Just merge it with !Boot.

Minor spelling mistake, that deposits libQt5Network into !ShredLibs

 
Sep 12, 2015 5:16pm
Avatar John Williams (567) 768 posts

Minor spelling mistake, that deposits libQt5Network into !ShredLibs

That !ShredLibs looks a bit destructive!

 
Sep 12, 2015 5:17pm
Avatar Chris Gransden (337) 1058 posts

Sorted. Now with the correct speeling. :-) Thanks.

 
Sep 12, 2015 8:10pm
Avatar Dave Higton (1515) 2926 posts

Well. RISC OS has a browser with Javascript capability! Congratulations, Chris!

But I’ve tried it on the BBxM, Iyonix and RPi, in that order (and all from one download, done on the BBxM, and shared via ShareFS).

On the BBxM, all that happened was: the desktop stopped updating, there was activity on the SSD for a few seconds, then a pause, then more SSD activity that didn’t stop. I gave up waiting after half an hour. It clearly wasn’t going to run.

Then I copied the downloads onto the Iyonix and installed it there. It ran fine – somewhat slowly, as you said, but successfully. I used it to access my LB-Link Ethernet wifi adaptor (you’ve probably seen the other thread – Otter will be an important tool for this sort of thing), and configure it to connect to a different AP. So it really does do what we need.

Then I copied the downloads to the RPi and installed it there. I was going to say that it just stopped the desktop from updating, but in fact the desktop has come back after a couple of minutes or so, sadly without any evidence of Otter running.

So only one success out of three so far, sadly.

 
Sep 12, 2015 9:28pm
Avatar Chris Mahoney (1684) 1920 posts

Pi B+ with RC14: Double-clicking the app resulted in the desktop not updating. I’ll give it a few more minutes and will edit this post if it comes back.

Edit: It loaded after about 7 minutes, and does appear to work (albeit extremely slowly).

 
Sep 12, 2015 9:36pm
Avatar Rick Murray (539) 11793 posts

[last edit/update: 00h07 CEST]

An application that loads a file of this type has not been found by the Filer. Blah-de-blah and try again.

It’s an ELF isn’t it? <clicky-clicky> Yup. <sigh>

Ah, it is a part of gccsdk-sharedlibs. Okay, I’ll install that and…

…wow, that’s a metric tonne of libraries there…

Okay, nothing is appearing on the screen. Lots of disc activity, first read/writes and now reading. Passing two three four five six (!) seven (?) minutes now and still reading. Is this a normal start-up or is this a one-off first time initialisation?

I’m using a 256MiB Pi Model B issue 2 with 170MiB free memory and a self-built ROM dating from… what was it? May? March? I forget. It predates ZeroPain, at any rate. Internet is via Vonets VAP11G WiFi adaptor. Pretty photos of it all on my blog (today’s entry).

Okay, this is taking a lesser eternity, so I’ll hit Save Reply and update when something actually happens.


Oh, nine minutes later we’re reading/writing instead of just reading and… nine and a half minutes, something appears (and the disc is continually being read?).

Right, RISC OS Open loads a little slower than on NetSurf, but looks okay and is laid out nicely.

David – don’t Alt-Break it. On my Pi it took nine and a half minutes to get started.

My blog loads, but the alignment of the right-hand column is off, it is as if the text is too large. Not a big deal right now, the same problem is evident in the Preferences window. That something like WebKit works on RISC OS is a big step forward.


I quit Otter, removed the support modules (and the HUGE ~93MiB Dynamic Area created for the Shared Libraries), and then restarted everything. Otter came up in about 12 seconds, and picked up where I left off (my blog, halfway down the page). That is a whole lot better than nine+ minutes!


Since people seem to think that copying to RAMdisc is the answer, I moved Otter, UnixFC, and UnixFont to a 52MiB RAMdisc and erased the Qt5 cache directory. Startup took about a minute.

Oops! Ctrl-F12 (TaskWindow) crashes Otter and now it’s refusing to start – twice failed to allocate memory in dynamic area for sprite area, then failed an assert "!image.isNull() in file qriscosbackingstore.cpp, line 233. I guess this is a polite way of saying I’m running out of available memory. ;-)

Since it has already started, everything moved from RAMdisc back to harddisc to free up that 52MiB of memory. It was getting “a bit tight” with only ~37MiB free!

And there you go. Continue session, and Otter returns with my blog.


Congratulations. In normal use, I have never had my free memory go below about 120MiB. Now? I think I have… oh, 39MiB free.


Holy crap! It’s slow and takes memory like you wouldn’t believe, but I’m not looking at my Yahoo! mailbox. On RISC OS!


Dare I? Dare I?

Oh what the hell. I’m going to have to delete Otter and copy the archives to USB key for storage (I can’t afford that much disc space right now) so let’s go for broke…

Trying to log into docs.google.com and the machine locks up with a request to fonts.gstatic.com and the drive activity LED hammering away. Whatever it is that creates these unbelievably long pauses (scanning fonts?) may become an big issue. I taskkilled Otter and copied UnixFC and UnixFont to RAMdisc but this has made no difference – I suspect the font that is being scanned is in the cache or something?
Went, had a bath, came back an hour and a half later, Otter (or UnixFC) was still busy.
Oh well.

 
Sep 12, 2015 9:37pm
Avatar Frederick Bambrough (1372) 764 posts

On the BBxM, all that happened was: the desktop stopped updating, there was activity on the SSD for a few seconds, then a pause, then more SSD activity that didn’t stop. I gave up waiting after half an hour. It clearly wasn’t going to run.

I found it works on the BB -xM if you copy UnixFC & UnixFont to RAM disc. I suspect it may also run without but will take a millennium to complete.

 
Sep 12, 2015 9:39pm
Avatar David Pitt (102) 743 posts

It’s a no go here too on the Raspberry Pi, with the ROM 09-Sep-15. The desktop appears stiffed but alt-Break works. The debug file is blank but a Shared Libraries DA of 93MB has been created.

P.S. Just tried with !Otter, !UnixFC & !UnixFont all on a RAM Disc and Otter has run. (Previously on SCSI or Fat32 disc it had been left for quite a while and never did start.)

P.P.S Rebooted the Pi and Otter now runs with all three components on SCSI.

 
Sep 12, 2015 9:41pm
Avatar Chris Mahoney (1684) 1920 posts

Copying !UnixFC and !UnixFont to a ram disc helps speed things up a bit.

Understatement of the year! This took it from about seven minutes down to less than one.

I created a relatively simple “map” site several years ago, where you can click on locations, zoom in, and query individual sites. It’s now working on RISC OS for the first time :)

 
Sep 12, 2015 9:59pm
Avatar Paul Porcelijn (2793) 1 post

With ARMX6 Otter works fairly well. Startup takes about 12 seconds.

 
Sep 12, 2015 10:00pm
Avatar Chris Gransden (337) 1058 posts

It looks like it is caused by the font cacheing in combination with slow disc media. To speed things up if you look inside !UnixFC there is an executable called fc-cache.
After first copying !UnixFC and !UnixFont to the ram disc and double clicking both, double click fc-cache. This will pre-create the cache files for all the fonts. Should only take a few seconds from ram disc. Once done copy the !UnixFC folder back to normal media.
Next time !Otter-browser starts up it should be much quicker as the fonts won’t need to be re-cached.

 
Sep 12, 2015 10:22pm
Avatar Dave Higton (1515) 2926 posts

I tried it on an RPi2 (944 MiB RAM) and it works there, so two successes out of 4.

How much RAM disc can one have that is big enough to speed Otter up, but small enough to leave enough RAM for Otter to run in?

I rebooted the first RPi to see how much RAM it has, and was surprised to see the value 192 MB as RO starts up. I presume that’s because some RAM is reserved by the pre-OS boot system for other stuff (graphics?) rather than a faulty RAM? Its something that I’ve not looked at in ages as there has always been oodles of RAM for what I need.

 
Sep 12, 2015 10:24pm
Avatar Rick Murray (539) 11793 posts

Dave – 192MiB RAM implies you have allocated 64MiB for the GPU.
Does this match the settings in config/txt?

Next page

Pages: 1 2 3 4 5 6 7 8

Reply

To post replies, please first log in.

Forums → Announcements →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Announce and discuss new hardware and software releases.

Voices

  • Chris Gransden (337)
  • rob andrews (112)
  • Leo Smiers (245)
  • John Ballance (21)
  • Rick Murray (539)
  • David Pitt (102)
  • John Williams (567)
  • Dave Higton (1515)
  • Chris Mahoney (1684)
  • Frederick Bambrough (1372)
  • Paul Porcelijn (2793)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys