Lc 9.0 Rc1 things noticed...

[bogs]

Downloaded and installed first 9rc1 32, then 64 bit. Same issues regardless.
System is a Mint box, LMDE2, Debian 8.

On setting a breakpoint , twice the IDE froze for more than 3 minutes.

• After restarting twice, I was able to set the breakpoint. On stepping through the code, I clicked on a variable to check its contents. Two different windows showed up, both empty. On trying to close the variable windows, the IDE disappeared (I assume crashed).
• On restart, attempted same, tried to check variable, no window showed up in +/- 4 mins.

  

• IDE appears frozen at this point as well, no response going from browse to pointer mode, no response from <ctrl + .>
  At more than 10 minutes, variable window started to show a frame only.

Attached stack.

htmlTester.zip

(868 Bytes) Downloaded 230 times

Other things noticed -

• Selecting an object and hitting enter did not bring up properties pane, expected behavior since um...2.x I think?
• Properties pane if closed or on change of controls does not retain its shape (i.e., widen the pane, change controls, both location and shape change back to the default instead of remaining as set).
• Dictionary opens in a web browser (?) which is not necessarily a bug, but seems odd.
• Alternately, when trying to edit a script the code editor would not open either from the button on the menubar, or right clicking on the object, or on clicking the blue box in the project browser, seemingly random failure or, IDE may have been frozen (no indication which).

[bogs]

Also attempted running the 32bit version of this on my Lenovo laptop, Sparky Linux(Debian testing branch).

On this machine, selecting a control and pressing [enter] *did* bring up the properties window, but I was unable to resize the properties window but once, the next 3 attempts it acted as if it was not resizeable (cursor changed to resize, but window did not change other than width). IDE did not seem frozen or stuck, was able to change properties within the window.

Same stack as above, same 3 lines of code. Was able to open one webpage and put the text in the field. On trying to open the second, the IDE seemed to freeze (unresponsive over 3 minutes).

I know that putting the html text in a field in this manner is blocking, as opposed to using the load command, but would find it hard to believe that livecode.com would take over 3 minutes to load on what is a relatively quick connection. In fact, in testing it in a browser on this laptop, it took about 5 seconds to fully download and load. In 6.5.2 it took less than 3 seconds to display the htmlText in the field.

[richmond62]

Someone "leaked" that, at the LiveCode offices in Edinburgh they have 1 machine running Linux for testing . . . as far as I recall it was running an outdated version of Ubuntu . . .

. . . crashes "and all" all over the "Linux Sphere" don't take me by surprise at all.

[bogs]

Heh, while I can't speak to the likely-hood that is true, that would be funny. At one of my previous jobs they had just that, one weak, under powered, older machine running Ubuntu 7.10 that was past its prime by some years to serve the entire company. Naturally it was blown out of the water on days we had full staff. Thanks for the humorous memory

[bwmilby]

