Re: [Rpcemu] 0.8.9 freezing at shutdown

Matthew Howkins wrote:
>By the time you reach the shutdown freeze, RISC OS has fully shutdown itself...
 
Just a thought, would a work around be to disable the RISC OS 4.02 warning window?

This is done using !Configure->Windows as described (with screenshot) at the bottom of this page:

 

http://www.apdl.co.uk/riscworld/volume6/issue6/fsteps/chap14.htm

 

Shutdown may either still hang RISC OS, or RPCEmu when File->Exit is selected, but the shutdown process may have got a little further.

 

HTH,

 

Richard

Re: [Rpcemu] 0.8.9 freezing at shutdown

> >

> This issue with the freeze on shutdown is a known problem and was first
> reported back in January; it is only found when the "Reduce CPU Usage"
> option is enabled.

> At that time I posted:

>   "I can confirm this is a fault with RPCEmu. I understand what causes the
> problem, and I will see if I can include a fix for the next
> release."

> This is still true now.

OK, thanks. There is therefore one question I'd welcome being answered.

Is it 'safe' for me to go on as I have? i.e. to proceed to the shutdown
freeze and then simply end the process by closing the xfce window? I always
save all the files I've been working on and shut their windows before
starting the shutdown. As yet I've seen no signs of a problem, but I have
no idea if I have just been lucky!

Yes, this is safe. By the time you reach the shutdown freeze, RISC OS has fully shutdown itself - there should be no ill effects when you then close the window.

Matthew

Re: [Rpcemu] 0.8.9 freezing at shutdown

> > > To make things a bit clearer I've put a screengrab at
> > >
> > > http://jcgl.orpheusweb.co.uk/temp/freeze.jpeg
> >

> >
> This issue with the freeze on shutdown is a known problem and was first
> reported back in January; it is only found when the "Reduce CPU Usage"
> option is enabled.

> At that time I posted:

> "I can confirm this is a fault with RPCEmu. I understand what causes the
> problem, and I will see if I can include a fix for the next
> release."

> This is still true now.

OK, thanks. There is therefore one question I'd welcome being answered.

Is it 'safe' for me to go on as I have? i.e. to proceed to the shutdown
freeze and then simply end the process by closing the xfce window? I always
save all the files I've been working on and shut their windows before
starting the shutdown. As yet I've seen no signs of a problem, but I have
no idea if I have just been lucky!

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.9 freezing at shutdown

> When I press ctrl-shft-f12 I get the above box offerring the choices I
> describe. Doing a shutdown via the switcher does the same. Both freeze
> when "shutdown" is selected. The icon goes to the 'pressed' state but
> I don't get "ready to be switched off" replacing the choice I was
> offerred.

In RPCEmu0.8.9/RO 5.19, ctrl-shft-f12 leads to a window saying that 'the
computer is now ready to be switched off' and gives the single option to
'Restart'. Presumably the OS has allowed running applications to quit,
so that closing the emulator window, at that point, is safe.

However, in RPCEmu0.8.9/RO 4.39 - my apologies, I now see that I was
mistaken in my previous post - ctrl-shft-f12 leads to a window giving
the options Off/Restart/Shutdown/Cancel. It is clicking Shutdown, which
leads to 'the computer is now ready to be switched off' so, in itself,
ctrl-shft-f12, doesn't put the machine in a safe state for its window to
be closed. I suppose that the same would apply to RO 4.02.

> To make things a bit clearer I've put a screengrab at
>
> http://jcgl.orpheusweb.co.uk/temp/freeze.jpeg

[snip]

> It shows the box the emulator puts up when I do shift-control-F12. As
> shown, it is just after I clicked on the "shutdown" icon which you can
> see in its depressed state.
>
> At that point nothing else happens.

[snip]

> I am wondering if it does close down further

If RO 4.02 is similar to RO 4.39, it should lead to 'the computer is now
ready to be switched off', so it seems that there _is_ a problem.

This issue with the freeze on shutdown is a known problem and was first reported back in January; it is only found when the "Reduce CPU Usage" option is enabled.

At that time I posted:

  "I can confirm this is a fault with RPCEmu. I understand what causes the problem, and I will see if I can include a fix for the next
release."

This is still true now.

Matthew

Re: [Rpcemu] 0.8.9 freezing at shutdown

On 30 Mar 2012, Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

[snip]

> When I press ctrl-shft-f12 I get the above box offerring the choices I
> describe. Doing a shutdown via the switcher does the same. Both freeze
> when "shutdown" is selected. The icon goes to the 'pressed' state but
> I don't get "ready to be switched off" replacing the choice I was
> offerred.

In RPCEmu0.8.9/RO 5.19, ctrl-shft-f12 leads to a window saying that 'the
computer is now ready to be switched off' and gives the single option to
'Restart'. Presumably the OS has allowed running applications to quit,
so that closing the emulator window, at that point, is safe.

However, in RPCEmu0.8.9/RO 4.39 - my apologies, I now see that I was
mistaken in my previous post - ctrl-shft-f12 leads to a window giving
the options Off/Restart/Shutdown/Cancel. It is clicking Shutdown, which
leads to 'the computer is now ready to be switched off' so, in itself,
ctrl-shft-f12, doesn't put the machine in a safe state for its window to
be closed. I suppose that the same would apply to RO 4.02.

> To make things a bit clearer I've put a screengrab at
>
> http://jcgl.orpheusweb.co.uk/temp/freeze.jpeg

[snip]

> It shows the box the emulator puts up when I do shift-control-F12. As
> shown, it is just after I clicked on the "shutdown" icon which you can
> see in its depressed state.
>
> At that point nothing else happens.

[snip]

> I am wondering if it does close down further

If RO 4.02 is similar to RO 4.39, it should lead to 'the computer is now
ready to be switched off', so it seems that there _is_ a problem.

Tony

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9. and !Photodesk - update

In message <7468a97652.George@tiscali..co.uk>
george greenfield <george.greenfield@tiscali.co.uk> wrote:

> In message <dce67f7452.George@tiscali..co.uk> you wrote:
>
>> In message <20120322144641.GC21730@spod.org>
>> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>>
>>> On Thu, Mar 22, 2012 at 02:14:44PM +0000, george greenfield wrote:
>>>> Is anyone running Photodesk (3.09 or 3.10) successfully on 0.8.9?
>>>>
>>>> I'm getting an 'insufficient memory (case 4)' error in a task window
>>>> when attempting to save retouched JPEGs since upgrading from 0.8.8.
>>>> I've set 256MB of RAM and a large image cache (15x the size of the
>>>> retouched file).
>>>
>>> Try reducing the memory to 128MB and retesting, it appears many versions
>>> of RISC OS have issues with 256MB.
>>>
>>> Peter
>>>
>> Problem persists with memory reduced to 128MB, unfortunately. I tried
>> the previous version of Photodesk, 3.09, on an earlier installation of
>> RPCEmu 0.8.8/4.02 (same PC) and the retouched JPEG saved normally.
>>
>> George
>>
> RPCEmu 0.8.9 has been exonerated! It turns out that what you MUSTN'T
> do is add Photodesk to Resources:$.Apps (which is what I had done a
> few days previously). It was only when I copied across my current copy
> of !Boot into the 0.8.8 installation, whereupon the problem magically
> reappeared, that I realized what the actual cause might be. Photodesk
> now runs (and saves - touching wood) happily from Utilities in
> 0.8.9/4.02. I've left RAM at 128MB just in case, however.
>
> George
>
After considerable experimentation, I can summarise the functioning of
Photodesk (at least on my current RPCEmu setup*) as follows, if anyone
is interested:

1. Photodesk runs and saves correctly from Resources:$.Apps - what I
said above is WRONG.

