edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [edbrowse-dev] quick js
@ 2021-03-07 13:26 Karl Dahlke
  2021-03-07 16:15 ` Chris Brannon
  0 siblings, 1 reply; 15+ messages in thread
From: Karl Dahlke @ 2021-03-07 13:26 UTC (permalink / raw)
  To: edbrowse-dev

[-- Attachment #1: Type: text/plain, Size: 4362 bytes --]

Almost a year ago we realized,with much disappointment, that duktape was far behind, and showed no sign of catching up.
Meantime more and more sites were using features that duktape couldn't even parse.
As Adam said 7 years ago: if edbrowse isn't a fully functional browser with js support, it will eventually die.
So what to do?

We looked briefly at v8, but there is no documentation on how to use it, and it's c++, and very complicated.
It's not that the documentation is bad, it doesn't exist!
So I turned again to spider monkey, which we were using many years ago, until duktape came along.
Spider will always be up to date, as it is part of Firefox, so that's good.
I made a new effort to use it, and got further along than we did in 2013, but I still can't figure out frames and cross compartment access, which most sites employ.
Here is a slightly helpful article.
https://andreasgal.com/2010/10/13/compartments/
But that's not helpful enough.
After several months I had to give up.
Only a Mozilla insider could make this work!
Then along comes quick js, which is up to date, for now, though it isn't part of a commercial browser, so might fall behind, just like duktape, and yes that makes me nervous.
But it's there, and it's current, and it's almost as easy to use as duktape.
Not quite because of some tedious free malloc issues, which I won't get into here, but it's close.
And it's C, so no c++ libraries and interconnections with the rest of edbrowse.
The api is so intuitive you don't even need documentation; just read the prototypes in the header files, and play, and experiment.
What a refreshing change!
So ... make edbrowseqk will build the quick js version, assuming you have already cloned and built and installed quick js.
git clone https://github.com/bellard/quickjs

That's good, maybe we can go back to whatever we were working on a year ago, after our long detoure.
But there are questions.

* I'd like to make quick part of the official edbrowse, as of version 3.8.0.
I know that's a big leap, but duktape doesn't work (on most sites), spider doesn't work (on most sites),
so it's hard to see why we shouldn't make the leap as soon as possible.
Once edbrowseqk doesn't core dump, and yes I still have a few of those, but once we're past that,
seems like quick will do better than any alternative that we have right now.
Thoughts?

* Then there is the makefile, and not sure why we have two, or if we need two.
Can't the makefile work for everybody, and forget GNUmakefile?
In any case, if duktape is replaced with quick, the build procedure changes, and the documentation in README must be brought up to date.

* quick builds a static library, not a shared library - does this present issues for our distributors?

* Quick error handling is still open and not well understood.
Check for exception, clear exception, capture exception and put it into the debug stream.
Right now I call a standard dump routine that prints the error message to stdout, in not the best format,
and if you use db>file to capture the debug log, that message won't be there.
So that's an open item.

* Frames present every browser with a security risk, which we have never addressed.
duktape doesn't care, quick doesn't care, spider cares so much that I can't even figure out how to do it!
The problem is: a bad site, evil.com, could bring up an innocent looking home page, then call up paypal in a frame.
"Use paypal to pay for your sox."
As you enter your password, or other juicy things, evil.com can see it, because it's a frame.
	frame[0].contentDocument.forms[0].password.value
Browsers have to prevent this, and we don't, and we never have.
There's some kind of cross origin criteria that I don't know, and haven't implemented.
A frame has to have the same domain as the page above, or subdomain, or I'm not sure.
Any help appreciated.

* Then there's a lot of find&fix to do before we cut a release.
Mostly making sure it doesn't core dump, but besides that, there are some missing classes and properties just cause quick is a bit different,
or perhaps we never got it right in the first place.
Remember we've spent almost a year not working on our dom at all.

As you see, this was too long for the chatroom.
But that's what this list is for.
Reply with any thoughts.

Karl Dahlke

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-07 13:26 [edbrowse-dev] quick js Karl Dahlke
@ 2021-03-07 16:15 ` Chris Brannon
  2021-03-07 16:44   ` Karl Dahlke
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Brannon @ 2021-03-07 16:15 UTC (permalink / raw)
  To: edbrowse-dev

Karl Dahlke <eklhad@comcast.net> writes:

> * I'd like to make quick part of the official edbrowse, as of version 3.8.0.
*SNIP*
> so it's hard to see why we shouldn't make the leap as soon as possible.

I don't see a reason not to ship it as soon as the core dumps and other
kinks are worked out, especially if it is going to be such a huge improvement.

> * Then there is the makefile, and not sure why we have two, or if we need two.
> Can't the makefile work for everybody, and forget GNUmakefile?

It should be possible to write a portable makefile.  I'll work on that,
since I do have experience with build systems.  On the topic of build
systems, would it be worth removing the cmake support?

> * quick builds a static library, not a shared library - does this
> present issues for our distributors?

Distros can package static libraries just as easy as dynamic libraries.
The advantage of a dynamic library for a distro maintainer is that if a
bug -- such as a security issue -- is found in a dependency, all of the
things that depend on it can be fixed by rebuilding the dynamic library.
With static linking, every package that links against the library needs
a rebuild.  There's a minor shitstorm on the Internet right now about
this, because some newer programming languages (namely Rust and Go) tend
to favor static linking or even make dynamic linking impossible.  My
advice is don't worry about it.

-- 
Chris Brannon
Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/).
Personal website: (https://the-brannons.com/)
Chat: IRC: teiresias on freenode, XMPP: chris@chat.number89.net


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [edbrowse-dev] quick js
  2021-03-07 16:15 ` Chris Brannon
