Re: Suggestion: Non-Appbuilding Community Edition
Hi Kevin, Thanks for acknowledging that you received it! I will compile a video of the problems, but will happily schedule a zoom and talk about some other things as well. I should have a video compiled within 1 week, since i'll still be using it all week long. Thanks Kevin, Tom On Fri, Sep 3, 2021 at 10:07 AM Kevin Miller via use-livecode < use-livecode@lists.runrev.com> wrote: > What I liked about your email to me Tom was that it was extremely > specific. You had just a handful of issues you considered absolutely key > and offered to Zoom to show that to me. I look forward to scheduling that > once I finish getting unburried __ > > Kind regards, > > Kevin > > Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ > LiveCode: Develop Yourself > > On 02/09/2021, 22:59, "use-livecode on behalf of Tom Glod via > use-livecode" use-livecode@lists.runrev.com> wrote: > > Lagi, > > I wrote to Kevin earlier and gave the exact same advice. those exact 2 > points needing to be addressed. > > Give long trial, fix the most obvious IDE issues ASAP. > > Without those two things how is any new developer going to join the > platform? > > > > On Thu, Sep 2, 2021 at 5:34 PM Lagi Pittas via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > Trials of 14 days or even 30 days are a waste of time. I can install > > something and use it for a couple of days - then life / work gets in > the > > way > > so It sits on the computer for 31 days and then times out. > > > > You then have to waste your time and the companies to get an > extension, > > and by the time they answer > > you get cheesed off and remove the program. > > > > The BEST trial is the one that lasts for 30 actual executions or 6 > months > > (whichever comes first). > > > > This stops the clever SOD who decides to keep it running without > exiting > > for 6 months but it times out anyway. > > Even better if he keeps it on for 2 days it counts as "executing" > twice so > > it will last 30 days. > > > > This means I have 30 days over a 6 month period to really test it > without > > rushing. > > > > The people who would game the system are the people who won't be > loyal > > customer anyway, so not giving a worthwhile trial period handicaps > those > > who want to give it a good try. > > > > You can also put a nag screen at the start of any executable with > an OK > > button link to a special discounted price - free marketing (what a > > brilliant Idea, why didn't I think of it?). > > > > But the best way of selling it is to FIX the bloody IDE - I am > running on a > > 16G 1 year Old 8th Generation CoreI7 processor and it STILL runs > like > > treacle. > > > > If I downloaded it today as a new person it would be off my machine > in less > > than 30 minutes. > > > > You could also use this as your "marketing" system by "giving it > away" to > > schools for nothing and without the trial period but the nag screen. > > > > It can then be used by the students to learn programming at no cost > - and > > some of the students parent might pony up for a paid for version at a > > student price (with no expiring standalones of cours - the most > stupid idea > > of the lot so far) > > > > > > Anyway Kevin, have I/we wastedour time again putting out these > cranky, > > stupid and not workable suggestions?. > > > > Lagi > > > > > > > > > > > > > > > > On Thu, 2 Sept 2021 at 15:55, Kevin Miller via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > We *are* considering the length of the trial actively, we may well > give a > > > longer trial a shot at some point. > > > > > > Kind regards, > > > > > > Kevin > > > > > > Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ > > > LiveCode: Develop Yourself > > > > > > On 02/09/2021, 15:51, "use-livecode on behalf of Ralph DiMola via > > > use-livecode" > > use-livecode@lists.runrev.com> wrote: > > > > > > True, true. > > > > > > There could be a small group of programmers that pass a stack > around > > > but you would not be able to convince/teach a civilian to install a > > > programming IDE and explain how to run the stack along with any > other > > > supporting files, SW or plug-ins... Mobile would be a non-starter. > I > > would > > > not dismiss this out-of-hand. A 90 day free IDE could also be an > option. > > > > > > Ralph DiMola > > > IT Director > > > Evergreen Information Services > > > rdim...@evergreeninfo.net > > > > > > > > > -Original Message- > > > From: use-livecode [mailto: > use-livecode-boun...@lists.runrev.com] On > > > Behalf Of
Re: Text encoding: summary of results and times.
I went back and re-did the tests, checking on the results. The file *is* UTF8, so I need to textDecode() it; if I don't, the result are simply wrong, and so the times are irrelevant. 1. Once it has been textDecoded(), i.e. is in internal format, and I run my algorithm it gets the correct results, taking 115.1 seconds. 2. BUT, if just before the algorithm is run, I do a textEncode(tStr, "UTF8") , it gets the correct results (identical to the above), but in only 3.3 seconds. The code, in a zip file containing the test stack, SpellCheck Library, and the 'bible' and "war" sample textfiles, can be downloaded from https://www.tweedly.org/Downloads/SpellLib.gz if anyone wants to look at it. Alex. On 03/09/2021 13:38, Alex Tweedly via use-livecode wrote: On 03/09/2021 11:07, David V Glasgow via use-livecode wrote: Alex states that put textEncode(tWHoleText, "UTF8") into tWholeText speeds replace up, but David B says LC internal format is UTF16. Doesn’t the 8 vs 16 difference matter? Or matters less than other encodings? I would regard that timing comparison with much suspicion. I was textEncoding() it inappropriately - I had just read it in from a file, so I *should* have been textDecoding() it. Therefore it is unclear whether the times I was seeing then are meaningful. 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 ___ 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: Suggestion: Non-Appbuilding Community Edition
In one word: DreamCard! :D Mark Schonewille Economy-x-Talk KvK 50277553 VAT NL002099948B21 https://ecxtalk.nl https://www.nt2.nu Programming LiveCode for the Real Beginner http://www3.economy-x-talk.com/file.php?node=programming-livecode-for-the-real-beginner Op 2-9-2021 om 15:49 schreef Michael Kristensen via use-livecode: Hi there I suggest that there could be a Non-Appbuilding Community Edition That would be for personal use, and to learn coding. Michael ___ 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: Random crash when building standalone
On 9/3/21 3:53 AM, Ludovic THEBAULT via use-livecode wrote:
Hello,
When I build a Windows or macOS standalone, I sometimes have several alerts that concern the "livecode's
stacks" ("answer dialog", "print chooser" ...) that are saved in the standalone (but
I don't want them to be!) and that conflict with the original stacks.
And rarely it ends with a livecode crash.
These "livecode stack's" are also added as substacks in my stacks...
This seems to be related to "old stacks".
I can't find any bug report about this but maybe I didn't look hard enough
I've seen this before with stacks that were originally built with MC, where you had to include
ask and answer stacks manually into the mainstack. I've also heard about these inclusions once
or twice in LC but I'm not sure what would cause that.
From the message box, do: put the substacks of stack "myMainStack"
If the ask/answer dialogs are there, then you can delete them:
delete stack "answer dialog" of stack "myMainStack"
delete stack "ask dialog" of stack "myMainStack"
Be sure to include the reference to your mainstack, since otherwise you might delete the one in
the IDE. That's no a permanent problem but it won't solve your issue.
You might also be able to do the same thing in the project browser, but I usually use the
message box.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.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: Sorting text is *VERY* slow in LC9 on Windows (Re: Accumulating text is *VERY* slow in LC9 on Windows)
I'm very much hoping that Mark W might magically fix this in 9.6.5. But in the meantime FWIW, the place where this was really hurting (in a script that took 8 minutes under LC6, was taking 8 hours under LC9, but I've gradually tamed it down to under an hour by buffering the large accumulations) was a single sort command, on 70 MB of data in approx 223,000 lines. I've replaced this line: sort lines of tNewTable by item iSortCol of each which took 1 second on Mac, 2063 seconds (i.e. 34 minutes) on Windows, with a call to this command command sortLinesByTabbedColumn @tTable, iSortCol local aTable, tSortTable, iARcounter, tARbuffer, tRow, k -- load table into an array for fast access by line number put tTable into aTable split aTable using return -- compile index of just the column to sort on, and line number set the itemDelimiter to tab repeat for each key k in aTable get (item iSortCol of aTable[k]) && k appendRow it, iARcounter, tARbuffer, tSortTable end repeat put tARbuffer after tSortTable -- sort it sort lines of tSortTable -- rebuild table out of array, in sorted order put empty into tARbuffer put empty into tTable repeat for each line tRow in tSortTable put last word of tRow into k appendRow aTable[k], iARcounter, tARbuffer, tTable end repeat put tARbuffer after tTable end sortLinesByTabbedColumn which takes 25 seconds on Windows (to my surprise, most of that time was in the final 'rebuild' loop). On 02/09/2021 23:53, Bob Sneidar via use-livecode wrote: I am going to say no, because you still have to traverse the file once to get it into sqLite, then do the sort, then write out the file when done. I might be mistaken, the subsequent SQL sort may make up for lost time. Using a memory SQL really shines when you need to make multiple passes at the data using different queries. One pass may not impress you much. For instance, I have a File Management module built into my application. A file can belong to a customer, and also to a site, and also to a device. Like so: custid siteid deviceidfilepath 123 disk/folder/file1 456 098 disk/folder/file2 789 765 432 disk/folder/file3 Note all have a custid, some have a siteid as well, and some also have a deviceid. So rather than query mySQL for the files for each site or device as I select them, I instead, upon selecting a customer, query mySQL for ALL the file records for that customer, (which of course contain the file records for all the sites and devices), then store that in a memory database. Then when a different site or device belonging to that customer is selected, I query the memory database for those belonging to that site, or that device in those modules respectively. The performance enhancement is significant. Another way I apply this is to get the objects on a card passing a list of properties I'm interested in, then store the data in a memory database. I can then query for objects with certain properties without having to iterate through all the objects on a card in a repeat loop. For instance, the farthest left, top, right and bottom object whose visible is true in 4 memory db queries, giving me the total rect of all the visible objects without grouping/ungrouping and the hell that can ensue. Bob S On Sep 2, 2021, at 11:22 , Bernard Devlin via use-livecode wrote: Whilst waiting for a fix, would a temporary solution be to use sqlite to create an in-memory database and let sqlite do the sorting for you? Regards, Bernard. On Mon, Aug 30, 2021 at 8:23 PM Ben Rubinstein via use-livecode < use-livecode@lists.runrev.com> wrote: Thanks to Mark Waddingham's advice about using a buffer var when accumulating a large text variabel in stages, I've now got a script that took 8 hours under LC9, and (8 minutes under LC6) down by stages to just under 1 hour under LC9. However I have some remaining issues not amenable to this approach; of which the most significant relates to the sort command. In all cases it seems to take much longer under LC9 than it did under LC6; although the factor is quite variable. The most dramatic is one instance, in which this statement: sort lines of tNewTable by item iSortCol of each takes 35 minutes to execute. `tNewTable` is a variable consisting of some 223,000 lines of text; approx 70MB. The exact same statement with the same data on the same computer in LC6 takes just 1 second. Has anyone else noticed something of this sort? As I said, the effect varies: e.g. 54 seconds versus 1 second; 22 seconds versus 1 second. So it may not be so noticeable in all cases.
Re: Suggestion: Non-Appbuilding Community Edition
What I liked about your email to me Tom was that it was extremely specific. You had just a handful of issues you considered absolutely key and offered to Zoom to show that to me. I look forward to scheduling that once I finish getting unburried __ Kind regards, Kevin Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ LiveCode: Develop Yourself On 02/09/2021, 22:59, "use-livecode on behalf of Tom Glod via use-livecode" wrote: Lagi, I wrote to Kevin earlier and gave the exact same advice. those exact 2 points needing to be addressed. Give long trial, fix the most obvious IDE issues ASAP. Without those two things how is any new developer going to join the platform? On Thu, Sep 2, 2021 at 5:34 PM Lagi Pittas via use-livecode < use-livecode@lists.runrev.com> wrote: > Trials of 14 days or even 30 days are a waste of time. I can install > something and use it for a couple of days - then life / work gets in the > way > so It sits on the computer for 31 days and then times out. > > You then have to waste your time and the companies to get an extension, > and by the time they answer > you get cheesed off and remove the program. > > The BEST trial is the one that lasts for 30 actual executions or 6 months > (whichever comes first). > > This stops the clever SOD who decides to keep it running without exiting > for 6 months but it times out anyway. > Even better if he keeps it on for 2 days it counts as "executing" twice so > it will last 30 days. > > This means I have 30 days over a 6 month period to really test it without > rushing. > > The people who would game the system are the people who won't be loyal > customer anyway, so not giving a worthwhile trial period handicaps those > who want to give it a good try. > > You can also put a nag screen at the start of any executable with an OK > button link to a special discounted price - free marketing (what a > brilliant Idea, why didn't I think of it?). > > But the best way of selling it is to FIX the bloody IDE - I am running on a > 16G 1 year Old 8th Generation CoreI7 processor and it STILL runs like > treacle. > > If I downloaded it today as a new person it would be off my machine in less > than 30 minutes. > > You could also use this as your "marketing" system by "giving it away" to > schools for nothing and without the trial period but the nag screen. > > It can then be used by the students to learn programming at no cost - and > some of the students parent might pony up for a paid for version at a > student price (with no expiring standalones of cours - the most stupid idea > of the lot so far) > > > Anyway Kevin, have I/we wastedour time again putting out these cranky, > stupid and not workable suggestions?. > > Lagi > > > > > > > > On Thu, 2 Sept 2021 at 15:55, Kevin Miller via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > We *are* considering the length of the trial actively, we may well give a > > longer trial a shot at some point. > > > > Kind regards, > > > > Kevin > > > > Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ > > LiveCode: Develop Yourself > > > > On 02/09/2021, 15:51, "use-livecode on behalf of Ralph DiMola via > > use-livecode" > use-livecode@lists.runrev.com> wrote: > > > > True, true. > > > > There could be a small group of programmers that pass a stack around > > but you would not be able to convince/teach a civilian to install a > > programming IDE and explain how to run the stack along with any other > > supporting files, SW or plug-ins... Mobile would be a non-starter. I > would > > not dismiss this out-of-hand. A 90 day free IDE could also be an option. > > > > Ralph DiMola > > IT Director > > Evergreen Information Services > > rdim...@evergreeninfo.net > > > > > > -Original Message- > > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On > > Behalf Of Kevin Miller via use-livecode > > Sent: Thursday, September 02, 2021 10:31 AM > > To: How to use LiveCode > > Cc: Kevin Miller; Michael Kristensen > > Subject: Re: Suggestion: Non-Appbuilding Community Edition > > > > Thanks for the constructive suggestion. Unfortunately with a free > > non-app building version, everyone who needs to run an app can just > > download that. > > > > Kind regards, > > > > Kevin > > > > Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ > > LiveCode: Develop Yourself > > > > On 02/09/2021, 14:49, "use-livecode on behalf of Michael
Re: Suggestion: Non-Appbuilding Community Edition
There are some good suggestions here around the Lagi, thank you. We will certainly be exploring ways to make that experience just right in the coming days. Kind regards, Kevin Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ LiveCode: Develop Yourself On 02/09/2021, 22:33, "use-livecode on behalf of Lagi Pittas via use-livecode" wrote: Trials of 14 days or even 30 days are a waste of time. I can install something and use it for a couple of days - then life / work gets in the way so It sits on the computer for 31 days and then times out. You then have to waste your time and the companies to get an extension, and by the time they answer you get cheesed off and remove the program. The BEST trial is the one that lasts for 30 actual executions or 6 months (whichever comes first). This stops the clever SOD who decides to keep it running without exiting for 6 months but it times out anyway. Even better if he keeps it on for 2 days it counts as "executing" twice so it will last 30 days. This means I have 30 days over a 6 month period to really test it without rushing. The people who would game the system are the people who won't be loyal customer anyway, so not giving a worthwhile trial period handicaps those who want to give it a good try. You can also put a nag screen at the start of any executable with an OK button link to a special discounted price - free marketing (what a brilliant Idea, why didn't I think of it?). But the best way of selling it is to FIX the bloody IDE - I am running on a 16G 1 year Old 8th Generation CoreI7 processor and it STILL runs like treacle. If I downloaded it today as a new person it would be off my machine in less than 30 minutes. You could also use this as your "marketing" system by "giving it away" to schools for nothing and without the trial period but the nag screen. It can then be used by the students to learn programming at no cost - and some of the students parent might pony up for a paid for version at a student price (with no expiring standalones of cours - the most stupid idea of the lot so far) Anyway Kevin, have I/we wastedour time again putting out these cranky, stupid and not workable suggestions?. Lagi On Thu, 2 Sept 2021 at 15:55, Kevin Miller via use-livecode < use-livecode@lists.runrev.com> wrote: > We *are* considering the length of the trial actively, we may well give a > longer trial a shot at some point. > > Kind regards, > > Kevin > > Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ > LiveCode: Develop Yourself > > On 02/09/2021, 15:51, "use-livecode on behalf of Ralph DiMola via > use-livecode" use-livecode@lists.runrev.com> wrote: > > True, true. > > There could be a small group of programmers that pass a stack around > but you would not be able to convince/teach a civilian to install a > programming IDE and explain how to run the stack along with any other > supporting files, SW or plug-ins... Mobile would be a non-starter. I would > not dismiss this out-of-hand. A 90 day free IDE could also be an option. > > Ralph DiMola > IT Director > Evergreen Information Services > rdim...@evergreeninfo.net > > > -Original Message- > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On > Behalf Of Kevin Miller via use-livecode > Sent: Thursday, September 02, 2021 10:31 AM > To: How to use LiveCode > Cc: Kevin Miller; Michael Kristensen > Subject: Re: Suggestion: Non-Appbuilding Community Edition > > Thanks for the constructive suggestion. Unfortunately with a free > non-app building version, everyone who needs to run an app can just > download that. > > Kind regards, > > Kevin > > Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ > LiveCode: Develop Yourself > > On 02/09/2021, 14:49, "use-livecode on behalf of Michael Kristensen > via use-livecode" use-livecode@lists.runrev.com> wrote: > > Hi there > > I suggest that there could be a Non-Appbuilding Community Edition > > That would be for personal use, and to learn coding. > > Michael > > ___ > 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 >
IDE performance (Re: Suggestion: Non-Appbuilding Community Edition)
I was wondering this too: when Lagi mentioned 'fix the IDE' I thought this might be a reference to some of a number of usabiity snags - it didn't occur to me that it was just speed. I develop on a nine-year old MacBook and have never noticed a speed issue with the IDE. I wonder if it's possible that the Windows IDE has been affected by the same issue to do with manipulating quantities of text that I've been talking about on the list, which Mark W has suggested might be fixed in a release very shortly? (Seems unlikely!) But definitely seems to be something platform specific. Lagi, if you're still able to access a 6.7 installer, could you confirm whether the IDE under 6.7 has the same problem on your set up? The problems with speed on Windows that I'm seeing came in after 6.7. Ben On 03/09/2021 03:05, Sean Cole (Pi) via use-livecode wrote: Hi Lagi, I have the LC IDE running on a remote Windows Server with 1 core (2Ghz) and 2GB ram. It struggles at times but is still usable (truly amazingly). Otherwise, I run it on Windows through Parallels Desktop with VM 8 cores and 8GB on an 8core 32GB Macbook Pro. Saving a stack takes 15 times longer in Win compared to the same machine in macOS. Other than the slight lag and bugginess of the script editor this is the only slowness I see. Unicode slows down some procedures but that is not limited to the IDE. I hope you can work out what is slowing it down to treacle speeds for you. It sounds a bit odd to me. On Fri, 3 Sept 2021 at 00:16, Bernard Devlin via use-livecode < use-livecode@lists.runrev.com> wrote: But the best way of selling it is to FIX the bloody IDE - I am running on a 16G 1 year Old 8th Generation CoreI7 processor and it STILL runs like treacle. << As I don't recognize this experience can you put a video of your experience on the cloud? I don't run on hardware anything like as beefy as you have. The only machine I've got where LC is slow is one where Windows itself is really slow (a 4yo laptop). On my two Apple machines (M1 and Intel, the latter is 5yo) it is not "like treacle", neither is it slow on my i5 Windows machine. It's a bit hard for LC Ltd to identify and fix something if it's only found in some odd cases. Regards, Bernard On Thu, Sep 2, 2021 at 10:34 PM Lagi Pittas via use-livecode < use-livecode@lists.runrev.com> wrote: Trials of 14 days or even 30 days are a waste of time. I can install something and use it for a couple of days - then life / work gets in the way so It sits on the computer for 31 days and then times out. You then have to waste your time and the companies to get an extension, and by the time they answer you get cheesed off and remove the program. The BEST trial is the one that lasts for 30 actual executions or 6 months (whichever comes first). This stops the clever SOD who decides to keep it running without exiting for 6 months but it times out anyway. Even better if he keeps it on for 2 days it counts as "executing" twice so it will last 30 days. This means I have 30 days over a 6 month period to really test it without rushing. The people who would game the system are the people who won't be loyal customer anyway, so not giving a worthwhile trial period handicaps those who want to give it a good try. You can also put a nag screen at the start of any executable with an OK button link to a special discounted price - free marketing (what a brilliant Idea, why didn't I think of it?). But the best way of selling it is to FIX the bloody IDE - I am running on a 16G 1 year Old 8th Generation CoreI7 processor and it STILL runs like treacle. If I downloaded it today as a new person it would be off my machine in less than 30 minutes. You could also use this as your "marketing" system by "giving it away" to schools for nothing and without the trial period but the nag screen. It can then be used by the students to learn programming at no cost - and some of the students parent might pony up for a paid for version at a student price (with no expiring standalones of cours - the most stupid idea of the lot so far) Anyway Kevin, have I/we wastedour time again putting out these cranky, stupid and not workable suggestions?. Lagi On Thu, 2 Sept 2021 at 15:55, Kevin Miller via use-livecode < use-livecode@lists.runrev.com> wrote: We *are* considering the length of the trial actively, we may well give a longer trial a shot at some point. Kind regards, Kevin Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/ LiveCode: Develop Yourself On 02/09/2021, 15:51, "use-livecode on behalf of Ralph DiMola via use-livecode" wrote: True, true. There could be a small group of programmers that pass a stack around but you would not be able to convince/teach a civilian to install a programming IDE and explain how to run the stack along with any other supporting files, SW or plug-ins... Mobile would be a non-starter. I would not dismiss this out-of-hand. A 90
Re: Text encoding.
I always have to double check this as well. I think the point is that LC knows what its internal format is, but doesn't know what the source format is. So you always have to specify the 'external' format, but never the internal one. With that in mind, it feels (at least in my language instincts) that if you're changing it out of the specified format, that's decoding; and vice versa. You have have to decode the text from UTF8 (or whatever) into the internal format; and encode it from the internal format into UTF8 (or whatever). Ben On 03/09/2021 03:55, J. Landman Gay via use-livecode wrote: I made the same mistake at first. The concepts felt backward to me, it seemed like we should encode text into the format we were aiming for. So If I wanted UTF16 I should encode it that way. If I wanted UTF8 for outbound text I should decode the UTF16 that LC uses. When the receiving server scripts went haywire I finally figured it out, but not before the Rails programmer wrote code to undo the gibberish I was sending. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 2, 2021 7:55:45 PM Alex Tweedly via use-livecode wrote: i.e.I encoded it on the way in. It should have been put textDecode(pStr, "UTF8") into pStr With that changed, my tiny test script works properly ___ 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: Bye, and thanks for the fish
Excuses for my typos. Kevin ofcourse. Met vriendelijke groet, Erik Beugelaar From: e.beugel...@me.com Sent: Friday, September 3, 2021 3:39:54 PM To: How to use LiveCode Subject: Re: Bye, and thanks for the fish About this I can say it is really true. I am supporting LiveCode from 2012 and never had the time to program a single word in it... but I loved the filosophy. I only did a review for Packt Publishing. There is hope!!! Blame me not to write any code till yet ;-) but the people behind LiveCode are honest, great, intelligent and always willing to help you out. So hive it a try and just call the HQ, Heather or Kelvin will sort it out if u hv license or financial problems to obtain a new license offer. Nice weekend to you all. Met vriendelijke groet / kind regards Erik Beugelaar From: use-livecode on behalf of J. Landman Gay via use-livecode Sent: Thursday, September 2, 2021 5:36:28 AM To: How to use LiveCode Cc: J. Landman Gay Subject: Re: Bye, and thanks for the fish This situation is the kind of thing that Kevin encourages you to contact support about. He's said he doesn't want to lose anyone. It's true that open source has made things difficult for the company, but they also value the folks who have stood by them all this time. Please do write to Heather. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 1, 2021 7:54:16 PM Neville Smythe via use-livecode wrote: >> On 1 Sep 2021, at 11:36 pm, use-livecode-requ...@lists.runrev.com wrote: >> >> i am not sure, if everyone is aware of it, but standalones that were >> created with the Starter Plan license will expire as soon as the Startert >> Plan subscription expires. > > Not even Apple is that rapacious. > > I used to have a commercial licence back when I was selling stuff (although > the economics of software never made sense). Since retiring I have been > “freeloading" with the Community edition as a hobbyist, my only LC uses > being for personal use, and maintaining admin and operating software I > wrote for a not-for-profit sporting organisation, and occasionally > contributing bug reports. I can well understand the need for LC to move to > a profitable basis, and I would be happy buy a plan if it made sense for > our use, but there is no way my NFP association can afford US$1000 every > year - or even one year (we would use 3 platforms, and not even the Server > is thrown in with the desktop platforms). And a Starter Kit that means the > app would stop working when I pass on (I have been around since Hypercard > day 1) is an insult. Seems to me the hobbyist use of LC has come to an end. > A great pity, but I guess times move on. > > I have greatly enjoyed being part of this (mostly) friendly and generous > community for many years. > > Neville Smythe > > ___ > 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: Bye, and thanks for the fish
About this I can say it is really true. I am supporting LiveCode from 2012 and never had the time to program a single word in it... but I loved the filosophy. I only did a review for Packt Publishing. There is hope!!! Blame me not to write any code till yet ;-) but the people behind LiveCode are honest, great, intelligent and always willing to help you out. So hive it a try and just call the HQ, Heather or Kelvin will sort it out if u hv license or financial problems to obtain a new license offer. Nice weekend to you all. Met vriendelijke groet / kind regards Erik Beugelaar From: use-livecode on behalf of J. Landman Gay via use-livecode Sent: Thursday, September 2, 2021 5:36:28 AM To: How to use LiveCode Cc: J. Landman Gay Subject: Re: Bye, and thanks for the fish This situation is the kind of thing that Kevin encourages you to contact support about. He's said he doesn't want to lose anyone. It's true that open source has made things difficult for the company, but they also value the folks who have stood by them all this time. Please do write to Heather. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 1, 2021 7:54:16 PM Neville Smythe via use-livecode wrote: >> On 1 Sep 2021, at 11:36 pm, use-livecode-requ...@lists.runrev.com wrote: >> >> i am not sure, if everyone is aware of it, but standalones that were >> created with the Starter Plan license will expire as soon as the Startert >> Plan subscription expires. > > Not even Apple is that rapacious. > > I used to have a commercial licence back when I was selling stuff (although > the economics of software never made sense). Since retiring I have been > “freeloading" with the Community edition as a hobbyist, my only LC uses > being for personal use, and maintaining admin and operating software I > wrote for a not-for-profit sporting organisation, and occasionally > contributing bug reports. I can well understand the need for LC to move to > a profitable basis, and I would be happy buy a plan if it made sense for > our use, but there is no way my NFP association can afford US$1000 every > year - or even one year (we would use 3 platforms, and not even the Server > is thrown in with the desktop platforms). And a Starter Kit that means the > app would stop working when I pass on (I have been around since Hypercard > day 1) is an insult. Seems to me the hobbyist use of LC has come to an end. > A great pity, but I guess times move on. > > I have greatly enjoyed being part of this (mostly) friendly and generous > community for many years. > > Neville Smythe > > ___ > 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: Text encoding.
On 03/09/2021 11:07, David V Glasgow via use-livecode wrote: Alex states that put textEncode(tWHoleText, "UTF8") into tWholeText speeds replace up, but David B says LC internal format is UTF16. Doesn’t the 8 vs 16 difference matter? Or matters less than other encodings? I would regard that timing comparison with much suspicion. I was textEncoding() it inappropriately - I had just read it in from a file, so I *should* have been textDecoding() it. Therefore it is unclear whether the times I was seeing then are meaningful. 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: Text encoding.
Following this with interest, but also a little confusion. I completely fell into the trap of assuming you encode outgoing and decode incoming. Alex states that put textEncode(tWHoleText, "UTF8") into tWholeText speeds replace up, but David B says LC internal format is UTF16. Doesn’t the 8 vs 16 difference matter? Or matters less than other encodings? Cheers David Glasgow > On 2 Sep 2021, at 1:01 pm, David Bovill via use-livecode > wrote: > > Thanks for the question Alex, I’m wrestling with the same issues - but so far > got no responses from encoding gurus here :) > > This is my understanding: > > 1) Yes its recommended to textEncode text that comes from outside into > Livecode’s internal native format (which is utf16). Livecode handles > everything internally “transparently” from then on - which I guess means all > usual language and control operations expect this utf16 internal format. My > guess is this is why a few things have got slower as compared with early > versions of Livecode. > 2) Without doing textEncode the engine tries to guess the encoding > (duck-typing?) and does this in a platform specific way? Again exactly what > is going on there is a bit opaque to me, but the take-home message is that > this is slower and less robust. So yes -losing nothing (assuming the original > file is utf8, and yes its the best alternative. > > I thing the hard thing to find out is exactly what type of encoding some > files are - would be great if there was a duck-typing service where we could > paste text or upload files and it would say - hey this looks like utf8 - but > that’s asking too much > > Schedule a call with me > On 2 Sep 2021, 12:12 +0100, Alex Tweedly via use-livecode > , wrote: >> Sorry to drag us off the interesting topic of licensing :-) into some >> Livecode question. >> >> I know little or nothing about Unicode, text encodings, etc. - so my >> question is indeed naive. >> >> I have a text file (War & Peace from Project Gutenberg), about 3.4Mb. >> The Mac describes it simply as "Plain text". >> >> When I read that into a variable, and then do >> replace tChar by SPACE in tWholeText >> it takes between 1000 and 4000 millisecs - versus the 8-10 msecs I had >> expected from other samples. >> >> If I put in >> put textEncode(tWHoleText, "UTF8") into tWholeText >> before the replace then it does indeed tae 8-10 msecs. >> >> Q1. What (if anything) am I losing by doing that ? >> >> Q2. Is this the best alternative ? >> >> Additional info - I just discovered that according to 'more' command >> line, the file start with : >> >> The Project >> >> if that is useful. >> >> Many thanks, >> >> 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 > ___ > 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
Random crash when building standalone
Hello,
When I build a Windows or macOS standalone, I sometimes have several alerts
that concern the "livecode's stacks" ("answer dialog", "print chooser" ...)
that are saved in the standalone (but I don't want them to be!) and that
conflict with the original stacks.
And rarely it ends with a livecode crash.
These "livecode stack's" are also added as substacks in my stacks...
This seems to be related to "old stacks".
I can't find any bug report about this but maybe I didn't look hard enough
Do you have any ideas to correct this problem ?
Thanks in advance !
Ludovic
___
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