2. Photodesk will save Sprites and Tiffs (I haven't tested other
formats than these and JPEGs as I don't use them).

3. Photodesk will save JPEGs /providing/ the 'Optimise' box is not
ticked. If the 'Optimise' box is ticked, the save will invariably fail
with the 'insufficient memory (case 4)' error message referred-to
above. The quality percentage selected is not a factor either way, as
far as I can establish.

This is not a bug in Photodesk; I've made the same tests on my Iyonix
without encountering the insufficient memory issue. Whether it's a
peculiarity of RPCEmu in general or my particular installation,
remains to be determined. There was no difference in the behaviour of
0.8.8 and 0.8.9. on this system. I didn't test on 0.8.X/5.17 because
Photodesk will not install on a HostFS drive.

(*RPCEmu 0.8.9 + RO 4.02 on Windows 7 (64-bit), 128MB RAM, Recompiler
mode)

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.9 freezing at shutdown

In article <3aa5a37852.old_coaster@old_coaster.yahoo.co.uk>, Tony Moore
<old_coaster@yahoo.co.uk> wrote:
> On 30 Mar 2012, Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> > I've continued to use 0.8.9 to write an article as a test, and overall
> > it has worked nicely so far.
> >
> > The main feedback I want to give at this point is as follows:
> >
> > When I try to shutdown the 'Risc PC' the icon depresses, but then the
> > emulation freezes.

> You don't say which RISC OS version you are using, nor the host OS.

RO 4.02 running on Xubuntu 11.10

> Here, RPCEmu0.8.9/RO4.39 and RPCEmu0.8.9/RO5.19 both run on a Win7 host,
> without problem. On neither system can I find a shutdown icon.

RO 4.02 offers me a box with a choice of "shutdown" or "cancel".

> I believe that the safest way of exiting either emulator is to press
> ctrl-shft-f12 and, when the 'computer is now ready to be switched off'.
> close the Windows container.

When I press ctrl-shft-f12 I get the above box offerring the choices I
describe. Doing a shutdown via the switcher does the same. Both freeze when
"shutdown" is selected. The icon goes to the 'pressed' state but I don't
get "ready to be switched off" replacing the choice I was offerred.

To make things a bit clearer I've put a screengrab at

http://jcgl.orpheusweb.co.uk/temp/freeze.jpeg

I've scaled this down a bit and made it a jpeg to reduce the size of
the file. It shows the box the emulator puts up when I do
shift-control-F12. As shown, it is just after I clicked on the
"shutdown" icon which you can see in its depressed state.

At that point nothing else happens. However the emulator mouse still
tries to follow the OS (Xubuntu) mouse around. And I can move the
OS mouse pointer outside the RPCEmu window and it works correctly.
But no mouse actions or keys affect what is then inside the emulator.
All I can do is close down the emulator by clicking on the close icon
on the Xfce/ROX window in which it is running.

I am wondering if it does close down further, but can't update the
display in the emulator window. However as reported earlier, one
CPU goes to 100 percent when the shutdown freezes, and stays that
way until I close the window and end the linux process.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.9 freezing at shutdown

On 30 Mar 2012, Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> I've continued to use 0.8.9 to write an article as a test, and overall
> it has worked nicely so far.
>
> The main feedback I want to give at this point is as follows:
>
> When I try to shutdown the 'Risc PC' the icon depresses, but then the
> emulation freezes.

You don't say which RISC OS version you are using, nor the host OS.

Here, RPCEmu0.8.9/RO4.39 and RPCEmu0.8.9/RO5.19 both run on a Win7 host,
without problem. On neither system can I find a shutdown icon.

I believe that the safest way of exiting either emulator is to press
ctrl-shft-f12 and, when the 'computer is now ready to be switched off'.
close the Windows container.

Tony

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] 0.8.9 freezing at shutdown

I've continued to use 0.8.9 to write an article as a test, and overall it
has worked nicely so far.

The main feedback I want to give at this point is as follows:

When I try to shutdown the 'Risc PC' the icon depresses, but then the
emulation freezes. I always close all files I'm working on before doing
this, so I just then shut the emulator window and it then quits OK.

However I've been monitoring the CPU loading as I was curious to see how
this varies when using TW to write a document, add graphics, etc.

I noticed this morning that the shutdown freeze causes one CPU to go to 100
percent loading and it stays like that until I shut the emulator window. So
I assume the shutdown is freezing the emulation by causing some kind of
endless loop.

Another minor point which struck me as interesting:

The machine I'm using has (IIUC) two CPU cores that pretend to be four
CPUs. In 'full steam ahead mode' the 0.8.9 does as 0.8.8 and the 100
percent 'red queen's race' switches back and forth every now and then
between 'cpu 1' and 'cpu 3'. i.e. it seems to use one pretend CPU from each
of the real ones.

But with the load-saving enabled, it switches around all four 'CPUs' quite
happily. Hard to say the average loading as the values keep jumping briefly
up to near 100 percent for a CPU, only to fall back a second or so later.
But the loading overally seems well below 'flat out'. Yet the behaviour
seems as responsive. (FWIW I still get the 'roller skating' behaviour of
the mouse pointer some of the time. Bit weird, but something I get used to,
and seems harmless.) So the effect of using the load-saving is quite
significant in terms of avoiding loading the CPUs. Excellent job! :-) Hence
I'm not really bothered by the freeze on shutdown, but I hope it is
diagnosed and fixed in due course as it is curious.

Cheers,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Patch: handle new variable "LIBDIR" in pkgconf template processing

Am Mi, 29.02.2012, 22:54 schrieb m0n0:

> this patch adds support for a new variable - "LIBDIR" within .pc
> template files.

Hello,

can we please discuss why this patch was rejected and how to improve it so
that the described problems can be fixed?

thanks,
m

Re: Digest mode

In message <52782a9951evanallen@talktalk.net>
<evanallen@talktalk.net> wrote:

> In article <a730017852.George@tiscali..co.uk>, george greenfield
> <george.greenfield@tiscali.co.uk> wrote:
>> I did enable it; it arrives; I tend to ignore it.
>
> Perhaps you ought to disable it?
>
You mean I ought to take control of my life? Steady on...

--
george greenfield

Re: Digest mode

In article <a730017852.George@tiscali..co.uk>, george greenfield
<george.greenfield@tiscali.co.uk> wrote:
> I did enable it; it arrives; I tend to ignore it.

Perhaps you ought to disable it?

--
Barry A.

Re: Digest mode

In article
<8d001425ead6b919cdaeed0ce55f3f6b-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUNBAjBbXkNGV10MQV13B0tTWzBeQkYBX1tcRlFV-webmailer2@s,
m0n0 <ole@monochrom.net> wrote:
> Am Donnerstag, den 29.03.2012, 11:55 +0200 schrieb george greenfield
> <george.greenfield@tiscali.co.uk>:

> > I too prefer individual messages, for same reasons as Richard states.
> > I tend to ignore the digest, TBH.

> Sorry, I don't understand.
> Digest mode can be selected by the user, right? So if you don't enable
> it, you won't get
> it. How can you ignore something which isn't there?

> Greets,
> m

Trouble is, a lot of folks are very bad at snipping, so when they reply to
a digest version, we none digest receivers can a get a bucket load of sh
one tee as well.

Dave

--

Dave Triffid

Re: URGENT: please check your compilers

On 29/03/2012 14:28, Daniel Silverstone wrote:
> On Wed, Mar 28, 2012 at 10:51:12PM +0100, Daniel Silverstone wrote:
> [snip]
>
> Everyone who might have had issues has responded favourably, so I have
> committed the change to libwapcaplet. Remember to recompile the world :-)

BTW, it's a good opportunity to test the top-level makefile...

$ make platform

should build everything for platform (gtk, beos...)

$ make platform netsurf will only build netsurf to speed up things

And of course

$ make clean

François.

Re: URGENT: please check your compilers

On Wed, Mar 28, 2012 at 10:51:12PM +0100, Daniel Silverstone wrote:
[snip]

Everyone who might have had issues has responded favourably, so I have
committed the change to libwapcaplet. Remember to recompile the world :-)

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

In message <5277a0e2cejcgl@audiomisc.co.uk>
Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> In article <51e99d7752.George@tiscali..co.uk>,
> george greenfield <george.greenfield@tiscali.co.uk> wrote:
>> In message <52777b6159jcgl@audiomisc.co.uk>
>>etc.
>
>> Glad the MDFs arrived. Would you send me the driver with 1600 x 900
>> included? I find 1680 x 1050 slightly too deep, and 1440 x 900
>> slightly too small; 1600 x 900 should be (to quote Goldilocks) 'just
>> right'.
>
> Attached. The MDF does go up to 1980 x 1080. But that would totally fill
> the display here!
>
Many thanks, Jim: 1600 x 900 works a treat, and is the best compromise
between RISC OS working area and access to the larger PC screen
(including taskbar) that I've yet tried.

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Digest mode

In message <8d001425ead6b919cdaeed0ce55f3f6b-EhVcX1lFRQVaRwYcDTpQCEFdd
QZLVF5dQUNBAjBbXkNGV10MQV13B0tTWzBeQkYBX1tcRlFV-webmailer2@server02.webmailer.ho
steurope.de>
m0n0 <ole@monochrom.net> wrote:

> Am Donnerstag, den 29.03.2012, 11:55 +0200 schrieb george greenfield
> <george.greenfield@tiscali.co.uk>:
>
>> I too prefer individual messages, for same reasons as Richard states.
>> I tend to ignore the digest, TBH.
>
>
> Sorry, I don't understand.
> Digest mode can be selected by the user, right? So if you don't enable
> it, you won't get
> it. How can you ignore something which isn't there?
>
> Greets,
> m
>
I did enable it; it arrives; I tend to ignore it.

George

--
george greenfield

Wakefield 2012 RISC OS Show - Guide information.

Hi Steve,

Here's are some details for the show guide entry for NetSurf:

Name: The NetSurf Developers
Web site: http://www.netsurf-browser.org/