@ 2021-03-07 16:44   ` Karl Dahlke
  2021-03-07 17:15     ` Chris Brannon
  0 siblings, 1 reply; 15+ messages in thread
From: Karl Dahlke @ 2021-03-07 16:44 UTC (permalink / raw)
  To: edbrowse-dev

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Chris: If you could help with a robust, portable makefile, that would be great.
Start with GNUmakefile as template,
and the same environment variables I guess, they seem to work for us.
Cept, we want edbrowse target to use quick, and still keep an edbrowseduk target to use duktape.
I guess we can keep edbrowsesm to build with spider monkey, though that one doesn't build at present, but that's my problem, not yours.
I'd let hello build the hello targets, I think that's ok.
Nobody but us is ever going to make any of these nonstandard targets.

As per cmake I don't know the answer to that one.
When the dust settles I'll ask Geoff - but I didn't want to bother him til we had a clear path.
I could have pestered him about building with spider monkey a few months ago; I'm glad I didn't.
Let's make sure we really know where we're headed first.

Also - how would this change your procedures for static builds.
Probably simplify them, since quickjs.a is already static.
And tidy builds a statid library too.

Karl Dahlke

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-07 16:44   ` Karl Dahlke
@ 2021-03-07 17:15     ` Chris Brannon
  2021-03-07 18:40       ` Geoff McLane
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Brannon @ 2021-03-07 17:15 UTC (permalink / raw)
  To: edbrowse-dev

> Also - how would this change your procedures for static builds.

It shouldn't change them.
When I'm redoing and consolidating the makefile, I'm going to add a
static target (or targets), to make my life easier and to make it easier for people
to build their own statics.
Right now I have this very brittle procedure for making statics, which
involves some minor patching to the cmake build files.  It broke on the
last release and I haven't fixed it.

-- 
Chris Brannon
Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/).
Personal website: (https://the-brannons.com/)
Chat: IRC: teiresias on freenode, XMPP: chris@chat.number89.net


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-07 17:15     ` Chris Brannon
@ 2021-03-07 18:40       ` Geoff McLane
  2021-03-07 19:27         ` Karl Dahlke
  0 siblings, 1 reply; 15+ messages in thread
From: Geoff McLane @ 2021-03-07 18:40 UTC (permalink / raw)
  To: Chris Brannon, edbrowse-dev, Karl Dahlke

Hi Karl, Chris, et al,

Wow, you touch on so many things, hard to know what to answer...

cmake vs makefile:

Any 'makefile' is basically unix/linux, *nix, only... There is really no 
such thing as a portable makefile, at least as far as Windows is 
concerned. Yes, MSVC Windows has `nmake`, but it deviates from most *nix 
makes, often very significantly...

cmake, on the other hand, is a `makefile` generator, and includes a 
'configure' stage, before the 'generator' kicks in, so is suitable for 
windows, and *nix, mostly... and is the closest we have to 'portable'...

I recently built edbrowse in windows, and pushed a 'win32' branch, with 
most of the required changes, but with Karl's faster than light changes, 
became outdated even before it landed... but no problem... keep up the 
energy Karl... ;=))

static vs shared: Yes, this is a storm!

*nix has a very good system in places to deal with 'shared' - just a few 
'fixed' directories - and their many arguments in favor of this are very 
sound...

Windows is a big problem case - no 'fixed' directories - or rather the 
ones there are like C:\Windows, etc... are really only for true 'system' 
software... certainly NOT recommended for other, 3rdParty, software...

Yes, others can be added to the PATH, by an 'installer', which has to 
have 'admin' privileges, and must include all/most shared DLLs, but then 
you get a horrendous PATH variable. Already, in my relatively new DELL03 
machine it is over 1300 bytes long, some 36 paths... and continues to 
grow... on just about every 3rdparty install...