On my 64-bit Ubuntu 16.04.3 VM, I was able to get the LiveCode site, another site, then back to LiveCode. The window did get dark for a little while. I would suggest adding some timing code to check how long it really takes for comparison. Using "the ticks", I got 3498 with a length of 1545436. My site (https://milby.us) only took 62 with a length of 27923.

I will say that the UI on this VM is very sluggish. I attribute that to it being a VM though. Anything that isn't tied to display seems to operate quickly. I'm using VirtualBox - so if anyone has hints on making it work better, I'd be willing to make adjustments. My primary LiveCode seat is a 5K iMac (late 2014). I also have access to a Win10 laptop which has LiveCode installed. The Linux VM is my latest install and will only be for testing. I may look into a thumb drive or possibly a USB3 external so I can dual boot a laptop.

EDIT:
Just enabled 3D acceleration which makes a world of difference in the VM. Also raised it to use 2 cores of the processor and maxed out the video RAM.

I updated the stack to capture clock start/stop times as well. For LiveCode it took 59 seconds, 3563 ticks. I tried several other sites and times were usually 1-3 seconds, but the length was also much less too.

Oh, and I ran the same test directly on my host... 66sec, 3973 ticks. My site 1sec, 51 ticks. So I'm not sure this is a Linux issue.

EDIT: Newer stack uploaded.

[LiveCode_Panos]

Someone "leaked" that, at the LiveCode offices in Edinburgh they have 1 machine running Linux for testing . . . as far as I recall it was running an outdated version of Ubuntu . . .

Your source is not well informed

We have 2 machines running native Linux (Ubuntu 16.04 64 bit and Fedora 64 bit), and several Linux VMs, running Ubuntu 16.04, Ubuntu 17.04, Xubuntu and Mint.

Best,
Panos
--

[FourthWorld]

Thanks, Panos. For the others here, what Panos said is easily confirmed by reading the bug reports you submit. That is, if you submit them. You'll see they refer to many different versions of Linux as they work to confirm, diagnose, and resolve reported issues.

[bogs]

@ bwmilby - if we're specifically talking about the livecode.com part of what I wrote up there, that did fail on two separate machines, one with a stable Os, and one of them a newer laptop with a cleanly installed (albeit testing) OS. I did download your modified stack, and will attempt to test it *provided* 9.0 decides to stay running heh.

I find that part of it the least of the problems, though. The IDE freezing for so long that I had to force kill it when I set a break point in the code editor was a bit more disheartening.

On setting a breakpoint , twice the IDE froze for more than 3 minutes.

I know the machine wasn't frozen, other wise I could not have killed the IDE. Well, I could have actually, but would have had to switch terminals, etc. You understand

I also found the properties window behavior bizarre. I'm just not sure they are *bugs*, or if it is some requirement my machines are not fulfilling.

@Panos - thanks for chiming in. Care to give up the target specs of what your expecting for hardware when someone is running this version of the IDE? Not rose colored glasses specs like 128k ram and 2d video heh, but something your running it reasonably well on? Vm hardware specs are fine too if your feeling generous.

@ Richard - I'll be happy to submit this as... I guess several bugs. Like I said in the other thread, as well as here, I'm just trying to figure out if they *are* bugs, or the result of my machine(s) setup(s). I did finally get around to creating a quality sign in, I just don't often think I have a reason to use it.

[bogs]

I tested with bwmilby's modified stack, without setting breakpoints in the debugger and it was able to complete, as he noted livecodes page was significantly slower than other page loads at 2 mins +/-, but during the 3 test runs I made without any break point, at no time did the IDE freeze or even act like it did.

So I set the break point in the code editor and started stepping through it. At the point where the variable 'tmpPage' was filled, I clicked on the variable to see the contents. No dice, IDE was frozen. Being conscious that https://livecode.com takes at least 3 minutes to show up when just running it, I waited for 10 minutes to pass.

The IDE did not unfreeze in all that time, so at that point I considered it hung and force closed it. I dunno, bug, or is it 'ID 10 T' error?

*Edit - I restarted the IDE, plugged in google address, put the break point, stepped through the code, and this time I actually did get to see the variable after it was full without crashing the IDE, but got a different unpleasant surprise

No such object? Really?? <sigh>

[richmond62]

Your source is not well informed

I am very happy to hear that

I shall "pay" for my mistake by downloading 9 RC1
onto MX Linux and seeing if it plays "nicely", and report back.

[bogs]

Submitted as bug report 21087 for the erratic behavior in the IDE after setting a breakpoint in the code editor.

Bug report 21088 submitted for the properties window issues, since that goes back to at least 8.1.6.

[jacque]

No such object? Really??

I've seen this periodically lately but haven't found a reliable recipe. My best guess is that at some point the debugger changes the default stack and of course the requested object isn't there. Handlers run normally outside the debugger. Hopefully your report will allow the team to pin it down, so thanks for submitting it.

[bogs]

Hopefully your report will allow the team to pin it down, so thanks for submitting it.

It is all Richard's fault for getting me to even look at it, so all credit (and blame) will be forwarded in his general direction

All kidding aside though, I am glad to hear I wasn't the only one to see this type of stuff. I started back-tracking through the releases and found apparently the same things in 8.1.6, but not in 7.1.4, so I guess I will be doing some installs to find out where this stuff started creeping in. Pretty sure I did not see it in 8.1.2, but I also spent less time than usual in that one due to how slowly it responded on this system.

[FourthWorld]

Submitted as bug report 21087 for the erratic behavior in the IDE after setting a breakpoint in the code editor.

Bug report 21088 submitted for the properties window issues, since that goes back to at least 8.1.6.

Thanks for submitting those, Bogs.

I was unable to reproduce most of what's there, found an outlier in text formatting for one of them that may be beyond LC's control to remedy (it's also a problem in other programs), and one part of one report appears to be a duplicate of an existing report in progress. I've added notes to each report with what I've found.

[bogs]

The format thing you mentioned is interesting, as I could not reproduce it in other programs. Maybe I should ask you how you opened it in Geany? heh.

As for the pi issue, initially when I read Mark's report I didn't think it was the same, but on having re-read it it may well be the same thing. Like Mark, I don't see this behavior in any Lc from 7.x earlier.