Lc 9.0 Rc1 things noticed...

If you find an issue in LiveCode but are having difficulty pinning down a reliable recipe or want to sanity-check your findings with others, this is the place.

Please have one thread per issue, and try to summarize the issue concisely in the thread title so others can find related issues here.

Moderators: heatherlaine, Klaus, FourthWorld, robinmiller, kevinmiller

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Mon Mar 19, 2018 7:39 am

bwmilby wrote:
Mon Mar 19, 2018 4:20 am
I think this long line thing was a big part of your issues, but every pair of eyes helps.
---------------------
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).
I completely forgot to answer these two questions~! ugh.
.. the long line issue came 2nd, after firing up the IDE for the first time and having it disappear without having done anymore than creating the new stack.
.. it may have even come third, since the IDE crashed and disappeared after I set the break point for the debugger the first time without even having run the code yet.
.. another problem that centers on my systems in particular is that primary development of the IDE is centered on Ubuntu, while almost everything I run in production is centered on Debian (not just based, but distro's that use debian as the core).

The problem with that imho is that Ubuntu is based on Debian (testing I believe), not the other way around, but Ubuntu throws a lot of other stuff into the mix (otherwise, it would be Debian, right? :wink: ) that plain old Debian doesn't bother with. So bugs I find on these systems are probably not reproducible on Ubuntu systems, as Richard and yourself have shown in many of the reply posts made in this very thread.

How often something like this would be a problem in a client application is a little tougher to answer. In my opinion, if something goofy happens one time, maybe not so bad. If something goofy happens all the time, maybe very bad. If something goofy happens after it has been working for years and years without issue, maybe your bankrupt. Unless your Ms, or Apple, although Apples been on the ropes a few times.

In case you meant how often do you have to put large text files into a client facing program, I can think of several ways that might break out.
.. your making a rich text editor (or a really REALLY rich text editor, like Richmond's lil jewel). Files could EASILY exceed 1.5 megs with a problem child typist that I'm sure you yourself has seen examples of.
.. Plain text with a lot of line wrapping - maybe your writing a .js editor (I've seen some of that code, it is like they never heard of line breaks :roll: ). After all, not everyone actually formats their code. Glad I don't have to maintain it :D
.. Scraping websites - formatting websites differs from person to person as much as formatting code. Your building a wysiwyg web editor, you REALLY better be prepared for long lines and huge files of every kind of text you can think of. It isn't like the olden days of yore when I was young(er) and you just banged out html in a text editor of your choice (although I am sure some do still, I know I do).

Think about some text editors you have probably used yourself. Geany just had to handle those long lines and large files. Pretty sure Sublime, mousepad, textpad, pluma, text mate, notepad, or any other text editor could handle it just as well. And I know Lc 6 could handle it, Mc handled it, and while I didn't actually test it in Rev 2.2, my guess is it could have handled it too. I'll test that out next to make sure though :P

So, what I guess I'm trying to say is, when your dealing with any client, even if your program is supposed to blink twice and quit, count on them wanting it to do that in ways you will never anticipate, otherwise it could be a big problem.
Image

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Mon Mar 19, 2018 8:59 am

bogs wrote:
Thu Mar 15, 2018 8:57 pm
[*]Alternately, when trying to edit a script the code editor would not open <sic> on clicking the blue box in the project browser...
[/list]
Translation on 'blue box' = script lines box on the far right of the project browser.
Selection_009.png
Selection_009.png (10.65 KiB) Viewed 529 times
Submitted a bug report 21094 for this as well since this is my primary method of accessing the script editor when working in the IDE.

It appears as far back as 8.1.4 (so far).
Image

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4393
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Lc 9.0 Rc1 things noticed...

Post by jacque » Mon Mar 19, 2018 6:11 pm

Regarding the time required to put htmltext into a field, I'm pretty sure it's related to two things, especially since you don't see it in LC 6. The main issue would be the unicode translation which was implemented in LC 7. The second thing, which is probably quicker but would still require time, is parsing the text to see what parts of the html can be displayed in the field,

I'm just theorizing here but if my guess is right then LC has to make 2 passes through the text, first for unicode conversion and next for html parsing, which would mean effectively going through 3 MB of data. I don't know if it would help, but you might try converting the clipboard to UTF 16 before setting the field text.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Mon Mar 19, 2018 6:52 pm

That made sense to me Jacque (are you frightened now? :twisted: ) so I tested in 7.1.4 based on that premise. Unfortunately, it doesn't seem to work out that way. While 7 took marginally longer, it was not on the scale that 8.x up takes.

In these pictures, I slightly modified the stack to have 2 text fields, one showing the htmlText, one just the text. The code used was the same code posted above, and has been used for all tests done on my side.

*Both* fields I ran with dontWrap alternately selected, then unselected. In either case, both runs turned out pretty close to the exact same times, a few seconds, and only marginally longer than in the 6.x series.

And while a larger file should take more time to load, I would be shocked if the size required for several minutes would be under a couple hundred megabytes at least. 4x that size if what you suspect is true, as it is actually loading 6 megs of information in 7 seconds or so (2 fields).

1. dontWrap set - less than 10 seconds to display and complete in both fields.
Selection_005.png
2. dontWrap off - about 2 seconds faster in the completion of both fields.
Selection_004.png
What ever changed pretty much changed after this point in time. What that something is is beyond me.

*Edit - just for fun in 8.1.4, I set the lock / unlock screen to see if it would speed things up, no love was found :D
Image

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4393
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Lc 9.0 Rc1 things noticed...

Post by jacque » Mon Mar 19, 2018 8:48 pm

I just tested using the source of the LC landing page with: set the htmltext of fld 1 to the clipboardData["text"]

It took 58 seconds to populate the field on my 4-year-old iMac. I opened the property inspector and set the vertical scrollbar. LC hung for about 20 seconds to implement that. Just some data points for you.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Tue Mar 20, 2018 3:06 am

jacque wrote:
Mon Mar 19, 2018 8:48 pm
LC hung for about 20 seconds to implement that.
Any version in the 8.x series pretty much hangs a while to do anything at all on either of my machines, opening the IDE, choosing a menu item, opening any ide window that deals with creating a program, like the PI, Pb, Se, although the application browser (which I almost never use) seems to work ok :?

Creating a stack, dragging a control to the cards, that part seems to move normally.
Image

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Tue Mar 20, 2018 5:53 am

While playing some more with the stack bwmilby provided I found some other interesting things about, in this case, 8.1.9.

With the 'don't wrap' set, as we all know, the field filled in with no effort. I happened to have conky running though when I took off the don't wrap setting (system monitor). With that setting off, it spiked my 3ghz rig and pegged it for the whole time that field was filling in, about 3 mins.
Selection_004.png
I also found that apparently the 'find and replace' doesn't seem to be working properly. It apparently *found* what I was looking for, but would not replace it (all those options were grayed out).
Selection_003.png
Anyone else see that kind of behavior?
Image

bwmilby
Posts: 142
Joined: Wed Jun 07, 2017 5:37 am
Contact:

Re: Lc 9.0 Rc1 things noticed...

Post by bwmilby » Tue Mar 20, 2018 6:41 am

I didn't run a system monitor, but could hear the fan kick in when doing the initial testing before I read about the "don't wrap" setting. The good thing is that since the issue appeared while source code was available, we can take a look to see what changed. It may be too much change to tell, but at least it is something to look into.

I have to select "All Tabs" or "Current Tab" for the find/replace dialog to enable those buttons.

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Tue Mar 20, 2018 3:27 pm

bwmilby wrote:
Tue Mar 20, 2018 6:41 am
I have to select "All Tabs" or "Current Tab" for the find/replace dialog to enable those buttons.
My bad, apparently I had selected that in a previous witch hunt in my earlier versions, and just never set it back :oops:

Now though I still wonder if that is not a bug. After all, if you click on 'Find and Replace', doesn't it necessarily follow that you are going to want to actually replace? Otherwise, why wouldn't you just hit "Find"?
Image

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4393
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Lc 9.0 Rc1 things noticed...

Post by jacque » Wed Mar 21, 2018 4:23 pm

Now though I still wonder if that is not a bug. After all, if you click on 'Find and Replace', doesn't it necessarily follow that you are going to want to actually replace? Otherwise, why wouldn't you just hit "Find"?
Presumably because Replace is destructive, and you need to specifically select the location where the changes should occur to avoid mutating unintended scripts.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Wed Mar 21, 2018 7:23 pm

jacque wrote:
Wed Mar 21, 2018 4:23 pm
...you need to specifically select the location where the changes should occur to avoid mutating unintended scripts.
Let us say that is the case (and I actually think it should be the case, for the reason you put especially), then in this particular dialog should not the options be limited to what will actually work?

I.e. you don't want "in all stacks" to be available, since it is not workable that way for the reason you put above. In fact, no stack option should be there, since none of them work for find and replace.
Image

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4393
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Lc 9.0 Rc1 things noticed...

Post by jacque » Wed Mar 21, 2018 11:03 pm

Using the script editor's Find and Replace, Find will put all the found locations into the Search Results tab in the script editor so you can see where each instance occurs. In that dialog, you can only do an actual replacement on scripts in open tabs, which is why the Replace options are disabled for anything that isn't a tab. Presumably you have chosen to open only the scripts you want to alter. This dialog won't let you mess up scripts that aren't viewable.

If you want to do a global replace across all stacks, even those that aren't open, use the Find and Replace dialog in the IDE's Edit menu. That allows you to mess up every stack in a whole folder in one click. :)

Edit: Say I want to replace all instances of "foo" with "bar" across several open stacks, but not all of them. I use the script editor's Find function to see where "foo" occurs. In the resulting list in the editor, I double-click the scripts I want to change, which opens them in tabs. Now that they are open in the editor, I can use Find and Replace to only alter those particular scripts.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Thu Mar 22, 2018 4:32 pm

Here is a surprise for me, Linux MX(15) runs Lc 9 without any of the issues I found running it in antiX, which I understand is a large part of the Mx project. Go figure. I'll have to leave it to Richmond to report if any of this weirdness taints MX(17), which I understand is the current release.

*Edit - no sooner did I post the above, then saw this weirdness opening the message box-
Selection_003.png
Selection_003.png (7.44 KiB) Viewed 355 times
What is apparently happening -
1. open IDE
2. with no stack open, click on message box
3. focus shifts from message box to tools palette, so you are unable to use the message box.
4. "put true into grevdevelopment" shows no error on opening message box
5. create a stack of any type, same behavior
6. add a button (or any object to the stack)
7. message box behavior resumes as normal (i.e. useable again).

@Jacque - I dunno, still wrapping me will head around all this, but then, you know how obtuse I can be. My take would still be that, if that is the case (and I believe you that it is), then those choices should be removed/hidden from the dialog brought up in the script editor. Why show controls that have no bearing on how the dialog will be used?
Last edited by bogs on Thu Mar 22, 2018 9:28 pm, edited 1 time in total.
Image

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4393
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Lc 9.0 Rc1 things noticed...

Post by jacque » Thu Mar 22, 2018 5:46 pm

It's a fairly standard interface to enable controls that are relevant in a particular situation and disable them when they don't apply. This provides a visual cue that the feature exists.

Your idea to hide the controls instead is also an accepted interface though, so if you think it's important enough you could submit a feature request for the change. If the current way confused you, it probably has confused others too.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 1763
Joined: Sat Feb 25, 2017 10:45 pm

Re: Lc 9.0 Rc1 things noticed...

Post by bogs » Thu Mar 22, 2018 8:18 pm

bogs wrote:
Thu Mar 22, 2018 4:32 pm
saw this weirdness opening the message box
Apparently the same in Linux Mint 13 (Maya). Testing in LM17 now, will edit if it is the same.

*Edit - ok, assuming Linux Mint(17x64) is one of the supported distros (Panos's list from here)
LiveCode_Panos wrote:
Sat Mar 17, 2018 12:54 am
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
I think I have a reproducible bug concerning the Message box. Dunno if someone wants to test out on Ubuntu.
Lc 9.0(rc1).
Steps to reproduce :
  1. open the IDE.
  2. with no stack open, click on message box.
  3. focus shifts from message box to tools palette, so you are unable to use the message box. This is regardless of whether you are in single or multi line mode.
  4. "put true into grevdevelopment" shows no error on opening message box.
  5. create a stack of any type, same behavior.
  6. add a button (or any object to the stack).
  7. message box behavior resumes as normal (i.e. useable again).


*Edit 2 - In addition to the above, I noticed that even with a stack and button around, when you hit [enter] after inputting a line, the focus immediately goes from the message box to the tools palette. Screwy.

Anyone else able to simulate it? Also, I did two searches for this kind of bug with various wording like

Code: Select all

9.0 rc1 message box focus
but came up dry, however I know others are better at searching the qdb, any one else see this reported?
Image

Post Reply

Return to “Bug Triage”