AND can lead to conflicts, breaks, as happened recently with a 
'Strawberry' perl install... It put some things in the PATH which broke 
several other 3rdPary builds... and was hard to find, debug...

And yes, I had this big fight with other *nix distro maintainer, about 
what I do with 'Tidy'... and compromised on adding cmake options to 
allow them to build/install tidy 'their' way ;=)) while still keeping my 
convenient Windows way...

Windows support:

Windows will always be a problem, especially edbrowse dependence on 
3rdParty libs... it requires considerable understanding and effort... to 
setup...

So, simply, some of this discussion would just go away, if you drop 
Windows support, and thus drop cmake!

This might not be a problem, since at this time, I do not think there is 
any other edbrowse users in Windows... they would be yelling otherwise - 
can't build edbrowse, for lots of reasons...

Good luck, with what ever you decide... will continue to help where I can...

HTH!

Best regards,
Geoff.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* [edbrowse-dev] quick js
  2021-03-07 18:40       ` Geoff McLane
@ 2021-03-07 19:27         ` Karl Dahlke
  2021-03-07 19:37           ` Chris Brannon
  0 siblings, 1 reply; 15+ messages in thread
From: Karl Dahlke @ 2021-03-07 19:27 UTC (permalink / raw)
  To: edbrowse-dev

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

Geoff: thank you for your kind and thoughtful reply.
You have been such a big help to us over the years.
I'm glad you still monitor this list.

I've come to realize over the years that a makefile, even if it's linux only, is valuable to us, because of the many other targets we build,
targets that will never be used by the casual user or the distributor.
So it's ok if these targets only build on linux.
Example: all those hello world programs that let us play with the various javascript engines.
So nice to just type make hello
And other targets to build debugging modes into edbrowse.
So we may well keep cmake going, but I think we will always have our own makefile in addition to cmake, even if it first seems a bit redundent.

I didn't want to ask you to restructure anything - until we were sure of our direction.
I think we're coming to a concensus.
I'll let you know.

As per the big question of do we even support windows and/or cmake any more, I don't know.
We all put a lot of work into it; yet there seems to be not a single windows edbrowse user.
It's just more compatible with the nix systems and the way they function.
Tyler has explained it more eloquently than I could.

One of my thoughts was, it might be easier to get funding if we could claim it ran on every platform, including windows.
Organizations expect that.
But we've never gotten a dime of funding anyways, so idk.
Meantime it is a bit of overhead to keep the windows port up.
All thoughts are welcome.

Meantime, you could casually ask yourself, in the background, what would have to change if duktape were replaced with quick.
Is it hard to do, or is it a quick fix?     Ha ha ha!
(I couldn't resist that one.)

Karl Dahlke

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-07 19:27         ` Karl Dahlke
@ 2021-03-07 19:37           ` Chris Brannon
  2021-03-08  8:46             ` Karl Dahlke
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Brannon @ 2021-03-07 19:37 UTC (permalink / raw)
  To: edbrowse-dev

Karl Dahlke <eklhad@comcast.net> writes:

> As per the big question of do we even support windows and/or cmake any
> more, I don't know.

Nowadays there is the Windows Subsystem for Linux (WSL), which is
essentially a Linux compatibility layer for Windows.
I'd be surprised if the static binaries didn't just run out of the box
under WSL.  So it's possible that the point is moot now, and we can
assume a *nix environment.

-- 
Chris Brannon
Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/).
Personal website: (https://the-brannons.com/)
Chat: IRC: teiresias on freenode, XMPP: chris@chat.number89.net


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [edbrowse-dev] quick js
  2021-03-07 19:37           ` Chris Brannon
@ 2021-03-08  8:46             ` Karl Dahlke
  2021-03-08 19:31               ` Geoff McLane
  2021-03-09 10:23               ` Kevin Carhart
  0 siblings, 2 replies; 15+ messages in thread
From: Karl Dahlke @ 2021-03-08  8:46 UTC (permalink / raw)
  To: edbrowse-dev

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

I've never even touched windows, well almost never, so forgive me if I'm being silly.
Let's say there was, someday, a windows edbrowse user.
He surely would want to use edbrowse in his home directory, accessing his own files in documents, downloads, desktop, etc.
There's not much point in him bringing up a virtual os, which he then has to live in entirely, and running edbrowse, just to say he ran it.
Or is WSL some kind of emulator that can wrap around and run a single linux program still in the context of your windows world?

Just curious.

And no - we shouldn't do too much until we see a windows user somewhere on the horizon.

Karl Dahlke

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-08  8:46             ` Karl Dahlke
@ 2021-03-08 19:31               ` Geoff McLane
  2021-03-08 21:18                 ` Karl Dahlke
  2021-03-09 10:23               ` Kevin Carhart
  1 sibling, 1 reply; 15+ messages in thread
From: Geoff McLane @ 2021-03-08 19:31 UTC (permalink / raw)
  To: Karl Dahlke, edbrowse-dev, Chris Brannon

Hi Karl, Chris, et al,

makefiles:

I completely understand you have no need to get into learning yet 
another language - cmake ;=))!

