So...
Has anyone on this list managed to get a RPCEmu install net connected
through Wi-Fi (Wirelessly)?
My test case will connect through the Wired LAN, but if I bridged with the
Wi-Fi there's no connection.
Thanks
Dave
The Win 7 side continues to connect regardless of which I have bridged.
D.
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 27 May 2015
Saturday, 23 May 2015
Re: [gccsdk] stdarg.h and stddef.h
In message <55606137.6070403@aaug.net>
John Tytgat <John.Tytgat@aaug.net> wrote:
> On 05/22/2015 07:09 AM, Ron wrote:
> > stdarg.h and stddef.h have references from other files, more-so stddef.h
> > It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> > #include 's referring to them?
> >
> > It is not an issue I have run into compiling, but Cproto uses the cpp
> > and traces everything in the files.
> >
> > Another thing it errors with is size_t, maybe the cproto grammar.y file
> > needs updating.
>
> stdarg.h and stddef.h. are headers files which should be available for
> building C or C++. Both headers files define very fundamental types
> (like size_t) which are tightly linked to the target definition (in our
> case arm-unknown-riscos). There is no need to delete the include
> statements in C/C++ programs, at some point you need those headers
> either directly or indirectly. Just google/wiki for more info on those
> headers.
>
> Because of their tight link to compiler's target definitions and
> actually being independent of the runtime library, they are located in
> lib/gcc/arm-unknown-riscos/4.7.4/include and not in the runtime library
> (which is in our case UnixLib), not in arm-unknown-riscos/include.
>
> I bet the background of your questions is that you are not using gcc/g++
> frontend executables but rather cpp/cc1 and you're missing all the
> necessary options (like the ones to correctly locate all the include
> directories) which gcc/gcc++ specifiy when starting cpp/cc1/ld/as/ etc.
> Unless you're really really know what you're doing, do not use cpp/cc1
> directly but use gcc/g++ and explore its options like -E/-S/-x etc for
> usecases like 'just preprocess', 'just create assembler file' etc. See
> documentation, or gcc --help
>
> Jo.
Yes to all the above, I was following the linux example of using cpp,
and /did/ find paths were missing and were including them manually.
I missed looking in lib.gcc but will look at using gcc -E (just preprocess) instead, this should save having to specify any paths and make things
simpler/safer.
Cproto uses it's -E switch with 0 to not call gcc/cpp at all /or/ to pass
extra options to cpp, maybe -Wp, <options> will work in that case, when
calling with 'gcc -E -Wp,'
A little confusing, but they are two separate programs and the -E
wont conflict, I think.
Thanks for the help, should be able to make positive progress one way
or another now.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
John Tytgat <John.Tytgat@aaug.net> wrote:
> On 05/22/2015 07:09 AM, Ron wrote:
> > stdarg.h and stddef.h have references from other files, more-so stddef.h
> > It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> > #include 's referring to them?
> >
> > It is not an issue I have run into compiling, but Cproto uses the cpp
> > and traces everything in the files.
> >
> > Another thing it errors with is size_t, maybe the cproto grammar.y file
> > needs updating.
>
> stdarg.h and stddef.h. are headers files which should be available for
> building C or C++. Both headers files define very fundamental types
> (like size_t) which are tightly linked to the target definition (in our
> case arm-unknown-riscos). There is no need to delete the include
> statements in C/C++ programs, at some point you need those headers
> either directly or indirectly. Just google/wiki for more info on those
> headers.
>
> Because of their tight link to compiler's target definitions and
> actually being independent of the runtime library, they are located in
> lib/gcc/arm-unknown-riscos/4.7.4/include and not in the runtime library
> (which is in our case UnixLib), not in arm-unknown-riscos/include.
>
> I bet the background of your questions is that you are not using gcc/g++
> frontend executables but rather cpp/cc1 and you're missing all the
> necessary options (like the ones to correctly locate all the include
> directories) which gcc/gcc++ specifiy when starting cpp/cc1/ld/as/ etc.
> Unless you're really really know what you're doing, do not use cpp/cc1
> directly but use gcc/g++ and explore its options like -E/-S/-x etc for
> usecases like 'just preprocess', 'just create assembler file' etc. See
> documentation, or gcc --help
>
> Jo.
Yes to all the above, I was following the linux example of using cpp,
and /did/ find paths were missing and were including them manually.
I missed looking in lib.gcc but will look at using gcc -E (just preprocess) instead, this should save having to specify any paths and make things
simpler/safer.
Cproto uses it's -E switch with 0 to not call gcc/cpp at all /or/ to pass
extra options to cpp, maybe -Wp, <options> will work in that case, when
calling with 'gcc -E -Wp,'
A little confusing, but they are two separate programs and the -E
wont conflict, I think.
Thanks for the help, should be able to make positive progress one way
or another now.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] stdarg.h and stddef.h
On 05/22/2015 07:09 AM, Ron wrote:
> stdarg.h and stddef.h have references from other files, more-so stddef.h
> It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> #include 's referring to them?
>
> It is not an issue I have run into compiling, but Cproto uses the cpp
> and traces everything in the files.
>
> Another thing it errors with is size_t, maybe the cproto grammar.y file
> needs updating.
stdarg.h and stddef.h. are headers files which should be available for
building C or C++. Both headers files define very fundamental types
(like size_t) which are tightly linked to the target definition (in our
case arm-unknown-riscos). There is no need to delete the include
statements in C/C++ programs, at some point you need those headers
either directly or indirectly. Just google/wiki for more info on those
headers.
Because of their tight link to compiler's target definitions and
actually being independent of the runtime library, they are located in
lib/gcc/arm-unknown-riscos/4.7.4/include and not in the runtime library
(which is in our case UnixLib), not in arm-unknown-riscos/include.
I bet the background of your questions is that you are not using gcc/g++
frontend executables but rather cpp/cc1 and you're missing all the
necessary options (like the ones to correctly locate all the include
directories) which gcc/gcc++ specifiy when starting cpp/cc1/ld/as/ etc.
Unless you're really really know what you're doing, do not use cpp/cc1
directly but use gcc/g++ and explore its options like -E/-S/-x etc for
usecases like 'just preprocess', 'just create assembler file' etc. See
documentation, or gcc --help
Jo.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> stdarg.h and stddef.h have references from other files, more-so stddef.h
> It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> #include 's referring to them?
>
> It is not an issue I have run into compiling, but Cproto uses the cpp
> and traces everything in the files.
>
> Another thing it errors with is size_t, maybe the cproto grammar.y file
> needs updating.
stdarg.h and stddef.h. are headers files which should be available for
building C or C++. Both headers files define very fundamental types
(like size_t) which are tightly linked to the target definition (in our
case arm-unknown-riscos). There is no need to delete the include
statements in C/C++ programs, at some point you need those headers
either directly or indirectly. Just google/wiki for more info on those
headers.
Because of their tight link to compiler's target definitions and
actually being independent of the runtime library, they are located in
lib/gcc/arm-unknown-riscos/4.7.4/include and not in the runtime library
(which is in our case UnixLib), not in arm-unknown-riscos/include.
I bet the background of your questions is that you are not using gcc/g++
frontend executables but rather cpp/cc1 and you're missing all the
necessary options (like the ones to correctly locate all the include
directories) which gcc/gcc++ specifiy when starting cpp/cc1/ld/as/ etc.
Unless you're really really know what you're doing, do not use cpp/cc1
directly but use gcc/g++ and explore its options like -E/-S/-x etc for
usecases like 'just preprocess', 'just create assembler file' etc. See
documentation, or gcc --help
Jo.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Friday, 22 May 2015
Re: [gccsdk] stdarg.h and stddef.h
In message <7ca001c854.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> In message <7b0f9ac754.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> > stdarg.h and stddef.h have references from other files, more-so stddef.h
> > It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> > #include 's referring to them?
> >
> > It is not an issue I have run into compiling, but Cproto uses the cpp
> > and traces everything in the files.
> >
> > Another thing it errors with is size_t, maybe the cproto grammar.y file
> > needs updating.
> >
> I have added two empty files stdarg.h and stddef.h and that has stopped
> those errors.
>
> The remaining errors seem to be related to size_t and wchar_t
>
> typedef long long size_t;
> typedef long long wchar_t;
>
> stops those errors, but what are the sensible values to use?
>
Copying over stddef.h from gcc3 answers this properly, and probably
fixes other type problems that I haven't encountered yet.
Grepping the 4.7.4 includes doesn't find what is in the gcc3 stddef.h,
there must be a good reason why this isn't in gcc4xx, and would it
break things by adding stddef.h in the normal place?
You can try Cproto out if you wish.
The header files will need to be added to gcc4xx to avoid the said errors
http://homepages.woosh.co.nz/ron.may/cproto.zip
simple useage
cproto ackermann.c
or
cproto -E 0 ackermann.c
runs without the cpp
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Ron <beeb@woosh.co.nz> wrote:
> In message <7b0f9ac754.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> > stdarg.h and stddef.h have references from other files, more-so stddef.h
> > It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> > #include 's referring to them?
> >
> > It is not an issue I have run into compiling, but Cproto uses the cpp
> > and traces everything in the files.
> >
> > Another thing it errors with is size_t, maybe the cproto grammar.y file
> > needs updating.
> >
> I have added two empty files stdarg.h and stddef.h and that has stopped
> those errors.
>
> The remaining errors seem to be related to size_t and wchar_t
>
> typedef long long size_t;
> typedef long long wchar_t;
>
> stops those errors, but what are the sensible values to use?
>
Copying over stddef.h from gcc3 answers this properly, and probably
fixes other type problems that I haven't encountered yet.
Grepping the 4.7.4 includes doesn't find what is in the gcc3 stddef.h,
there must be a good reason why this isn't in gcc4xx, and would it
break things by adding stddef.h in the normal place?
You can try Cproto out if you wish.
The header files will need to be added to gcc4xx to avoid the said errors
http://homepages.woosh.co.nz/ron.may/cproto.zip
simple useage
cproto ackermann.c
or
cproto -E 0 ackermann.c
runs without the cpp
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Patch for autobuilder mercurial source fetcher
On Tue, May 19, 2015 at 02:04:14PM +0100, John Ballance wrote:
> Hi
>
> Please patch the autobuilder fetch-program as below.
Thanks for this - now applied in r6864.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi
>
> Please patch the autobuilder fetch-program as below.
Thanks for this - now applied in r6864.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] stdarg.h and stddef.h
In message <7b0f9ac754.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> stdarg.h and stddef.h have references from other files, more-so stddef.h
> It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> #include 's referring to them?
>
> It is not an issue I have run into compiling, but Cproto uses the cpp
> and traces everything in the files.
>
> Another thing it errors with is size_t, maybe the cproto grammar.y file
> needs updating.
>
I have added two empty files stdarg.h and stddef.h and that has stopped
those errors.
The remaining errors seem to be related to size_t and wchar_t
typedef long long size_t;
typedef long long wchar_t;
stops those errors, but what are the sensible values to use?
Thanks Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Ron <beeb@woosh.co.nz> wrote:
> stdarg.h and stddef.h have references from other files, more-so stddef.h
> It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
> #include 's referring to them?
>
> It is not an issue I have run into compiling, but Cproto uses the cpp
> and traces everything in the files.
>
> Another thing it errors with is size_t, maybe the cproto grammar.y file
> needs updating.
>
I have added two empty files stdarg.h and stddef.h and that has stopped
those errors.
The remaining errors seem to be related to size_t and wchar_t
typedef long long size_t;
typedef long long wchar_t;
stops those errors, but what are the sensible values to use?
Thanks Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 21 May 2015
[gccsdk] stdarg.h and stddef.h
stdarg.h and stddef.h have references from other files, more-so stddef.h
It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
#include 's referring to them?
It is not an issue I have run into compiling, but Cproto uses the cpp
and traces everything in the files.
Another thing it errors with is size_t, maybe the cproto grammar.y file
needs updating.
TIA Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
It appears 4.1.2 and 4.7.4 dont have these files, is it ok to delete the
#include 's referring to them?
It is not an issue I have run into compiling, but Cproto uses the cpp
and traces everything in the files.
Another thing it errors with is size_t, maybe the cproto grammar.y file
needs updating.
TIA Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Tuesday, 19 May 2015
[gccsdk] Patch for autobuilder mercurial source fetcher
Index: fetch-program
===================================================================
--- fetch-program (revision 6860)
+++ fetch-program (working copy)
@@ -46,7 +46,18 @@
git clone $AB_GIT
elif [ "$AB_HG" != "" ] ; then
+ AB_JBTMP=(${AB_HG//[\'\"]/})
+ if [ -e "${AB_JBTMP[1]}/.hg" ] ; then
+ cd ${AB_JBTMP[1]}
+ echo "doing hg pull ${AB_JBTMP[0]}"
+ hg pull ${AB_JBTMP[0]}
+ echo "doing hg update -C "
+ hg update -C
+ cd ..
+ else
+ echo "doing hg clone $AB_HG"
hg clone $AB_HG
+ fi
elif [ "$AB_URL" != "" ] ; then
wget -U "GCCSDK Autobuilder for RISC OS" -nv $AB_URL
Hi
Please patch the autobuilder fetch-program as below.
This extends the AB_HG method in 2 ways:
1: it permits the reuse of existing .hg which is left if the autobuilder -D option was given, which had left the sources in place for debug. This is beneficial if a large repository is being used .. it takes 20+mins here every build otherwise...
2: if the hg command was enclosed in ' or " these are removed, which enables cloning or pulling of the repository into a specific subdirectory of the build directory
It may also be worth doing the same mods to some of the other fetch methods
Thanks
John
===================================================================
--- fetch-program (revision 6860)
+++ fetch-program (working copy)
@@ -46,7 +46,18 @@
git clone $AB_GIT
elif [ "$AB_HG" != "" ] ; then
+ AB_JBTMP=(${AB_HG//[\'\"]/})
+ if [ -e "${AB_JBTMP[1]}/.hg" ] ; then
+ cd ${AB_JBTMP[1]}
+ echo "doing hg pull ${AB_JBTMP[0]}"
+ hg pull ${AB_JBTMP[0]}
+ echo "doing hg update -C "
+ hg update -C
+ cd ..
+ else
+ echo "doing hg clone $AB_HG"
hg clone $AB_HG
+ fi
elif [ "$AB_URL" != "" ] ; then
wget -U "GCCSDK Autobuilder for RISC OS" -nv $AB_URL
Hi
Please patch the autobuilder fetch-program as below.
This extends the AB_HG method in 2 ways:
1: it permits the reuse of existing .hg which is left if the autobuilder -D option was given, which had left the sources in place for debug. This is beneficial if a large repository is being used .. it takes 20+mins here every build otherwise...
2: if the hg command was enclosed in ' or " these are removed, which enables cloning or pulling of the repository into a specific subdirectory of the build directory
It may also be worth doing the same mods to some of the other fetch methods
Thanks
John
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Monday, 18 May 2015
Re: [gccsdk] autobuilder - GLib-Critical error
On Tue, May 19, 2015 at 01:15:04AM +0100, John Ballance wrote:
> Hi
>
> mea culpa.. as you found, I have no "" on the AB_HG line. a typo here.
It turns out that John was doing a syntax like:
AB_HG=https://blahblah/projectname nameondisc
and this was confusing things. This doesn't really fit with the idea of
AB_HG as a URL rather than a list of options to hg, though I can see the
benefits of providing extra options.
> (I've also got some mods for the fetcher to do a hg pull if the
> sources are there.. cuts about 15 mins off the load time. .. how can
> I usefully feed those back as I dont have update rights(as far as I
> can see)
Posting a patch here is the best way, it's best to make it an attachment
(just the raw output from 'svn diff', don't zip it or anything) so quoting
inline doesn't mangle it. (In another version control system, 'git
send-email' will do everything for you, but doesn't exist for SVN sadly).
One caveat though is that often we want to wipe out the previous state so
that we know a build will run from scratch, whereas any reliance on previous
state then makes a build a function on all the previous builds. So is it
possible to add a flag that would enable 'svn update'/'git pull'/'hg pull'
in fetch-program? That would mean we can either build afresh or, if you're
debugging or updating the build, just pulling recent changes. There's also
the issue that you want to remove unversioned files (like compiler output)
and you can't trust 'make clean' to do that
('git clean -xfd && git reset --hard' is a thing, but not all VCSes do that)
Theo
(my git bias may be showing)
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi
>
> mea culpa.. as you found, I have no "" on the AB_HG line. a typo here.
It turns out that John was doing a syntax like:
AB_HG=https://blahblah/projectname nameondisc
and this was confusing things. This doesn't really fit with the idea of
AB_HG as a URL rather than a list of options to hg, though I can see the
benefits of providing extra options.
> (I've also got some mods for the fetcher to do a hg pull if the
> sources are there.. cuts about 15 mins off the load time. .. how can
> I usefully feed those back as I dont have update rights(as far as I
> can see)
Posting a patch here is the best way, it's best to make it an attachment
(just the raw output from 'svn diff', don't zip it or anything) so quoting
inline doesn't mangle it. (In another version control system, 'git
send-email' will do everything for you, but doesn't exist for SVN sadly).
One caveat though is that often we want to wipe out the previous state so
that we know a build will run from scratch, whereas any reliance on previous
state then makes a build a function on all the previous builds. So is it
possible to add a flag that would enable 'svn update'/'git pull'/'hg pull'
in fetch-program? That would mean we can either build afresh or, if you're
debugging or updating the build, just pulling recent changes. There's also
the issue that you want to remove unversioned files (like compiler output)
and you can't trust 'make clean' to do that
('git clean -xfd && git reset --hard' is a thing, but not all VCSes do that)
Theo
(my git bias may be showing)
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] autobuilder - GLib-Critical error
Hi
mea culpa.. as you found, I have no "" on the AB_HG line. a typo here.
no unusual characters and the checkout is correct.. sources are over a gb...
(I've also got some mods for the fetcher to do a hg pull if the sources are there.. cuts about 15 mins off the load time. .. how can I usefully feed those back as I dont have update rights(as far as I can see)
John
mea culpa.. as you found, I have no "" on the AB_HG line. a typo here.
no unusual characters and the checkout is correct.. sources are over a gb...
(I've also got some mods for the fetcher to do a hg pull if the sources are there.. cuts about 15 mins off the load time. .. how can I usefully feed those back as I dont have update rights(as far as I can see)
John
On 18/05/2015 22:54, Theo Markettos wrote:
On Mon, May 18, 2015 at 07:41:17AM +0100, John Ballance wrote:Hi Theo Starting in an xterm causes firefox to be popped open when the glib err is reported, then the script continues. the condensed (# comments removed) setvars equates to echo "1" AB_HG="https://..." echo "2" (where ... is the correct hg path) THEN: autobuilder, via fetch-program, scans setvars as a file and correctly does the mercurial clone (its about a GB), after which it invokes setvars as a scriptHmm, I set up a setvars file like this: echo "1" AB_HG="https://bitbucket.org/tortoisehg/thg" echo "2" (a randomly selected hg repo) and I get: Autobuilder: Fetching source for tortoisehg abort: repository "https://bitbucket.org/tortoisehg/thg" not found! It turns out that the quotes on AB_HG are getting passed through to hg, ie it's trying to call: hg clone "https://bitbucket.org/tortoisehg/thg" and hg doesn't like that. As to why the quotes are getting passed through, it appears fetch-program is a pile of grep hacks that don't actually parse the setvars file, they just do basic text extraction. What I'm guessing is that your hg URL is tripping up the grep and it's somehow trying to launch your hg URL in a browser (how, I can't tell without the URL). So I suggest stripping the quotes, ie AB_HG=https://bitbucket.org/tortoisehg/thg This successfully checks out on my machine. If your URL has any unusual characters (spaces? UTF-8? odd punctuation?) can you say what they are? Theo
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] autobuilder - GLib-Critical error
On Mon, May 18, 2015 at 07:41:17AM +0100, John Ballance wrote:
> Hi Theo
>
> Starting in an xterm causes firefox to be popped open when the glib
> err is reported, then the script continues.
>
> the condensed (# comments removed) setvars equates to
>
> echo "1"
>
> AB_HG="https://..."
>
> echo "2"
>
> (where ... is the correct hg path)
>
> THEN:
> autobuilder, via fetch-program, scans setvars as a file and
> correctly does the mercurial clone (its about a GB), after which it
> invokes setvars as a script
Hmm, I set up a setvars file like this:
echo "1"
AB_HG="https://bitbucket.org/tortoisehg/thg"
echo "2"
(a randomly selected hg repo)
and I get:
Autobuilder: Fetching source for tortoisehg
abort: repository "https://bitbucket.org/tortoisehg/thg" not found!
It turns out that the quotes on AB_HG are getting passed through to hg, ie
it's trying to call:
hg clone "https://bitbucket.org/tortoisehg/thg"
and hg doesn't like that. As to why the quotes are getting passed through,
it appears fetch-program is a pile of grep hacks that don't actually parse
the setvars file, they just do basic text extraction.
What I'm guessing is that your hg URL is tripping up the grep and it's
somehow trying to launch your hg URL in a browser (how, I can't tell without
the URL).
So I suggest stripping the quotes, ie
AB_HG=https://bitbucket.org/tortoisehg/thg
This successfully checks out on my machine.
If your URL has any unusual characters (spaces? UTF-8? odd punctuation?) can
you say what they are?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi Theo
>
> Starting in an xterm causes firefox to be popped open when the glib
> err is reported, then the script continues.
>
> the condensed (# comments removed) setvars equates to
>
> echo "1"
>
> AB_HG="https://..."
>
> echo "2"
>
> (where ... is the correct hg path)
>
> THEN:
> autobuilder, via fetch-program, scans setvars as a file and
> correctly does the mercurial clone (its about a GB), after which it
> invokes setvars as a script
Hmm, I set up a setvars file like this:
echo "1"
AB_HG="https://bitbucket.org/tortoisehg/thg"
echo "2"
(a randomly selected hg repo)
and I get:
Autobuilder: Fetching source for tortoisehg
abort: repository "https://bitbucket.org/tortoisehg/thg" not found!
It turns out that the quotes on AB_HG are getting passed through to hg, ie
it's trying to call:
hg clone "https://bitbucket.org/tortoisehg/thg"
and hg doesn't like that. As to why the quotes are getting passed through,
it appears fetch-program is a pile of grep hacks that don't actually parse
the setvars file, they just do basic text extraction.
What I'm guessing is that your hg URL is tripping up the grep and it's
somehow trying to launch your hg URL in a browser (how, I can't tell without
the URL).
So I suggest stripping the quotes, ie
AB_HG=https://bitbucket.org/tortoisehg/thg
This successfully checks out on my machine.
If your URL has any unusual characters (spaces? UTF-8? odd punctuation?) can
you say what they are?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sunday, 17 May 2015
Re: [gccsdk] autobuilder - GLib-Critical error
Hi Theo
Starting in an xterm causes firefox to be popped open when the glib err is reported, then the script continues.
the condensed (# comments removed) setvars equates to
(where ... is the correct hg path)
THEN:
autobuilder, via fetch-program, scans setvars as a file and correctly does the mercurial clone (its about a GB), after which it invokes setvars as a script
setvars, once invoked, prints "1" to the terminal then pops up the glib error.
in a basic login it stops here. In an X terminal window firefox is started with no helpful info and the script continues by printing "2"
i.e. a basic failure within the build system before it does anything, really, other than invoke a shell script following a mercurial checkout.
At least I know what is going on.. I suspect the attempt to open firefox is the issue that gives the glib error, though why that is happening is unclear
Cheers
John
Starting in an xterm causes firefox to be popped open when the glib err is reported, then the script continues.
the condensed (# comments removed) setvars equates to
echo "1"
AB_HG="https://..."echo "2"
(where ... is the correct hg path)
THEN:
autobuilder, via fetch-program, scans setvars as a file and correctly does the mercurial clone (its about a GB), after which it invokes setvars as a script
setvars, once invoked, prints "1" to the terminal then pops up the glib error.
in a basic login it stops here. In an X terminal window firefox is started with no helpful info and the script continues by printing "2"
i.e. a basic failure within the build system before it does anything, really, other than invoke a shell script following a mercurial checkout.
At least I know what is going on.. I suspect the attempt to open firefox is the issue that gives the glib error, though why that is happening is unclear
Cheers
John
On 18/05/2015 04:03, Theo Markettos wrote:
On Sun, May 17, 2015 at 09:50:10PM +0100, John Ballance wrote:Hi Theo Thanks for the reply, and for the suggestions A few points 1: Though there is a ubuntu desktop around (ctrl-alt-F7) I am working directly from a plain text (?) login at ctrl-alt-F1 2: What I said about the failure is accurate. the setvars script has the AB_HG line in it, which is detected and used by autobuilder fetch-program script. Once that has completed the sources are in place. The autobuilder then invokes setvars. It runs fine (doing echo 'some text') until it encounters the AB_HG= line, at which point the GLib error ss reported and nothing goes further.But the AB_HG line is just setting an environment variable, it doesn't execute anything? What does the setvars file look like (what's the package, if it's one in the tree?)I've now tried again in a desktop terminal window. GLib throws all sorts of funnies out, eventually returning to setvars to continue...I think you'll need to post the log - often what you see is a symptom of an earlier problem, and without the full log we don't have much to go on.I tried the code you suggested for Xvfb, but it then complains it cannot open display 99 (your example). I presume Xvfb :99 needs an & after it to return to command line?Yes.I'm still none the wiser as to why glib decided it needed to push something to the display though, and none the wiser what it actually tries to push.I have no idea. It's unusual for things to need X during builds, and it's also unusual for things to invoke gtk/glib apps as part of the build. The log should tell us more. Theo
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] autobuilder - GLib-Critical error
On Sun, May 17, 2015 at 09:50:10PM +0100, John Ballance wrote:
> Hi Theo
>
> Thanks for the reply, and for the suggestions
>
> A few points
>
> 1: Though there is a ubuntu desktop around (ctrl-alt-F7) I am
> working directly from a plain text (?) login at ctrl-alt-F1
>
> 2: What I said about the failure is accurate.
>
> the setvars script has the AB_HG line in it, which is detected and
> used by autobuilder fetch-program script. Once that has completed
> the sources are in place. The autobuilder then invokes setvars. It
> runs fine (doing echo 'some text') until it encounters the AB_HG=
> line, at which point the GLib error ss reported and nothing goes
> further.
But the AB_HG line is just setting an environment variable, it doesn't
execute anything?
What does the setvars file look like (what's the package, if it's one in the
tree?)
> I've now tried again in a desktop terminal window. GLib throws all
> sorts of funnies out, eventually returning to setvars to continue...
I think you'll need to post the log - often what you see is a symptom of an
earlier problem, and without the full log we don't have much to go on.
> I tried the code you suggested for Xvfb, but it then complains it
> cannot open display 99 (your example).
>
> I presume Xvfb :99 needs an & after it to return to command line?
Yes.
> I'm still none the wiser as to why glib decided it needed to push
> something to the display though, and none the wiser what it actually
> tries to push.
I have no idea. It's unusual for things to need X during builds, and it's
also unusual for things to invoke gtk/glib apps as part of the build. The
log should tell us more.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi Theo
>
> Thanks for the reply, and for the suggestions
>
> A few points
>
> 1: Though there is a ubuntu desktop around (ctrl-alt-F7) I am
> working directly from a plain text (?) login at ctrl-alt-F1
>
> 2: What I said about the failure is accurate.
>
> the setvars script has the AB_HG line in it, which is detected and
> used by autobuilder fetch-program script. Once that has completed
> the sources are in place. The autobuilder then invokes setvars. It
> runs fine (doing echo 'some text') until it encounters the AB_HG=
> line, at which point the GLib error ss reported and nothing goes
> further.
But the AB_HG line is just setting an environment variable, it doesn't
execute anything?
What does the setvars file look like (what's the package, if it's one in the
tree?)
> I've now tried again in a desktop terminal window. GLib throws all
> sorts of funnies out, eventually returning to setvars to continue...
I think you'll need to post the log - often what you see is a symptom of an
earlier problem, and without the full log we don't have much to go on.
> I tried the code you suggested for Xvfb, but it then complains it
> cannot open display 99 (your example).
>
> I presume Xvfb :99 needs an & after it to return to command line?
Yes.
> I'm still none the wiser as to why glib decided it needed to push
> something to the display though, and none the wiser what it actually
> tries to push.
I have no idea. It's unusual for things to need X during builds, and it's
also unusual for things to invoke gtk/glib apps as part of the build. The
log should tell us more.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] autobuilder - GLib-Critical error
Hi Theo
Thanks for the reply, and for the suggestions
A few points
1: Though there is a ubuntu desktop around (ctrl-alt-F7) I am working directly from a plain text (?) login at ctrl-alt-F1
2: What I said about the failure is accurate.
the setvars script has the AB_HG line in it, which is detected and used by autobuilder fetch-program script. Once that has completed the sources are in place. The autobuilder then invokes setvars. It runs fine (doing echo 'some text') until it encounters the AB_HG= line, at which point the GLib error ss reported and nothing goes further.
I've now tried again in a desktop terminal window. GLib throws all sorts of funnies out, eventually returning to setvars to continue...
I tried the code you suggested for Xvfb, but it then complains it cannot open display 99 (your example).
I presume Xvfb :99 needs an & after it to return to command line?
I'm still none the wiser as to why glib decided it needed to push something to the display though, and none the wiser what it actually tries to push.
Many thanks
John
Thanks for the reply, and for the suggestions
A few points
1: Though there is a ubuntu desktop around (ctrl-alt-F7) I am working directly from a plain text (?) login at ctrl-alt-F1
2: What I said about the failure is accurate.
the setvars script has the AB_HG line in it, which is detected and used by autobuilder fetch-program script. Once that has completed the sources are in place. The autobuilder then invokes setvars. It runs fine (doing echo 'some text') until it encounters the AB_HG= line, at which point the GLib error ss reported and nothing goes further.
I've now tried again in a desktop terminal window. GLib throws all sorts of funnies out, eventually returning to setvars to continue...
I tried the code you suggested for Xvfb, but it then complains it cannot open display 99 (your example).
I presume Xvfb :99 needs an & after it to return to command line?
I'm still none the wiser as to why glib decided it needed to push something to the display though, and none the wiser what it actually tries to push.
Many thanks
John
On 17/05/2015 17:21, Theo Markettos wrote:
On Sun, May 17, 2015 at 05:02:04PM +0100, John Ballance wrote:Hi I'm having fun with porting a package that uses mercurial (hg) for its sources. I have set up a minimal package that has little in setvars other than the line starting AB_HG= The sources are correctly fetched, then the autobuilder/build enters setvars, and proceeds to produce GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Error: no display specified when it gets to the AB_HG= line Any suggestions/cures/etc would be appreciatedHow are you running it? SSH session or via a Linux desktop? The GLib- line is not necessarily a problem - I don't know that one, but some X programs are a bit 'chatty' as regards warnings. Programs spit these messages out on the console but otherwise seem to work normally. 'No display specified' means you don't have an X session, and something wants to open a graphical window. I don't know why that might be, it'll depend on what you're doing. A couple of solutions... one is to install vncserver and run things from within a VNC session. That should mean your DISPLAY variable is set up right. An alternative is to install Xvfb and do: Xvfb :99 export DISPLAY=localhost:99 which will give you a virtual X session (that goes nowhere) but should at least stop complaints about lack of X server. Note if you SSH then ssh -X will forward X over your SSH tunnel, so you can start program on machine A and have it displayed on machine B. So you can build somewhere that isn't your local machine if you choose. For instance, ssh -X from a Mac to a Linux box and XQuartz on the Mac will display Linux programs. Can you pin it down to which component is complaining? My guess would be it's something in your build, not to do with the AB_HG as such. Theo
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Re: [gccsdk] autobuilder - GLib-Critical error
On Sun, May 17, 2015 at 05:02:04PM +0100, John Ballance wrote:
> Hi
>
> I'm having fun with porting a package that uses mercurial (hg) for
> its sources. I have set up a minimal package that has little in
> setvars other than the line starting AB_HG=
>
> The sources are correctly fetched, then the autobuilder/build enters
> setvars, and proceeds to produce
>
> GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
> Error: no display specified
>
> when it gets to the AB_HG= line
>
> Any suggestions/cures/etc would be appreciated
How are you running it? SSH session or via a Linux desktop?
The GLib- line is not necessarily a problem - I don't know that one, but
some X programs are a bit 'chatty' as regards warnings. Programs spit these
messages out on the console but otherwise seem to work normally.
'No display specified' means you don't have an X session, and something
wants to open a graphical window. I don't know why that might be, it'll
depend on what you're doing.
A couple of solutions... one is to install vncserver and run things from
within a VNC session. That should mean your DISPLAY variable is set up
right.
An alternative is to install Xvfb and do:
Xvfb :99
export DISPLAY=localhost:99
which will give you a virtual X session (that goes nowhere) but should at
least stop complaints about lack of X server.
Note if you SSH then ssh -X will forward X over your SSH tunnel, so you can
start program on machine A and have it displayed on machine B. So you can
build somewhere that isn't your local machine if you choose. For instance,
ssh -X from a Mac to a Linux box and XQuartz on the Mac will display Linux
programs.
Can you pin it down to which component is complaining? My guess would be
it's something in your build, not to do with the AB_HG as such.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi
>
> I'm having fun with porting a package that uses mercurial (hg) for
> its sources. I have set up a minimal package that has little in
> setvars other than the line starting AB_HG=
>
> The sources are correctly fetched, then the autobuilder/build enters
> setvars, and proceeds to produce
>
> GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
> Error: no display specified
>
> when it gets to the AB_HG= line
>
> Any suggestions/cures/etc would be appreciated
How are you running it? SSH session or via a Linux desktop?
The GLib- line is not necessarily a problem - I don't know that one, but
some X programs are a bit 'chatty' as regards warnings. Programs spit these
messages out on the console but otherwise seem to work normally.
'No display specified' means you don't have an X session, and something
wants to open a graphical window. I don't know why that might be, it'll
depend on what you're doing.
A couple of solutions... one is to install vncserver and run things from
within a VNC session. That should mean your DISPLAY variable is set up
right.
An alternative is to install Xvfb and do:
Xvfb :99
export DISPLAY=localhost:99
which will give you a virtual X session (that goes nowhere) but should at
least stop complaints about lack of X server.
Note if you SSH then ssh -X will forward X over your SSH tunnel, so you can
start program on machine A and have it displayed on machine B. So you can
build somewhere that isn't your local machine if you choose. For instance,
ssh -X from a Mac to a Linux box and XQuartz on the Mac will display Linux
programs.
Can you pin it down to which component is complaining? My guess would be
it's something in your build, not to do with the AB_HG as such.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] autobuilder - GLib-Critical error
Hi
I'm having fun with porting a package that uses mercurial (hg) for its sources. I have set up a minimal package that has little in setvars other than the line starting AB_HG=
The sources are correctly fetched, then the autobuilder/build enters setvars, and proceeds to produce
GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Error: no display specified
when it gets to the AB_HG= line
Any suggestions/cures/etc would be appreciated
Thanks
John
I'm having fun with porting a package that uses mercurial (hg) for its sources. I have set up a minimal package that has little in setvars other than the line starting AB_HG=
The sources are correctly fetched, then the autobuilder/build enters setvars, and proceeds to produce
GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Error: no display specified
when it gets to the AB_HG= line
Any suggestions/cures/etc would be appreciated
Thanks
John
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
[gccsdk] gettext-0.19.3 build issues
Hi
Any suggestions please
I'm tying to build gettext, and autobuilder is fetching 0.19.3
It is falling over with :
RO libpack: Attempt to pack host binary: "./lib/GNU.Gettext.dll"
... a dll is logically not relevant, but I'm rather unsure just why it is there
using ubuntu with the 4.7.1 gcc and autobuilder downloaded just now. the build-world for gcc4 went fine...
Many thanks
John
Any suggestions please
I'm tying to build gettext, and autobuilder is fetching 0.19.3
It is falling over with :
RO libpack: Attempt to pack host binary: "./lib/GNU.Gettext.dll"
... a dll is logically not relevant, but I'm rather unsure just why it is there
using ubuntu with the 4.7.1 gcc and autobuilder downloaded just now. the build-world for gcc4 went fine...
Many thanks
John
--
Stop press! Just announced -
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
Most Trusted Broadband Provider in the 2014 Moneywise Customer Services Awards
For full details of see https://www.utilitywarehouse.co.uk/reviews?exref=095761
Intrigued? Call me
John Ballance C.Eng MIET - jwb@macpcrepair.co.uk - 07976 295923
Saturday, 16 May 2015
Re: [gccsdk] static build of libcrypto
In article <DUB120-DS17ED2B80851EC510C949FFF0DB0@phx.gbl>,
alan buckley <alan_baa@hotmail.com> wrote:
> This resolved most symbols, but it looks like dladdr is missing from the
> static library.
I checked in a change to libssl so libcrypto longer uses dladdr.
Chris.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
alan buckley <alan_baa@hotmail.com> wrote:
> This resolved most symbols, but it looks like dladdr is missing from the
> static library.
I checked in a change to libssl so libcrypto longer uses dladdr.
Chris.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [Rpcemu] Another connection problem
In article <54c313f46fdave@triffid.co.uk>,
Dave Symes <dave@triffid.co.uk> wrote:
> On 13 May, dave@triffid.co.uk wrote:
> > Ah well that was late yesterday.
> > Today (Wednesday) upon booting up everything, I find that what I thought
> > yesterday, is not the same today.
> > Obviously networking Win side is the same as before, however networking
> > on the RPCEmu install is not. It gives the appearance of working, but
> > fails.
> > So it looks like the later versions of Open VNP are suss.
> > When (I get time), I'll uninstall 2.3.6 and start again with 2.1.3 and
> > see what happens.
> > Dave
> Awooga awooga awooga! Brain fart...
> Silly old man, even though it was there in front of me when I did the
> bridging... I didn't notice... The laptop is connected to the network
> via WAP (Wireless access point) so not suprising it was not working
> well.(It's a known RPCEmu might not work over WiFi thing).
> The Win side continued to worked okay over the bridged connection.
> Thereafter I did install 2.1.3 which obviously didn't play the game
> either.
> Strange business, as the RO ShareFS shares on other machines showed in
> name, but were not accessible.
> Time to stop playing and get on...
> Dave
> As all other computer on the LAN here are cable connected, no problems.
> D.
Right, a bit of time to play...
I was intrigued...
I took the laptop networking off WiFi and put it on a cable, uninstalled
Open VNP 2.1.3 then after a cold boot installed it again.
Did all the required config stuff/bridging etc.
So now I still have Win networking working okay.
I now have ShareFS networking between the Laptop RPCEmu and the two Real
RPCs on the LAN, but ShareFS will not work between the Laptop RPCEmu and
any RPCEmus on other PCs or V-V (Other RPCEmus talk to each other okay).
They show in the ShareFS Discs window (On all the RPCEmus) and can be
double clicked to the icon bar, but then when clicked on won't connect.
FWIW. All Win-PC machines are running as the same named Workgroup.
Anyone have any thought on why it'll connect with Real RO but not any
virtuals?
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Dave Symes <dave@triffid.co.uk> wrote:
> On 13 May, dave@triffid.co.uk wrote:
> > Ah well that was late yesterday.
> > Today (Wednesday) upon booting up everything, I find that what I thought
> > yesterday, is not the same today.
> > Obviously networking Win side is the same as before, however networking
> > on the RPCEmu install is not. It gives the appearance of working, but
> > fails.
> > So it looks like the later versions of Open VNP are suss.
> > When (I get time), I'll uninstall 2.3.6 and start again with 2.1.3 and
> > see what happens.
> > Dave
> Awooga awooga awooga! Brain fart...
> Silly old man, even though it was there in front of me when I did the
> bridging... I didn't notice... The laptop is connected to the network
> via WAP (Wireless access point) so not suprising it was not working
> well.(It's a known RPCEmu might not work over WiFi thing).
> The Win side continued to worked okay over the bridged connection.
> Thereafter I did install 2.1.3 which obviously didn't play the game
> either.
> Strange business, as the RO ShareFS shares on other machines showed in
> name, but were not accessible.
> Time to stop playing and get on...
> Dave
> As all other computer on the LAN here are cable connected, no problems.
> D.
Right, a bit of time to play...
I was intrigued...
I took the laptop networking off WiFi and put it on a cable, uninstalled
Open VNP 2.1.3 then after a cold boot installed it again.
Did all the required config stuff/bridging etc.
So now I still have Win networking working okay.
I now have ShareFS networking between the Laptop RPCEmu and the two Real
RPCs on the LAN, but ShareFS will not work between the Laptop RPCEmu and
any RPCEmus on other PCs or V-V (Other RPCEmus talk to each other okay).
They show in the ShareFS Discs window (On all the RPCEmus) and can be
double clicked to the icon bar, but then when clicked on won't connect.
FWIW. All Win-PC machines are running as the same named Workgroup.
Anyone have any thought on why it'll connect with Real RO but not any
virtuals?
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 15 May 2015
[gccsdk] [Bug 260] New: readdir fails to return any files on Fat32FS with suffix swapping
http://www.riscos.info/bugzilla3/show_bug.cgi?id=260
Summary: readdir fails to return any files on Fat32FS with
suffix swapping
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: Unixlib and SharedCLibrary
AssignedTo: peter@chocky.org
ReportedBy: alan_baa@hotmail.com
Estimated Hours: 0.0
If suffix swapping is on and a directory contains a large number of files on a
Fat32FS drive than iterating the directory using opendir/readdir will not
return all the files.
The problems is because the hack described in dirent.c does not work on
Fat32FS, so it should be recoded to avoid the hack.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Summary: readdir fails to return any files on Fat32FS with
suffix swapping
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: Unixlib and SharedCLibrary
AssignedTo: peter@chocky.org
ReportedBy: alan_baa@hotmail.com
Estimated Hours: 0.0
If suffix swapping is on and a directory contains a large number of files on a
Fat32FS drive than iterating the directory using opendir/readdir will not
return all the files.
The problems is because the hack described in dirent.c does not work on
Fat32FS, so it should be recoded to avoid the hack.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] Native !GCC gcc and cpp issues
I think unixify failure is wrong description so I have started this new thread as a continuation of the same problems for the Native !GCC
gccsdk/gcc4/recipe/files/gcc/gcc/config/arm/riscos-gcc.c has a function
riscos_convert_filename()
that spoils '*gcc foo.bar.c' from working and also does nothing to help
gcc example.c -I../foo.bar
I have built a native !GCC 4.7.4 with a bypass of that function,
and it fixes the first problem and
gcc foo.bar.c (lex.yy.c)
now works.
Before and after this change to riscos-gcc.c
there is no alteration to the -I../foo.bar problem which currently only
works if the RISC OS name is used
-I^foo/bar or
@.foo/bar (for the current directory)
I now have to find a place to convert the -I../foo.bar to RISC OS.
There is a file
gccsdk/gcc4/recipe/files/gcc/libcpp/rname.c
but it seems to be to do with CROSS_DIRECTORY_STRUCTURE and RISC OS library paths.
maybe the patch to riscosify will have to be in cpp itself.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
gccsdk/gcc4/recipe/files/gcc/gcc/config/arm/riscos-gcc.c has a function
riscos_convert_filename()
that spoils '*gcc foo.bar.c' from working and also does nothing to help
gcc example.c -I../foo.bar
I have built a native !GCC 4.7.4 with a bypass of that function,
and it fixes the first problem and
gcc foo.bar.c (lex.yy.c)
now works.
Before and after this change to riscos-gcc.c
there is no alteration to the -I../foo.bar problem which currently only
works if the RISC OS name is used
-I^foo/bar or
@.foo/bar (for the current directory)
I now have to find a place to convert the -I../foo.bar to RISC OS.
There is a file
gccsdk/gcc4/recipe/files/gcc/libcpp/rname.c
but it seems to be to do with CROSS_DIRECTORY_STRUCTURE and RISC OS library paths.
maybe the patch to riscosify will have to be in cpp itself.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 14 May 2015
Re: More disc cache improvements
On 8 May 2015 as I do recall,
Vincent Sanders wrote:
>
> I am interested in the persistent disc cache write performance on
> different platforms, especially RISC OS, to see if my recent changes
> improve the situation there..
>
[snip]
> I would like these two lines from the logfile along with the OS and
> hardware spec of the system. E.g. "RISC OS 5 on Iyonix with FAT
> formatted hard drive" or "ROOL beta on Raspberry Pi 2 with FAT
> formatted SD card"
>
Here are three examples from recent browsing sessions on using RISC OS
5 on Iyonix - no idea what format the hard drive is, I'm afraid, but it is a
normal hard disc and not a card-based system.
(13649.720000) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 1376/258/1118/0 (100%/18%/81%/0%)
(13649.720000) content/llcache.c llcache_finalise 3361: Backing store wrote 35071872 bytes in 0 ms average 23816 bytes/second
(7479.800000) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 656/168/488/0 (100%/25%/74%/0%)
(7479.800000) content/llcache.c llcache_finalise 3361: Backing store wrote 3034863 bytes in 0 ms average 5796 bytes/second
21213.750000) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 2061/418/1643/0 (100%/20%/79%/0%)
(21213.750000) content/llcache.c llcache_finalise 3361: Backing store wrote 10209144 bytes in 0 ms average 22666 bytes/second
There's clearly massive variation involved; I notice that the 'fast'
examples above (1 and 3) list over a hundred images never
rendered while the 'slow' example lists only 41, and example 1 lists 83
'excessive conversions' from 59 images converted more than once while the
second two runs both list zero excessive conversions....
--
Harriet Bazley == Loyaulte me lie ==
An atheist is a man with no invisible means of support.
Vincent Sanders wrote:
>
> I am interested in the persistent disc cache write performance on
> different platforms, especially RISC OS, to see if my recent changes
> improve the situation there..
>
[snip]
> I would like these two lines from the logfile along with the OS and
> hardware spec of the system. E.g. "RISC OS 5 on Iyonix with FAT
> formatted hard drive" or "ROOL beta on Raspberry Pi 2 with FAT
> formatted SD card"
>
Here are three examples from recent browsing sessions on using RISC OS
5 on Iyonix - no idea what format the hard drive is, I'm afraid, but it is a
normal hard disc and not a card-based system.
(13649.720000) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 1376/258/1118/0 (100%/18%/81%/0%)
(13649.720000) content/llcache.c llcache_finalise 3361: Backing store wrote 35071872 bytes in 0 ms average 23816 bytes/second
(7479.800000) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 656/168/488/0 (100%/25%/74%/0%)
(7479.800000) content/llcache.c llcache_finalise 3361: Backing store wrote 3034863 bytes in 0 ms average 5796 bytes/second
21213.750000) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 2061/418/1643/0 (100%/20%/79%/0%)
(21213.750000) content/llcache.c llcache_finalise 3361: Backing store wrote 10209144 bytes in 0 ms average 22666 bytes/second
There's clearly massive variation involved; I notice that the 'fast'
examples above (1 and 3) list over a hundred images never
rendered while the 'slow' example lists only 41, and example 1 lists 83
'excessive conversions' from 59 images converted more than once while the
second two runs both list zero excessive conversions....
--
Harriet Bazley == Loyaulte me lie ==
An atheist is a man with no invisible means of support.
Re: Google
On 13 May 2015 as I do recall,
Richard Ashbery wrote:
> In article <54c2328532JohnRW@ukgateway.net>, John Williams
> I've just tried Google again with Javascript off and a search works
> normally. Anyone able to confirm?
>
Excellent - I'm amazed. I was about to report a total lack of feedback via
the Twitter route, but perhaps they actually took some notice of the various
reports after all!
--
Harriet Bazley == Loyaulte me lie ==
It is impossible to enjoy idling thoroughly unless one has plenty of work to do
Richard Ashbery wrote:
> In article <54c2328532JohnRW@ukgateway.net>, John Williams
> I've just tried Google again with Javascript off and a search works
> normally. Anyone able to confirm?
>
Excellent - I'm amazed. I was about to report a total lack of feedback via
the Twitter route, but perhaps they actually took some notice of the various
reports after all!
--
Harriet Bazley == Loyaulte me lie ==
It is impossible to enjoy idling thoroughly unless one has plenty of work to do
Re: Google
In message <54c34dbdb8brian.jordan9@btinternet.com>
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <54c3467e90riscos@gotadsl.co.uk>,
> Richard Ashbery <riscos@gotadsl.co.uk> wrote:
>> In article <54c2328532JohnRW@ukgateway.net>, John Williams
>> <JohnRW@ukgateway.net> wrote:
>> > In article <1c3b90c054.ricp@user.minijem.plus.com>, Richard Porter
>> > <ricp@minijem.plus.com> wrote:
>
>> > > I think it's absolutely essential that we have a javascript
>> > > on/off button on the toolbar. If javescript is off google won't
>> > > work and if it's on streetmap.co.uk won't work.
>
>> I've just tried Google again with Javascript off and a search works
>> normally. Anyone able to confirm?
>
> Seems to be true here as well.
>
Same here (NS 3.4 Dev CI #2735).
--
George
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <54c3467e90riscos@gotadsl.co.uk>,
> Richard Ashbery <riscos@gotadsl.co.uk> wrote:
>> In article <54c2328532JohnRW@ukgateway.net>, John Williams
>> <JohnRW@ukgateway.net> wrote:
>> > In article <1c3b90c054.ricp@user.minijem.plus.com>, Richard Porter
>> > <ricp@minijem.plus.com> wrote:
>
>> > > I think it's absolutely essential that we have a javascript
>> > > on/off button on the toolbar. If javescript is off google won't
>> > > work and if it's on streetmap.co.uk won't work.
>
>> I've just tried Google again with Javascript off and a search works
>> normally. Anyone able to confirm?
>
> Seems to be true here as well.
>
Same here (NS 3.4 Dev CI #2735).
--
George
Wednesday, 13 May 2015
Re: Google
In article <54c3467e90riscos@gotadsl.co.uk>,
Richard Ashbery <riscos@gotadsl.co.uk> wrote:
> In article <54c2328532JohnRW@ukgateway.net>, John Williams
> <JohnRW@ukgateway.net> wrote:
> > In article <1c3b90c054.ricp@user.minijem.plus.com>, Richard Porter
> > <ricp@minijem.plus.com> wrote:
> > > I think it's absolutely essential that we have a javascript
> > > on/off button on the toolbar. If javescript is off google won't
> > > work and if it's on streetmap.co.uk won't work.
> I've just tried Google again with Javascript off and a search works
> normally. Anyone able to confirm?
Seems to be true here as well.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
Richard Ashbery <riscos@gotadsl.co.uk> wrote:
> In article <54c2328532JohnRW@ukgateway.net>, John Williams
> <JohnRW@ukgateway.net> wrote:
> > In article <1c3b90c054.ricp@user.minijem.plus.com>, Richard Porter
> > <ricp@minijem.plus.com> wrote:
> > > I think it's absolutely essential that we have a javascript
> > > on/off button on the toolbar. If javescript is off google won't
> > > work and if it's on streetmap.co.uk won't work.
> I've just tried Google again with Javascript off and a search works
> normally. Anyone able to confirm?
Seems to be true here as well.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
Re: Google
In article <54c34a2274JohnRW@ukgateway.net>, John Williams
<JohnRW@ukgateway.net> wrote:
> In article <54c3467e90riscos@gotadsl.co.uk>, Richard Ashbery
> <riscos@gotadsl.co.uk> wrote:
> > I've just tried Google again with Javascript off and a search
> > works normally. Anyone able to confirm?
> Yes, it's fine again!
> Perhaps my feedback was noted! Message-ID:
> <54c0f9056fJohnRW@ukgateway.net>
> > I have used the Send feedback link on the bottom of a search page
> > to send this. I hope others will follow.
Have done that but mainly thanking them for mending their broken code.
If it goes belly-up again we can always use your rather clever
Javascript control utility.
Richard
<JohnRW@ukgateway.net> wrote:
> In article <54c3467e90riscos@gotadsl.co.uk>, Richard Ashbery
> <riscos@gotadsl.co.uk> wrote:
> > I've just tried Google again with Javascript off and a search
> > works normally. Anyone able to confirm?
> Yes, it's fine again!
> Perhaps my feedback was noted! Message-ID:
> <54c0f9056fJohnRW@ukgateway.net>
> > I have used the Send feedback link on the bottom of a search page
> > to send this. I hope others will follow.
Have done that but mainly thanking them for mending their broken code.
If it goes belly-up again we can always use your rather clever
Javascript control utility.
Richard
Re: Google
In article <54c3467e90riscos@gotadsl.co.uk>,
Richard Ashbery <riscos@gotadsl.co.uk> wrote:
> I've just tried Google again with Javascript off and a search works
> normally. Anyone able to confirm?
Yes, it's fine again!
Perhaps my feedback was noted! Message-ID: <54c0f9056fJohnRW@ukgateway.net>
> I have used the Send feedback link on the bottom of a search page to send
> this. I hope others will follow.
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Rites *
Richard Ashbery <riscos@gotadsl.co.uk> wrote:
> I've just tried Google again with Javascript off and a search works
> normally. Anyone able to confirm?
Yes, it's fine again!
Perhaps my feedback was noted! Message-ID: <54c0f9056fJohnRW@ukgateway.net>
> I have used the Send feedback link on the bottom of a search page to send
> this. I hope others will follow.
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Rites *
Re: Google
In article <54c2328532JohnRW@ukgateway.net>, John Williams
<JohnRW@ukgateway.net> wrote:
> In article <1c3b90c054.ricp@user.minijem.plus.com>, Richard Porter
> <ricp@minijem.plus.com> wrote:
> > I think it's absolutely essential that we have a javascript
> > on/off button on the toolbar. If javescript is off google won't
> > work and if it's on streetmap.co.uk won't work.
I've just tried Google again with Javascript off and a search works
normally. Anyone able to confirm?
Richard
<JohnRW@ukgateway.net> wrote:
> In article <1c3b90c054.ricp@user.minijem.plus.com>, Richard Porter
> <ricp@minijem.plus.com> wrote:
> > I think it's absolutely essential that we have a javascript
> > on/off button on the toolbar. If javescript is off google won't
> > work and if it's on streetmap.co.uk won't work.
I've just tried Google again with Javascript off and a search works
normally. Anyone able to confirm?
Richard
[Rpcemu] Another connection problem
On 13 May, dave@triffid.co.uk wrote:
> Ah well that was late yesterday.
> Today (Wednesday) upon booting up everything, I find that what I thought
> yesterday, is not the same today.
> Obviously networking Win side is the same as before, however networking
> on the RPCEmu install is not. It gives the appearance of working, but
> fails.
> So it looks like the later versions of Open VNP are suss.
> When (I get time), I'll uninstall 2.3.6 and start again with 2.1.3 and
> see what happens.
> Dave
Awooga awooga awooga! Brain fart...
Silly old man, even though it was there in front of me when I did the
bridging... I didn't notice... The laptop is connected to the network via
WAP (Wireless access point) so not suprising it was not working well.(It's
a known RPCEmu might not work over WiFi thing).
The Win side continued to worked okay over the bridged connection.
Thereafter I did install 2.1.3 which obviously didn't play the game either.
Strange business, as the RO ShareFS shares on other machines showed in
name, but were not accessible.
Time to stop playing and get on...
Dave
As all other computer on the LAN here are cable connected, no problems.
D.
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Ah well that was late yesterday.
> Today (Wednesday) upon booting up everything, I find that what I thought
> yesterday, is not the same today.
> Obviously networking Win side is the same as before, however networking
> on the RPCEmu install is not. It gives the appearance of working, but
> fails.
> So it looks like the later versions of Open VNP are suss.
> When (I get time), I'll uninstall 2.3.6 and start again with 2.1.3 and
> see what happens.
> Dave
Awooga awooga awooga! Brain fart...
Silly old man, even though it was there in front of me when I did the
bridging... I didn't notice... The laptop is connected to the network via
WAP (Wireless access point) so not suprising it was not working well.(It's
a known RPCEmu might not work over WiFi thing).
The Win side continued to worked okay over the bridged connection.
Thereafter I did install 2.1.3 which obviously didn't play the game either.
Strange business, as the RO ShareFS shares on other machines showed in
name, but were not accessible.
Time to stop playing and get on...
Dave
As all other computer on the LAN here are cable connected, no problems.
D.
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tuesday, 12 May 2015
Re: [Rpcemu] Another connection problem
In article
<CAC85+4Kaxs+i8Un-FmJaww-2dxLkKe8doinbtSThCfhSyYU=jA@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
> So 64bit problem only?
> Hum...
> 2015-05-12 23:18 GMT+02:00 Dave Symes <dave@triffid.co.uk>:
> > In article
> > <CAC85+4+Tk_KE9dJWSyKTvLvDxBj4mstKvwZb20MdAGB2=08BXA@mail.gmail.com>,
> > David Feugey <dfeugey@ascinfo.fr> wrote:
> > [Snippy]
> >
> > > Interesting. I read somewhere that with newer versions of OpenVPN,
> > > TAP code was rewritten, and more strict on sync/async code (multiple
> > > commands = async, even if you use sync functions... or something
> > > like this). Many people seems to have problem to use it from their
> > > code.
> >
> > > I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
> >
> > Glad you've now got it working.
> >
> > A FWIW. Just for the fun of it, I went to my old laptop running Win 7
> > Home 32 bit, a machine that's never had RPCEmu or a Networking bridge
> > installed.
> >
> > Copied a RPCEmu running 5.22 to it, installed OpenVNP 2.3.6 then32 bit
> > version (Just the TAP bit) did all the post install stuff and it just
> > worked okay.
> >
> > Dave
[Snip]
Ah well that was late yesterday.
Today (Wednesday) upon booting up everything, I find that what I thought
yesterday, is not the same today.
Obviously networking Win side is the same as before, however networking on
the RPCEmu install is not.
It gives the appearance of working, but fails.
So it looks like the later versions of Open VNP are suss.
When (I get time), I'll uninstall 2.3.6 and start again with 2.1.3 and see
what happens.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAC85+4Kaxs+i8Un-FmJaww-2dxLkKe8doinbtSThCfhSyYU=jA@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
> So 64bit problem only?
> Hum...
> 2015-05-12 23:18 GMT+02:00 Dave Symes <dave@triffid.co.uk>:
> > In article
> > <CAC85+4+Tk_KE9dJWSyKTvLvDxBj4mstKvwZb20MdAGB2=08BXA@mail.gmail.com>,
> > David Feugey <dfeugey@ascinfo.fr> wrote:
> > [Snippy]
> >
> > > Interesting. I read somewhere that with newer versions of OpenVPN,
> > > TAP code was rewritten, and more strict on sync/async code (multiple
> > > commands = async, even if you use sync functions... or something
> > > like this). Many people seems to have problem to use it from their
> > > code.
> >
> > > I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
> >
> > Glad you've now got it working.
> >
> > A FWIW. Just for the fun of it, I went to my old laptop running Win 7
> > Home 32 bit, a machine that's never had RPCEmu or a Networking bridge
> > installed.
> >
> > Copied a RPCEmu running 5.22 to it, installed OpenVNP 2.3.6 then32 bit
> > version (Just the TAP bit) did all the post install stuff and it just
> > worked okay.
> >
> > Dave
[Snip]
Ah well that was late yesterday.
Today (Wednesday) upon booting up everything, I find that what I thought
yesterday, is not the same today.
Obviously networking Win side is the same as before, however networking on
the RPCEmu install is not.
It gives the appearance of working, but fails.
So it looks like the later versions of Open VNP are suss.
When (I get time), I'll uninstall 2.3.6 and start again with 2.1.3 and see
what happens.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Another connection problem
So 64bit problem only?
Hum...2015-05-12 23:18 GMT+02:00 Dave Symes <dave@triffid.co.uk>:
In article
<CAC85+4+Tk_KE9dJWSyKTvLvDxBj4mstKvwZb20MdAGB2=08BXA@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
[Snippy]
> Interesting. I read somewhere that with newer versions of OpenVPN, TAP
> code was rewritten, and more strict on sync/async code (multiple
> commands = async, even if you use sync functions... or something like
> this). Many people seems to have problem to use it from their code.
> I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
Glad you've now got it working.
A FWIW.
Just for the fun of it, I went to my old laptop running Win 7 Home 32 bit,
a machine that's never had RPCEmu or a Networking bridge installed.
Copied a RPCEmu running 5.22 to it, installed OpenVNP 2.3.6 then32 bit
version (Just the TAP bit) did all the post install stuff and it just
worked okay.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
--
Mobile : 06 76 67 91 60
Re: [Rpcemu] Another connection problem
In article
<CAC85+4+Tk_KE9dJWSyKTvLvDxBj4mstKvwZb20MdAGB2=08BXA@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
[Snippy]
> Interesting. I read somewhere that with newer versions of OpenVPN, TAP
> code was rewritten, and more strict on sync/async code (multiple
> commands = async, even if you use sync functions... or something like
> this). Many people seems to have problem to use it from their code.
> I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
Glad you've now got it working.
A FWIW.
Just for the fun of it, I went to my old laptop running Win 7 Home 32 bit,
a machine that's never had RPCEmu or a Networking bridge installed.
Copied a RPCEmu running 5.22 to it, installed OpenVNP 2.3.6 then32 bit
version (Just the TAP bit) did all the post install stuff and it just
worked okay.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAC85+4+Tk_KE9dJWSyKTvLvDxBj4mstKvwZb20MdAGB2=08BXA@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
[Snippy]
> Interesting. I read somewhere that with newer versions of OpenVPN, TAP
> code was rewritten, and more strict on sync/async code (multiple
> commands = async, even if you use sync functions... or something like
> this). Many people seems to have problem to use it from their code.
> I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
Glad you've now got it working.
A FWIW.
Just for the fun of it, I went to my old laptop running Win 7 Home 32 bit,
a machine that's never had RPCEmu or a Networking bridge installed.
Copied a RPCEmu running 5.22 to it, installed OpenVNP 2.3.6 then32 bit
version (Just the TAP bit) did all the post install stuff and it just
worked okay.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Another connection problem
2015-05-12 13:52 GMT+02:00 Peter Howkins <rpcemu.howkins@marutan.net>:
My guess: sync / async.On Tue, May 12, 2015 at 07:47:39AM +0200, David Feugey wrote:
> Perhaps you should mention which version of TAP you're using.
>
> Latest version 9.21.1
>
>
> Also attach the full log file to the thread.
>
> It is basically done.
> The rest (AKA ...) is loadconfig lines, and OS lines. With no error.
Yes, those are what I want to see. Those lines were added to aid in
reproducing the setup that the user has, a reproducable bug is one that's
likely to get fixed rather than ignored.
Please post the log on *all* issues reported.
Why not...
RPCEmu 0.8.12
Build: 32-bit binary
Compiler: GCC version 4.6.2
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x100
OS: ServicePackMajor = 1
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 48
Allegro version ID: Allegro 4.4.2, MinGW32
Host Colour Depth: 32
Working Directory: C:\Users\Utilisateur\Virtual Machines\RPCEmu\RPCEmu 5.22
loadconfig: bridgename = "rpcemu"
loadconfig: model = "RPCSA"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "ethernetbridging"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "0"
loadconfig: cdrom_enabled = "1"
loadconfig: refresh_rate = "30"
loadconfig: stretch_mode = "1"
loadconfig: sound_enabled = "1"
loadconfig: vram_size = "2"
loadconfig: mem_size = "128"
loadconfig: cpu_idle = "1"
romload: Loaded 'riscos' 4194304 bytes
romload: Total ROM size 4 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
RPCEmu 0.8.12
Build: 32-bit binary
Compiler: GCC version 4.6.2
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x100
OS: ServicePackMajor = 1
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 48
Allegro version ID: Allegro 4.4.2, MinGW32
Host Colour Depth: 32
Working Directory: C:\Users\Utilisateur\Virtual Machines\RPCEmu\RPCEmu 5.22
loadconfig: bridgename = "rpcemu"
loadconfig: model = "RPCSA"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "ethernetbridging"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "0"
loadconfig: cdrom_enabled = "1"
loadconfig: refresh_rate = "30"
loadconfig: stretch_mode = "1"
loadconfig: sound_enabled = "1"
loadconfig: vram_size = "2"
loadconfig: mem_size = "128"
loadconfig: cpu_idle = "1"
romload: Loaded 'riscos' 4194304 bytes
romload: Total ROM size 4 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
Latest version of RPCEmu, under Windows 7 Pro, startup all OK, as stated before.
Even networking, since I give indication about correct MAC address inside RISC OS.
Nota: I unplugged SyncClock, since it does not interact the right way with RISC OS 5.22.
> Also *disable* windows firewall (or any third party firewall) and test.
>
> Already tested. No effect.
>
> 2) The version I'm using is 'TAP-Windows Provider V9' (Open VNP 2.1.3)
>
> Interesting. I read somewhere that with newer versions of OpenVPN, TAP
> code was rewritten, and more strict on sync/async code (multiple commands
> = async, even if you use sync functions... or something like this). Many
> people seems to have problem to use it from their code.
>
> I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
> Should I suggest an update? I'm now stuck with an old version of OpenVPN
> (that I use for other purposes), including many flaws... Not very optimal
> (but it works).
Incidentally, now I know it causes an issue I'll see if I can add which
version of the the TAP drier is in use to the log file ....
It's already the case and was in my fragment of log file.
Tap-Win32: version: 9.21.0
I'll attempt to reproduce this with the new driver and see if there's a
simple fix.
Bye, David
Re: [Rpcemu] Another connection problem
On Tue, May 12, 2015 at 07:47:39AM +0200, David Feugey wrote:
> Perhaps you should mention which version of TAP you're using.
>
> Latest version 9.21.1
>
>
> Also attach the full log file to the thread.
>
> It is basically done.
> The rest (AKA ...) is loadconfig lines, and OS lines. With no error.
Yes, those are what I want to see. Those lines were added to aid in
reproducing the setup that the user has, a reproducable bug is one that's
likely to get fixed rather than ignored.
Please post the log on *all* issues reported.
> Also *disable* windows firewall (or any third party firewall) and test.
>
> Already tested. No effect.
>
> 2) The version I'm using is 'TAP-Windows Provider V9' (Open VNP 2.1.3)
>
> Interesting. I read somewhere that with newer versions of OpenVPN, TAP
> code was rewritten, and more strict on sync/async code (multiple commands
> = async, even if you use sync functions... or something like this). Many
> people seems to have problem to use it from their code.
>
> I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
> Should I suggest an update? I'm now stuck with an old version of OpenVPN
> (that I use for other purposes), including many flaws... Not very optimal
> (but it works).
Incidentally, now I know it causes an issue I'll see if I can add which
version of the the TAP drier is in use to the log file ....
I'll attempt to reproduce this with the new driver and see if there's a
simple fix.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Perhaps you should mention which version of TAP you're using.
>
> Latest version 9.21.1
>
>
> Also attach the full log file to the thread.
>
> It is basically done.
> The rest (AKA ...) is loadconfig lines, and OS lines. With no error.
Yes, those are what I want to see. Those lines were added to aid in
reproducing the setup that the user has, a reproducable bug is one that's
likely to get fixed rather than ignored.
Please post the log on *all* issues reported.
> Also *disable* windows firewall (or any third party firewall) and test.
>
> Already tested. No effect.
>
> 2) The version I'm using is 'TAP-Windows Provider V9' (Open VNP 2.1.3)
>
> Interesting. I read somewhere that with newer versions of OpenVPN, TAP
> code was rewritten, and more strict on sync/async code (multiple commands
> = async, even if you use sync functions... or something like this). Many
> people seems to have problem to use it from their code.
>
> I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
> Should I suggest an update? I'm now stuck with an old version of OpenVPN
> (that I use for other purposes), including many flaws... Not very optimal
> (but it works).
Incidentally, now I know it causes an issue I'll see if I can add which
version of the the TAP drier is in use to the log file ....
I'll attempt to reproduce this with the new driver and see if there's a
simple fix.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 11 May 2015
Re: [Rpcemu] Another connection problem
Perhaps you should mention which version of TAP you're using.
Latest version 9.21.1
Also attach the full log file to the thread.
It is basically done.
The rest (AKA ...) is loadconfig lines, and OS lines. With no error.
Also *disable* windows firewall (or any third party firewall) and test.
Already tested. No effect.
2) The version I'm using is 'TAP-Windows Provider V9' (Open VNP 2.1.3)
Interesting. I read somewhere that with newer versions of OpenVPN, TAP code was rewritten, and more strict on sync/async code (multiple commands = async, even if you use sync functions... or something like this). Many people seems to have problem to use it from their code.
I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
Should I suggest an update? I'm now stuck with an old version of OpenVPN (that I use for other purposes), including many flaws... Not very optimal (but it works).
Thanks again.
David.
-- Mobile : 06 76 67 91 60
Re: [gccsdk] make: File '-c' not found
In message <5550C668.2070701@gmx.com>
Duncan Moore <duncan.moore@gmx.com> wrote:
>
> On 03/02/2015 16:11, Duncan Moore wrote:
> > The problem is with 'make'.
> > This code is in job.c:
> >
> > #elif defined (__riscos__)
> >
> > char default_shell[] = "";
> > int batch_mode_shell = 0;
> >
> > #else
> >
> > It's not just in the RISC OS version, but in the GNU make version itself.
> > If I remove this code (so default_shell becomes "/bin/sh"), then
> > everything works.
>
> I've had this code removed in my local version of 'make' since February
> and experienced no problems. WPB, Ron, I think you've been using it too
> (Ron's local version). Any problems? If not, and seeing as the Unixlib
> exec*() functions have logic to handle "/bin/sh", then if no-one has any
> objections I'll send these changes to the GNU 'make' bug list, and
> eventually they'll feed through to the RISC OS version:
>
> diff -u make-4-1/job.c make-4-1-ro1/job.c
> --- make-4-1/job.c 2014-10-05 17:24:51 +0100
> +++ make-4-1-ro1/job.c 2015-05-11 15:18:07 +0100
> @@ -62,11 +62,6 @@
> const char *default_shell = "";
> int batch_mode_shell = 0;
>
> -#elif defined (__riscos__)
> -
> -const char *default_shell = "";
> -int batch_mode_shell = 0;
> -
> #else
>
> const char *default_shell = "/bin/sh";
>
> Duncan
I haven't seen anything bad happen since removing those changes.
For people with old or existing make, they should always have
SHELL = /bin/bash
in their makefile to avoid thed issue.
It will become the default once you have your change accepted.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Duncan Moore <duncan.moore@gmx.com> wrote:
>
> On 03/02/2015 16:11, Duncan Moore wrote:
> > The problem is with 'make'.
> > This code is in job.c:
> >
> > #elif defined (__riscos__)
> >
> > char default_shell[] = "";
> > int batch_mode_shell = 0;
> >
> > #else
> >
> > It's not just in the RISC OS version, but in the GNU make version itself.
> > If I remove this code (so default_shell becomes "/bin/sh"), then
> > everything works.
>
> I've had this code removed in my local version of 'make' since February
> and experienced no problems. WPB, Ron, I think you've been using it too
> (Ron's local version). Any problems? If not, and seeing as the Unixlib
> exec*() functions have logic to handle "/bin/sh", then if no-one has any
> objections I'll send these changes to the GNU 'make' bug list, and
> eventually they'll feed through to the RISC OS version:
>
> diff -u make-4-1/job.c make-4-1-ro1/job.c
> --- make-4-1/job.c 2014-10-05 17:24:51 +0100
> +++ make-4-1-ro1/job.c 2015-05-11 15:18:07 +0100
> @@ -62,11 +62,6 @@
> const char *default_shell = "";
> int batch_mode_shell = 0;
>
> -#elif defined (__riscos__)
> -
> -const char *default_shell = "";
> -int batch_mode_shell = 0;
> -
> #else
>
> const char *default_shell = "/bin/sh";
>
> Duncan
I haven't seen anything bad happen since removing those changes.
For people with old or existing make, they should always have
SHELL = /bin/bash
in their makefile to avoid thed issue.
It will become the default once you have your change accepted.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [Rpcemu] Another connection problem
On Mon, May 11, 2015 at 10:06:50PM +0200, David Feugey wrote:
> Small but important correction.I made tests again. Interface is OK under
> RISC OS with right MAC address.
> When pinging something, packets are sent, answer is received by the bridge
> but does not reach the TAP interface.
> Nota: the same TAP module works with OpenVPN.
> Perhaps I should try with an old version of TAP?
Perhaps you should mention which version of TAP you're using.
Also attach the full log file to the thread.
Also *disable* windows firewall (or any third party firewall) and test.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Small but important correction.I made tests again. Interface is OK under
> RISC OS with right MAC address.
> When pinging something, packets are sent, answer is received by the bridge
> but does not reach the TAP interface.
> Nota: the same TAP module works with OpenVPN.
> Perhaps I should try with an old version of TAP?
Perhaps you should mention which version of TAP you're using.
Also attach the full log file to the thread.
Also *disable* windows firewall (or any third party firewall) and test.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Another connection problem
In article
<CAC85+4LG+4faCMHUesXDKUTFPMaKdy1SAk66VGSSN9mi6x3gwg@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
> I suspect many possibilities:
> 1/ problem with 64 bit OS
> 2/ problem with version of TAP
> 3/ problem with RISC OS 5.22
> 4/ problem with RPCEmu
> 5/ all of this :)
What I'm about to write is not much help, but just for info...
1) I have Win 7 Pro SP1 64 bit running this RPCEmu okay.
2) The version I'm using is 'TAP-Windows Provider V9' (Open VNP 2.1.3)
3) No problem connecting with RO 4.02, 4.39, 6.20 and 5.22
4) RPCEmu now using 0.8.12 on all RPCEmu installs. No connection problem
that relates to this thread.
One last thought, have you checked the Windows Firewall is set to allow
the RPCEmu-Recompiler.exe through.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAC85+4LG+4faCMHUesXDKUTFPMaKdy1SAk66VGSSN9mi6x3gwg@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
> I suspect many possibilities:
> 1/ problem with 64 bit OS
> 2/ problem with version of TAP
> 3/ problem with RISC OS 5.22
> 4/ problem with RPCEmu
> 5/ all of this :)
What I'm about to write is not much help, but just for info...
1) I have Win 7 Pro SP1 64 bit running this RPCEmu okay.
2) The version I'm using is 'TAP-Windows Provider V9' (Open VNP 2.1.3)
3) No problem connecting with RO 4.02, 4.39, 6.20 and 5.22
4) RPCEmu now using 0.8.12 on all RPCEmu installs. No connection problem
that relates to this thread.
One last thought, have you checked the Windows Firewall is set to allow
the RPCEmu-Recompiler.exe through.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Another connection problem
Found this in the log.
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{070E7820-9C49-40FC-82B5-6470976FFDDD}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.21.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
...
Tap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: tap_cleanup
Bye, DavidTap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{070E7820-9C49-40FC-82B5-6470976FFDDD}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.21.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
...
Tap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32: tap_cleanup
2015-05-11 22:06 GMT+02:00 David Feugey <dfeugey@ascinfo.fr>:
By, DavidPerhaps I should try with an old version of TAP?Nota: the same TAP module works with OpenVPN.When pinging something, packets are sent, answer is received by the bridge but does not reach the TAP interface.Small but important correction.I made tests again. Interface is OK under RISC OS with right MAC address.2015-05-11 21:23 GMT+02:00 David Feugey <dfeugey@ascinfo.fr>:Of course, I also tried to make it again from scratch with new TAP and new RPCemu set up, with exactly the same result: some error sometimes, and when no error, no network connection. All seems OK, but packets are not received by the TAP interface.2015-05-11 21:20 GMT+02:00 David Feugey <dfeugey@ascinfo.fr>:Bye, David5/ all of this :)4/ problem with RPCEmu3/ problem with RISC OS 5.222/ problem with version of TAP1/ problem with 64 bit OSI suspect many possibilities:Of course, ping does not workand this http://www.marutan.net/rpcemu/manual/net-ro-bri.htmlthis http://www.marutan.net/rpcemu/manual/net-ro.htmlI made this, http://www.marutan.net/rpcemu/manual/net-win.htmlYes. I also applied the commands to correct connection ; configured the ROS side ; and launchedRPCEmu with network connection, and no alert.--2015-05-11 20:18 GMT+02:00 Dave Symes <dave@triffid.co.uk>:In article
<CAC85+4KfPiyF6F4M0LjvyfNAoqbsTx76ooivFjygUyuqVkU91w@mail.gmail.com>,
One idle thought...David Feugey <dfeugey@ascinfo.fr> wrote:
> My setup: Windows 7 Pro 64bit
> On the RISC OS side: RPCEMu, last version + RISC OS 5.22
> In the middle, me, almost no hair left :)
> I configured the bridge, put the right options, and no connection.
> No packets are received by the bridge. The other part (Windows one) works
> normally.
> Should I use a very specific of OpenVPN? Problem with IPv6 or 64bit?
> Problem with ROS 5.22?
> I don't need to connect every day. It's just for !Store.
> I would be so happy to get a simple 'client mode networking' a la Virtual
> Risc PC :)
> (would solve also lot of problems when connecting to DHCP network or
> multiples networks).
> Bye, David
You have been to Win side Control panel-Network Connections and after
selecting both the "rpcemu" and original interface, done the Menu "Bridge
Connections" bit?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Mobile : 06 76 67 91 60
--Mobile : 06 76 67 91 60
--Mobile : 06 76 67 91 60
--
Mobile : 06 76 67 91 60
Re: [Rpcemu] Another connection problem
Small but important correction.I made tests again. Interface is OK under RISC OS with right MAC address.
2015-05-11 21:23 GMT+02:00 David Feugey <dfeugey@ascinfo.fr>:
Of course, I also tried to make it again from scratch with new TAP and new RPCemu set up, with exactly the same result: some error sometimes, and when no error, no network connection. All seems OK, but packets are not received by the TAP interface.2015-05-11 21:20 GMT+02:00 David Feugey <dfeugey@ascinfo.fr>:Bye, David5/ all of this :)4/ problem with RPCEmu3/ problem with RISC OS 5.222/ problem with version of TAP1/ problem with 64 bit OSI suspect many possibilities:Of course, ping does not workand this http://www.marutan.net/rpcemu/manual/net-ro-bri.htmlthis http://www.marutan.net/rpcemu/manual/net-ro.htmlI made this, http://www.marutan.net/rpcemu/manual/net-win.htmlYes. I also applied the commands to correct connection ; configured the ROS side ; and launchedRPCEmu with network connection, and no alert.--2015-05-11 20:18 GMT+02:00 Dave Symes <dave@triffid.co.uk>:In article
<CAC85+4KfPiyF6F4M0LjvyfNAoqbsTx76ooivFjygUyuqVkU91w@mail.gmail.com>,
One idle thought...David Feugey <dfeugey@ascinfo.fr> wrote:
> My setup: Windows 7 Pro 64bit
> On the RISC OS side: RPCEMu, last version + RISC OS 5.22
> In the middle, me, almost no hair left :)
> I configured the bridge, put the right options, and no connection.
> No packets are received by the bridge. The other part (Windows one) works
> normally.
> Should I use a very specific of OpenVPN? Problem with IPv6 or 64bit?
> Problem with ROS 5.22?
> I don't need to connect every day. It's just for !Store.
> I would be so happy to get a simple 'client mode networking' a la Virtual
> Risc PC :)
> (would solve also lot of problems when connecting to DHCP network or
> multiples networks).
> Bye, David
You have been to Win side Control panel-Network Connections and after
selecting both the "rpcemu" and original interface, done the Menu "Bridge
Connections" bit?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Mobile : 06 76 67 91 60
--Mobile : 06 76 67 91 60
--
Mobile : 06 76 67 91 60
Re: [Rpcemu] Another connection problem
Of course, I also tried to make it again from scratch with new TAP and new RPCemu set up, with exactly the same result: some error sometimes, and when no error, no network connection. All seems OK, but packets are not received by the TAP interface.
2015-05-11 21:20 GMT+02:00 David Feugey <dfeugey@ascinfo.fr>:
Bye, David5/ all of this :)4/ problem with RPCEmu3/ problem with RISC OS 5.222/ problem with version of TAP1/ problem with 64 bit OSI suspect many possibilities:Of course, ping does not workand this http://www.marutan.net/rpcemu/manual/net-ro-bri.htmlthis http://www.marutan.net/rpcemu/manual/net-ro.htmlI made this, http://www.marutan.net/rpcemu/manual/net-win.htmlYes. I also applied the commands to correct connection ; configured the ROS side ; and launchedRPCEmu with network connection, and no alert.--2015-05-11 20:18 GMT+02:00 Dave Symes <dave@triffid.co.uk>:In article
<CAC85+4KfPiyF6F4M0LjvyfNAoqbsTx76ooivFjygUyuqVkU91w@mail.gmail.com>,
One idle thought...David Feugey <dfeugey@ascinfo.fr> wrote:
> My setup: Windows 7 Pro 64bit
> On the RISC OS side: RPCEMu, last version + RISC OS 5.22
> In the middle, me, almost no hair left :)
> I configured the bridge, put the right options, and no connection.
> No packets are received by the bridge. The other part (Windows one) works
> normally.
> Should I use a very specific of OpenVPN? Problem with IPv6 or 64bit?
> Problem with ROS 5.22?
> I don't need to connect every day. It's just for !Store.
> I would be so happy to get a simple 'client mode networking' a la Virtual
> Risc PC :)
> (would solve also lot of problems when connecting to DHCP network or
> multiples networks).
> Bye, David
You have been to Win side Control panel-Network Connections and after
selecting both the "rpcemu" and original interface, done the Menu "Bridge
Connections" bit?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Mobile : 06 76 67 91 60
--
Mobile : 06 76 67 91 60
Re: [Rpcemu] Another connection problem
Yes. I also applied the commands to correct connection ; configured the ROS side ; and launched
RPCEmu with network connection, and no alert.2015-05-11 20:18 GMT+02:00 Dave Symes <dave@triffid.co.uk>:
In article
<CAC85+4KfPiyF6F4M0LjvyfNAoqbsTx76ooivFjygUyuqVkU91w@mail.gmail.com>,
One idle thought...David Feugey <dfeugey@ascinfo.fr> wrote:
> My setup: Windows 7 Pro 64bit
> On the RISC OS side: RPCEMu, last version + RISC OS 5.22
> In the middle, me, almost no hair left :)
> I configured the bridge, put the right options, and no connection.
> No packets are received by the bridge. The other part (Windows one) works
> normally.
> Should I use a very specific of OpenVPN? Problem with IPv6 or 64bit?
> Problem with ROS 5.22?
> I don't need to connect every day. It's just for !Store.
> I would be so happy to get a simple 'client mode networking' a la Virtual
> Risc PC :)
> (would solve also lot of problems when connecting to DHCP network or
> multiples networks).
> Bye, David
You have been to Win side Control panel-Network Connections and after
selecting both the "rpcemu" and original interface, done the Menu "Bridge
Connections" bit?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
--
Mobile : 06 76 67 91 60
Re: [Rpcemu] Another connection problem
In article
<CAC85+4KfPiyF6F4M0LjvyfNAoqbsTx76ooivFjygUyuqVkU91w@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
> My setup: Windows 7 Pro 64bit
> On the RISC OS side: RPCEMu, last version + RISC OS 5.22
> In the middle, me, almost no hair left :)
> I configured the bridge, put the right options, and no connection.
> No packets are received by the bridge. The other part (Windows one) works
> normally.
> Should I use a very specific of OpenVPN? Problem with IPv6 or 64bit?
> Problem with ROS 5.22?
> I don't need to connect every day. It's just for !Store.
> I would be so happy to get a simple 'client mode networking' a la Virtual
> Risc PC :)
> (would solve also lot of problems when connecting to DHCP network or
> multiples networks).
> Bye, David
One idle thought...
You have been to Win side Control panel-Network Connections and after
selecting both the "rpcemu" and original interface, done the Menu "Bridge
Connections" bit?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAC85+4KfPiyF6F4M0LjvyfNAoqbsTx76ooivFjygUyuqVkU91w@mail.gmail.com>,
David Feugey <dfeugey@ascinfo.fr> wrote:
> My setup: Windows 7 Pro 64bit
> On the RISC OS side: RPCEMu, last version + RISC OS 5.22
> In the middle, me, almost no hair left :)
> I configured the bridge, put the right options, and no connection.
> No packets are received by the bridge. The other part (Windows one) works
> normally.
> Should I use a very specific of OpenVPN? Problem with IPv6 or 64bit?
> Problem with ROS 5.22?
> I don't need to connect every day. It's just for !Store.
> I would be so happy to get a simple 'client mode networking' a la Virtual
> Risc PC :)
> (would solve also lot of problems when connecting to DHCP network or
> multiples networks).
> Bye, David
One idle thought...
You have been to Win side Control panel-Network Connections and after
selecting both the "rpcemu" and original interface, done the Menu "Bridge
Connections" bit?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
In article <1c3b90c054.ricp@user.minijem.plus.com>,
Richard Porter <ricp@minijem.plus.com> wrote:
> I think it's absolutely essential that we have a javascript on/off
> button on the toolbar. If javescript is off google won't work and if
> it's on streetmap.co.uk won't work.
OK - it ain't very pretty and a bit clumsy, but it seems to work
more-or-less:
My application !JS puts an application icon on the iconbar courtesy of the
Pinboard which, if double-clicked on whilst NetSurf is loaded, will change
and reflect the status of JSon or JSoff.
It only refreshes by grace of a window being briefly drawn over it, and it
moves the pointer a bit - but it seems to do the trick.
A green icon means Javascript is active, and a red one inactive. A grey one
means you've quitted or failed to load NetSurf
On my RPi the mechanics of opening configuration windows and their
subsequent closing is visible briefly, but a lot better than having to go
through all those clicks yourself. Perhaps less visible on a faster
machine.
It uses action files created by KeyStroke and executed by Executor to make
it work, and uses Shift/F1 and Shift/F2 as the shortcut keys - but if you
use these manually, the status is not refreshed on the iconbar - so don't!
It can be downloaded from:
http://le.petit.four.free.fr/JS.zip
Please contact me directly with any observations, or via the News Groups if
I subsequently make an announcement there, as this list is not for
discussion of third party applications.
Best wishes,
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Trader(s) *
Richard Porter <ricp@minijem.plus.com> wrote:
> I think it's absolutely essential that we have a javascript on/off
> button on the toolbar. If javescript is off google won't work and if
> it's on streetmap.co.uk won't work.
OK - it ain't very pretty and a bit clumsy, but it seems to work
more-or-less:
My application !JS puts an application icon on the iconbar courtesy of the
Pinboard which, if double-clicked on whilst NetSurf is loaded, will change
and reflect the status of JSon or JSoff.
It only refreshes by grace of a window being briefly drawn over it, and it
moves the pointer a bit - but it seems to do the trick.
A green icon means Javascript is active, and a red one inactive. A grey one
means you've quitted or failed to load NetSurf
On my RPi the mechanics of opening configuration windows and their
subsequent closing is visible briefly, but a lot better than having to go
through all those clicks yourself. Perhaps less visible on a faster
machine.
It uses action files created by KeyStroke and executed by Executor to make
it work, and uses Shift/F1 and Shift/F2 as the shortcut keys - but if you
use these manually, the status is not refreshed on the iconbar - so don't!
It can be downloaded from:
http://le.petit.four.free.fr/JS.zip
Please contact me directly with any observations, or via the News Groups if
I subsequently make an announcement there, as this list is not for
discussion of third party applications.
Best wishes,
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Trader(s) *
[Rpcemu] Another connection problem
My setup: Windows 7 Pro 64bit
On the RISC OS side: RPCEMu, last version + RISC OS 5.22I would be so happy to get a simple 'client mode networking' a la Virtual Risc PC :)
(would solve also lot of problems when connecting to DHCP network or multiples networks).
Bye, David
Re: Google
On Mon, May 11, 2015 at 16:05:47 +0100, Chris Newman wrote:
> In article <6fb323c254.jim@abbeypress.net>,
> Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> > Richard Porter wrote on 8 May:
> > > I think it's absolutely essential that we have a javascript on/off
> > > button on the toolbar. If javescript is off google won't work and if
> > > it's on streetmap.co.uk won't work.
> > I fourth the motion.
> I fifth, sixth, seventh ....nth the motion.
I look forward to patches provided byone of Richard, Jim or Chris; or sponsored
by them in some manner.
D.
(P.S. I think this is a fairly dodgy approach, but if it's what the users want
then the users get to supply the fix)
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> In article <6fb323c254.jim@abbeypress.net>,
> Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> > Richard Porter wrote on 8 May:
> > > I think it's absolutely essential that we have a javascript on/off
> > > button on the toolbar. If javescript is off google won't work and if
> > > it's on streetmap.co.uk won't work.
> > I fourth the motion.
> I fifth, sixth, seventh ....nth the motion.
I look forward to patches provided byone of Richard, Jim or Chris; or sponsored
by them in some manner.
D.
(P.S. I think this is a fairly dodgy approach, but if it's what the users want
then the users get to supply the fix)
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Subscribe to:
Posts (Atom)