Lc 9.0 Rc1 things noticed...

[FourthWorld]

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?

I first went to LiveCode.com in my browser to see if their WordPress install was part of the delay. Then I viewed source, copied, and pasted into Geany.

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.

Different PI. It had to be completely rewritten to support widgets.

I should get around to posting my old PI some day. I use my Property Sheet more often lately, but the PI I once made many years ago may be worth resurrecting....

[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?

I first went to LiveCode.com in my browser to see if their WordPress install was part of the delay. Then I viewed source, copied, and pasted into Geany.

I dunno then, cause I followed your steps exactly, and it pasted into Geany as soon as I hit ctrl+v. The time it takes to fill in a field or in an Lc variable window shouldn't be longer than it takes to display in a field, i.e. it never takes longer than 3 mins to fill in the field, the IDE shouldn't hang for +10 mins. to display the contents of a variable would be my guess.

The old PI sounds interesting for sure,

Specs on my laptop for my own reference, I can't ever seem to remember it when I'm not on it
Sparky Linux 4.9.0-6-686 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) i686 GNU/Linux
Memory:
total.....used.....free.....shared.....buff/cache.....available
2.9G....373M....1.6G.....23M.......1.0G.............2.2G
Video - [AMD/ATI] Mullins [Radeon R2 Graphics]

[FourthWorld]

I hear you on the delay, but I was unable to reproduce that. There was a delay, but probably less than a minute. Geany was only slightly faster.

3GHz G3220, Ubuntu 14.04, LCv9rc1

[bwmilby]

I also tried just setting the text vice htmltext and it took about the same amount of time. I also tried Google with stepping through. As long as I don't actually try to open a variable, it is fine (I can step through each line). When I stop to view the tmpPage, I get the same error when I try to continue.

I will also note, that I did try to view the tmpPage data yesterday with the LiveCode site. It did open, but took a long time.