Information: We develop NetSurf, an open source web browser with
RISC OS support.

If you're a NetSurf user, please stop by our stand
and let us know how you find it. Even if you're not
a user, come by to see what you're missing!

We'll have several developers on-hand to demo features
and discuss both future plans and current issues.

Cheers,

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

[StevenB@wrocc.org.uk: Wakefield 2012 RISC OS Show - Guide information.]

----- Forwarded message from StevenB@wrocc.org.uk -----

X-Virus-Scanned: Debian amavisd-new at parsifal.org.uk
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 required=6.31 tests=[none]
X-Yahoo-Newman-Id: 978945.33951.bm@omp1004.bt.mail.ird.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 5s2RlhAVM1kEIeUJtUVvLMgd0gqpSGjP7RU0SnWlqS.3Qe7
zjvRRXlCieib84P.bZ6JaIxJobswF8wdRiPe1T431i1cGHT7ZB632tvRuE_l
PdldY3WdJkZMtPMO6XnJ5AmspUj1szBwlXDNq0.M90m8Y8y2g7OdjbRrHX3H
l7hCJkxqXhGA_7bRGuwvTzAhS2gdqIq0ZHvg_f043yuVD7kaDdi242F7XEtR
duIYzMlM_E60aByIH2NHGI9BUQg9Wa9x6i3NdEnOAwl4MgBBybcPqBbq9dZw
Outgsjokdz5S9LOd2exNBUKrXuCAKHo9zD2awjuV4NEWBaB.65sev4fAa_i0
hWP7EP4nMJbY0.90lQ04xct_9yIrFBQK_1E5nWyR_quO3XxzzRW8PwQk9o_O
8mm35MrOx9BVBXs2Eed.1hnA-
X-Yahoo-SMTP: Bxg38yOswBD2Jvld6BnPxHjIy5zzYjLv5nrxEmSUqJ6vEsuhXkxz
From: StevenB@wrocc.org.uk
To: chris@cjemicros.co.uk, mike_k_cook@yahoo.co.uk, dllm@usa.net,
srevill@riscosopen.org, bavison@riscosopen.org,
ahodgkinson@riscosopen.org, trevor.johnson@laposte.net,
support@sinenomine.co.uk, vince@softrock.co.uk,
richard@orpheusinternet.co.uk, ajr@rcomp.co.uk, riscos@luafox.com,
jim@archivemag.co.uk, organizer@blueyonder.co.uk,
keith.dunlop@usablerange.co.uk, help@netsurf-browser.org,
martin@mw-software.com
Subject: Wakefield 2012 RISC OS Show - Guide information.
Mail-Followup-To: chris@cjemicros.co.uk, mike_k_cook@yahoo.co.uk,
dllm@usa.net, srevill@riscosopen.org, bavison@riscosopen.org,
ahodgkinson@riscosopen.org, trevor.johnson@laposte.net,
support@sinenomine.co.uk, vince@softrock.co.uk,
richard@orpheusinternet.co.uk, ajr@rcomp.co.uk, riscos@luafox.com,
jim@archivemag.co.uk, organizer@blueyonder.co.uk,
keith.dunlop@usablerange.co.uk, help@netsurf-browser.org,
martin@mw-software.com, StevenB@wrocc.org.uk
X-Pepperfish-Spamscore: -2.9
X-Pepperfish-Spamlevel: --
X-Pepperfish-SpamReport: BAYES_00=-1.9, PPF_USER_AGENT=-1,
RCVD_IN_DNSWL_NONE=-0.0001

Dear Exhibitors

In order for the WROCC to complete the Show Guide for inclusion on our web
site I should be gratefull for the following information please:

Contact details - Name, 'phone, web site and email.

Product offers, special or otherwise that you want to promote or
emphasise.

Any other information you would like included.

The sooner you reply then the sooner the information gets included, all of
which aids the advertising of the event.

Thankyou.

Best Regards

--
Steve Bass

----- End forwarded message -----

Digest mode

Am Donnerstag, den 29.03.2012, 11:55 +0200 schrieb george greenfield
<george.greenfield@tiscali.co.uk>:

> I too prefer individual messages, for same reasons as Richard states.
> I tend to ignore the digest, TBH.

Sorry, I don't understand.
Digest mode can be selected by the user, right? So if you don't enable
it, you won't get
it. How can you ignore something which isn't there?

Greets,
m

Re: netsurf-users Digest, Vol 59, Issue 6

In message <b4b4f97752.ricp@user.minijem.plus.com>
Richard Porter <ricp@minijem.plus.com> wrote:

> On 29 Mar 2012 Tricia Garner wrote:
>
>> How can one loooong email with all the replies in all the threads
>> which people haven't snipped repeated again and again possibly be
>> less annoying than 40 emails? Just curious.
>
> I quite agree. With 40 messages properly threaded it's easy just to
> ignore topics that you're not interested in. With digests you have to
> plough through everything, and then of course you have the problem of
> how to post a reply.
>
I too prefer individual messages, for same reasons as Richard states.
I tend to ignore the digest, TBH.

George

--
george greenfield

Digest mode

Am Donnerstag, den 29.03.2012, 11:21 +0200 schrieb Richard Porter
<ricp@minijem.plus.com>:

> With digests you have to
> plough through everything, and then of course you have the problem of
> how to post a reply.

You can't talk for everyone. It depends on several things: for example
personal taste
and the application that you use.

For me it is more easy to look at the digest summary and see if there
is something that is interesting.
If there is something interesting, I'm going to take a further look at
the message.

Greets,
m

Re: netsurf-users Digest, Vol 59, Issue 6

On 29 Mar 2012 Tricia Garner wrote:

> How can one loooong email with all the replies in all the threads
> which people haven't snipped repeated again and again possibly be
> less annoying than 40 emails? Just curious.

I quite agree. With 40 messages properly threaded it's easy just to
ignore topics that you're not interested in. With digests you have to
plough through everything, and then of course you have the problem of
how to post a reply.

--
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: netsurf-users Digest, Vol 59, Issue 6

In article <5277f53bddtricia@orchid-squad.org.uk>,
Tricia Garner <tricia@orchid-squad.org.uk> wrote:
> On 26 Mar, in article
> <8f18b3c749ca5517d1f25a4db079e5d1-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUNBAjBeX15ZVF0WXVloCVQ6XFxcQ0IDWFhdQg==-webmailer2@s,
> m0n0 <ole@monochrom.net> wrote:
> > Am Montag, den 26.03.2012, 00:37 +0200 schrieb Tim Hill
> > <tim@timil.com>:

> > > Why's it there? Are there still people on dialup who need it?

> > Generally this feature is offered by the Mail list managers to
> > provide users an option limit the amount of mails they get. This
> > has nothing to do with dialup. It's just less annoying to get 1
> > mail once a day, instead of getting 40 mails...

> > I'm subscribed to several mail lists and I like the digest feature.

> > Greets,
> > m

> How can one loooong email with all the replies in all the threads
> which people haven't snipped repeated again and again possibly be
> less annoying than 40 emails? Just curious.

It is a matter of personal preference. For me I prefer the one long
digest rather than many emails. Obviously others prefer all the single
emails.

Re: netsurf-users Digest, Vol 59, Issue 6

On 26 Mar, in article
<8f18b3c749ca5517d1f25a4db079e5d1-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUNBAjBeX15ZVF0WXVloCVQ6XFxcQ0IDWFhdQg==-webmailer2@s,
m0n0 <ole@monochrom.net> wrote:
> Am Montag, den 26.03.2012, 00:37 +0200 schrieb Tim Hill
> <tim@timil.com>:

> > Why's it there? Are there still people on dialup who need it?

> Generally this feature is offered by the Mail list managers to
> provide users an option limit the amount of mails they get. This
> has nothing to do with dialup. It's just less annoying to get 1
> mail once a day, instead of getting 40 mails...

> I'm subscribed to several mail lists and I like the digest feature.

> Greets,
> m

How can one loooong email with all the replies in all the threads
which people haven't snipped repeated again and again possibly be
less annoying than 40 emails? Just curious.

I know subscribers on this list are good at trimming quotes, but
there are plenty of others where it just doesn't happen.

--

Tricia

These taglines aren't always all that interesting...

Re: netsurf-users Digest, Vol 59, Issue 6

On 25 Mar at 18:08, Rob Kendrick <rjek@netsurf-browser.org> wrote:

> On Sun, Mar 25, 2012 at 04:41:24PM +0100, Allan Bennett wrote:
> > In message
> > <31ef1ff0f8d057348bf4f9b1bfc0039a@mwinf5c65.me-wanadoo.net>
> > netsurf-users-request@netsurf-browser.org wrote:
>
> <snip>
>
> > > When replying, please edit your Subject line so it is more
> > > specific than "Re: Contents of netsurf-users digest..."
> >
> > Thanks for your replies - now have the problem sorted:
>
> Please don't do this. In fact, I'm tempted to disable digest support
> on the mailing list, because nobody ever gets this right.

