Saturday, 14 November 2020

Re: I would like to help

On Sat, Nov 14, 2020 at 05:20:24AM +0000, Lorenzo Miguel Tareszkiewicz Rezende wrote:
> First, I would like to know somethings:
>
> * Why is netsurf not hosted on a source public code repo like github, gitlab (OpenSource) or Bitbucker?

We have our own infrastructure that works well for us. It is, however,
public: anyone can access it. We'd rather not outsource our downtime to
another organisation.

> * Does you guys want help on webassembly implementation and javascript?

Yes! We use Duktape as the interpreter, but the bindings to our DOM are
still incomplete.

> * Does Netsurf provide a api like CEF or WPE Webkit?

I think these are APIs for embedding a browser in another app? This has
been on our TODO list for a very long time but it's a bit more involved
that it first sounds due to having to turn the whole event processing
system up-side-down.

B.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: I would like to help

On Sat, Nov 14, 2020 at 05:20:24 +0000, Lorenzo Miguel Tareszkiewicz Rezende wrote:
> First, I would like to know somethings:
>
> * Why is netsurf not hosted on a source public code repo like github, gitlab (OpenSource) or Bitbucker?

Because back when we started, such services didn't offer the kind of access
control which we need in order to support third party frontend contributors.
Indeed most still don't unless you pay them money.

> * Does you guys want help on webassembly implementation and javascript?

Implementing the JS/DOM bindings, and supporting stuff like that would be very
welcome. It's a tough job because of keeping track of ownership/permissions
and in that we often have to improve our DOM implementation for each feature.

WebAssembly is probably a long long way off as yet.

> * Does Netsurf provide a api like CEF or WPE Webkit?

We do not, though it might be nice to produce a 'frontend' which is such.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Friday, 13 November 2020

I would like to help

First, I would like to know somethings:
  • Why is netsurf not hosted on a source public code repo like github, gitlab (OpenSource) or Bitbucker?
  • Does you guys want help on webassembly implementation and javascript?
  • Does Netsurf provide a api like CEF or WPE Webkit?

Tuesday, 10 November 2020

Re: [gccsdk] Cross-compiling header issues

On 10/11/2020 14:49, Dominic Hamon wrote:
>
>
> On October 30, 2020, Dominic Hamon <dma@hey.com> wrote:
>
>
>
> On October 29, 2020, Lee Noar <lee.noar@sky.com> wrote:

> It does sound like regex.h should be including sys/types.h. If
> you make
> this change locally in your environment, does the project build?
> If so,
> then I will commit it.
>
>
> Would you like me to prepare a patch?

Sorry, I may have slightly forgot there, but sorted now :-) Thanks for
that.

> There are some other oddities I'm finding in the crosslib headers
> around things like definitions of strtoul not being in the std
> namespace, but i wonder if that's related to it not fully supporting
> C++11?

I've thought for a while that our headers have probably aged a bit
compared to what you might find with a more up to date compiler.
Having said that, they are really meant to compliment our GCC4.7.4 and
so probably match its capabilities better. The port of GCC 10 uses the
same headers because it was the easy option, but whether it would
benefit from a header update, I don't know.

Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Cross-compiling header issues



On October 30, 2020, Dominic Hamon <dma@hey.com> wrote:


On October 29, 2020, Lee Noar <lee.noar@sky.com> wrote:
On 26/10/2020 13:13, Dominic Hamon wrote:
> Hello
> 
> I'm embarking on my first attempt to cross-compile something for riscos. 
> I have the environment all set up and figured out how to make the 
> project, but i'm not sure what the appropriate fix is for an issue:
> 
> The project in question (https://github.com/google/benchmark) runs a 
> check at build time to see which regex engine is available (std::regix, 
> posix regex, or gnu posix regex). It does this by compiling some test 
> programs and seeing which succeeds. The issue is that none do for riscos 
> (yet).
> 
> The closest I get is with the posix regex version, which includes 
> `regex.h`. This fails with the error:
> 
> $ $CXX posix_regex.cpp
> In file included from posix_regex.cpp:1:0:
> /home/dominic/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/include/regex.h:56:2: 
> error: 'size_t' does not name a type
> 
> I believe I could fix this by including <sys/types.h> in the crosslib's 
> regex.h (linux does this 
> https://code.woboq.org/linux/include/regex.h.html#23) but is this 
> appropriate? It seems like the right fix to me as regex.h shouldn't be 
> using types that haven't been declared.
> 
> Would this change be acceptable?

It does sound like regex.h should be including sys/types.h. If you make
this change locally in your environment, does the project build? If so,
then I will commit it.

Would you like me to prepare a patch?


It does, yes.

There are some other oddities I'm finding in the crosslib headers around things like definitions of strtoul not being in the std namespace, but i wonder if that's related to it not fully supporting C++11?

Thanks,
Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Monday, 9 November 2020

[gccsdk] paths.h

Hi

The attached patch adds the paths.h header. This header is common on Unix systems, and contains defines for common system paths. While the contents don't appear to be standardised, the patch adds a reduced set of defines from other platforms that are relevant to UnixLib.

Sources:
https://docs.oracle.com/cd/E36784_01/html/E36873/paths.h-3head.html

Regards
Cameron

[gccsdk] Patch to add missing 64-bit atomic functions

Hi

Attached is a patch to provide a number of missing 64-bit atomic functions. These are needed for the c89atomic library (https://github.com/mackron/c89atomic), and have been tested with the test program provided with it.

Note that due to a bug in c89atomic, the code path for GCC 4.6 and earlier is being used with GCC 4.7, which fails due to the lack of __sync_lock_test_and_set_1, which appears to be more complicated to fix. This is worked around in https://github.com/mackron/c89atomic/pull/1 , however it is something to look out for in the future.

Regards
Cameron