LC7 & Unicode
I do not know much, if anything about the LC implementation of Unicode or Unicode itself but I have been wondering. LC 7.0.3 performance without doubt (to my eyes) seems to be less than LC 6.7.3 and from my reading of posts on this list it seems to be due to LC 7.0.3 implementing Unicode? So, my question and perhaps it has been asked before but I don’t remember reading about it is: Can LC 7 & LC 8 be coded to enable Unicode to be switched “on”/“off” either globally or on an individual control basis? If possible LC 6 could be immediately dumped for future updates. So, where you are using a control that contains a lot of data, DataGrid or Bernd’s modTableField, you could turn off the Unicode in relation to these controls and leave it on for those controls that may need it more. Presumably this would improve the performance. As I say, I know nothing of Unicode. All the best Terry ___ 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: LC7 & Unicode
Terence Heaford wrote: > Can LC 7 & LC 8 be coded to enable Unicode to be switched “on”/“off” > either globally or on an individual control basis? Not likely. Unicode affects all things that deal with strings. That's pretty much most of the engine. Moreover, the refactoring for Unicode wasn't limited to Unicode alone, but incorporates a wide range of changes that are needed to knock off the rest of the Kickstarter goals. No one expected the first pass at such a deep revision to be both uncommonly transparent to users and also optimized. Now that v7 is out they can explore ways to refine performance. This may be a good time to remind people of the invitation posted here a few weeks ago from RunRev's Peter Brett: if you have a project which runs noticeably slower, contact support AT runrev.com to make arrangements to send it to them so they can profile it and optimize those portions of the engine that can make the biggest difference. V6 is clearly legacy technology. V7 is the bridge to v8 and everything else the future holds. Just as there came a time when the team had to move on from v3, v4, and v5, the longer they need to maintain v6.x the longer it will take to complete the Kickstarter goals. So let's identify those issues that truly prevent us from moving our projects to v7, and with any luck they'll be fixed as quickly as the "print into rect" issue was. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: LC7 & Unicode
On 2015-03-10 19:41, Richard Gaskin wrote: Terence Heaford wrote: Can LC 7 & LC 8 be coded to enable Unicode to be switched “on”/“off” either globally or on an individual control basis? Not likely. Unicode affects all things that deal with strings. That's pretty much most of the engine. This is a common misconception. Internally, the LC7 engine only uses Unicode if it has to. If your application only uses native strings, then LC7 will only use native strings. Built-in Unicode support has very little to do with the fact that LC7 is slower for some workloads. The cause of potential slow-down is more fundamental, and has to do with the way that variables and values in the language are handled and the way that the language is executed. As Richard says, some of these changes were required in order to enable the future development of the LiveCode language and to make it more flexible and powerful. We care about performance. Mark, who designed the LC7 engine, has done some quite extensive work recently -- even in his own time, over weekends -- to look for opportunities to improve performance. It's been invaluable for us to get hold of some real-world stacks that we've been given by users and developers. Peter -- Dr Peter Brett LiveCode Engine Development Team ___ 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: LC7 & Unicode
re: Internally, the LC7 engine only uses Unicode if it has to. If your application only uses native strings, then LC7 will only use native strings. Built-in Unicode support has very little to do with the fact that LC7 is slower for some workload I don't now, and don't intend to, use Unicode. I don't want *ANY* overhead associated with a feature I don't use. How does LC7 detect Unicode is being used? Can we turn off that detection, thus eliminating Unicode processing? How can we determine whether or not Unicode is being "used"? My situation: I create a "chunk" of data by concatenating binary data to "native strings". Then, I save the chunk into a large roll-your-own one-record-at-a-time "database". If LC7 is somehow automatically detecting Unicode, perhaps my "blob" of data is fooling it into thinking it's Unicode. There are 165,000+ records in my DB. Yes, I know a datastore of that size should use SQLite, or some other database handler. But, it started out 8 years ago being less than 1,000 records. Imagine my surprise when the quick-n-dirty stack slowly morphed into a real app. Incidentally, the "blob" also includes native HTML text. Could that be involved somehow in Unicode detection? TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4689967.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
On Wed, Mar 11, 2015 at 6:27 AM, TEDennis wrote: > re: Internally, the LC7 engine only uses Unicode if it has to. If your > application only uses native strings, > then LC7 will only use native strings. Built-in Unicode support has very > little to do with the fact that LC7 is slower for some workload > "something" make the load time an intolerable one second or more that wasn't there before in earlier 32 bit versions of LC Server. Really annoying. This had nothing to do with 'workload'. sqb -- Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words ___ 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: LC7 & Unicode
It should be noted that Gmail incorrectly quoted TED. On Wed, Mar 11, 2015 at 7:30 PM, stephen barncard < stephenrevoluti...@barncard.com> wrote: > Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words -- Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words ___ 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: LC7 & Unicode
stephen barncard wrote: "something" make the load time an intolerable one second or more that wasn't there before in earlier 32 bit versions of LC Server. Really annoying. This had nothing to do with 'workload'. Is that on Dreamhost, or have you been able to reproduce it on another shared host? -- Richard Gaskin Fourth World Systems Software Design and Development for Desktop, Mobile, and 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
Re: LC7 & Unicode
On Wed, Mar 11, 2015 at 10:27 PM, Richard Gaskin wrote: > Is that on Dreamhost, or have you been able to reproduce it on another > shared host? I have a "standby" shared account at Intersever.. thanks to your suggestion. I am pretty sure I did a test but maybe not. thanks for reminding me. .but moving all my stuff would be a pain... I'll do a test though. Perhaps I've been lazy about this. No one else has this problem now? (blush) -- Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words ___ 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: LC7 & Unicode
stephen barncard wrote: > On Wed, Mar 11, 2015 at 10:27 PM, Richard Gaskin wrote: > >> Is that on Dreamhost, or have you been able to reproduce it on >> another shared host? > > I have a "standby" shared account at Intersever.. thanks to your > suggestion. > I am pretty sure I did a test but maybe not. thanks for > reminding me. > > .but moving all my stuff would be a pain... I'll do a test though. I'd be interested in your results. So far we've tested on InterServer, HostGator, and JaguarPC in addition to Dreamhost, and the noticeable lag has only been evident on Dreamhost. Being a long-time Dreamhost fan like yourself I would prefer to keep using them as well, so I've been helping Phil Davis who's been stewarding this issue through DH support. It's been a long diagnostic process, but recently we may have found the root cause, and if so I would expect a fix from them shortly. I'll keep you posted with any definitive news from them. -- Richard Gaskin Fourth World Systems Software Design and Development for Desktop, Mobile, and 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
Re: LC7 & Unicode
On Thu, Mar 12, 2015 at 9:16 AM, Richard Gaskin wrote: > I'll keep you posted with any definitive news from them. > thanks, Richard -- Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words ___ 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: LC7 & Unicode
No response to my prior post, so let's try this again ... Dr Peter Brett wrote: "Internally, the LC7 engine only uses Unicode if it has to. If your application only uses native strings, then LC7 will only use native strings. Built-in Unicode support has very little to do with the fact that LC7 is slower for some workload" I don't now, and don't intend to, use Unicode. I don't want *ANY* overhead associated with a feature I don't use. How can we determine whether or not Unicode is being "used"? How does the LC7 engine detect Unicode is being used? Can we turn off that detection, thus eliminating Unicode processing? My situation: I create a "chunk" of data by concatenating binary data to "native strings". Then, I save the chunk into a large roll-your-own one-record-at-a-time "database". If LC7 is somehow automatically detecting Unicode, perhaps my "blob" of data is fooling it into thinking it's Unicode. The "blob" also includes native HTML text. Could that be involved somehow in Unicode detection? TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690247.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
> No response to my prior post, so let's try this again ... I'll give some answers as far as I understand LC7 at present, if I get something wrong no doubt someone will correct me! It wouldn't be the first time. :) > Dr Peter Brett wrote: "Internally, the LC7 engine only uses Unicode if it > has to. If your application only uses native strings, then LC7 will only > use native strings. Built-in Unicode support has very little to do with the > fact that LC7 is slower for some workload" > > I don't now, and don't intend to, use Unicode. You could try LC6.7.3 instead, as far as I'm aware it has most of the same features as LC7 apart from the native unicode. > I don't want *ANY* overhead associated with a feature I don't use. If you really need to use LC 7.x.x, then you currently have no choice, it should work fine with or without Unicode, it may be slower, but the engineers are working to improve that. > How can we determine whether or not Unicode is being "used"? I can't see any easy way to do that, but I seem to remember some people discussing it on this list a while ago, maybe somebody could chime in. > How does the LC7 engine detect Unicode is being used? I really don't know, but I'd guess it has some way to detect the number of bytes used per character. > Can we turn off that detection, thus eliminating Unicode processing? No, this has been asked several times on the list, it's part of the internal processing that LC uses and is too deeply embedded to eliminate. > My situation: I create a "chunk" of data by concatenating binary data to > "native strings". Then, I save the chunk into a large roll-your-own > one-record-at-a-time "database". If LC7 is somehow automatically detecting > Unicode, perhaps my "blob" of data is fooling it into thinking it's Unicode. If there is a problem, this sounds like the type of case that the engineers are asking to see, if you can send your stacks to them and point out where the problem lies, they should be able to pinpoint the culprit and eliminate it from future builds. You would be helping them to build a better LiveCode, then you and the rest of the LC community benefits. If you are concerned with your app security, you can email the files to them, they will even sign an NDA agreement if necessary, but they do have a strong respect for customer confidentiality. If they never get to see your files, they may never see a similar problem, we all seem to generate unique situations (problems) from time to time. > The "blob" also includes native HTML text. Could that be involved somehow > in Unicode detection? If your HTML text contains some Unicode characters, maybe that is triggering the Unicode detection. I hope you find a solution. Paul ___ 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: LC7 & Unicode
Paul: Thanks for the response. I asked: "/Can we turn off that /[Unicode]/ detection, thus eliminating Unicode processing?/" You replied: "/No, this has been asked several times on the list, it's part of the internal processing that LC uses and is too deeply embedded to eliminate/". I have been watching this forum for many moons, but usually don't have much to say. I have seen MANY questions asked about whether an option was available to turn off the Unicode "feature". I have seen the responses, all of which were negative. OK, fine. LC7 can't live without Unicode. If Unicode is what's behind the performance glitches, then that's most certainly not the answer I want to hear. But, life goes on. My question arose from Dr. Brett's claim that "/the LC7 engine only uses Unicode if it has to/". That was news to me, and it made it sound to me like the engine was somehow detecting Unicode being used. That's why I asked if we could disable that detection, and thus effectively disable Unicode processing. I envisioned a bazillion places in the engine's code where it might say "If gUnicodeGlobal is true then ... else ...". I hope there aren't a bazillion places where the engine determines it has to use Unicode, because that would require a bunch of needless CPU cycles that could be reduced to referencing a single global (like above). Perhaps my logical view of the situation was incorrect, but I (we) can hope, right? re: "/this sounds like the type of case that the engineers are asking to see/" Agreed. That sounds like the next step in the resolution of "my" problem. But, none of them responded, so I got the feeling they weren't interested. If they need some example data, I can spend the time to extrapolate some records during a test run within the IDE. However, the explanation of concatenating native strings to a few binary bytes should give them enough info to say "yes" or "no" about the engine's detection of Unicode ... which I hoped could be turned off, so no matter what info I use would bypass the Unicode processing. If that's not the case, then ... ... we're back to square one, meaning I/we have to live with Unicode's performance issues. I'm wondering how a feature like Unicode that has had a major performance impact managed to get past the initial design stage, but that's a different issue altogether. Surely somebody, somewhere foresaw this "enhancement" would be a major resource hog. TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690262.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
I think the important part of Peter Brett's answer comes after his remarks on Unicode: >> Internally, the LC7 engine only uses Unicode if it has to. If your application only uses native strings, then LC7 will only use native strings. Built-in Unicode support has very little to do with the fact that LC7 is slower for some workloads. *The cause of potential slow-down is more fundamental, and has to do with the way that variables and values in the language are handled and the way that the language is executed. * As Richard says,* some of these changes were required in order to enable the future development of the LiveCode language and to make it more flexible and powerful.* << I know no more about unicode than the next person. Perhaps being able to sell an app to 1 billion Chinese people might be beneficial to some. I can think of a Hebrew app I once wrote which was a nightmare in an earlier version of Livecode, but which would be far easier now with unicode. But all the goodness of widgets and the javascript engine and the new "DSL" language enhancements seem to me to be far more significant than unicode. I would imagine that the Livecode staff want v8+ to be no slower than version v6.x. What is coming in v8 would appear to me to be a bigger evolutionary step in the history of the engine than all the previous evolutionary steps combined. After decades of working with computers, I am struggling to think of a technology which has attempted to make such a massive step. Perhaps the difference between Mac OS 9 and OS X is the kind of shift we are going to see. Or between DOS and OS/2. Or Window 3.1 and Windows NT. With all of Apple's and Microsoft's and IBM's resources, they struggled with the performance of the early versions of their technological shift. If someone can think of a programming environment which has made an analogous shift to that which Livecode is undertaking, I'd be interested to hear. I can think of an open source database and a web application framework which made major shifts. These changes brought very little in benefit to the projects, and seemed to be vanity projects for those involved. But what Livecode are doing with v8 has obvious benefits. I really hope they succeed. Regards, Bernard On Mon, Mar 16, 2015 at 7:02 PM, TEDennis wrote: > ... we're back to square one, meaning I/we have to live with Unicode's > performance issues. > > I'm wondering how a feature like Unicode that has had a major performance > impact managed to get past the initial design stage, but that's a different > issue altogether. Surely somebody, somewhere foresaw this "enhancement" > would be a major resource hog. > > TED > > ___ 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: LC7 & Unicode
> If > Unicode is what's behind the performance glitches, then that's most > certainly not the answer I want to hear. But, life goes on. This is what I understand the LC engineers are actively working on, so hopefully there should be some performance improvements in the future. I really suspect that there's more to the performance issue than just Unicode, there have been changes to the graphics engine, AV foundation and probably lots of other code resource changes. LC7 was a total re-write over LC6, and even though it shares many of the same new features, I assume it accesses them differently, so I'd expect there to be many areas for improvements and tweaks as long as development continues. > re: "/this sounds like the type of case that the engineers are asking to > see/" > > Agreed. That sounds like the next step in the resolution of "my" problem. > But, none of them responded, so I got the feeling they weren't interested. They rarely respond to specific issues on the user list, they used to respond more often on the Dev list, but for an engineer to look at this problem you need to report it to the quality control centre [ http://quality.runrev.com ]. Even if it doesn't turn out to be a bug you may benefit from reporting it there. > ... we're back to square one, meaning I/we have to live with Unicode's > performance issues. Does LC6.7.3 not work for you until LC7 performance improves? > I'm wondering how a feature like Unicode that has had a major performance > impact managed to get past the initial design stage, but that's a different > issue altogether. Surely somebody, somewhere foresaw this "enhancement" > would be a major resource hog. I think Bernard hit the nail square on the head… >> Perhaps being able to sell an app to 1 billion Chinese people might be >> beneficial to some. Paul ___ 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: LC7 & Unicode
Bernard: I didn't see the transition in Dr. Brett's discussion to be as black and white as your interpretation. re: all the goodness of widgets and the javascript engine and the new "DSL" language enhancements seem to me to be far more significant than unicode. Agree 100%, and I am looking forward to the re-architected version (LC 8) so I can make significant changes to extend the LC base for my own purposes. Not because I need to do it, but just because LC provides the ability to do it ... and I like to play around with code. If you build it, they will come. Since the major complaints have been mostly related to Unicode, it's apparent that most everybody "out here" has been relating the performance issues to Unicode. Apparently all those references have been wrong. How did we ALL (or most of us) get to the point where we thought Unicode was the culprit? Dr. Brett's reference to "more fundamental" issues immediately followed his discussion of Unicode, so I interpreted that to mean the "/way values and variables are handled/" was also related to Unicode. I made this (possibly incorrect) subtle association because "values and variables" can themselves be Unicode. I reasoned that if Unicode wasn't involved, the impact of the "more fundamental" changes wouldn't have been so severe. In any case, we get back to my comment ... modified a bit to match your response: /I'm wondering how these LC language extensions that have had a major performance impact managed to get past the initial design stage, but that's a different issue altogether. Surely somebody, somewhere foresaw these "enhancements" would be a major resource hog./ It has been a while since LC7 hit the streets. Perhaps there were some warnings ahead of time that I didn't pay attention to, but I don't recall being "conditioned" to experience a significant performance hit. Does that mean they didn't know about those performance glitches until builders of *real* apps started using the new system? Or, was it a "damn the torpedoes, full speed ahead" scenario? TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690266.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
re: Does LC6.7.3 not work for you until LC7 performance improves? I gave up quite a while ago trying to use any version higher than 6.1 because I ran into an intermittent issue with arrays. I don't even remember what the problem was now, but that same app now works in 7.0.4. Well, it *almost* works. Unfortunately, 7.0 caused a problem with "eof" being reported when the last record in the file was read, instead of on the next read. That was a show stopper. I reported it, and they [claim to have] fixed it. The next time I "enhance" that app, I will verify the fix and use 7.x from then on. At which time I will encounter the performance glitch. Again. Sigh ... TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690269.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
On Tue, Mar 17, 2015 at 4:38 AM, TEDennis wrote: > Apparently all those references have been wrong. How > did we ALL (or most of us) get to the point where we thought Unicode was > the > culprit? > > Probably because LC7 was billed as the Unicode version and it's simple word association. The fact that a lot more was being changed under the hood seems to be brushed over and the focus returns to 'it's Unicode'. > I reasoned that if Unicode wasn't involved, the impact of the > "more fundamental" changes wouldn't have been so severe. > > And then of course the human trait not to believe what we've been told. Some people believe the World Trade Centres were a controlled demolition perpetrated by the US Gov. No matter how many times you show them videos of planes crashing into WTC 1 & 2 they wont change their mind and the theories and websites persist. People have decided that Unicode is to blame for LC 7's slowdown and although the experts have explained there are other fundamental reasons for the sluggishness, some stick with the Unicode theory. Personally I've seen very little performance hit. Certainly FAR less than when compared to upgrading my phone from iOS 7 to iOS 8 - but then again Apple wouldn't let such a performance hit get past the design phase would they - unless of course you call it Lion, Mountain Lion, Mavericks or Yosemite. Yes, within the IDE I do notice an occasional lethargy, but once I build a standalone I can't see what all the fuss is about. I do accept though that other people's millage may vary, but regardless my own 'theory' is: I've never seen so much time and effort put into improving LC than has occurred since the success of the Kick Starter campaign. I've never seen so many posts by Runrev employees, including Kevin, on this LIst, as there've been since the IKS campaign. I've not seen so many bug squashed and such a determination to exterminate them as is currently the case. Now is the ONLY time I've ever noted users posting a bug they've recorded at the QQC and withn days post again that it's been fixed and then at the next release a grateful post as to how responsive Runrev have been. I can not fathom the extra code, time and effort that will be required to bring us LC 8. I do know that it is impossible to get there without some kind of performance hit, but be that as it may if there is some way, any way to reduce that performance hit then Runrev will make every effort to achieve it AND if anyone actually comes up with a VALID way to improve the code and improve the performance, Runrev will happily implement it for the benefit of everyone: users and the company bottom line. ___ 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: LC7 & Unicode
Kay C Lan: Well, I'm glad you got that off your chest. Feel better? It seems you have an emotional tie to somebody or something at RunRev. It could simply be that your years of Revolution/LiveCode usage has created a strong loyalty. Whatever ... It's likely your view is somewhat biased towards the positive. re: I've never seen so much time and effort put into improving LC than has occurred since the success of the Kick Starter campaign. I sure hoped that would be the case, and that's why I donated to the KS campaign. I have been using Rev/LC since 2007. It has great potential, and I want to see that potential realized. Not just for myself in my own post-career software projects, but for newbies just dipping their toes into the very complex world of software development. LC8 *should* prepare the way for a more robust ... and STABLE ... product. re: Apple wouldn't let such a performance hit get past the design phase would they - unless of course you call it Lion, Mountain Lion, Mavericks or Yosemite. Your comparison of the relative complexities of LC's application development platform and Apple's full blown operating system is almost comical. But, that discussion is beyond the scope of this forum. I am, and will continue to be, a supporter of this company and its goals. But, that doesn't mean I have to sit by quietly and let issues that affected an entire user community go by with nary a comment. And there you have it. TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690286.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
Cogent comments, all. One of the functions of this community, I believe, is to support and encourage the livecode dev team, and each other. Another equally important function is to provide honest feedback and a kick in the pants when it seems to be needed. I love the direction the team is going. Are they perfect in every aspect? No. Is that normal? Yes. Do the need us to call out problems? Yes. For me, the worst thing is to create software that gets used, but get no feedback, good or bad. Best wishes to all on the list and to those at Livecode who are working hard to create the best product they can. Bill William Prothero http://es.earthednet.org > On Mar 17, 2015, at 7:55 AM, TEDennis wrote: > > Kay C Lan: Well, I'm glad you got that off your chest. Feel better? > > It seems you have an emotional tie to somebody or something at RunRev. It > could simply be that your years of Revolution/LiveCode usage has created a > strong loyalty. Whatever ... It's likely your view is somewhat biased > towards the positive. > > re: I've never seen so much time and effort put into improving LC than has > occurred since the success of the Kick Starter campaign. > > I sure hoped that would be the case, and that's why I donated to the KS > campaign. I have been using Rev/LC since 2007. It has great potential, and > I want to see that potential realized. Not just for myself in my own > post-career software projects, but for newbies just dipping their toes into > the very complex world of software development. LC8 *should* prepare the > way for a more robust ... and STABLE ... product. > > re: Apple wouldn't let such a performance hit get past the design phase > would they - unless of course you call it Lion, Mountain Lion, Mavericks or > Yosemite. > > Your comparison of the relative complexities of LC's application development > platform and Apple's full blown operating system is almost comical. But, > that discussion is beyond the scope of this forum. > > I am, and will continue to be, a supporter of this company and its goals. > But, that doesn't mean I have to sit by quietly and let issues that affected > an entire user community go by with nary a comment. > > And there you have it. > > TED > > > > -- > View this message in context: > http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690286.html > Sent from the Revolution - User mailing list archive at Nabble.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: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: LC7 & Unicode
TEDennis wrote: Kay C Lan: Well, I'm glad you got that off your chest. Feel better? It seems you have an emotional tie to somebody or something at RunRev. It could simply be that your years of Revolution/LiveCode usage has created a strong loyalty. Whatever ... It's likely your view is somewhat biased towards the positive. One man's "bias toward the positive" is another man's "bias toward the productive". :) I thought Kay's post lent a welcome balance to the discussion. But before we rush into "Richard's an apologist fanboy!" (the former is not the case, but I'll gladly admit the latter), let's see if we can avoid ad hominem altogether and instead look at Kay's comments on their own merit. For example, the reference to iOS 8 is a good and fair one, IMO: The transition from LiveCode v6 to v7 was in many ways similar in scope to Apple's migration from OS 9 to OS X, yet even with the relatively modest scope of change in iOS 8 we saw one of the wealthiest and most powerful multinationals in the world stumble, and have to release 8.0.1 shortly after - and then it was discovered that 8.0.1 had critical issues, and rushed 8.0.2 out right after. This isn't to suggest that Apple fell down on the job. It's just a healthy reminder that sometimes software engineering is less trivial than we might prefer. re: Apple wouldn't let such a performance hit get past the design phase would they - unless of course you call it Lion, Mountain Lion, Mavericks or Yosemite. Your comparison of the relative complexities of LC's application development platform and Apple's full blown operating system is almost comical. But, that discussion is beyond the scope of this forum. Such a perspective may actually be a point in LiveCode's favor: LiveCode is far more complex than just about any consumer app; it really does have much more in common with an OS or virtual machine. It's a sort of meta-OS, allowing us to write apps to a single API which then get translated across a range of OS APIs that few developers of even simple consumer apps dare to attempt. It would seem LiveCode's been doing a pretty good job if we find ourselves with a perspective that lets us take this level of effort for granted. If we look at just one small corner of that, the pulsing default button on OS X, we'd see a level of effort deeper than I care to write here but suffice to say nothing in the OS APIs supports what LiveCode allows its users to do with that. And that's just one very small corner of one of seven platforms LiveCode deploys to. Of course our participation in improving the quality of the tools we rely on is essential, and it benefits no one to whitewash areas of actual concern. But I won't hold it against Kay or anyone else if they enjoy using LiveCode. I certainly wouldn't feel compelled to dismiss their thoughts as "emotional", any more than I would dismiss complaints on such grounds. To move forward productively it's helpful to look at what's working and not working based on our own direct experience. This may be a good example: I am, and will continue to be, a supporter of this company and its goals. But, that doesn't mean I have to sit by quietly and let issues that affected an entire user community go by with nary a comment. "Entire user community" is pretty big, and neither Kay nor anyone else has suggested no one report bugs. Since I migrated my work to v7 I find I'm working at least as productively as under v6.x, in some ways more so given the effort Fraser put in with GDK integration and that I spend nearly half of my time these days on Ubuntu (most of the rest on Mac and a bit on Windows, FWIW). But I can't presume to speak for everyone, and more importantly I don't believe any single one of us can. I know firsthand many who are enjoying v7. Sure, like all previous versions, and like nearly all software ever written, it has bugs. But the degree to which bugs specific to v7 are preventing anyone from using it has not been clearly defined, and seems likely to be as frequently the result of social memetics than actual firsthand experience. In fact, I think Kay's observation about human nature here is relevant: "And then of course the human trait not to believe what we've been told." This is not to dismiss actual bugs, but it does help remind us that readers of this list enjoy a great many repetitive posts about a relatively small number of issues from an even smaller number of posters. When we look at the community's discussion as a whole, the number of actual issues is far small than the many posts about them. So let's find issues and report them. And when we have trouble pinning down a recipe, lets explore the issue here and work together to find the recipe that will make it reproducible for the team, and thus fixable. But let's also try to maintain a perspective of actual scope here, relying more often on what we've seen for ourselves ra
Re: LC7 & Unicode
Richard: re: I thought Kay's post lent a welcome balance to the discussion. Good for you. It's all in perspective. The tone of Kay's post certainly didn't sound like a "welcome balance" to me. It sounded condescending, so I responded in kind. Trust me, that was far milder than what I felt like saying. re: "Entire user community" is pretty big, and neither Kay nor anyone else has suggested no one report bugs. Nor did I. My comment was about me, and my reluctance to keep strong feelings under wraps. Especially since I've already been doing that. For a long time. I spent a very successful career developing big bux big iron software, all the way from programming low level operating system interfaces (including assisting IBM with some of their early operating systems) to high level management. I know software is a tough job. My involvement in this thread started with a desire for clarification of a claim made by one of the developers (?) which made it sound like LC was determining all by its lonesome that Unicode was being used. If that were the case, and we could disable that auto-determination, I would readily use it as an "easy" way out of a situation that affects my application. Sometimes the developers are so close to their baby that they overlook some obvious alternatives. Was that the case here? I don't know. And I still don't. I doubted it when I first conceived the notion, but I would have been amiss by not mentioning it with the hopes of being a help to myself and others in the community. re: But let's also try to maintain a perspective of actual scope here, relying more often on what we've seen for ourselves rather than what we heard from someone who who heard it from someone else. If you can review the comments here and on other forums and come to the conclusion that Unicode support did not impact the "Entire User Community" at some level, then we will have to agree to disagree. I know for a FACT that it impacted my app in a negative manner, and I explained the circumstances. A simple answer to a simple question would have short circuited this discussion many posts ago. re: Have you submitted it? [the "eof" bug]. If not, do you have a sample script I might use to verify the issue and submit it for you? I submitted it, complete with a detailed script/recipe. It was accepted as a bug, and they [claim to have] fixed it. When I need to enhance that app, I will verify it. TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690301.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
On 17/03/2015 18:19, TEDennis wrote: re: Have you submitted it? [the "eof" bug]. If not, do you have a sample script I might use to verify the issue and submit it for you? I submitted it, complete with a detailed script/recipe. It was accepted as a bug, and they [claim to have] fixed it. When I need to enhance that app, I will verify it. We all have our own way of working, but . if I had reported a bug which - had a serious impact on an app of mine - has been claimed to be fixed - and I had any doubt about that fix then I would verify it (or confirm its non-fixed status and re-report) so that when I needed to enhance my app, I would be confident it would work. Alex. ___ 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: LC7 & Unicode
You're right. Everybody has their own way of working. I have no reason to doubt they fixed it, considering the detailed self-validating script I submitted. However, I will most certainly verify it in my own app when I enhance that app. If it fails for some reason at that point in time, then there's probably a different, albeit related, bug that needs to be researched, documented, and submitted. Hopefully by the time I need to enhance the app, 7.x's performance will have improved. Combining that with a show stopper glitch having been fixed, will be cause for dancing in the aisles. Currently, I have no reason to open up the app. In the meantime, any other community members who use 7.x can benefit from a fix of a glitch in file read processing they don't even know they have. TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690306.html Sent from the Revolution - User mailing list archive at Nabble.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: LC7 & Unicode
On Mon, Mar 16, 2015 at 11:13 PM, Kay C Lan wrote: > Some people believe the World Trade Centres were a controlled demolition > perpetrated by the US Gov. No matter how many times you show them videos of > planes crashing into WTC 1 & 2 they wont change their mind and the theories > and websites persist. People have decided that Unicode is to blame for LC > This is especially a really bad analogy. Some people and 1100 Engineers and architects who say steel buildings don't collapse by a jet fuel fire. There are false flags all around us. But people believe what they are told by 'official investigations'. sorry, this irked me. you opened the door. -- Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words ___ 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