But of course cmake has a way to build different things - default for 
the casual/release-only user, or the developer, who wants everything. 
This is done with conditional 'OPTIONS', like say 'OPTION(BUILD_HELLOW 
"Enable the build of the 'hello' app" OFF).

Tidy has several, like BUILD_TAB2SPACE, BUILD_SAMPLE_CODE, etc... which 
are OFF for the 'user'. I even have a perl script, cmakeopts.pl, to show 
me the options available in every new cmake project I get into... it 
gives me insight into what the project is about, and what are the 
possibilities...

And of course a debug build is achieved by the -DCMAKE_BUILD_TYPE=Debug 
option...

cmake is a build generator, not a builder. So while the *nix default is 
'UNIX Makefiles', it supports the likes of Ninja, Watcom, ... etc... 
then more in Windows - MSVC, +++, and the MAC...

So 'makefiles' is just one of the outputs... for a specific toolset... 
starting with 'make' itself...

But you should continue to do what you are comfortable with, 
absolutely... no question...

Windows support:

My guess is that Windows users - those that have chosen Windows as their 
OS of choice - do not, EVER use the command line... may not even know 
about it... and have found other GUI based tools for web browsing, and 
email... etc...

A long time back, in Windows XP era, I did try to help a friend, who is 
blind, set up/repair her system. She had a 'talker' app running, which 
meant she could navigate various GUI apps with the keyboard, where 
options, like say in the MS Express email app she used, to fetch emails, 
read emails, reply etc... are spoken commands... as she navigated the 
apps 'menu', or tabbed through a dialog...

A modern Windows system has such a talker service built in... as is 
voice-to-text s/w... I think likewise in the MAC...

So a command line apps, like 'edbrowser' would just NOT be on their list 
;=))

And Chris, just reading more about WSL, it looks like it is a Virtual 
Machine - you have to intall a linux ditribution, like Ubuntu 20.04... 
so yes, I would imagine you could run native unix command line apps...

But, like Karl suggests, why would I do that? Looks interesting to me as 
a developer, explorer, but to a 'user'... to what gain?

I used to have a dual boot machine - Ubuntu or Windows - that gets tedious!

Now I am lucky enough to have 2 (+++) separate machines... and have them 
both running each day... and choose which I find better for various 
tasks... this is email is being done in linux... I can even ssh into the 
*nix machine to/from Windows...

In the past have played with some *nix emulators, like 'cygwin', 
'msgsys/mingw', ... but these never turned out very well... although I 
still continue to build a `mingw-64` version of Tidy...

And of course there are quite a number of 'Virtual Machines' - Hyper-V, 
VirtualBox, andLinux, QEMU, VMware,... 15 or more... all of which I 
avoid... except for some interesting, distracting, fun...

In general, I am a Windows 'native' user, developer, that also dabbles 
in cross-porting to other OS'es, for FUN ;=))

duk-moz-quick:

Given that I see the sources in eb, it would be easy to build all 3 
version - eb-duk, eb-moz, eb-quick - given that, like for the current 
duktape, I can download the other source, and build them in Windows... 
or they have a Windows binary distribution... although much prefer SOURCE...

If the project does NOT yet support the cmake generator, that is the 
first thing to add, as I do for 'duktape'... using my 'gencmake'...

I have a make2cmake.pl/am2cmake.pl script, which does quite well to gen 
the necessary 'CMakeList.txt', from examining the makefiles... even a 
'log2make.pl' to read unix 'make' logs... and I have a gencmake.pl 
script, to just traverse the folders, and guess... These auto 
generations usually need some manual fixes, but sometimes surprisingly 
minor...

The problem often comes from any library dependencies they may have... I 
have to back up, get that source, build and install that first... I 
already have over 50++ such 3rdParty.x64 libs...

And most of the time, I will choose to build it as a static library, to 
save me the hassle of copying various DLLs all over the place...

Even if the source already has a 'CMakeLists.txt', if it was generated, 
maintained by a *nix based person, it will only produce a shared (DLL) 
library. You 'Quickjs' seems an exception... But with cmake it is 
usually just seconds to adjust that to also build a 'static' library... 
and vice versa...

So, to answer you Karl, yes, it can be quick fix ;=)) Or it can turn 
into a week(s) or more... depends on so many things...

Please point me to the source, to use, and I will give it/them a try... 
just out of interest... thanks...

onwards:

If I were you, I would forget cmake at this time, unless and until you 
have a Windows user (other than me!)...

