Post by: Fifi on November 23, 2018, 11:59:43 pm
While testing the last revision of my multi lingual installation script on different Linux distributions, I discovered that the last InForm beta 8 doesn't run on Debian 8 and 9.
A first error message is displayed saying "InForm designer is not running. Please start the main program", then a second message is displayed saying "UiEditorPreview component not found or failed to load".
I tried to recompile it but unfortunately I got the same result even after a reboot.
However, QB64 and vWATCH run fine on Debian 9.
Below is a screen shot of the error:
http://www.as2.com/qb64/pictures/jpg/inform-debian9.jpg (http://www.as2.com/qb64/pictures/jpg/inform-debian9.jpg)
BTW, I just reinstalled a Debian 8 to check if I got the same behavior but unfortunately there was the same problem as you can see with the screenshot below:
http://www.as2.com/qb64/pictures/jpg/inform-debian8.jpg (http://www.as2.com/qb64/pictures/jpg/inform-debian8.jpg)
However, after my different tests, both QB64 v1,2, InForm beta8 and vWATCH 1,05 run fine on CentOS7, Mint 18 & 19, Ubuntu 18 and all its derivatives (Kubuntu, Lubuntu, etc.)
Hope this helps.
Cheers.
Fifi
Post by: Fifi on November 24, 2018, 10:05:00 am
Other bad news.
Following my tests of my last install script (that is running fine on Manjaro), bellow are the first problem I get with InForm on Manjaro 17,1,12 (Hakoila with kernel 4,14,67-1) and Manjaro 18,0,0 (Ilyrlia with the kernel 4,14,8-1).
InForm runs fine, creates the form, but when you save the project, doesn't start QB64. However, I can compile the form directly when loading in QB64 and it works.
The second problem is with vWACH on Manjaro 17,1,12 (Hakoila with kernel 4,14,67-1) and Manjaro 18,0,0 (Ilyrlia with the kernel 4,14,8-1) that creates the xyz.vwatch.bas, compiles it, allows to select the variables, but when you run the executable with F8, it's OK as long as you hit this function key with the focus on the vWATCH window, but if you hit that same F8 function key with the focus on the executable, both the executable and the vWATCH windows freeze.
Hope this helps.
Cheers.
Fifi
Post by: FellippeHeitor on November 25, 2018, 04:23:05 pm
Starting with Beta 8, InForm uses TCP/IP locally to have the editor and the preview windows communicate with each other.
Can you confirm it's not being blocked by your distros?
Post by: Fifi on November 25, 2018, 11:25:48 pm
Thanks for reporting, Fifi.
You're welcome but that's the minium I can do (testing & reporting).
Starting with Beta 8, InForm uses TCP/IP locally to have the editor and the preview windows communicate with each other.
Can you confirm it's not being bloked by your distros?
As you know, TCP/IP is the "basic" & default comunication protocol on Linux, including of course Debian. So, how could I guess if InForm is blocked since this protocol works fine calling both internal and external web sites (e.g. using my own QB64, InForm & vWATCH installation script that downloads QB64, InForm and vWATCH from qb64.org)?
Bellow is the picture of my TCP/IP settings on Debian 8.
http://www.as2.com/qb64/pictures/jpg/debian8-tcpip.jpg
Hope this hepls.
Cheers.
Fifi
Post by: FellippeHeitor on November 26, 2018, 04:23:41 am
Post by: Fifi on November 26, 2018, 01:47:35 pm
This will likely be in your firewall settings, as there may be a blacklist of sorts, but I don’t have instructions where to find it.
By default, on Debian 8 (jessie) and Debian 9 (stretch) the firewall is completely open (no filter) for these 2 distros and doesn't block anything (as well as on Ubuntu).
Then, as you can see bellow, the next command line gives the following same result on these 2 distro releases:
Code: QB64: [Select]
- ~$ sudo iptables -L
- target prot opt source destination
- target prot opt source destination
- target prot opt source destnation
- ~$
If I may, let me suggest that you install Debian 8 (or 9) in a VM (whatever VirtualBox or better VMware Fusion for MacOS) to check what's wrong.
Please let me know if I can do something else to help you further (e.g. I can send you a pre-installed debian-8.vmdk disk file that works with the 2 VM tools).
Cheers.
Fifi
Post by: Fifi on November 29, 2018, 07:52:22 pm
I just installed the last release of Debian (9.6) and the problem with Inform still is there.
However, I also installed Q4OS (2.4) that is a fork of Debian 9.6 and InForm runs like a charm on this distro!
So, I can't understand where the problem is with Debian (8 and 9) since, as said earlier, there is no lock on the firewall.
So, what kind of TCP/IP communication protocol (and what port) are you using?
PS: I've a pre-installed Debian 9.6 virtual disk available for you that you can use both with VMware Fusion and VirtualBox. So, just tell me if you want to download it and I'll put in on my server.
Post by: FellippeHeitor on November 29, 2018, 07:57:42 pm
I have downloaded Debian 9.6 but haven't installed it yet, so I'm still to be able to observe what's going on more closely.
InForm Designer communicates with qb64.org via standard HTTP on port 80 to check for updates if the user didn't disable that feature.
InForm Designer communicates locally with the Preview Component using its own protocol by opening port 60680.
Post by: Fifi on November 29, 2018, 08:12:13 pm
I didn't know you could disable the update process.
So, I didn't modify anything on InForm.
The amazing thing is that InForm runs like a charm on many distros, including Q4OS 2.4 (a fork of Debian 9.6) but not on a native Debian.
I'll check later with an older Debian version (7) to see if the problem allready was there and I'll keep you posted.
Cheers.
Fifi
Post by: FellippeHeitor on November 29, 2018, 08:17:23 pm
I didn't know you could disable the update process.
Check the Options menu.
Post by: FellippeHeitor on November 30, 2018, 09:50:56 pm
Turns out the connection handshake is timing out for some reason. I tried increasing timeout values but what eventually worked was keeping both modules in a loop *until* a connection was established, which is far from desirable.
This happened in a virtual machine and something could be hogging the system regarding local TCP/IP connections. I don't recall if you are running in a VM or bare metal, that could have something to do with it.
Either way, if you're willing to give this hacky solution a try, grab both files I'm attaching here, delete UiEditor and UiEditorPreview binaries and replace them with the recompiled versions from the sources I'm providing.
Since this seems like an isolated issue and not a real bug, until I can actually pinpoint the failure with pure Debian systems I'm not changing InForm Beta 8. If it turns out to be InForm's fault I will release an online update as well as update the packages, but till then I will have to investigate further.
UiEditor.bas and UiEditorPreview.bas must be in the InForm folder in your QB64 folder. The binaries must be placed as follows: (i) UiEditor in QB64's folder and (ii) UiEditorPreview in the InForm subfolder.
Post by: Fifi on December 01, 2018, 11:37:23 am
Yes, I'm running all my Linux distros in VMs (VMware Fusion under OS/X 10.9.5).
And yes, your changes fixed the behavior with both Debian 8 and Debian 9.
Thanx for your corrections.
Cheers.
Fifi
Post by: FellippeHeitor on December 01, 2018, 04:21:32 pm
Yes, I'm running all my Linux distros in VMs (VMware Fusion under OS/X 10.9.5).
That said, I wonder if anyone would have Debian 8 or 9 running bare metal to test all this against. Especially considering even other distros *based* on Debian 8/9 deal fine with the timeout delays InForm uses.
Post by: Fifi on December 01, 2018, 05:22:24 pm
Yes, I'm running all my Linux distros in VMs (VMware Fusion under OS/X 10.9.5).
That said, I wonder if anyone would have Debian 8 or 9 running bare metal to test all this against. Especially considering even other distros *based* on Debian 8/9 deal fine with the timeout delays InForm uses.
I'll try the two versions on a bare metal system this week end and I'll keep you posted.
Cheers.
Fifi
Post by: Casteele on February 02, 2019, 04:43:35 am
I can confirm this problem exists on my Debian Stretch machine, running "bare metal" and NOT in a virtual machine. Likewise, the patched files attached above do seem to fix the problem for me, as well. Here's my uname -a output: "Linux caslt1-deb64b 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux". My machine's TCP/IP stack/firewall/iptables/etc is completely open to my LAN/intranet, so there should be no problems with any kind of communications.
Also, have you considered perhaps there's a bug in the QB64 code for the TCP/IP communications causing the timeout? (Or even in any of the libraries QB64 links against in Debian?)
Post by: Fifi on February 02, 2019, 05:29:48 pm
Sorry for being so long to come back (I had a domestic accident but all is OK now).
So, yes I also tried on 2 different bare metal systems (a PC and my iMac 27 both natively running both Debian 8 and 9) and the problem still was there.
However, your patches fixed it.
So, unless you find another solution as suggested by Casteele, may I nicely recommand that you include your patches in your next release.
Cheers.
Fifi