seconded.

--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/

Re: URGENT: please check your compilers

On 28/03/2012 23:51, Daniel Silverstone wrote:
> Hi,
>
> I want to inline a bunch of libwapcaplet in order to allow for greater
> efficiency throughout our codebase.
>

Works for me(tm):

$ gcc -pedantic -c test-braced-groups.c
/boot/home/test-braced-groups.c: In function `foo':
/boot/home/test-braced-groups.c:3: warning: ANSI C forbids braced-groups
within expressions
$ gcc -c test-braced-groups.c
$ g++ -pedantic -c test-braced-groups.cpp
/boot/home/test-braced-groups.cpp: In function `int foo()':
/boot/home/test-braced-groups.cpp:3: warning: ANSI C++ forbids
braced-groups within expressions
$ g++ -c test-braced-groups.cpp
$

François.

Re: URGENT: please check your compilers

On 28/03/2012 23:51, Daniel Silverstone wrote:
> return ({ int a = 1; int b = 2; a + b; });

I've used this constructs in defines many times on BeOS without trouble
IIRC, I'll have check anyway.

François.

Re: URGENT: please check your compilers

On Wed, 28 Mar 2012 22:51:12 +0100, Daniel Silverstone wrote:

> If everyone's okay with it, then I'll make the changes to the libs (to disable
> pedantic) and then make the wapcaplet change [which will require a full rebuild
> because it's an ABI change of significant proportions]. I'd like to decide one
> way or the other by the weekend, so can people please check and report to the
> list their findings.

Perfectly happy here, same as you get:

9.RAM Disk:> gcc -pedantic -c test.c
test.c: In function 'foo':
test.c:3: warning: ISO C forbids braced-groups within expressions
9.RAM Disk:> gcc -c test.c
9.RAM Disk:> gcc --version
gcc (GCC) 4.2.4 (adtools build 20090118)

Chris

URGENT: please check your compilers

Hi,

I want to inline a bunch of libwapcaplet in order to allow for greater
efficiency throughout our codebase.

A quick test here suggests we're in for around 1.5% improvement in speed by
inlining this stuff. Unfortunately it will rely on a C feature called
'braced-groups' which ISO C/C++ forbids. GCC normally allows them unless you
pass -pedantic (which we do for somethings right now, so we'd have to stop
doing that) but I'm unsure if everyone's compilers will support them.

Since libwapcaplet's header is exposed to frontends, we need to be certain that
the unusual compilers such at the obj-c stuff on the cocoa frontend and the g++
on the beos/haiku one allow braced-groups.

A simple test could be:

petitemort% cat test.c
int foo()
{
return ({ int a = 1; int b = 2; a + b; });
}
petitemort% gcc -pedantic -c test.c
test.c: In function 'foo':
test.c:3:9: warning: ISO C forbids braced-groups within expressions [-pedantic]
petitemort% gcc -c test.c
petitemort%

In the example above, with pedantic on, the warning is generated, but with it
off, it's not. Now my GCC is modern and I'm on amd64 so I'm asking everyone to
check that their target compilers support the above.

If everyone's okay with it, then I'll make the changes to the libs (to disable
pedantic) and then make the wapcaplet change [which will require a full rebuild
because it's an ABI change of significant proportions]. I'd like to decide one
way or the other by the weekend, so can people please check and report to the
list their findings.

Thanks,

Daniel.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

In article <51e99d7752.George@tiscali..co.uk>,
george greenfield <george.greenfield@tiscali.co.uk> wrote:
> In message <52777b6159jcgl@audiomisc.co.uk>
>etc.

> Glad the MDFs arrived. Would you send me the driver with 1600 x 900
> included? I find 1680 x 1050 slightly too deep, and 1440 x 900
> slightly too small; 1600 x 900 should be (to quote Goldilocks) 'just
> right'.

Attached. The MDF does go up to 1980 x 1080. But that would totally fill
the display here!

> In general I'm surprised you've had problems with modes; my setup here
> (4.02 on 0.8.9, running on W7 64-bit) deals quite happily with mode
> changes. Presumably you've increased the VRAM settings radically as
> suggested here
> http://www.riscos.info/pipermail/rpcemu/2011-October/001391.html

Yes. I increased all the bandlimit values by a factor of 10 some time ago.

At present I'm not sure what has been causing the various errors. It may be
the large modes, or something else. I'll experiment again if after various
other changes they cease or become rare. But for now, if it works OK, 1280
x 1024 actually suits me OK as per an old AKF MDF.

Here is the LG1920 MDF that I used along with the ones you sent.

# Monitor description file for GSM ce00
# Created by Decode EDID Version 1.2

# Max Viewable H 30 cm / 11.7 inch
# Max Viewable V 51 cm / 19.9 inch
# Diaganol Viewable 59.2 cm / 23.1 inch
#
# Line Rate: 30-83kHz
# Frame Rate: 56-75Hz
# Max Dot Rate: 170MHz
file_format:1
monitor_title:LG 1080p HD screen
DPMS_state:3

# Mode: VESA 1024 x 768 @ 75Hz
# Bounds: H 60.02kHz, V 75.03Hz DClock 78.75MHz
startmode
mode_name:1024 x 768
x_res:1024
y_res:768
pixel_rate:78750
h_timings:96,176,0,1024,0,16
v_timings:3,28,0,768,0,1
sync_pol:0
EndMode

# Mode: VESA 1024 x 768 @ 70Hz
# Bounds: H 56.48kHz, V 70.07Hz DClock 75.00MHz
startmode
mode_name:1024 x 768
x_res:1024
y_res:768
pixel_rate:75000
h_timings:136,144,0,1024,0,24
v_timings:6,29,0,768,0,3
sync_pol:3
EndMode

# Mode: VESA 800 x 600 @ 75Hz
# Bounds: H 46.88kHz, V 75.00Hz DClock 49.50MHz
startmode
mode_name:800 x 600
x_res:800
y_res:600
pixel_rate:49500
h_timings:80,160,0,800,0,16
v_timings:3,21,0,600,0,1
sync_pol:0
EndMode

# Mode: VESA 800 x 600 @ 72Hz
# Bounds: H 48.08kHz, V 72.19Hz DClock 50.00MHz
startmode
mode_name:800 x 600
x_res:800
y_res:600
pixel_rate:50000
h_timings:120,64,0,800,0,56
v_timings:6,23,0,600,0,37
sync_pol:0
EndMode

# Mode: VESA 800 x 600 @ 60Hz
# Bounds: H 37.88kHz, V 60.32Hz DClock 40.00MHz
startmode
mode_name:800 x 600
x_res:800
y_res:600
pixel_rate:40000
h_timings:128,88,0,800,0,40
v_timings:4,23,0,600,0,1
sync_pol:0
EndMode

# Mode: VESA 640 x 480 @ 75Hz
# Bounds: H 37.50kHz, V 75.00Hz DClock 31.50MHz
startmode
mode_name:640 x 480
x_res:640
y_res:480
pixel_rate:31500
h_timings:64,120,0,640,0,16
v_timings:3,16,0,480,0,1
sync_pol:3
EndMode

# Mode: VESA 640 x 480 @ 60Hz
# Bounds: H 31.47kHz, V 59.94Hz DClock 25.18MHz
startmode
mode_name:640 x 480
x_res:640
y_res:480
pixel_rate:25175
h_timings:96,48,0,640,0,16
v_timings:2,33,0,480,0,10
sync_pol:3
EndMode

# Mode: GEN 1152 x 864 @ 75Hz
# Bounds: H 67.72kHz, V 75.00Hz DClock 104.03MHz
startmode
mode_name:1152 x 864
x_res:1152
y_res:864
pixel_rate:104025
h_timings:120,192,0,1152,0,72
v_timings:3,35,0,864,0,1
sync_pol:0
EndMode

# Mode: GEN 1280 x 960 @ 75Hz
# Bounds: H 75.22kHz, V 75.00Hz DClock 129.99MHz
startmode
mode_name:1280 x 960
x_res:1280
y_res:960
pixel_rate:129988
h_timings:136,224,0,1280,0,88
v_timings:3,39,0,960,0,1
sync_pol:0
EndMode

# Mode: GEN 1152 x 864 @ 60Hz
# Bounds: H 53.70kHz, V 60.00Hz DClock 81.62MHz
startmode
mode_name:1152 x 864
x_res:1152
y_res:864
pixel_rate:81624
h_timings:120,184,0,1152,0,64
v_timings:3,27,0,864,0,1
sync_pol:0
EndMode

# Mode: GEN 1280 x 1024 @ 75Hz
# Bounds: H 80.25kHz, V 75.00Hz DClock 138.67MHz
startmode
mode_name:1280 x 1024
x_res:1280
y_res:1024
pixel_rate:138672
h_timings:136,224,0,1280,0,88
v_timings:3,42,0,1024,0,1
sync_pol:0
EndMode

# Mode: GEN 1280 x 1024 @ 60Hz
# Bounds: H 63.60kHz, V 60.00Hz DClock 108.88MHz
startmode
mode_name:1280 x 1024
x_res:1280
y_res:1024
pixel_rate:108883
h_timings:136,216,0,1280,0,80
v_timings:3,32,0,1024,0,1
sync_pol:0
EndMode

# 1600 x 900 (52.2 kHz, 55 Hz)
startmode
mode_name:1600 x 900
x_res:1600
y_res:900
pixel_rate:108000
h_timings:96,34,236,1600,60,44
v_timings:2,32,0,900,0,11
sync_pol:3
endmode

# Mode: DTD 1920 x 1080 @ 59Hz
# Bounds: H 66.59kHz, V 59.93Hz DClock 138.50MHz
startmode
mode_name:1920 x 1080
x_res:1920
y_res:1080
pixel_rate:138500
h_timings:32,80,0,1920,0,48
v_timings:5,23,0,1080,0,3
sync_pol:1
EndMode

#End

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

In message <52777b6159jcgl@audiomisc.co.uk>
Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> In article <1c09227752.George@tiscali..co.uk>, george greenfield
> <george.greenfield@tiscali.co.uk> wrote:
>> In message <5277065e71jcgl@audiomisc.co.uk> Jim Lesurf
>> <jcgl@audiomisc.co.uk> wrote:
>
>> >
>> > Yes, please!
>
>> >
>> Couldn't zip the MDFs as they are read-only, so have attached them 'as
>> is'. Hope they survive! Filetype is DOS in case you need to restore it.
>> Good luck!
>
> Thanks. The files came through OK. :-)
>
> I have done some experiments with those files this morning, and come up
> with some results that puzzle me...
>
> I also had 'Duh!' moment this morning as I suddenly realised that maybe the
> screen mode file(s) for my Iyonix might also work given that rpcemu has
> relaxed the old limits on vram. So I also experimented with the MDF for my
> 1920 x 1080 screen, which also includes lower modes like 1600 x 900, etc.

Glad the MDFs arrived. Would you send me the driver with 1600 x 900
included? I find 1680 x 1050 slightly too deep, and 1440 x 900
slightly too small; 1600 x 900 should be (to quote Goldilocks) 'just
right'.

In general I'm surprised you've had problems with modes; my setup here
(4.02 on 0.8.9, running on W7 64-bit) deals quite happily with mode
changes. Presumably you've increased the VRAM settings radically as
suggested here
http://www.riscos.info/pipermail/rpcemu/2011-October/001391.html

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

Update to previous emails...

I've changed to using one of the old acorn 'AKF' mode files that gives 1280
x 1024 at 70Hz. I have also now switched on the 'idle' behaviour. And I've
changed to using 256 megs of ram. I suddenly realised I'd only been set to
32 megs by default. So perhaps some of the errors I got were due to lack of
memory so far as the 'machine' perceived. (?)

Pleased to say that the 'idle' works neatly during use. If I type into a TW
window the CPU useage wanders up and down as I type, falling back to just a
few percent when I've not been doing much. The mouse continues to be
responsive, so I don't get the old problem of missing mouse events.

The only snag is one that I think others have reported. When I do a
shutdown the machine seems to 'freeze' with the shutdown button on the
dialogue window presenting the 'depressed' state. However since I always
close all my files before doing a shutdown then - unless someone tells me
otherwise - I'll assume this is in practice a cosmetic problem, not one
that may foul up the emulator or work created using it.

The last few uses haven't given any 'random' errors of the kind I reported
earlier. Fingers crossed. I've continued to use rpcemu to write a document
and fiddle with drawfile, etc. But am also out a copy of the resulting
files every now and then to have 'safe' on my Iyonix so I won't lose if a
serious problem crops up. :-)