In your readme's mark it as unused, not maintained, may fail... etc

Best regard,
Geoff.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* [edbrowse-dev] quick js
  2021-03-08 19:31               ` Geoff McLane
@ 2021-03-08 21:18                 ` Karl Dahlke
  0 siblings, 0 replies; 15+ messages in thread
From: Karl Dahlke @ 2021-03-08 21:18 UTC (permalink / raw)
  To: edbrowse-dev

> Please point me to the source, to use, and I will give it/them a try...

git clone https://github.com/bellard/quickjs

Karl Dahlke


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-08  8:46             ` Karl Dahlke
  2021-03-08 19:31               ` Geoff McLane
@ 2021-03-09 10:23               ` Kevin Carhart
  2021-03-09 14:37                 ` Geoff McLane
  1 sibling, 1 reply; 15+ messages in thread
From: Kevin Carhart @ 2021-03-09 10:23 UTC (permalink / raw)
  To: Karl Dahlke, edbrowse-dev

In 2019 through last year, I was stuck at a work PC and wanted to do little or no ssh'ing from the office.  Yet I had itchy fingers for an edbrowse.  I think I even got the mingw compiler together but then discovered WSL.  So, I'm not advocating for WSL particularly, but I found it intriguing that there was another option.  The workload to get it wasn't terrible.  It's true that WSL sets up its own filesystem and this could put people off the idea.  I believe the top level in linux world would be under several folders in windows like files\blah\blah\linuxroot\home\kevin.  You technically could get things back and forth if you were willing to read the boards to figure it out.  Non admins, people with no root or sudo, stuck at work, are a niche who might be interested in edbrowse for Windows.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-09 10:23               ` Kevin Carhart
@ 2021-03-09 14:37                 ` Geoff McLane
  2021-03-09 22:52                   ` Kevin Carhart
       [not found]                   ` <20210210053836.eklhad@comcast.net>
  0 siblings, 2 replies; 15+ messages in thread
From: Geoff McLane @ 2021-03-09 14:37 UTC (permalink / raw)
  To: Kevin Carhart, Karl Dahlke, edbrowse-dev, Chris Brannon

Hi Karl, Chris, Kevin, et al,

Thanks Karl for the source pointer... I had read that before, but was 
buried deep in my emails...

I cloned it into both Ubuntu and Windows...

Regrettably, it only offers a 'Makefile' build, which did build fine in 
Ubuntu... but really pollutes its own repo... sad, but not really a 
problem...

And it seems the only concession to Windows is through one of the 
emulators, mingw, so is difficult to build in native Windows, using 
MSVC, without first constructing a suitable CMakeLists.txt...

I took an initial run at it, but a few of my helper tools failed to 
generate anything meaningful... they have put the main library source in 
the /root/, mixed with files that have their own 'main', thus are EXEs, 
not LIBs, which makes guessing tricky, faulty...

And add the fact that, from the linux build, it seems several sources 
are generated during 'make', from built tools, like qjs$(EXE), 
qjsc$(EXE), ... which always causes a problem, for my auto generated 
scripts... but cmake can handle fine... after manual intervention...

Luckily, so far, it seems the only extra depend lib is pthreads, which I 
already have...

Sadly, after I got my first CMakeLists.txt build going, see the source 
includes 'unistd.h', showing that it has NEVER been built in native 
Windows, which does not have such a header, but there are some somewhat 
equivalent native windows headers... just needs a MACRO, like edbrowse 
src has...

And ran into Built-in Functions Provided by GCC, like builtin_clz, and 
others... which strangely had not seen before... read therefore do not 
have a known windows native solution...

Anyway, I took a few runs at it, but sadly, made NO significant 
progress... which is disheartening, to say the least... so had to give 
up for now...

Searching around, found https://github.com/mengmo/QuickJS-Windows-Build, 
but it uses MSYS2 emulator... which I do have... but what am I gaining 
with this?

Will try to poke at it now and then, and may try a 'mingw', or 'msys2' 
build, but certainly /NO/ quick solution ;=((

And yes, Kevin, I too am a little facinated by WSL... seemingly a MS 
free-be!?!?!? ... I have read into the install docs, and as you say, 
does not look TOO terrible ;=))... so may get around to trying that... 
for fun!

You know, I started this new, well circa Dec 2019, Dell03 Windows 10 
machine - A Dell XPS 8930 - with a total 1.5 TB of disk space - which I 
have already more than half filled! But have added a 2 TB usd hdd, that 
I can move things too... I am sure WSL is going to gobble up some more 
;=)) But WSL, being a Virtual Machine, will probably not like to install 
on a transient-like usb drive...

Yes, I would like to keep a windows build of edbrowse... its very 
existence may encourage those 'niche' users...