If I add another card with a browser widget, then it only takes 4 seconds (260 ticks) to return control (and maybe a second or two for the page to actually paint on the screen.

Code: Select all

set the htmlText of widget "Browser" to tmpPage

So, it looks like the issue is with the text field, probably the methods pushing data into it.

[bogs]

As long as I don't actually try to open a variable, it is fine (I can step through each line). When I stop to view the tmpPage, I get the same error when I try to continue.

Yah, screwy ain't it?

Things like that tend to make me think it is more involved than simply the field, although I believe that is part of it. Too bad you can't view the variable without interaction with a field in the debugger, I'm sure that would be telling

Hmmm, maybe you can ....thinking....thinking....thinking... lemme get back to you on that one.

Can't speak to widgets, I'll take your word for it since I haven no experience with them.

[bogs]

Just noticed something else with the property inspector. In browse mode, clicked on a field, and focus went to the property inspector instead of the field . Very weird things going on, wonder how far back that one goes.

After changing a few lines, went to save and then the IDE locked up again with a nonsensical message -

Of course, this stack was only made in 9.0, so I didn't think it would try to save in any format but 9.0

[jacque]

Too bad you can't view the variable without interaction with a field in the debugger

You can see most content by simply pointing to the variable in the script editor itself. If you point to an array you'll just see the keys. If the variable content is very long, it may be truncated.

[FourthWorld]

Re. the "nonsense message": If the stack has never been opened in any earlier version of LiveCode, and if you've never used Save As to save the stack to any earlier format, that may be a bug. If you file a bug report please post the number here so we can follow its progress.

[bogs]

Ok, I *think* I have been able to prove conclusively (at least to my satisfaction) that the livecode.com issue in the fields is solely a problem with the current fields themselves.

First, I changed some of the code to put the page directly into the clipboard. Then I ran the code from Lc 6.5.2, and then 9.0. Code for both tests -

Code: Select all

on returnInField
   put "" into field "Field1"; put "" into field "Field2"
   put "Fetching..." into field "Field1"
   put empty into field "time"
   put empty into field "length"
   put empty into field "stop"
   put the ticks into tStart
   put the long time into field "start"
   put the text of field "txtURL" into tmpURL
   set the clipboardData["html"] to url tmpURL
   put the long time into field "cbTime"
   set the text of field "Field1" to the clipboardData
   set the htmlText of field "Field2" to  the clipboardData
   put (the ticks - tStart) into field "time"
   put the length of tmpPage into field "length"
   put the long time into field "stop"
end returnInField

Not surprisingly, the data goes into the clipboard lickety-split in either of the two IDEs. The remaining handling of it is (or should be) all on the field controls. You can see this behavior by stepping through the debugger in 9 particularly.

6.5.2 times about 4 seconds, clipboard fields and all -

Selection_006.png (8.04 KiB) Viewed 6799 times

9.0 times about 4-6 seconds to get it into the clipboard, all the rest of the time is spent getting it into a field -

[bogs]

As long as I don't actually try to open a variable, it is fine (I can step through each line). When I stop to view the tmpPage, I get the same error when I try to continue.

Things like that tend to make me think it is more involved than simply the field, although I believe that is part of it. Too bad you can't view the variable without interaction with a field in the debugger, I'm sure that would be telling
Hmmm, maybe you can ....thinking....thinking....thinking... lemme get back to you on that one.

Doh, clipboardData let me view the contents without requiring the Lc environment.

Now, you and I both experienced that error in the editor just trying to view the variable of what is obviously working code (you can step through it, I can as well long as the IDE doesn't fall over), but trying to view the variable, no matter how long it takes, should *not* be throwing an error of any kind short of there being an actual error.

Just my (what am I up to now? $0.64?) cents.

This also concludes my testing of 9.0, I'll drop back to the 8.x series for testing for bugs since it is just too flaky on my system(s).

[bwmilby]

Yes, it is strange. But as was mentioned, that is probably a debugger bug where the defaultstack is getting reset and not restored. It makes sense because viewing the variable opens a new window (stack) with the content of the variable. I get the same error on Mac.

Also, the delay in opening that stack is going to be caused by the same thing that makes the test stack perform slowly. Taking a 1.5MB hunk of text and importing it into the field as htmltext is causing the issue. Using text isn't any better (although it looks better - same as pasting source into Geany). It still took 55 seconds on my machine to display the LiveCode source. [I wrote this before seeing what @bogs had written in the previous couple of posts]

One question... what are we trying to test by getting the LC site raw text and manually setting the htmltext for a field? Even apart from the time issue, the field can't handle the web site HTML. All kinds of CSS "stuff" is left before you even see any content. Are we trying to use a field to "clean"/"simplify" HTML?

Also, I'm not sure a paste into a text editor is a good comparison. In Firefox, select all (ctrl-a) and copy (ctrl-c). Use the same logic, but in a button with 2 lines changed:
put the clipboarddata["text"] into tmpPage
set the text of field "txtPage" to tmpPage
And it only took 1 tick (1 sec) with a length of 3848. It looked just like what I got when I pasted into Geany (ctrl-a, ctrl-c in Firefox, ctrl-v in Geany). I tried with "view source", but couldn't get that to work at all with the stack (worked fine with Geany though). Wouldn't work even if I re-copied the text from Geany.
Reread thread, this doesn't really apply.

You could dump large variable like that to a file and view externally as one option, but that would need to be added to the code beforehand. [I think the clipboard is a pretty good way too.]

I was going to post an updated stack, but now I need to go back and make some changes
One thing I find funny, Linux in a VM is slightly faster than my Mac host on this test.

[bwmilby]

Here's an updated version of the test stack. The time to set htmltext/text is pretty close. I added a page with the browser widget to compare (the widget is very fast in comparison). Also added an option to put the page on the clipboard (fullclipboarddata["html"]).

Edit: updated stack/image

[bwmilby]

This also concludes my testing of 9.0, I'll drop back to the 8.x series for testing for bugs since it is just too flaky on my system(s).

I think this long line thing was a big part of your issues, but every pair of eyes helps. I think you spotted at least one item that should be relatively easy to get corrected (the error when in debug). PI oddness may take more effort.

Not sure what can be done about the long line/wrapping issue. How often would something like this actually be a problem in a client application? Just curious since I have not done anything client facing in LC yet (just dev facing stuff).

[bogs]

Too bad you can't view the variable without interaction with a field in the debugger

You can see most content by simply pointing to the variable in the script editor itself. If you point to an array you'll just see the keys. If the variable content is very long, it may be truncated.

Yes, if the variable was something like 'put 12435x787 into tmpVar', I would probably view that by pointing at the variable itself in the script. Unfortunately, even the briefest legitimate webpage is likely to be longer than what it shown with the hover
.. It is ok, though, the clipboardData trick showed me what I was curious about, without the weird delays.

Re. the "nonsense message": If the stack has never been opened in any earlier version of LiveCode, and if you've never used Save As to save the stack to any earlier format, that may be a bug. If you file a bug report please post the number here so we can follow its progress.

I don't see how a stack created in 9.0 could possibly be opened in a version earlier than say, 8.x unless you specifically saved it to an earlier format. However, this brings up ANOTHER issue and that seems to be that backwards compatibility to any great extent is probably shot as well. Trying to save from inside 9 to anything earlier than 7.x wasn't even available.

As a side note, I had to jettison 8.1.6 since it started acting like 9.0 to the point the code editor started wonking out on me, which hadn't happened previously (before installing 9.0). I think I'm going to grab some holy water and a cross

[bogs]

Taking a 1.5MB hunk of text and importing it into the field as htmltext is causing the issue. Using text isn't any better (although it looks better - same as pasting source into Geany). It still took 55 seconds on my machine to display the LiveCode source. [I wrote this before seeing what @bogs had written in the previous couple of posts]

As you saw in my previous post, taking a 1.5 MB hunk of text and importing it into a field shouldn't have any impact whatsoever. It takes seconds to put it in the clipboard, it takes seconds to paste it into a text editor (on my machine, anyway, Richard must have some anomaly going on there heh), and it takes literally seconds to do exactly the same process in MUCH older versions of Lc.

We're not talking about slamming 500 megs of text into it, and even if we were, I think +/- 3 minutes is far too long, especially once it is all in memory in one form or another and all your doing is updating the field.

One question... what are we trying to test by getting the LC site raw text and manually setting the htmltext for a field? Even apart from the time issue, the field can't handle the web site HTML. All kinds of CSS "stuff" is left before you even see any content. Are we trying to use a field to "clean"/"simplify" HTML?

Actually, what started this whole test was a post by Mariasole, which I started attempting to solve in 6.x, my default IDE for most things, cross pollinated by an https question posted around the same time. The https question triggered going through several versions of the IDE, running simple tests.

I didn't notice any huge time delays until I reached 8.1.6. In that thread, Richard suggested using 9.0. I felt my mind shear under the bearing of his Jedi will and.....oh wait, thats a different story

You could dump large variable like that to a file and view externally as one option, but that would need to be added to the code beforehand. [I think the clipboard is a pretty good way too.]

I was going to post an updated stack, but now I need to go back and make some changes
One thing I find funny, Linux in a VM is slightly faster than my Mac host on this test.

Heh, the stack is mostly a starting point to the projects I mentioned above. The part that really intrigued me and the reason I kept using it was that with the simple (initially what, 3 lines?) code and controls of what I believe to be the least computationally challenging thing on the planet managed to, on both of my machines, completely blow 8 and 9 up, since as I say, I don't see *any* of these issues in the much older IDEs, not even in MC. I wouldn't have thought too much would need to be changed in a functioning field metaphor control, but I guess something must have been.

You've already put more thought into this test than I probably ever would have since I spend the far greater bulk of my time in the past, with all its warts, where (unless I fix it myself) the warts will remain constant.

I don't mind peeking at the newer versions once in a while, but I sure couldn't ever put up with all this stuff on any kind of permanent basis.