Cheers,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

On 28 Mar, jcgl@audiomisc.co.uk wrote:
>

> With that it seems to bootup OK. Although I've only tried twice so far,
> so I may have been lucky! If/when I get other errors I'll report them.

I've now had one or two 'random' error problems with SparkFS during a
session of work with rpcemu 0.8.9.

The first time I loaded SparkFS to unpack some zips transferred from my
Iyonix it worked fine. I then quit SparkFS telling it (as I usually do) to
remove its file module(s) as well.

When I tried to run it again it gave an error window, leading me to "File
'ZipUseCentralDirectory' not found".

However SparkPlug worked OK for opening a zip.

I shut down rpcemu and started it up again. Tried SparkFS and it loaded and
worked OK with the same target files as before.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

In article <1c09227752.George@tiscali..co.uk>, george greenfield
<george.greenfield@tiscali.co.uk> wrote:
> In message <5277065e71jcgl@audiomisc.co.uk> Jim Lesurf
> <jcgl@audiomisc.co.uk> wrote:

> >
> > Yes, please!

> >
> Couldn't zip the MDFs as they are read-only, so have attached them 'as
> is'. Hope they survive! Filetype is DOS in case you need to restore it.
> Good luck!

Thanks. The files came through OK. :-)

I have done some experiments with those files this morning, and come up
with some results that puzzle me...

I also had 'Duh!' moment this morning as I suddenly realised that maybe the
screen mode file(s) for my Iyonix might also work given that rpcemu has
relaxed the old limits on vram. So I also experimented with the MDF for my
1920 x 1080 screen, which also includes lower modes like 1600 x 900, etc.

For safety (which proved wise) I took a backup of my predesk.configure
directory! I ended up needing that.

The first thing I found was that - as reported yesterday - if I used the
!Boot screen 'try' button the screen just blanked out until I used the
mouse and it reverted. This happened even with low modes I felt sure the
rpc would be happy to provide.

So having made the above backup I use the 'set' option to make a new mode
the choice for bootup.

When I did this, the bigger faster modes - right up to 1600 x 900 worked
OK. The rpcemu window immediately changed to this size and all seemed well.

However I then found that when I ran rpcemu again I got problems during
bootup.

The bootup would proceed to the desktop appearing and icons started to
populate the icon bar. But once the screenmode-chooser icon appeared I got
an "application may have gone wrong" error window. I could choose either
cancel or quit and it would go - only to get a second. cancel or quit that
took me though the rest of the bootup and my other apps appeared and seem
OK.

Choosing 'describe' gave "undefined instruction at &000A5004".

Since I'd changed to the large mode I assumed that was the problem. So I
tried running !Boot by double-clicking in order to change to a smaller
mode.

That *also* gave errors. But not every time. The behaviour was erratic.
Sometimes trying to doubleclick !Boot did nothing noticable. Other times it
gave a "has gone wrong". On one occasion it produced a rpcemu error (little
white box with "bad opcode 16 316B316B at 006C010^" {the last symbol was
the 'hat' superscript}

So I shut down rpceemu, replaced the old configure files, and restarted.
That went find. So I tried a smaller mode (1280 x 1024) that has been the
standard I used on my Iyonix until getting the new monitor.

With that it seems to bootup OK. Although I've only tried twice so far, so
I may have been lucky! If/when I get other errors I'll report them.

Is the above to expected if a mode is too big or too fast for rpcemu? If
so, is there a defined limit?

If wished I can attach the mode file I used in addition to the ones George
posted here so people can check it out.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: Netsurf 2.9

On 27/03/2012 20:10, Chris Young wrote:
> On Thu, 23 Feb 2012 10:13:28 +0000, Vincent Sanders wrote:
>
>> For the release itself we aim to be created four weeks subsequently on
>> March 24th but this may change if more testing is required or it is
>> decided we are happy before then.
>
> Any update? I was quite surprised to not see a release last Saturday.

Given the amount of changes this week-end, it's probably not the best
time for a release :D

François.

Re: Netsurf 2.9

On Thu, 23 Feb 2012 10:13:28 +0000, Vincent Sanders wrote:

> For the release itself we aim to be created four weeks subsequently on
> March 24th but this may change if more testing is required or it is
> decided we are happy before then.

Any update? I was quite surprised to not see a release last Saturday.

Chris

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

In message <5277065e71jcgl@audiomisc.co.uk>
Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> In article <2643037752.George@tiscali..co.uk>, george greenfield
> <george.greenfield@tiscali.co.uk> wrote:
>> In message <5276fcadbdjcgl@audiomisc.co.uk> Jim Lesurf
>> <jcgl@audiomisc.co.uk> wrote:
>
>> > For the laptop someone kindly pointed me to a wide screen mode that
>> > was 700 pixels high - perfect for my laptop. However the new box has a
>> > 1920 x 1080 screen. So I'd like a mode that is more like 1024 pixels
>> > high than 700.
>> >
>> > Can someone point me at such a mode suitable for RPCEmu? Or will
>> > almost any suitably sized mode from, say, my Iyonix, do the job?
>
>> >
>> I don't know anything about Linux distros, but there are a couple of
>> Xerox flat screen MDFs I've found that you could try; the XM3-22wB
>> offers 1680 x 1050 (not quite your preferred 1024 but better than 1080)
>> or there's the XM3-19w which offers 1440 x 900 which certainly will fit.
>> I'll zip them and email them if you want to try them.
>
> Yes, please!
>
> Thanks,
>
> Jim
>
Couldn't zip the MDFs as they are read-only, so have attached them 'as
is'. Hope they survive! Filetype is DOS in case you need to restore
it. Good luck!

George

--
george greenfield

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

A couple of comments as feedback in case they are useful, or someone can
add something.

I've just been trying out 0.8.9 using the current screen mode, etc. Been
writing an article using TechWriter with some drawfile illustrations.

Overall, seems to work nicely. And - unlike 0.8.8. on my laptop - I can now
use the three-finger salute to ask for a shutdown. :-)