Best regards,
Geoff.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-09 14:37                 ` Geoff McLane
@ 2021-03-09 22:52                   ` Kevin Carhart
       [not found]                   ` <20210210053836.eklhad@comcast.net>
  1 sibling, 0 replies; 15+ messages in thread
From: Kevin Carhart @ 2021-03-09 22:52 UTC (permalink / raw)
  To: Geoff McLane, Karl Dahlke, edbrowse-dev, Chris Brannon

Hi Geoff!


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
       [not found]                   ` <20210210053836.eklhad@comcast.net>
@ 2021-03-14 20:36                     ` Geoff McLane
  2021-03-15  9:44                       ` Kevin Carhart
  0 siblings, 1 reply; 15+ messages in thread
From: Geoff McLane @ 2021-03-14 20:36 UTC (permalink / raw)
  To: Karl Dahlke, Edbrowse-dev, Kevin Carhart

20210314: Building the QuickJS library update

Just an update... persued 4 different tracks... some success, some 
failures... they are -

1. Using mingw-64 emulator - OK, but todo edbrowse with same mingw...
2. Using MSVC 2019 native .x64 - got close, but close is not good enough
3. Using the MS WSL emulator - wow, a million steps to do... so far only 
built tidy, edbrowse, ...
4. Using github.com/c-smile/quickjspp - the premake5.exe tool FAILED to 
build MSVC solution... hmmmm...

The detailed exploration is below... or jump to the 'Summary:'

1. Using mingw-64
###################

Encountered an error, I can NOT seem to get past... but sort of got 
there, eventually...

[  9%] Building C object CMakeFiles/quickjs.dir/quickjs.c.obj
D:\mingw-w64\mingw64\bin\gcc.exe -DCONFIG_BIGNUM 
-DCONFIG_VERSION=\"2020-11-08\" -D_GNU_SOURCE \
  -Wall -Wno-array-bounds -Wno-format-truncation -Wno-unused-variable 
-Wno-unused-but-set-variable \
-MMD -MF -O  -D_REENTRANT -O3 -DNDEBUG   -o 
CMakeFiles\quickjs.dir\quickjs.c.obj   -c D:\Projects\quickjs\quickjs.c

C:\Users\ubunt\AppData\Local\Temp\cchgmH6R.s: Assembler messages:
C:\Users\ubunt\AppData\Local\Temp\cchgmH6R.s:30898: Error: .seh_savexmm 
offset is negative
C:\Users\ubunt\AppData\Local\Temp\cchgmH6R.s:30899: Error: .seh_savexmm 
offset is negative

I am using mingw-64, with gcc version (x86_64-posix-seh-rev0, Built by 
MinGW-W64 project) 8.1.0

I searched long and hard, but can /NOT/ find an update to my 
installation of mingw-64 - from -
http://mingw-w64.org/doku.php/download
2020/05/13  19:30           960,504 mingw-w64-install.exe
Appears I have the 'latest'...

 From here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048 found -
(a) Which says: "not if -fno-reorder-blocks-and-partition" - to try
(b) Eric Botcazou 2018-06-13 11:26:27 UTC
This will be fixed in the 8.2 release.  Thanks for reporting the problem.

Ok, added '-fno-reorder-blocks-and-partition', and it compiled! WOW ;=)) 
success!!!

Now to figure out how to link edbrowse to this 'libquickjs.a'???

Probably need to build 'edbrowse' using the same emulator... TODO...


2. Using MSVC native
###################

A: Fixed the buildin crt with creating a "ctz_clz.h" header which adds 
these functions..
Add to cutils.h -
+#ifdef _MSC_VER
+#include "ctz_clz.h"
+#define __attribute__(x)
+#endif // _MSC_VER
+

B: Commented out <unistd.h>, in various places - like -

+#ifndef _MSC_VER
  #include <unistd.h>
+#endif /* #ifndef _MSC_VER */

C: Few other relatively minor fixes in the source... \

D: On __int128 being used. At the moment can not find a patch to cover 
this...

E: Swiched OFF CONFIG_BIGNUM support... eventually got 'quickjs.lib' to 
build

F: Big problem - the 'qjsc' compiler failed to convert 'repl.js' to 
'repl.c', and likewise with 'qjscalc.js' to C code... overcame this with 
copy the generated *.c files from the mingw-64 build... not a good solution!

So, I have a 'quickjs.lib'... need to sort out which headers to install 
- list looks like 'quickjs-atom.h, quickjs-libc.h, quickjs-opcode.h, 
quickjs.h'... so TODO: finish the INSTALL step... then TODO: build of 
eb-qjs...


3. More exploration into WSL - it's getting to be much more than expected!
###################

Per the install docs - 
https://docs.microsoft.com/en-us/windows/wsl/install-win10 -

