Re: Refactoring is your friend / moving from 6.x to 9.x
Richard: > Is there an actual list of concrete concerns here [...] > or did I just spend an hour reading that I'll never get back? > I feel rickrolled. A profound question, my friend. :D You may notice something special about the following link, adapted in honor of the situation: http://curryk.com/NeverGonna.mp4 Oh boy - I was ALWAYS gullible enough to fall for the "concrete concerns" type of line every single time, and rush off to make a newer list, until finally I wised up to the world's ways and realized that (outside of bug reports and specific issues) such statements are sometimes used merely to deflect - it's not always a matter of actually wanting more details, but rather quite simply an unwanted message. These days, I am usually prepared in advance and merely smile and point a finger toward the information; the answer long preceded the question! Many of the details had been in place and waiting for some time, by myself and others. They've been presented and discussed before, so I didn't anticipate the need to reference every single one yet again; perhaps I should have. But I understand that memories can be convenient, and assumptions and agendas can be strong enough to brush aside what we already know every now and then. So, the "reverse rickrolled" link above connects to some aging stats that still hold generally true on the subject of performance. In many very basic tasks (math, loops, arrays) LC 9 has fallen short by 1.x or even 2.x, and that's still the case as of 902 final. And testing indicated that it's almost certainly NOT just a Unicode thing. I'm sorry if that makes me the messenger of inconvenient news, or a destroyer of attractive explanations, but I prefer the plain truth of reality. Repeatable, proven, public tests, videotaped and distributed; sorry, but it's fact. No line of talk or alternate authoritative studies can alter that. Test it yourself, or look the other way if you must, but the facts persist either way. I'm going to wait until there are relevant engine changes to update the results chart and test stack. It'll be fair as usual; in the original round of testing I went out of my way to make sure 9 had at least one match in its favor, and now I know a few other areas thanks to these talks. Hopefully after said engine changes, 9 will be the big winner! When it comes to another matter of efficiency and saving work by avoiding repetition, I've always been a big fan of Richard's own rather extensive and lengthy rhetoric on the subject, and his repertoire of catchy acronyms such as WET (We Enjoy Typing) versus DRY (Don't Repeat Yourself). But I do believe in following through and applying the fundamental concepts consistently across the board, including reasonably minimizing repetition of the work itself. In fact Richard, there was a very eloquent past message of yours on a similar subject, if memory serves me well. I may post a link eventually if I have time to hunt it down, and defer to your own words on that; it was very well said. Bob: > Some may think I'm overstating my case, but I think Livecode > stands alone in development environments for speedy development > and ease of use. You may be surprised that I agree! But of course you wouldn't be surprised if you noticed that for many years now, I am 100% specialized and 100% dedicated to LiveCode consulting and development. It's all I do. I walk the walk, while others talk; all LiveCode, all the time. So I understand if you feel an impulse to circle the wagons, but it's preaching to the choir or perhaps to the preacher himself. That question of which tool was settled long ago, and I'm a bigger LC proponent than almost anyone, especially since my skin is 100% in the game as a dedicated and exclusive specialist in that one tool. What we are looking at here is the question of making THE tool better in some areas. And if that's a bad thing, then count me guilty as charged, because I use, teach, and promote this tool 24/7/365 year after year, there are big plans ahead, and there are certain things I want in place for LC's own benefit, for yours, and for my own. Far from being a threat, they will help LC maintain its advantage against any potential competition. Mark Waddingham: > It hasn't as yet - that PR > (https://github.com/livecode/livecode/pull/6671) has actually > turned into a mini-grab bag of things [...] > - reduction of memory usage of the 'handle' structures used to > hold values (particularly on 64-bit) > - faster processing of integer index access in arrays > - faster short-path array access (both storing and fetching) [...] Yes!!! Just what I was hoping to hear, that this is still in the works. Thank you, sir. It should help a great deal. And THAT is the reason I engage in these particular discussions, and make myself cannon fodder at times to get the info out there: there are amazing benefits still to be realized, even when using such
Re: Navigator 7.0.1rc1 is available -- Multi-target windows!
Wow, that's a lot of information you're displaying -- have you noticed any hit on Navigator's display performance? Also, couldn't you replace the left of tID & "," & the top of tID & "," & the right of tID & "," & the bottom of tID with the rect of tID ? On Fri, Jan 4, 2019 at 8:02 PM pink via use-livecode < use-livecode@lists.runrev.com> wrote: > > > > 1. One thing I would love to do is assign different commands to the > > "Command Bars", I've been going through the source code and haven't > > figured > > out where this happens... > > > > I obviously need to do better here: just right-click/control-click a > command bar. The pop-up menu lets you select any existing command to assign > to that command bar. You can create new named commands by selecting New > Command... at the top of the menu. Note: I just now noticed that you have > to have at least one control selected for this to work. I'll fix that in an > update. > > EXCELLENT! > > > > > 2. Another feature request would be to assign a different color for > > groups > > (and folded group contents) > > > > I thought about this, but I thought the overall "color things based on > whether they have a script/behavior" was more important, but I'll take a > look and see how tough this would be to work in. > > --Ultimately, a user can get around it by using the same color if they > don't > want to distinguish between certain things... I use the same color for with > or without a script > > > > > 3. it seems as though all controls in a card are being indented... was > it > > always like that? > > > > Good eye -- no, they weren't before, but I added that additional level of > indent because of allowing multiple targets. It would be easy enough to > undo depending on the consensus opinion. > > --I would prefer not to have the extra indent, but it's not a dealbreaker > or > anything :P > > > > > 4. it would be nice if there were an easier way to clean up the List > > Display String list... as far as I can tell the only way is to manually > > edit > > the prefs file > > > > Definitely agreed, it was just the lack of/need for interface inspiration > and a desire to work on something else/laziness. But yes, editing the prefs > is the only way at present to clean up the list display list. > > --I had A LOT to clean up, each addition to my line just made it > exponentially larger... > > iff(the vis of tID,"","hid") & iff(char 1 to 5 of the name of tID is > "group","---grp ---" & the short name of tID & "---",toUpper(char 1 of the > name of tID) && the short name of tID) && "id[" & the short ID of tID & "]" > && the height of tID & "x" & the width of tID && the mpDevNotes of tID && > the left of tID & "," & the top of tID & "," & the right of tID & "," & the > bottom of tID & "/" & the layer of tID > > > > > > > - > --- > Greg (pink) Miller > mad, pink and dangerous to code > -- > Sent from: > http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Navigator 7.0.1rc1 is available -- Multi-target windows!
> > 1. One thing I would love to do is assign different commands to the > "Command Bars", I've been going through the source code and haven't > figured > out where this happens... > I obviously need to do better here: just right-click/control-click a command bar. The pop-up menu lets you select any existing command to assign to that command bar. You can create new named commands by selecting New Command... at the top of the menu. Note: I just now noticed that you have to have at least one control selected for this to work. I'll fix that in an update. EXCELLENT! > > 2. Another feature request would be to assign a different color for > groups > (and folded group contents) > I thought about this, but I thought the overall "color things based on whether they have a script/behavior" was more important, but I'll take a look and see how tough this would be to work in. --Ultimately, a user can get around it by using the same color if they don't want to distinguish between certain things... I use the same color for with or without a script > > 3. it seems as though all controls in a card are being indented... was it > always like that? > Good eye -- no, they weren't before, but I added that additional level of indent because of allowing multiple targets. It would be easy enough to undo depending on the consensus opinion. --I would prefer not to have the extra indent, but it's not a dealbreaker or anything :P > > 4. it would be nice if there were an easier way to clean up the List > Display String list... as far as I can tell the only way is to manually > edit > the prefs file > Definitely agreed, it was just the lack of/need for interface inspiration and a desire to work on something else/laziness. But yes, editing the prefs is the only way at present to clean up the list display list. --I had A LOT to clean up, each addition to my line just made it exponentially larger... iff(the vis of tID,"","hid") & iff(char 1 to 5 of the name of tID is "group","---grp ---" & the short name of tID & "---",toUpper(char 1 of the name of tID) && the short name of tID) && "id[" & the short ID of tID & "]" && the height of tID & "x" & the width of tID && the mpDevNotes of tID && the left of tID & "," & the top of tID & "," & the right of tID & "," & the bottom of tID & "/" & the layer of tID > - --- Greg (pink) Miller mad, pink and dangerous to code -- Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Navigator 7.0.1rc1 is available -- Multi-target windows!
"so I get the current way it works. " Ditto that. I was afraid to ask indenting. Then suddenly it appeared! BR Bob Sneidar wrote: I say NAY! I like the way it indents now. I'm surprised the interface doesn't list every card, each indented, with all it's own controls indented further, but it would get really really busy at that point so I get the current way it works. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Navigator 7.0.1rc1 is available -- Multi-target windows!
I say NAY! I like the way it indents now. I'm surprised the interface doesn't list every card, each indented, with all it's own controls indented further, but it would get really really busy at that point so I get the current way it works. Bob S > On Jan 4, 2019, at 10:35 , Geoff Canyon via use-livecode > wrote: > >> >> 3. it seems as though all controls in a card are being indented... was it >> always like that? >> > > Good eye -- no, they weren't before, but I added that additional level of > indent because of allowing multiple targets. It would be easy enough to > undo depending on the consensus opinion. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Navigator 7.0.1rc1 is available -- Multi-target windows!
I have noted over the years that when designing graphics, lots of different colors is confusing to the mind. Everytime something changes, whether in a typeset layout with pictures and graphics, or in a user interface, the mind stops and asks, "Why is that?" If it asks too many times or too often, the mind gets frustrated, and it takes away from the thing you want the user to actually be focused on. The way Navigator works now is quite nice. More and different colors and my poor mind might wince. :-) Bob S > On Jan 4, 2019, at 10:35 , Geoff Canyon via use-livecode > wrote: > >> >> 2. Another feature request would be to assign a different color for groups >> (and folded group contents) >> > > I thought about this, but I thought the overall "color things based on > whether they have a script/behavior" was more important, but I'll take a > look and see how tough this would be to work in. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Refactoring is your friend / moving from 6.x to 9.x
+1 I'm just elated I can write apps again after such a long drought from Hypercard, and the disappointment I had with Supercard. I personally think LC is what Hypercard should ALWAYS have been, or would have become had Apple had kept it up, or had someone else taken it up. Now I do not develop in Windows or Linux, so there may be/have been some real concerns there. Still, what we can do, what many of us have done is nothing short of breathtaking. My service manager who was rolling his eyes when I told him what I was going to do with Forms Generator is now tickled pink that we can generate forms on demand, on site, that look professional. That app had a lot to do with my present status in the company. I took the job as a copier installer. I'm now the Systems Administrator for the entire comany, and they are training me for Pre-Sales Software Consultation and support. I just finished a little utility that takes accounting data export from Toshiba copiers and adds up the color and black totals that make some kind of sense (the export file decidedly does NOT make sense) in a great looking interface, and then outputs a PDF report, or a tab delimited txt file for use in Excel. The customer I wrote it for initially had his doubts about our company, but after I sent him that little gem he LOVES us. So does his accounting department who no longer has to cobble all the data together themselves. The time it took to do all this would have been unthinkable in a C derivative or in a Java based environment. Never mind all the new features and updates I've been adding all along. Some may think I'm overstating my case, but I think Livecode stands alone in development environments for speedy development and ease of use. Bob S > On Jan 3, 2019, at 22:40 , Richard Gaskin via use-livecode > wrote: > > Read through this whole thread, optimistic that I'd find the list of things > that differentiate v6 and v9 so we can hone in on actual solutions. > > I learned two things: > > - lock/unlock changed > > - It's apparently easier to write a thousands of words philosophizing > about how a small team of C++ programmers should provide a uniform > scripting interface for a nearly unprecedented number of OSes, > stay on top of ongoing API changes in every one of those OSes, > multiply features, fix bugs, incorporate Unicode, maintain or improve > all aspects of performance, and keep the joint running than it is to > even briefly summarize concerns about any of the above. > > Is there an actual list of concrete concerns here that the team may be able > to take action on or at least explain how/why the change exists, or did I > just spend an hour reading that I'll never get back? > > I feel rickrolled. > > > I've worked with too many people moving from Drupal 7 to Drupal 8, or Python > 2 to 3, or any version of Apple's C headers in the '90s that broke > declarations quarterly, or HyperCard 2 to 3, to get too out-of-breath about > undoing workarounds in old code to work with-the-grain for v9's enhancements > and fixes for long-standing anomalies. When I describe LC's high priority > for backward compatibility to nearly any other experienced dev I know, they > look at me like I'm high and spouting tales of dancing ponies; many > professional development systems consider backward compatibility a very minor > nice-to-have, if they devote time to it at all. Many of us here buy computers > from a hardware vendor with a similar view. > > As for performance, in threads with Geoff Canyon, Mark Talutto, and others > who provided real-world use cases and metrics, we do see some performance > degradation in v9 from v6 in some cases, a surprising amount on par given how > relatively little work v6 had to do under the hood with encodings and types, > a few things a wee bit faster, and overall such a strong comeback from the v7 > series that it should be clear to those earnestly following along that the > team has indeed been quite evidently working on performance, and delivering > improvements over the v9 cycle. > > Then again, my work may not touch the items on the concern list. I can't > know, because I couldn't find such a list in this long thread. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
Re: Is anyone doing multiple window management under Windows 10...
done. On Fri, Jan 4, 2019 at 3:55 PM Paul Dupuis via use-livecode < use-livecode@lists.runrev.com> wrote: > I am trying to generate some interest in getting this bug: > https://quality.livecode.com/show_bug.cgi?id=16305 > > fixed for the next release of LiveCode. The 'effective' keyword for > stack rectangles still thinks Windows 10 has 8px borders! (when they are > 1px) > > When this bug was submitted Windows 10 was sort of new, but by now I > would have expected it to be fixed, but it is still present in LC9.0.2 > > If you would also like this fixed, please add yourself to the CC list on > the bug report. > > Thank you > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: DataView and DataView Tree Levure Helpers
On Fri, Jan 4, 2019 at 3:05 PM JJS via use-livecode < use-livecode@lists.runrev.com> wrote: > Thanks very much for your clear reply Trevor. > > And i'd like to thank you for your great contributions. > You are welcome. > Given the fact we can always "roll back" , i can give it a try on a > project and see how it goes. > > I was especially interested in the Dataview as perhaps it is faster and > may scroll smoother than the DG2. > I haven't done any comparison tests myself. I would be interested to hear how it goes. LiveCode still needs to add a new feature that will improve scrolling speed in any DG-like control. I don't know what the timeline is for that though. > (and who knows Levure might be adopted by LC to add as an optional way > of working) LiveCode already recommends it to development teams. See this page on their website: https://livecode.com/products/livecode-platform/levure/ -- Trevor DeVore CTO - ScreenSteps www.screensteps.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: DataView and DataView Tree Levure Helpers
Thanks very much for your clear reply Trevor. And i'd like to thank you for your great contributions. Given the fact we can always "roll back" , i can give it a try on a project and see how it goes. I was especially interested in the Dataview as perhaps it is faster and may scroll smoother than the DG2. Have a good weekend ! (and who knows Levure might be adopted by LC to add as an optional way of working) Op 4-1-2019 om 19:51 schreef Trevor DeVore via use-livecode: On Fri, Jan 4, 2019 at 12:12 PM JJS via use-livecode < use-livecode@lists.runrev.com> wrote: Curious about some things. Can this dataview do the same things as the datagrid? Like Form with images and fields on a row via row template or similar? Yes. Row templates use the same concept as DataGrids. Does it has scroller for mobile? or has it to be created like with DG1 and other groups? The scroller for mobile is built in. You can see the code in the `preOpenControl` message: https://github.com/trevordevore/levurehelper-dataview/blob/master/dataview_behavior.livecodescript#L68 l hesitate on using a lot of 3rd party tools, support could be stopped anytime, and if you then depend on it... We already depend on LC. That is a valid concern and one that I share myself. The tools that I release are open source and there is no official support for them. Given my responsibilities at my company I have chosen not to sell or officially support contributions I make available to the LiveCode community. I do, however, want to contribute non-proprietary work I do to the community so that we can all make better apps. I have chosen to do that through making the code available on GitHub and using the MIT license. I also try to document them as best as I can given the time I have available. Everyone has full access to the source code and others can contribute to the source code. For example, three other people have contributed to Levure besides myself. They contribute by helping with docs, submitting code updates, and reporting issues. You can see the list of contributors here: https://github.com/trevordevore/levure/graphs/contributors Like i like to give levure a try, but also hesitate, can i turn back to the "normal" way of building an app? You can always go back to how you were developing your apps previously. How much "unwinding" would need to be done depends on how many changes you make to your app in order to adopt everything that Levure has to offer. Regarding what is "normal" – Outside of apps that only use a handful of stack files, I honestly don't know that there is a "normal" way of building an app in LiveCode. I have seen a lot of different organizational approaches over the years. Since LiveCode doesn't have a "project" concept it seems that everyone tries to create their own version of what a project should be. At least with Levure you are using a well-documented system whose source code is available and that is at least being used by some other people. Let me know if you have any further questions. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Is anyone doing multiple window management under Windows 10...
I am trying to generate some interest in getting this bug: https://quality.livecode.com/show_bug.cgi?id=16305 fixed for the next release of LiveCode. The 'effective' keyword for stack rectangles still thinks Windows 10 has 8px borders! (when they are 1px) When this bug was submitted Windows 10 was sort of new, but by now I would have expected it to be fixed, but it is still present in LC9.0.2 If you would also like this fixed, please add yourself to the CC list on the bug report. Thank you ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: DataView and DataView Tree Levure Helpers
On Fri, Jan 4, 2019 at 12:12 PM JJS via use-livecode < use-livecode@lists.runrev.com> wrote: > Curious about some things. Can this dataview do the same things as the datagrid? > > Like Form with images and fields on a row via row template or similar? > Yes. Row templates use the same concept as DataGrids. > Does it has scroller for mobile? or has it to be created like with DG1 > and other groups? > The scroller for mobile is built in. You can see the code in the `preOpenControl` message: https://github.com/trevordevore/levurehelper-dataview/blob/master/dataview_behavior.livecodescript#L68 > l hesitate on using a lot of 3rd party tools, support could be stopped > anytime, and if you then depend on it... > > We already depend on LC. > That is a valid concern and one that I share myself. The tools that I release are open source and there is no official support for them. Given my responsibilities at my company I have chosen not to sell or officially support contributions I make available to the LiveCode community. I do, however, want to contribute non-proprietary work I do to the community so that we can all make better apps. I have chosen to do that through making the code available on GitHub and using the MIT license. I also try to document them as best as I can given the time I have available. Everyone has full access to the source code and others can contribute to the source code. For example, three other people have contributed to Levure besides myself. They contribute by helping with docs, submitting code updates, and reporting issues. You can see the list of contributors here: https://github.com/trevordevore/levure/graphs/contributors > Like i like to give levure a try, but also hesitate, can i turn back to > the "normal" way of building an app? > You can always go back to how you were developing your apps previously. How much "unwinding" would need to be done depends on how many changes you make to your app in order to adopt everything that Levure has to offer. Regarding what is "normal" – Outside of apps that only use a handful of stack files, I honestly don't know that there is a "normal" way of building an app in LiveCode. I have seen a lot of different organizational approaches over the years. Since LiveCode doesn't have a "project" concept it seems that everyone tries to create their own version of what a project should be. At least with Levure you are using a well-documented system whose source code is available and that is at least being used by some other people. Let me know if you have any further questions. -- Trevor DeVore CTO - ScreenSteps www.screensteps.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Navigator 7.0.1rc1 is available -- Multi-target windows!
Answers inline: On Fri, Jan 4, 2019 at 5:06 AM pink via use-livecode < use-livecode@lists.runrev.com> wrote: > I love this plugin... one of my top 3 favorites > > Here's my wishlist: > > 1. One thing I would love to do is assign different commands to the > "Command Bars", I've been going through the source code and haven't figured > out where this happens... > I obviously need to do better here: just right-click/control-click a command bar. The pop-up menu lets you select any existing command to assign to that command bar. You can create new named commands by selecting New Command... at the top of the menu. Note: I just now noticed that you have to have at least one control selected for this to work. I'll fix that in an update. > > 2. Another feature request would be to assign a different color for groups > (and folded group contents) > I thought about this, but I thought the overall "color things based on whether they have a script/behavior" was more important, but I'll take a look and see how tough this would be to work in. > > 3. it seems as though all controls in a card are being indented... was it > always like that? > Good eye -- no, they weren't before, but I added that additional level of indent because of allowing multiple targets. It would be easy enough to undo depending on the consensus opinion. > > 4. it would be nice if there were an easier way to clean up the List > Display String list... as far as I can tell the only way is to manually > edit > the prefs file > Definitely agreed, it was just the lack of/need for interface inspiration and a desire to work on something else/laziness. But yes, editing the prefs is the only way at present to clean up the list display list. > > > > > > - > --- > Greg (pink) Miller > mad, pink and dangerous to code > -- > Sent from: > http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Refactoring is your friend / moving from 6.x to 9.x
On 1/4/19 3:40 AM, Malte Pfaff-Brill via use-livecode wrote: Actually I did not expect this thread to turn into philosophical discussions. What I was searching for was input on gotchas you guys and girls may have experienced when moving from the monolith engine to the refactored one., so that I would get an idea on what to look out for when continuing to refactor my old project(s). Here's one that bit me: In LC 8 dp15 a change was made to tab controls: they are now transparent, even if you set a background color and make them opaque, but *only on Mac OS*. My workaround is to set an opaque rectangle behind the tab controls. It's not in the release notes. https://quality.livecode.com/show_bug.cgi?id=17219 -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: DataView and DataView Tree Levure Helpers
Curious about some things. Can this dataview do the same things as the datagrid? Like Form with images and fields on a row via row template or similar? Does it has scroller for mobile? or has it to be created like with DG1 and other groups? l hesitate on using a lot of 3rd party tools, support could be stopped anytime, and if you then depend on it... We already depend on LC. Like i like to give levure a try, but also hesitate, can i turn back to the "normal" way of building an app? Thanks. Op 4-1-2019 om 18:28 schreef Trevor DeVore via use-livecode: On Wed, Jan 2, 2019 at 10:55 PM Trevor DeVore wrote: Over the holiday break I took time to package up some UI controls I use in my own projects and make them available as helpers for Levure apps*. The controls are named "DataView" and "DataView Tree". The DataView is a leaner, more efficient DataGrid Form. It allows you to efficiently display highly customized rows of data on desktop and mobile. The DataGrid Tree is built on top of the DataView and works with a tree structure. I've added another DataView helper named "DataView Database Cursor Helper" and updated the demo app. This helper adds a `dvCursor` property to a DataView along with a number of other properties. You open a database cursor, assign it to the DataView, and then the DataView will automatically move through the cursor in order to display the rows the user is currently looking at. Fast and efficient, even for large result sets. Demo: https://github.com/trevordevore/dataview_demo DataView Database Cursor Helper: https://github.com/trevordevore/levurehelper-database_dbcursor ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: file: vs bibfile: usage?
On a Mac you have to use binfile if you want the appropriate line endings (LF)*
as file will change them to the legacy version (CR). On Windows, you probably
still want to use file so that the line endings are adjusted to CRLF. UTF
recognizes both as valid (CRLF and LF), not sure about CR.
* I use Xcode as my justification to say that LF is proper. It is the line
ending used there.
Thanks,
Brian
On Jan 4, 2019, 11:54 AM -0600, Paul Dupuis via use-livecode
, wrote:
> I have seen example in the dictionary, for example in the LC901
> Dictionary under "textEncode" entry, where LC9 text (in a field or
> variable) is encoded as UTF-8 and written to a file as:
>
> puttextEncode(tSomeText,"UTF-8") intoURL ("file:")
>
> However, my understanding is the the "file:" identifier tries to do
> "intelligent" line ending translation for the platform LC is running on.
> So in order to produce true UTF8 platform independent output, the
> examples should be
>
> puttextEncode(tSomeText,"UTF-8") intoURL ("binfile:")
>
> In other words, should not the rule be that when outputting anything
> other than "native" text (MacRoman (OSX) or Latin-1 (Win) or ISO for
> Linux), should it always be written a "binfile:" (i.e binary) so the
> coding is not changed?
>
> Does any LC expert know the answer to this?
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
file: vs bibfile: usage?
I have seen example in the dictionary, for example in the LC901
Dictionary under "textEncode" entry, where LC9 text (in a field or
variable) is encoded as UTF-8 and written to a file as:
puttextEncode(tSomeText,"UTF-8") intoURL ("file:")
However, my understanding is the the "file:" identifier tries to do
"intelligent" line ending translation for the platform LC is running on.
So in order to produce true UTF8 platform independent output, the
examples should be
puttextEncode(tSomeText,"UTF-8") intoURL ("binfile:")
In other words, should not the rule be that when outputting anything
other than "native" text (MacRoman (OSX) or Latin-1 (Win) or ISO for
Linux), should it always be written a "binfile:" (i.e binary) so the
coding is not changed?
Does any LC expert know the answer to this?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: DataView and DataView Tree Levure Helpers
On Wed, Jan 2, 2019 at 10:55 PM Trevor DeVore wrote: > > Over the holiday break I took time to package up some UI controls I use in > my own projects and make them available as helpers for Levure apps*. The > controls are named "DataView" and "DataView Tree". The DataView is a > leaner, more efficient DataGrid Form. It allows you to efficiently display > highly customized rows of data on desktop and mobile. The DataGrid Tree is > built on top of the DataView and works with a tree structure. > I've added another DataView helper named "DataView Database Cursor Helper" and updated the demo app. This helper adds a `dvCursor` property to a DataView along with a number of other properties. You open a database cursor, assign it to the DataView, and then the DataView will automatically move through the cursor in order to display the rows the user is currently looking at. Fast and efficient, even for large result sets. Demo: https://github.com/trevordevore/dataview_demo DataView Database Cursor Helper: https://github.com/trevordevore/levurehelper-database_dbcursor -- Trevor DeVore ScreenSteps www.screensteps.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Navigator 7.0.1rc1 is available -- Multi-target windows!
I love this plugin... one of my top 3 favorites Here's my wishlist: 1. One thing I would love to do is assign different commands to the "Command Bars", I've been going through the source code and haven't figured out where this happens... 2. Another feature request would be to assign a different color for groups (and folded group contents) 3. it seems as though all controls in a card are being indented... was it always like that? 4. it would be nice if there were an easier way to clean up the List Display String list... as far as I can tell the only way is to manually edit the prefs file - --- Greg (pink) Miller mad, pink and dangerous to code -- Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Refactoring is your friend / moving from 6.x to 9.x
> Of course, the latter is making the assumption that > Malte has a Retina mac... Indeed he has (now and did not back in the days where the app was written) Actually I did not expect this thread to turn into philosophical discussions. What I was searching for was input on gotchas you guys and girls may have experienced when moving from the monolith engine to the refactored one., so that I would get an idea on what to look out for when continuing to refactor my old project(s). I was aware of the unicode related changes and am trying to remove all the stuff that has been deprecated (like charToNum, useUnicode, and the like). That is pretty well documented and understandable. Marks explanation on my redrawing issues are explanations that are understandable, make sense and I am aware now. The „fun“ part is, that something like this will never be able to be caught by unit tests or simple example stacks. One will need real world projects of a certain size to see the effect. To put things into perspective here, the app I am refactoring has to draw/redraw about 1500 controls, of which only a couple are changing positions / get a new label etc. Retina quite surely is a factor here. Also settings for „accelerated rendering“ might play a role. While I applaud Currys effort to set up real world benchmarking stacks to compare between engines, I lack the self confidence to be convinced to write perfect code. I surely do not, especially if like in my case the number of lines of code go into the 10 thousands. I *try* to avoid redundancy . Most of the time I succeed and if I do find areas that are redundant, I refactor. The engine got a long way here. Behaviors, and nested behaviours (this me anyone?) are a very good example on how the engine matured over the years. I would not dare to expect that code written 10 years ago for an engine that was current 10 years ago is still useable without optimisations. I just have been away for too long to be able to know what to look out for. I am indem looking forward to the array optimisations to come, as once that is off the table I am looking forward to actually having something that will be much faster than I had it in previous versions. Cheers, Malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: IMAP library, or support via tsNet?
That's great, thank you Charles. Ben On 04/01/2019 00:08, Charles Warwick via use-livecode wrote: Hi Ben, Support for IMAP was added into tsNet a while ago. There are a few lessons that I’ve added to LiveCode’s website on IMAP. Lessons: http://lessons.livecode.com/m/4071/l/858279-how-to-use-tsnet-to-display-an-e-mail-message-from-an-imap-account http://lessons.livecode.com/m/4071/l/858974-how-to-use-tsnet-to-display-the-folders-stored-in-an-imap-account http://lessons.livecode.com/m/4071/l/860779-how-to-use-tsnet-to-delete-an-e-mail-message-from-an-imap-account Regards, Charles. On 4 Jan 2019, at 5:56 am, Ben Rubinstein via use-livecode wrote: Aha! I didn't even realise that there was an imap URL protocol. Thanks Matthias, that's exactly what I needed. best regards, Ben On 03/01/2019 13:57, Matthias Rebbe via use-livecode wrote: Ben, i just did a quick test with my local test mai server. This script for example would output the number of messages in the imap folder to the message box. put tUSERNAME into pSettings["username"] put put into pSettings["password"] put "STATUS INBOX (MESSAGES)" into pRequest put "imap://192.168.7.25" into pURL put tsnetCustomSync(pURL,pRequest,xHeaders,rOutHeaders,rResult,rBytes,pSettings) Did not try ssl, but should work also. Regards, Matthias Matthias Rebbe free tools for Livecoders: https://instamaker.dermattes.de https://winsignhelper.dermattes.de Am 03.01.2019 um 12:17 schrieb Ben Rubinstein via use-livecode : Is there anything in the way of an IMAP library around? My needs are relatively simple: I want to connect to an iMAP server, recursively list folders and fetch the size of each (if necessary by fetching the size of each message) e.g. in JavaScript with this library https://github.com/emailjs/emailjs-imap-client I'd be using connect() listMailboxes() listMessages(... ['RFC822.SIZE']) ... Is there a library that would support this kind of access? Does tsNet provide anything above the basic network primitives to support this? Some time I ago there was a tantalising hint on this list: On 24/08/2017 11:05, Charles Warwick via use-livecode wrote: IMAP and POP3 support in tsNet under Linux is only available in tsNet 1.3.0+ which will be bundled with the next LC release. All other platforms have had support for those protocols for a while. I hope to have some documentation available in the next two weeks. Did that ever come to fruition? Many thanks, Ben ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Refactoring is your friend / moving from 6.x to 9.x
On 2019-01-04 09:03, Kay C Lan via use-livecode wrote: So what I can't confirm is whether PR6671 has been implemented into a current version of LC9, but what I will say is this, if it hasn't then Malte can look forward to an eventual speed improvement in large Array operations as Mark Wa has already identified this problem and is working on a fix. If it has been implemented then Malte needs to take a look at Mark Wa examples and see where he can use some of Mark Wa's good code to replace his own poorly performing code. It hasn't as yet - that PR (https://github.com/livecode/livecode/pull/6671) has actually turned into a mini-grab bag of things which need to be separated out slightly: - reduction of memory usage of the 'handle' structures used to hold values (particularly on 64-bit) - faster processing of integer index access in arrays - faster short-path array access (both storing and fetching) - 'static' switch optimization (switches with all literal cases are now constant time and not linear in the number of cases) - params([, ) which returns an numeric array of parameters up to - sequence and array literals - a try(expr, error-expr) function (evaluates error-expr as the result if expr throws) - array meta-indexing (tArray[first], tArray[last], tArray[next]) The only one which is unlikely to survive is the meta-indexing as (1) they don't quite work correctly and (2) Monte had a better suggestion which I've not had a chance to implement. It also contains benchmarks derived from my talk at LCG on optimization, and Curry's which he posted a while back. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Refactoring is your friend / moving from 6.x to 9.x
On 2019-01-04 07:40, Richard Gaskin via use-livecode wrote: Read through this whole thread, optimistic that I'd find the list of things that differentiate v6 and v9 so we can hone in on actual solutions. I learned two things: - lock/unlock changed Except it hasn't - lock/unlock screen work the same as they always have - they nest. Differences since 5 however, include: - rendering was changed to use Skia - support for Retina displays was added (4x as many pixels to render on more modern Macs) - screen updates only happen once per command execution and only if necessary (if the screen is unlocked) As suggested in another post, I suspect Malte's speed difference was actually caused by over-unlocking (or interaction with a slightly wrong IDE script in the 5 IDE - assuming he was timing in the IDE) and the fact that Retina macs have 4x as many pixels to render (5.x did not do Retina resolution). Of course, the latter is making the assumption that Malte has a Retina mac... Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Refactoring is your friend / moving from 6.x to 9.x
On Fri, Jan 4, 2019 at 6:03 PM Richard Gaskin via use-livecode wrote: > Is there an actual list of concrete concerns here that the team may be > able to take action on ... I think the closest would be: >Malte wrote: >Not yet fixable for me: >Array operations on larger data sets still slower than they were Which leads me to the post titled: On Performance of Array Access posted 31 Aug 2018 relating specifically to large array data sets. >The wise Mark Wa (on a 2018MBP) wrote: >Generally, I don't tend to like to 'jump the gun' on anything related to >optimization lest it is not what it seems when running in the real world >but... His scripts used for the tests are all public, repeatable and objective, but if you don't want to bother finding that Post here are the results (PR6671 refers to a GitHub Pull Request into the LC9 engine) >LC6.7.11: 1117ms >LC9.0.1: 4020ms >PR6671: 1017ms >6.7.11: 1055ms >9.0.1: 3281ms >PR6671: 497ms >6.7.11: 16872ms >9.0.1: 8305ms >PR6671: 4315ms >6.7.11: 16508ms >9.0.1: 6397ms >PR6671: 3001ms >REAL WORLD CASE >Now, I'm always a little skeptical about using synthetic benchmarks for >performance. However, both of the above are actually real-world >examples. Furthermore, when running a rather large LCS project on an >engine with PR6671, I got a 2x speed up - one particular input took >3mins to process, rather than 6mins (one phase of processing actually >saw a 5x speed up!). So what I can't confirm is whether PR6671 has been implemented into a current version of LC9, but what I will say is this, if it hasn't then Malte can look forward to an eventual speed improvement in large Array operations as Mark Wa has already identified this problem and is working on a fix. If it has been implemented then Malte needs to take a look at Mark Wa examples and see where he can use some of Mark Wa's good code to replace his own poorly performing code. How this thread diverged from a problem that was clearly resolved by fixing poor code, to, what seems to me, 'our poor code should run just as fast in LC9 as LC5', I don't know. Sorry. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