However the mouse pointer sometimes seems to behave as if 'on roller
skates'. ;-> i.e. if I move the mouse quickly and halt, the mouse pointer
seems to glide on for some way before also stopping. This takes a little
getting used to as I'm working in a small window compared to the overall
screen area at present. But it isn't actually a problem. Just something
like learning to ride a bike... :-)

Is this to be expected given the new feature of allowing the system to
'idle'? Although that said, is that enabled by default? I've not explicitly
switched it on so far as I am aware.

No sign of the old problem where mouse events got 'missed' if the mechanism
for easing CPU demand was set.

FWIW My machine has (IIUC) two i3 CPUs which 'pretend' to be 4 cores. So if
I monitor the CPU loading either cpu 1 or 3 go to 100 percent when running
0.8.9, and this alternates every now and then. The others tend to show a
loading of 1-5 percent each. So I presume this means the *actual* loading
is about '25 percent' - i.e. about half a CPU's worth in physical terms.
(Or have I totally misundestood the way this works?)

I'll keep experimenting. But for document writing, 0.8.9 using RO4.02, etc,
seems to be fine to me so far.

Cheers,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

In article <2643037752.George@tiscali..co.uk>, george greenfield
<george.greenfield@tiscali.co.uk> wrote:
> In message <5276fcadbdjcgl@audiomisc.co.uk> Jim Lesurf
> <jcgl@audiomisc.co.uk> wrote:

> > For the laptop someone kindly pointed me to a wide screen mode that
> > was 700 pixels high - perfect for my laptop. However the new box has a
> > 1920 x 1080 screen. So I'd like a mode that is more like 1024 pixels
> > high than 700.
> >
> > Can someone point me at such a mode suitable for RPCEmu? Or will
> > almost any suitably sized mode from, say, my Iyonix, do the job?

> >
> I don't know anything about Linux distros, but there are a couple of
> Xerox flat screen MDFs I've found that you could try; the XM3-22wB
> offers 1680 x 1050 (not quite your preferred 1024 but better than 1080)
> or there's the XM3-19w which offers 1440 x 900 which certainly will fit.
> I'll zip them and email them if you want to try them.

Yes, please!

Thanks,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9 and screen modes

In message <5276fcadbdjcgl@audiomisc.co.uk>
Jim Lesurf <jcgl@audiomisc.co.uk> wrote:

> I've just set up 0.8.9 on my nice shiney new box (running Xubuntu 11.10).
>
> This works nicely so far, but I've only had a brief check to see it starts
> up and I do simple things like open a TW window.
>
> I complied the emulator, set it to use SA110, and then put in the cmos
> file, hd4 file, and contents of hostfs from the 0.8.8. version on my
> laptop. The 0.8.9 then comes up as on the laptop.
>
> The only thing I'd like to change is the old chestnut... screen mode.
>
> For the laptop someone kindly pointed me to a wide screen mode that was 700
> pixels high - perfect for my laptop. However the new box has a 1920 x 1080
> screen. So I'd like a mode that is more like 1024 pixels high than 700.
>
> Can someone point me at such a mode suitable for RPCEmu? Or will almost any
> suitably sized mode from, say, my Iyonix, do the job?
>
> One snag is that if I use the !Boot screen option to 'try' other modes on
> RPCEmu the RPCEmu screen goes blank for one second, then comes back to
> the default. So I don't know if all the other modes I've tied are
> unsuitable, or if the emulator doesn't give time to show them for a 'try',
> or if there is a buglet here. Can someone advise, please?
>
> Thanks,
>
> Jim
>
I don't know anything about Linux distros, but there are a couple of
Xerox flat screen MDFs I've found that you could try; the XM3-22wB
offers 1680 x 1050 (not quite your preferred 1024 but better than
1080) or there's the XM3-19w which offers 1440 x 900 which certainly
will fit. I'll zip them and email them if you want to try them.

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: r13705 tlsa - /trunk/netsurf/desktop/tree.c

In article
<OUT-4F70EC28.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:

> Shouldn't we be using gui_system_colour_char() to get system colours

Yes, now fixed. Thanks!

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

[Rpcemu] RPCEmu 0.8.9 and screen modes

I've just set up 0.8.9 on my nice shiney new box (running Xubuntu 11.10).

This works nicely so far, but I've only had a brief check to see it starts
up and I do simple things like open a TW window.

I complied the emulator, set it to use SA110, and then put in the cmos
file, hd4 file, and contents of hostfs from the 0.8.8. version on my
laptop. The 0.8.9 then comes up as on the laptop.

The only thing I'd like to change is the old chestnut... screen mode.

For the laptop someone kindly pointed me to a wide screen mode that was 700
pixels high - perfect for my laptop. However the new box has a 1920 x 1080
screen. So I'd like a mode that is more like 1024 pixels high than 700.

Can someone point me at such a mode suitable for RPCEmu? Or will almost any
suitably sized mode from, say, my Iyonix, do the job?

One snag is that if I use the !Boot screen option to 'try' other modes on
RPCEmu the RPCEmu screen goes blank for one second, then comes back to
the default. So I don't know if all the other modes I've tied are
unsuitable, or if the emulator doesn't give time to show them for a 'try',
or if there is a buglet here. Can someone advise, please?

Thanks,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: r13705 tlsa - /trunk/netsurf/desktop/tree.c

On Sun, 25 Mar 2012 18:52:58 -0000, svn-commits wibbled on for an age:

> + plot_style_fill_tree_background.fill_colour =
> + nsoption_colour(sys_colour_Window);

I think this is wrong. Shouldn't we be using gui_system_colour_char()
to get system colours, as the options are overidden by the system
colours unless set to something other than 0x00000000?

Chris

Re: [Rpcemu] RPCEmu 0.8.9. and !Photodesk

In message <dce67f7452.George@tiscali..co.uk> you wrote:

> In message <20120322144641.GC21730@spod.org>
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
>> On Thu, Mar 22, 2012 at 02:14:44PM +0000, george greenfield wrote:
>>> Is anyone running Photodesk (3.09 or 3.10) successfully on 0.8.9?
>>>
>>> I'm getting an 'insufficient memory (case 4)' error in a task window
>>> when attempting to save retouched JPEGs since upgrading from 0.8.8.
>>> I've set 256MB of RAM and a large image cache (15x the size of the
>>> retouched file).
>>
>> Try reducing the memory to 128MB and retesting, it appears many versions
>> of RISC OS have issues with 256MB.
>>
>> Peter
>>
> Problem persists with memory reduced to 128MB, unfortunately. I tried
> the previous version of Photodesk, 3.09, on an earlier installation of
> RPCEmu 0.8.8/4.02 (same PC) and the retouched JPEG saved normally.
>
> George
>
RPCEmu 0.8.9 has been exonerated! It turns out that what you MUSTN'T
do is add Photodesk to Resources:$.Apps (which is what I had done a
few days previously). It was only when I copied across my current copy
of !Boot into the 0.8.8 installation, whereupon the problem magically
reappeared, that I realized what the actual cause might be. Photodesk
now runs (and saves - touching wood) happily from Utilities in
0.8.9/4.02. I've left RAM at 128MB just in case, however.

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: netsurf-users Digest, Vol 59, Issue 6

Am Montag, den 26.03.2012, 00:37 +0200 schrieb Tim Hill
<tim@timil.com>:

> Why's it there? Are there still people on dialup who need it?

Generally this feature is offered by the Mail list managers to provide
users an
option limit the amount of mails they get. This has nothing to do
with dialup. It's just less annoying to get 1 mail once a day, instead
of getting 40 mails...

I'm subscribed to several mail lists and I like the digest feature.

Greets,
m

Re: netsurf-users Digest, Vol 59, Issue 6

In article <20120325172209.GG5576@pepperfish.net>, Rob Kendrick
<rjek@netsurf-browser.org> wrote:
> On Sun, Mar 25, 2012 at 06:16:14PM +0100, Richard Porter wrote:
> > > Please don't do this. In fact, I'm tempted to disable digest
> > > support on the mailing list, because nobody ever gets this right.