Joined the Windows Insiders Program, as requested... hope I do not 
regret this... do not like words like -
you will receive emails, and the only way to stop this (spam), is to 
un-join the program... well, ok, but not nice...

Am running the min version - Microsoft Windows [Version 10.0.19041.804], 
so that's ok...
ran 2021/03/11  18:34        15,282,176 wsl_update_x64.msi
Did a Windows feature update, which took about 1/2 hour - must now reboot...

Had to jump through some other hoops, installed Ubuntu 20.04... and 
evenually got an 'Ubuntu' app, which opens as a terminal... and it 
certainly looks and feels like Ubuntu...

Then spent some time setting up this 'bash' terminal... add my own 
'.bash_aliases'... installed g++, cmake... even git cloned tidy, built, 
and installed it...

TODO: But still to figure out where all this is stored? So presently NO 
access to my native Windows filesystem... and when in Ubuntu, can't yet 
access outside of the unix root, '/'...

So at this time this is a MAJOR setback... yes I could re-download all 
the sources... TODO: but...

At this time this is no different to using a 2nd machine...

And really puts me no closer to building QuickJS in native Windows???

On WSL, in general, so far it feels like a very good linux emulator... 
single click access to terminal... much faster than a dual boot... just 
missing the native filesystem access... or at least access to my 
expansion drives - G: and H:

Hmmm, found /mnt/g, /mnt/h, and then /mnt/c and /mnt/d, so do have 
access to full filesystem... will try some more things...

Wow, I have to say that it is quite a 'complete' emulation... maybe more 
than an 'emulation'... it is running a linux kernel...
ubunt@DELL03:~/bin$ hvers
Show LSB version 'lsb_release -a'
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

Show version 'uname -a'
Linux DELL03 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 
UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
ubunt@DELL03:~/bin$

As indicated, really a 'Virtual Machine'... to download my 
edbrowse-fork, had to even copy a rca .pub to my github account...

And can now see my complete disk system, in terms that I know - A:, B:, 
C:, ... drives - namely -
$ df -H | grep -v /dev/loop
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb        270G  2.3G  254G   1% /
tmpfs            10G     0   10G   0% /mnt/wsl
tools           492G  180G  312G  37% /init
none             10G     0   10G   0% /dev
none             10G   17k   10G   1% /run
none             10G     0   10G   0% /run/lock
none             10G     0   10G   0% /run/shm
none             10G     0   10G   0% /run/user
tmpfs            10G     0   10G   0% /sys/fs/cgroup
C:\             492G  180G  312G  37% /mnt/c
D:\             1.1T  598G  403G  60% /mnt/d
G:\             2.1T  1.6T  430G  79% /mnt/g
H:\             2.1T  775G  1.3T  39% /mnt/h

There is quite a problem with line endings... git, in native windows, 
adds CR/LF pair to text/script files, which causes the '#! /bin/sh' 
shell to break, and need to do 'dos2unix <script>' to make it right...

Ran into a problem building in '/mnt/h/UTILS/eb-fork/temp' - can NOT 
find CURL, but curl IS installed... I think... DONE: Solved the build 
prob...

To start, cloned my eb-fork into this filesystem... at 
~/projects/eb-fork... and commenced a build - needed to install pcre - 
pcre-dev, libreadline-dev, duktape-dev, ... and it built fine... ran a 
../src/jsrt test... looks ok... http://yahoo.com loaded, seemingly 
fine... got links...

Then back to the native clone... ran my build-me.sh, and now it builds 
fine here too - log -
-- +++ Search using paths /home/ubunt
-- *** Tidy found inc /usr/include lib /usr/lib/libtidy.so
-- *** CURL found inc /usr/include/x86_64-linux-gnu lib 
/usr/lib/x86_64-linux-gnu/libcurl.so
-- cURL version 7.68.0
-- *** PCRE found inc /usr/include lib /usr/lib/x86_64-linux-gnu/libpcre.so
-- *** READLINE found inc /usr/include lib 
/usr/lib/x86_64-linux-gnu/libreadline.so
-- *** Duktape found inc /usr/include lib 
/usr/lib/x86_64-linux-gnu/libduktape.so
-- *** Building static library STATIC
-- Language ebrc files: 
LANG_EBRC_FILES=/mnt/h/UTILS/eb-fork/lang/ebrc-de;/mnt/h/UTILS/eb-fork/lang/ebrc-en;/mnt/h/UTIL>-- 
Doc guide files: 
DOC_GUIDE_FILES=/mnt/h/UTILS/eb-fork/doc/usersguide.html;/mnt/h/UTILS/eb-fork/doc/usersguide_fr.htm>-- 
Language msg files: 
LANG_MSG_FILES=/mnt/h/UTILS/eb-fork/lang/msg-de;/mnt/h/UTILS/eb-fork/lang/msg-en;/mnt/h/UTILS/eb>-- 
*** Setup build of ebrc.c, msg-strings.c, and startwindow.c
-- Configuring done
-- Generating done
-- Build files have been written to: /mnt/h/UTILS/eb-fork/temp
[100%] Built target edbrowse