Why's it there? Are there still people on dialup who need it?

--
Tim Hill
..............................................................
www.timil.com

Re: netsurf-users Digest, Vol 59, Issue 6

On Sun, Mar 25, 2012 at 06:16:14PM +0100, Richard Porter wrote:
> > Please don't do this. In fact, I'm tempted to disable digest support on
> > the mailing list, because nobody ever gets this right.
>
> Could you just bounce any messages with a subject starting "Re:
> netsurf-users Digest"?

No.

> Better still, those who receive only the digest should have posting
> disabled

And receiving, IMO.

> because even if the subject is changed the message threading won't
> work.

Quite.

B.

Re: netsurf-users Digest, Vol 59, Issue 6

On 25 Mar 2012 Rob Kendrick wrote:

> On Sun, Mar 25, 2012 at 04:41:24PM +0100, Allan Bennett wrote:
>> In message <31ef1ff0f8d057348bf4f9b1bfc0039a@mwinf5c65.me-wanadoo.net>
>> netsurf-users-request@netsurf-browser.org wrote:

> <snip>

>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of netsurf-users digest..."
>>
>> Thanks for your replies - now have the problem sorted:

> Please don't do this. In fact, I'm tempted to disable digest support on
> the mailing list, because nobody ever gets this right.

Could you just bounce any messages with a subject starting "Re:
netsurf-users Digest"? Better still, those who receive only the digest
should have posting disabled because even if the subject is changed
the message threading won't work.

--
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: netsurf-users Digest, Vol 59, Issue 6

On Sun, Mar 25, 2012 at 04:41:24PM +0100, Allan Bennett wrote:
> In message <31ef1ff0f8d057348bf4f9b1bfc0039a@mwinf5c65.me-wanadoo.net>
> netsurf-users-request@netsurf-browser.org wrote:

<snip>

> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of netsurf-users digest..."
>
> Thanks for your replies - now have the problem sorted:

Please don't do this. In fact, I'm tempted to disable digest support on
the mailing list, because nobody ever gets this right.

B.

Re: Wakefield Show

On 25 Mar, Rob Kendrick wrote in message
<20120325151150.GE5576@pepperfish.net>:

> On Sun, Mar 25, 2012 at 03:21:00PM +0100, Chris Hughes wrote:
> > In message <20120325133021.GC5576@pepperfish.net>
> > Rob Kendrick <rjek@netsurf-browser.org> wrote:
> >
> > > None of us have received any forms. Can you email them directly to
> > > John-Mark? (Who is copied on this mail.)
> >
> > Steve sent them on 14 March direct to Rob.
> >
> > But I have attached them again. :-)
>
> My inbox disagrees, but we'll have these sorted out as soon as we can.

They were sent on 13th March, but I never had chance to follow them up and
confirm that the mail had arrived. I discovered yesterday that my ISP seems
to have got its SMTP relay blacklisted for spam again recently so there's a
chance it got swallowed somewhere on the way for that reason.

--
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-users Digest, Vol 59, Issue 6

In message <31ef1ff0f8d057348bf4f9b1bfc0039a@mwinf5c65.me-wanadoo.net>
netsurf-users-request@netsurf-browser.org wrote:

> Send netsurf-users mailing list submissions to
> netsurf-users@netsurf-browser.org

> To subscribe or unsubscribe via the World Wide Web, visit
> http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-
> users-netsurf-browser.org

> or, via email, send a message with subject or body 'help' to
> netsurf-users-request@netsurf-browser.org

> You can reach the person managing the list at
> netsurf-users-owner@netsurf-browser.org

> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of netsurf-users digest..."

> Today's Topics:

> 1. Installing Themes - Risc OS (Allan Bennett)
> 2. Re: Installing Themes - Risc OS (cj)
> 3. Re: Installing Themes - Risc OS (Steve Fryatt)

> ----------------------------------------------------------------------

> Message: 1
> Date: Sat, 24 Mar 2012 17:37:02 GMT
> From: Allan Bennett <albenito@eclipse2k.freeserve.co.uk>
> Subject: Installing Themes - Risc OS
> To: netsurf-users@netsurf-browser.org
> Message-ID: <54da937552.SuperAl@albenito.eclipse2k.freeserve.co.uk>
> Content-Type: text/plain; charset=us-ascii

> Hi All,

> Trying to install Netsurf Themes to !Netsurf on an Armini
> (Beagleboard).

> On Risc PC & Iyonix, new themes were added to
> Choices:WWW.NetSurf.Themes, but cannot do this on the Armini - get the
> error message: "Path variable had multiple entries and was used for a
> write operation".

> D&D of !Netsurf with themes added from Iyonix to Armini fails, also.

> OK, so what do I need to do?

Thanks for your replies - now have the problem sorted:

I was opening up Choices via !Netsurf.OpenChoices which opens up:
Choices:WWW.NetSurf.Themes

...which I thought would be identical to:
ADFS::HardDisc.$.!Boot.Choices.WWW.NetSurf.Themes

...apparently not!

Sorry, Steve, I have no idea what "NetSurf's internal theme download
handler" is - the theme files were manually installed (D&D from
another machine) these are filetyped 'Data' and have always worked OK.

The themes from http://www.netsurf-browser.org/downloads/themes/
download as 'Archive' files on this Iyonix, and the instructions on
the same page "Select a theme link from below and NetSurf will ask for
confirmation before the theme is installed." doesn't seem to work.

Just to complicate things a bit, they download as 'XML' files on my
Armini.

--
Allan Bennett

Re: Wakefield Show

On Sun, Mar 25, 2012 at 03:21:00PM +0100, Chris Hughes wrote:
> In message <20120325133021.GC5576@pepperfish.net>
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > None of us have received any forms. Can you email them directly to
> > John-Mark? (Who is copied on this mail.)
>
> Steve sent them on 14 March direct to Rob.
>
> But I have attached them again. :-)

My inbox disagrees, but we'll have these sorted out as soon as we can.

> > I think we have only ever had two tables on one occation, when our
> > neighbour was unable to turn up. In general, we would prefer to only
> > have one table, but if you put us next to an otherwise spare one, we
> > promise to make it look occupide :)
>
> Well I have pencilled in two tables for you but can reduce it if you
> want otherwise you have two at no extra cost!

I'm sure we can make use of them :)

> >> If you are coming and needed any wi-fi or backing panes I would need
> >> to know sooner rather then later. :-)
>
> > Traditionally we have organised our own Wi-Fi, as the venue's gets
> > rather expensive when they charge per-device, and we have on occation
> > had as many as 10.
>
> Don't blame you.

As clarification: no, we don't need either.

B.

Re: Wakefield Show

On Sun, Mar 25, 2012 at 01:18:34PM +0100, Chris Hughes wrote:
> Hi Rob
>
> I know that Steve Fryatt has been in touch on my behalf and emailed
> you the forms regarding a stand this year at the Wakefield Show, which
> is rapidly approaching.

None of us have received any forms. Can you email them directly to
John-Mark? (Who is copied on this mail.)

> Do you know yet if you will be attending?
>
> We have provisionally pencilled in two tables as usual for you.

I think we have only ever had two tables on one occation, when our
neighbour was unable to turn up. In general, we would prefer to only
have one table, but if you put us next to an otherwise spare one, we
promise to make it look occupide :)

> If you are coming and needed any wi-fi or backing panes I would need
> to know sooner rather then later. :-)

Traditionally we have organised our own Wi-Fi, as the venue's gets
rather expensive when they charge per-device, and we have on occation
had as many as 10.

> If the the delay is due to payment (because JMB is away), we can if
> necessary sort this out on the day.

I'm sat at the same table as John-Mark as I type this; he has now
returned to the UK.

B.

Re: FatMessages - front end maintainers, please read!

On Sun, Mar 25, 2012 at 03:16:33PM +0200, Chris Young wrote:
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
> >Can people please go through netsurf/resources/FatMessages and change
> >the prefixes appropriately if they know a message is used only by a
> >specific front end. For example, there's a lot of stuff there that
> >looks like it's only used by the RISC OS front end for its menu
> >construction, but I don't know if some other platform makes use of
> >them.
> >(I suppose we could always suck it and see.)
>
> I know I nicked a lot of the risc os strings for amiga but they could always be duplicated if necessary.

If messages are common, they should stay that way, rather than
duplicating them. We don't want to increase the amount of work for
translators, or make the files fatter than they need to be.

For clarity, it may be worth making any group of tags as "all", even if
one of the frontends doesn't use them all.

B.

[show2012@wrocc.org.uk: Wakefield Show]

I don't recall us ever having two tables, or having been emailed the
forms for this year. John-Mark: were these sent direct to you?

We should probably get back to Chris about this today.

B.

FatMessages - front end maintainers, please read!

We're moving towards keeping just one messages file checked into version
control that contains all messages for all front end and language
combinations, and then split things up at build time. This should both
help to keep languages in sync as well as reduce the amount of messages
data each front end has to load. (ie, there's a lot of GTK- and RISC
OS-specific stuff in there at the moment.)

There is now netsurf/resources/FatMessages, which is processed by
netsurf/utils/split-messages.pl, which can be called like this:

./utils/split-messages.pl en gtk < resources/FatMessages

This will output to stdout all the messages that are relevent to the GTK
front end in English. 'fr ro' for French RISC OS, 'nl ami' for Dutch
AmigaOS, etc.

Messages with a platform 'all' get emitted for all platforms. And
here's the problem. I managed to automate the appropriate tagging of
platform-specific messages for some things (such as the GTK messages, or
RISC OS interactive help), but a lot of stuff isn't namespaced
helpfully.

Can people please go through netsurf/resources/FatMessages and change
the prefixes appropriately if they know a message is used only by a
specific front end. For example, there's a lot of stuff there that
looks like it's only used by the RISC OS front end for its menu
construction, but I don't know if some other platform makes use of them.
(I suppose we could always suck it and see.)

Ta.
B.

Re: Installing Themes - Risc OS

On 24 Mar, cj wrote in message
<527596edecchris@chris-johnson.org.uk>:

> In article <54da937552.SuperAl@albenito.eclipse2k.freeserve.co.uk>,
> Allan Bennett <albenito@eclipse2k.freeserve.co.uk> wrote:
>
> > On Risc PC & Iyonix, new themes were added to
> > Choices:WWW.NetSurf.Themes, but cannot do this on the Armini - get the
> > error message: "Path variable had multiple entries and was used for a
> > write operation".
>
> You probably need to use Choices$Write: rather than Choices:

Is this installing via NetSurf's internal theme download handler, or
manually in some way?

NetSurf looks to be using Choices$Write correctly in it's theme install,
although that's just based on a quick read through the code in question.

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 28 April 2012
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

Re: Installing Themes - Risc OS

In article <54da937552.SuperAl@albenito.eclipse2k.freeserve.co.uk>,
Allan Bennett <albenito@eclipse2k.freeserve.co.uk> wrote:
> On Risc PC & Iyonix, new themes were added to
> Choices:WWW.NetSurf.Themes, but cannot do this on the Armini - get the
> error message: "Path variable had multiple entries and was used for a
> write operation".

You probably need to use Choices$Write: rather than Choices:

--
Chris Johnson

Installing Themes - Risc OS

Hi All,

Trying to install Netsurf Themes to !Netsurf on an Armini
(Beagleboard).

On Risc PC & Iyonix, new themes were added to
Choices:WWW.NetSurf.Themes, but cannot do this on the Armini - get the
error message: "Path variable had multiple entries and was used for a
write operation".

D&D of !Netsurf with themes added from Iyonix to Armini fails, also.

OK, so what do I need to do?

--
Allan Bennett

BeOS build broken (again) due to libdom

I just noticed, one day after fixing the BeOS build, that r13573 broke
it again...

Of course, since I use the top-level Makefile, it's wasn't even built
nor installed, so it was missing the headers. I added it as r13574.

Now I'll have to fix libdom itself, I guess I'll spend quite some time.

I'll try to make a Haiku cross-compiler to make it easier for others to
test builds, but it would have been nice to tell beforehand about that.

For now it's complaining about "ANSI does not permit the keyword
'inline'", and of course not finding libxml2...

François.

Re: [Rpcemu] RPCEmu 0.8.9. and !Photodesk

In message <20120322144641.GC21730@spod.org>
Peter Howkins <rpcemu.howkins@marutan.net> wrote:

> On Thu, Mar 22, 2012 at 02:14:44PM +0000, george greenfield wrote:
>> Is anyone running Photodesk (3.09 or 3.10) successfully on 0.8.9?
>>
>> I'm getting an 'insufficient memory (case 4)' error in a task window
>> when attempting to save retouched JPEGs since upgrading from 0.8.8.
>> I've set 256MB of RAM and a large image cache (15x the size of the
>> retouched file).
>
> Try reducing the memory to 128MB and retesting, it appears many versions
> of RISC OS have issues with 256MB.
>
> Peter
>
Problem persists with memory reduced to 128MB, unfortunately. I tried
the previous version of Photodesk, 3.09, on an earlier installation of
RPCEmu 0.8.8/4.02 (same PC) and the retouched JPEG saved normally.

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.9. and !Photodesk

On Thu, Mar 22, 2012 at 02:14:44PM +0000, george greenfield wrote:
> Is anyone running Photodesk (3.09 or 3.10) successfully on 0.8.9?
>
> I'm getting an 'insufficient memory (case 4)' error in a task window
> when attempting to save retouched JPEGs since upgrading from 0.8.8.
> I've set 256MB of RAM and a large image cache (15x the size of the
> retouched file).

Try reducing the memory to 128MB and retesting, it appears many versions
of RISC OS have issues with 256MB.

Peter

--
Peter Howkins
peter.howkins@marutan.net

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.8.9. and !Photodesk

Is anyone running Photodesk (3.09 or 3.10) successfully on 0.8.9?

I'm getting an 'insufficient memory (case 4)' error in a task window
when attempting to save retouched JPEGs since upgrading from 0.8.8.
I've set 256MB of RAM and a large image cache (15x the size of the
retouched file). Quitting all other apps makes no difference.
Photodesk 3.09 works ok on 0.8.8 on this PC, so I'm wondering if
something has changed in 0.8.9's memory handling which Photodesk
doesn't like.

George

--
george greenfield

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

works fine on FreeBSD ia64

Hi

Just to say thank you. The browser
works fine on FreeBSD ia64. The only
other broser that works seems to be firefox3,
which will be obsolete very soon. So, it
seems netsurf will be the only nearly full
featured browser available on this platform.

By the way, is extjs [1,2] any help for
your js project? It builds fine on FreeBSD ia64 for me.

Thanks again

[1] http://www.sencha.com/products/extjs/
[2] http://www.freebsd.org/cgi/url.cgi?ports/www/extjs/pkg-descr

--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423

Re: CSS in objective c

On Tue, Feb 28, 2012 at 03:59:21PM +0100, bernard naudy wrote:
> Is it possible to use css in objective c. The purpose is to build templates
> applications for iphone where we can easily modify the code to have changes
> done in the colors, etc.

I assume by 'css' you mean our 'libcss' -- There are already people using it
for iOS development.

https://github.com/rsms/libcss-osx might be of use to you -- I have no idea how
iOS development works relative to MacOS development though.

Good luck, and please do share your findings with the list.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

[GeSHi-devel] Linking to a given line in a source file

Is it supported / possible at all?

It would be nice to be able to point an url to a given line in an highlighted file, eg. when starting from an error message...

Bye
Gaetano

Re: [GeSHi-devel] error in geshi parser (or language file) ?

Benny Baumann wrote:

Hi,

I'll have to dig into this one, but usually this kind of bug arises from a problem with the regexps used inside the language file. Especially the ones used in the ini.php (and the ones in php.php) are quite nasty sometimes; thus good knowledge of PCRE is advised ;-)

I think I have a convincing explanation for this case:
1. geshi adds a whitespace at the beginning of file before starting the parsing
2. while parsing (regexp parts), my code matches that whitespace, and geshi replaces it with a "<span etc...> </span>" tag
3. after parsing is done, geshi removes the added whitespace at the beginning of file. Except that this is not a whitespace anymore but a "<" character

Am 13.03.2012 18:34, schrieb Gaetano Giunta:

I am using the language file attached to validate the ini settings files of eZ Publish (tested on geshi 1.8.6 and 1.8.10).

It mostly works, but when I try to analyze the following file (2 lines):

[RegionalSettings] TranslationExtensions[]=monextension  

I get the following output:

span style="background-color: yellow;"> <span style="">&#91;</span></span>RegionalSettings<span style="">&#93;</span>...   IE. in the results the opening angle bracket for "span" is missing.

I remember there was a bug showing simular behaviour years ago. As mentioned above: I've to dig into this a little.

 This does not happen if there is eg. an empty line at the beginning of the file being highlighted. Is it due to a bug in the parser itself, or is something wrong with the language definition?

Hard to say off-hand, but I guess probably the parser has some trouble. I'll come back with more details as they are found.

  Thanks Gaetano  ps: any chance to get the ezini and eztemplate language definitions included in the next release? I submitted them a long time ago...

Since 1.0.8.10 quite some time went by and I'm still working to fetch up on the releases. Seems as if
- either I missed that mail
- there was some problm in the language file (which usually leads to a small mail about the issue asking to try fixing it (usually accompanied with some hints).

IDK what's it in this case ^^ Though I'll review the language files. If you verified them against the langcheck.php they should be okay.

Best regards,
BenBE.