Moved onto QuickJS - re-cloned it into ~/projects/quickjs - ran '$ 
make'... and it completed ok... did 'make install', and it put the 
compiled exes in /usr/local/bin, and the headers into /usr/local/include...

Back to edbrowse build, and can not find a target in the 'makefile'...

TODO: How to build eb-qjs, using the above 'quickjs' lib, in 
'/usr/local/lib'???0

4. Found c-smile:fork, using 'premake5' for MSVC 2019
###################

Cloned this repo - https://github.com/c-smile/quickjspp

And downloaded - https://premake.github.io/download.html - to get 
'premake5.exe'...

In a 'build' dir, did - premake5 "--file=..\premake5.lua" vs2019
Built MSVC sln in a '.build\vs2019\quickjs.sln, but it FAILED to load??? 
Could not find my MSVC 2019 installation...
Maybe if I run 'premake5 vs2019' in a MSVC command prompt... no still 
FAILED!
But from the gen'ed quikcjs.vcxproj noted some potential MACROS to add -
<PreprocessorDefinitions>JS_STRICT_NAN_BOXING;CONFIG_BIGNUM;_HAS_EXCEPTIONS=0
which may help, in my getting close MSVC build, and verifies a lot of 
things...

I am getting closer with my CMakeLists/MSVC build... so TODO: persue a 
build in this repo... especially interested in how the BIGNUM/__int128 
problem is dealt with... it it is...

Summary:
########

You can see quite a few TODO: markers, and will continue to work on 
these, as time permits...

TODO:mingw: build edbrowse in mingw-64 emulator...
TODO:msvc: set up a link for eb-qjs.exe build...
TODO:WSL: access or download 'edbrowse' source, and build... but does 
this help? Yes and NO! time sink...
TDOO:WSL: build eb-qjs version... need to mod CMakeLists.txt... shift 
most of the source to an eb.lib, then build various versions, with minor 
src changes - no repeated srcs...
TOTO:c-smile: take this a few steps further forward... a big maybe...


If interested, at this time, could push a win-bld branch, in my fork... 
if you have time to catch up to a few purely Windows things... not 
urgent... it may be a few commits behind master...

Any feedback appreciated... lots of FUN, and time, exploring...

Best regards, Geoff.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [edbrowse-dev] quick js
  2021-03-14 20:36                     ` Geoff McLane
@ 2021-03-15  9:44                       ` Kevin Carhart
  0 siblings, 0 replies; 15+ messages in thread
From: Kevin Carhart @ 2021-03-15  9:44 UTC (permalink / raw)
  To: Edbrowse-dev

Thank you for writing this Tales from the Compilation Trenches narrative.  Yes, that syntax /mnt/c is the linkage that I found to and from WSL-world.

In case this helps with which quickjs includes to use,and you haven't worked it out in the meantime,  we made a basic proof of concept program in February and I put my gcc one-liner in a comment.  

gcc js_hello_quick.c -o js_hello_quick quickjs.c libregexp.c libunicode.c cutils.c -lm -ldl -lpthread

https://github.com/CMB/edbrowse/commit/d7cd398f6ba6b4cb813745e560176079594e55b8#diff-25a6634263c1b1f6fc4697a04e2b9904ea4b042a89af59dc93ec1f5d44848a26



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-03-15  9:45 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-07 13:26 [edbrowse-dev] quick js Karl Dahlke
2021-03-07 16:15 ` Chris Brannon
2021-03-07 16:44   ` Karl Dahlke
2021-03-07 17:15     ` Chris Brannon
2021-03-07 18:40       ` Geoff McLane
2021-03-07 19:27         ` Karl Dahlke
2021-03-07 19:37           ` Chris Brannon
2021-03-08  8:46             ` Karl Dahlke
2021-03-08 19:31               ` Geoff McLane
2021-03-08 21:18                 ` Karl Dahlke
2021-03-09 10:23               ` Kevin Carhart
2021-03-09 14:37                 ` Geoff McLane
2021-03-09 22:52                   ` Kevin Carhart
     [not found]                   ` <20210210053836.eklhad@comcast.net>
2021-03-14 20:36                     ` Geoff McLane
2021-03-15  9:44                       ` Kevin Carhart

edbrowse-dev - development list for edbrowse

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/edbrowse-dev

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 edbrowse-dev edbrowse-dev/ https://inbox.vuxu.org/edbrowse-dev \
		edbrowse-dev@edbrowse.org
	public-inbox-index edbrowse-dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.edbrowse.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git