Re: Faster way to get tabStops?
Hi Dan, I ran into the same problem and figured that acessing the field and ask for formattedWidth is slow. So I tried to minimize that. I took each tab delimited item an stuffed it into an array. For each column one key. You end up with each key holding the data of one column worth of data Then I put that column into a field that has the same properties as the original field and get the formattedWidth. This tells me the space I need to set the tabstops. That way I only access the field column times. This speeds up the whole process tremendously. To see it in action you can have a look: --- http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384 -- watch for line breaks. look at the script of field fData handler mtfAdjustToWidthOfContent. Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689064.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: Faster way to get tabStops?
Wow. Nice Bernd. On Thu, Feb 19, 2015 at 1:47 AM, BNig bernd.niggem...@uni-wh.de wrote: Hi Dan, I ran into the same problem and figured that acessing the field and ask for formattedWidth is slow. So I tried to minimize that. I took each tab delimited item an stuffed it into an array. For each column one key. You end up with each key holding the data of one column worth of data Then I put that column into a field that has the same properties as the original field and get the formattedWidth. This tells me the space I need to set the tabstops. That way I only access the field column times. This speeds up the whole process tremendously. To see it in action you can have a look: --- http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384 -- watch for line breaks. look at the script of field fData handler mtfAdjustToWidthOfContent. Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689064.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
7.0 Issues
I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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: Problems in On-Rev??
Joseba, on which on-rev server is your account hosted? Diesel, Tio, Pancake or Jasmine? My accounts on the servers canary, pancake and jasmine are working. The on-rev status page at http://on-rev.com/support/server-status/ does not show any malfunction. But if your website is not working then you should definitely send an emergency support request using the web form at http://on-rev.com/support/contact-us/ Regards, Matthias Am 19.02.2015 um 20:44 schrieb Joseba Aguayo jagu...@telur.es: Is there problems in On-Rev Our website does not work since yesterday!!! Someone else?? Un saludo. Joseba (jagu...@telur.es) ___ 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: 7.0 Issues
Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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
iOS 64-bit support and 1st Gen iPad
Got a question I’m hoping someone can answer. I’ve done some research, but can’t find what I’m looking for. With LC 6.7.2, we gained 64-bit support for iOS apps. It seems to include 32-bit support as well, since I can install and run an app on my 1st Gen iPad mini running iOS 8.1.3. However, we are also in need of still supporting the 1st Gen iPad (if at all possible), running iOS 5.1.1. I can’t seem to get my app to install on that device, no matter what I try (Xcode, iTunes, TestFlight, other testing service, etc.). From Xcode, I get a message that apps that include 64-bit architecture cannot be installed with Xcode on devices running anything older than iOS 6.0. But the message also suggests that installing on a 1st Gen iPad will still be supported through the App Store, although it’s a little vague. But if that’s the case, how in the world do we test our apps before going live with them!? So, is anyone out there still trying to support the iPad 1? If so, have you been able to get an app installed after building it with LC 6.7.2? *Should* this work? Is there perhaps a bug of some kind in LC? Just trying to figure out what’s going on exactly. If we have to, we can probably drop iPad 1 support, since users would still be able to download the older version of the app through the app store, but that means no more updates for that device… Thanks, Chris -- Chris Sheffield Read Naturally, Inc. www.readnaturally.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
Problems in On-Rev??
Is there problems in On-Rev Our website does not work since yesterday!!! Someone else?? Un saludo. Joseba (jagu...@telur.es) ___ 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: 7.0 Issues
Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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: 7.0 Issues
I think what you will have to do is this: Check the LC version; if it’s = 7 then arrayEncode(tData,6) — force the engine to use the old arrayEncoding else arrayEncode(tData) — older versions can not have the extra parameter end if LiveCode 7 will be smart enough to decode the array either way. Eric On Feb 19, 2015, at 12:49 PM, Peter Haworth p...@lcsql.com wrote: Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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: 7.0 Issues
Additionally, The dictionary may be a bit inaccurate. In LC 7, if there is no version, arrayEncode uses the encoding for the version you are on, LC 7 encoding. So, if LC 8 has different encoding than 7, LC 8 will use LC 8 encoding when no version is specified. Eric On Feb 19, 2015, at 12:49 PM, Peter Haworth p...@lcsql.com wrote: Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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: Vector Export?
On 2/19/2015 10:50 AM, Graham Samuel wrote: Is there any way to export a vector image? What I’m actually trying to do is to export a screenshot that can have a higher resolution than that of the screen, for printing and so on. Other apps can do this, in effect (I mean they can have enlargement and/or resolution-changing features). What do people do when they want a high-res output? I usually just run images through an image processing app after export if I need to alter them. I'm not aware of any way to change the resolution from within LC. -- 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: [ANN] R.I.P. Mac Mini
On 19/02/15 03:31, Bob Warren wrote: A few days back I finished doing a few minor corrections to my Unicode File/Folder/Picture Choosers for Windows and Linux, and declared them stable. If you download them, please test them well before distributing them in any way, to make absolutely sure they are as stable as I think they are. I then had an idea. I had had a first-generation Mac Mini sitting in the corner of my computer room for a long time, and I hadn't done much with it. (One reason is that it had a broken DVD drive.) It occurred to me that since the Mac file system is not so different to that of Linux, it might not be too difficult to produce some chooser widgets for Mac as well. Of course, they would need to be legacy (English only) widgets, because the machine had OS X Tiger 10.4 that was not supported by LiveCode/Unicode. So I had a bash at it. I rolled the Linux and Windows widgets together, and soon came up with a new set of MAC chooser widgets that had reached what I might fairly call the beta stage. However, the very day after, my Mini started going a bit crazy, and like a drip I didn't realize immediately that the cooling system had failed and that it was overheating. The end result is that now I have a fried Mac Mini. I do not intend to buy another one. In Brazil (my country of residence), Macs are impossibly expensive. If I replaced my simple Mini with an equivalent modern one, it would cost me $1,500 (which you might find difficult to believe). You now know why Macs are extremely rare in Brazil! Luckily, I had not only finished the programs, I had taken a few screenshots. I was therefore able to put the widgets up at my site: GENERAL INFO: http://www.howsoft.com/runrev/runrev_stacks_index.htm MAC CHOOSERS PAGE: http://www.howsoft.com/runrev/macchoosers/ DOWNLOADS: http://www.howsoft.com/runrev/downloads/ Under the circumstances (of my now being Macless), I'd be grateful if any of you could tell me: a) whether these widgets work on a real MAC; b) whether they are stable enough for usage in your opinion; b) whether they detect DVD drives correctly as well as other USB devices such as pendrives and external HDs. Thanks! Regards to all. Well; I'll try them on my PPC G5 running both 10.4 and 10.5 as to Real Macs (by 'real' I assume to mean 'reasonably comtemporary) I will try them on my 'unreal' 10.8 (VMware) . . . I will, also, just to be bloody-minded, see how they behave on my Linux box :) Richmond. ___ 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: Faster way to get tabStops?
Thanks Mike, you can load the field with 5000 lines worth of data via the Helper stack - Examples - choose 5000 - click button fill with n lines of random data, then move the lines by moving the dividers and then control-click into the field. This triggers the recalculation of the column widths via mtfAdjustToWidthOfContent It is quite fast. Kind regards Bernd Mike Bonner wrote Wow. Nice Bernd. On Thu, Feb 19, 2015 at 1:47 AM, BNig lt; bernd.niggemann@ gt; wrote: Hi Dan, I ran into the same problem and figured that acessing the field and ask for formattedWidth is slow. So I tried to minimize that. I took each tab delimited item an stuffed it into an array. For each column one key. You end up with each key holding the data of one column worth of data Then I put that column into a field that has the same properties as the original field and get the formattedWidth. This tells me the space I need to set the tabstops. That way I only access the field column times. This speeds up the whole process tremendously. To see it in action you can have a look: --- http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384 -- watch for line breaks. look at the script of field fData handler mtfAdjustToWidthOfContent. Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689067.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: The Future of Animation in LiveCode
On 18 Feb 2015, at 01:52, Alex Tweedly a...@tweedly.net wrote: If the problem is that LC is just too slow, and the required calculations continuously or consistently take more time than is elapsed (i.e. we just keep getting further and further behind), then the problem is performance, not how/when we can trigger redraws. But if the issue is simply that timers can't be relied upon to trigger while calculations proceed, then we can (at considerable effort) minimize the impact of that. The problem is none of those. It's a problem that many games have, and that is not solvable with LC, because of the way it is always sequential. An extreme example would be a real time game, which does auto-saves every 5 or 30 minutes to hard disk, of non-trivial data amounts. The game would update it's screen timely as expected, until it saves, at which point it stalls for 1-5 seconds, to write to the hard disk. Note that many games actually do it like that (ie. Factorio, all Paradox developed games, etc.). Because LC can't do two things at once, and because it's screen redraw is so slow, one will run into these problems far more often, and with less intensive tasks then file access. Sometimes with just the screen updates alone (with the non-laggy amount of participants being well below 30 pieces, and without any user input or AI/maintenance stuff running). Even worse, there is simply no workaround. Now if there'd be a way to do screen redraws in parallel to doing calculations by script, that'd be a different thing. But because LC _depends_ on sequentiality for things like the message path and how send in time works, that is probably not going to happen very soon, and even long term (ie. in the next 5 years) it's doubtful. So in a sense it's both of your examples at once. -- Chat with other LC people: http://bjoernke.com/chatrev Use a better dictionary in the IDE: http://www.bjoernke.com/bvgdocu Try chartsEngine: https://livecode.com/store/marketplace/charts-engine-1-2-1 ___ 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: Because LC can't do two things at once.
Richmond wrote: I wonder WHY Livecode cannot do two things at once . . . There is a difference between concurrency and parallelism which is useful here because LC currently provides a limited form of concurrency for some operations but delivers true parallelism only in the most recent version of 7 and only with regard to GPUs (and not AFAIK something we can use in our scripts, but something done in the engine to optimize rendering). Long but excellent distinction between the two: Rob Pike - 'Concurrency Is Not Parallelism' https://www.youtube.com/watch?v=cN_DpYBzKso TL/DR version: Concurrency is a logical framework for handling tasks independently, while parallelism is the actual simultaneous execution of code across multiple processors. This distinction is also useful here when comparing LC to other languages, since Python is one of the world's most popular languages and offers concurrency but not parallelism (at least not in the main distribution, though I believe there are now forks that provide parallelism). Within LC, network I/O is concurrent (but not parallel) when you use callbacks, e.g.: accept connections on port with SomeCallbackMessage In those cases the network I/O is non-blocking, and whatever handler is accepting connections can be triggered again even before SomeCallbackMessage has completed. This is very limited, however, since most non-network-I/O tasks are blocking, so chances are that SomeCallbackMessage will prevent anything meaningful from taking place in any re-entrant network I/O handlers. Other forms of non-parallel concurrency can be had in LC as it is today using timers or wait 0 with messages - here's a simple stack to illustrate some of those options: http://www.fourthworld.net/channels/lc/IdleHour.rev While a very simple demo, the ideas shown there can be expanded to make good use of idle processing time to handle background tasks independently of other operations.* And then there are other ways we can use LC as it is today to achieve not only concurrency but even parallelism, using multiprocessing as an alternative to multithreading: faceless standalones launched with open process for neither, which can work completely independently of the UI the user is interacting with, and exchange data with that UI app either through local sockets or even just the file system (tmp is good for this). But all that's just tiny baby steps compared to what could be possible, so I like this question: AND, could it be revamped so that it could do two things at once? Given: - Python's success with non-parallel concurrency - the overhead of threads - the complexity of managing threads to avoid race conditions which (libURL aside) we've largely never had to even think about ...I would suggest we think carefully about what exactly we want. Forking is absolutely essential for the Server engine to be able to support FastCGI implementations for more scalable systems. But forking is a very specific form of concurrency. Threading is another, one which requires syntax for managing queues and priorities. Probably not as difficult to implement as it is to design the syntax for. Let the debate RAGE :) All for it. We already know we need some form of parallelism for large-scale server work, so it's probably useful to begin thinking about an approach for these sorts of things that could benefit the desktop as well. * If we want to max out the CPU by taking full advantage of idle time for background processing, it would be ideal to do this only when powered by wall socket, so laptops running from battery wouldn't be drained unnecessarily by what could be optional workloads. To do that we'd need to be able to know when a computer us running on battery, so I requested a powerStatus function: http://quality.runrev.com/show_bug.cgi?id=13819 -- 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
Re: Because LC can't do two things at once.
Well, for anyone who's ever made an application multitasking/multithreading, they'll tell you that there is all sorts of extra complication involved in making it work, and if you've ever written anything for a multithreading environment, it is definitely a lot of extra work (it's worth it, IMHO, but it is not easy and straightforward). You actually can make LC multithreaded-ish, and there have been discussions about doing that, especially in server setups. If you were prioritizing features for LC, would this be one of your top 5? It might make my top 10, but I don't know if it would be in my top 5. On Thu, Feb 19, 2015 at 1:06 PM, Richmond richmondmathew...@gmail.com wrote: That's a quote from another posting . . . this might be the rock on which Livecode founders. Other languages can do two, or more, things at once . . . I am either too out of touch with other computer languages, or I don't know enough about how computer languages talk to computers (which, de facto, is pretty much the same thing), but I wonder WHY Livecode cannot do two things at once . . . AND, could it be revamped so that it could do two things at once? Java can manage multi-threaded programming . . . I assume [] that more and more computer languages are in the process of becoming capable of multi-threading . . . A while back, just for fun, I ran up a silly little game where the end-user had to steer a rocket past some static planets to get to Earth. The reason the planets were static is just because I could think of no way of them precessing in their orbits while the end-user was pressing arrow keys. Before I look a complete, steaming nit, I am sure there is a work around; but, to be quite honest, I wonder how many work arounds are necessary before the bell rings. In the great scheme of things my silly little game is neither here nor there: what it did do for me was NOT demonstrate the super capabilities of Livecode [ after 14 years of messing around with Livecode I am pretty well aware of those ], BUT demonstrate some of its limitations . . . Now, I know that the initial idea of Livecode was this: Kevin designing a front-end for a UNIX clone of Hypercard that he felt was more user-friendly than the Metacard one. However, like the Rary, it grew out of control . . . --- Side line; extreme tangentialism coming up: skip down to next load of dotted lines if you have a problem drifting off-off-off-topic with Richmond. There was a Scotsman down to University in England, who was walking down the road and saw a matchbox lying in the road. Picking up the matchbox and opening it he found, inside, a small note written on a piece of paper and a small, black, spherical object that pulsated. The paper said; This matchbox contains a Rary; feed it and care for it and it will bring you good fortune. The Scotsman took the matchbox back to his student room and started to feed the Rary; after his 3 years (short degree courses in England) the Rary was about the size of a tennis ball; black and hairy with no obvious eyes, mouth or other orifices. The man went away back to his butt-and-ben in the hills to look after his ageing parents, and continued to feed the Rary; by the time his parents were gathered the thing was about the size of a large medicine ball. Over the years our man continued to care for the Rary until it became the size of a small tractor and the man was beggared with the feeding bills. He decide to get rid of the Rary; so he got the thing into a boat and rowed it all the way south down the West Coast and past France and Spain; left into the Mediterranean, through the Suez canal, all the way across the Indian ocean until he came to Japan. Arriving at Japan he rolled the Rary, at great personal expense to himself and his health, up to the top of a very high cliff. He was just about to push the Rary over the cliff when it turned to him and said: It's a long way to tip a Rary. Should this story really annoy you; I take no credit whatsoever for it; my father, Donald Mathewson, told it to me when I was about 7, and, at the risk of sounding incredibly juvenile, I haven't stopped laughing since. --- NOW, Livecode is no longer a UNIX clone of Hypercard with Kevin's GUI strapped on the front. Nor is it anything like what it was 10 years ago. So, it has to keep growing AND evolving to compete [ THAT is the magic word ] . . . - After all; if it ONLY grows, then it is going to get pushed off the cliff soon enough. - Possibly the next reasonable step is multi-threading ? Let the debate RAGE :) Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe,
Re: 7.0 Issues
On 2/19/2015 2:49 PM, Peter Haworth wrote: The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. From what you've seen, it sounds like the default in 7.0 is to encode the new way, and the dictionary is misleading. Richard G. mentioned on the list that the default was the new encoding. We should clear that up, it's going to affect me too eventually. -- 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: Because LC can't do two things at once.
One of the work arounds isn't really, its kind of a standard thing. A game loop. Loop, do these things, do those things, update the screen, loop again. For your trek to earth game, this would probably be sufficient. Rather than waiting for an arrow key event, one of the loop steps would be to check the keysdown and act appropriately. Having said that, being able to turn some of this over to separate threads on separate cores would be awesome. As it is, you can only reach a certain amount of complexity before running into trouble. Too many objects to move, intersects to check, etc for each loop makes it impossible to get a reliable frame rate. This is where more work arounds would come in. My hope is that box2d will offset most of its stuff to a separate core (or more if they're available) but time will tell. Also, if I recall correctly, the IDE will be broken out to a thread some way so that even if you repeat forever end repeat, shouldn't bring the IDE to its knees. (benefits for standalones too must likely? ) Alas, as usual, I read way way too much but can't recall where I saw this, and if it was a suggestion, or an actual goal. On Thu, Feb 19, 2015 at 12:00 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Richmond wrote: I wonder WHY Livecode cannot do two things at once . . . There is a difference between concurrency and parallelism which is useful here because LC currently provides a limited form of concurrency for some operations but delivers true parallelism only in the most recent version of 7 and only with regard to GPUs (and not AFAIK something we can use in our scripts, but something done in the engine to optimize rendering). Long but excellent distinction between the two: Rob Pike - 'Concurrency Is Not Parallelism' https://www.youtube.com/watch?v=cN_DpYBzKso TL/DR version: Concurrency is a logical framework for handling tasks independently, while parallelism is the actual simultaneous execution of code across multiple processors. This distinction is also useful here when comparing LC to other languages, since Python is one of the world's most popular languages and offers concurrency but not parallelism (at least not in the main distribution, though I believe there are now forks that provide parallelism). Within LC, network I/O is concurrent (but not parallel) when you use callbacks, e.g.: accept connections on port with SomeCallbackMessage In those cases the network I/O is non-blocking, and whatever handler is accepting connections can be triggered again even before SomeCallbackMessage has completed. This is very limited, however, since most non-network-I/O tasks are blocking, so chances are that SomeCallbackMessage will prevent anything meaningful from taking place in any re-entrant network I/O handlers. Other forms of non-parallel concurrency can be had in LC as it is today using timers or wait 0 with messages - here's a simple stack to illustrate some of those options: http://www.fourthworld.net/channels/lc/IdleHour.rev While a very simple demo, the ideas shown there can be expanded to make good use of idle processing time to handle background tasks independently of other operations.* And then there are other ways we can use LC as it is today to achieve not only concurrency but even parallelism, using multiprocessing as an alternative to multithreading: faceless standalones launched with open process for neither, which can work completely independently of the UI the user is interacting with, and exchange data with that UI app either through local sockets or even just the file system (tmp is good for this). But all that's just tiny baby steps compared to what could be possible, so I like this question: AND, could it be revamped so that it could do two things at once? Given: - Python's success with non-parallel concurrency - the overhead of threads - the complexity of managing threads to avoid race conditions which (libURL aside) we've largely never had to even think about ...I would suggest we think carefully about what exactly we want. Forking is absolutely essential for the Server engine to be able to support FastCGI implementations for more scalable systems. But forking is a very specific form of concurrency. Threading is another, one which requires syntax for managing queues and priorities. Probably not as difficult to implement as it is to design the syntax for. Let the debate RAGE :) All for it. We already know we need some form of parallelism for large-scale server work, so it's probably useful to begin thinking about an approach for these sorts of things that could benefit the desktop as well. * If we want to max out the CPU by taking full advantage of idle time for background processing, it would be ideal to do this only when powered by wall socket, so laptops running from battery wouldn't be drained unnecessarily by what could be optional workloads. To do that
Re: 7.0 Issues
Thanks Eric and Jacque. I entered QCC report 14639. I altered my code to do as you suggest Eric. I wonder how this affects how an array variable is stored in a custom property? As I understand it, the variable is automatically array encoded if you do something like set the cArray of me to tArray and decoded when you get it back out of the cProp. Personally I only use cProps for stuff that doesn't need to survive across runs of LC so wouldn't be affected by any changes in that area but others may not be so lucky. On Thu Feb 19 2015 at 1:18:58 PM J. Landman Gay jac...@hyperactivesw.com wrote: On 2/19/2015 2:49 PM, Peter Haworth wrote: The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. From what you've seen, it sounds like the default in 7.0 is to encode the new way, and the dictionary is misleading. Richard G. mentioned on the list that the default was the new encoding. We should clear that up, it's going to affect me too eventually. -- 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 ___ 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: 7.0 Issues
Ho Eric, Spoke too soon. Your code wont compile in versions prior to 7 because of the extra parameter. I guess I could compile it in 7 but that would mean I would have to compile that script in 7 every time I wanted to make a change and there's a lot of handlers in it so high probability of changes. I suppose I could use a do statement (yuk). The more I think about this, the more it's a pretty bad backward compatibility problem. I'm wondering if the dictionary entry is in fact the way it was supposed to be implemented, meaning if the new parm isn't present the old encoding is used. You only care about the new encoding if you're storing unicode data in an array and doesn't seem like any more of an imposition to use the new parameter than having to use textEncode/Decode for other unicode operations. On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett e...@canelasoftware.com wrote: I think what you will have to do is this: Check the LC version; if it’s = 7 then arrayEncode(tData,6) — force the engine to use the old arrayEncoding else arrayEncode(tData) — older versions can not have the extra parameter end if LiveCode 7 will be smart enough to decode the array either way. Eric On Feb 19, 2015, at 12:49 PM, Peter Haworth p...@lcsql.com wrote: Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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:
Re: 7.0 Issues
Hi Peter, I forgot about that fact. I just checked some code in a library we use and indeed the arrayEncode for version 7 is wrapped in a do statement. I agree about the behavior. Mark W. made some comments to a bug report I submitted explaining the current functionality but I can not find it. eric On Feb 19, 2015, at 2:15 PM, Peter Haworth p...@lcsql.com wrote: Ho Eric, Spoke too soon. Your code wont compile in versions prior to 7 because of the extra parameter. I guess I could compile it in 7 but that would mean I would have to compile that script in 7 every time I wanted to make a change and there's a lot of handlers in it so high probability of changes. I suppose I could use a do statement (yuk). The more I think about this, the more it's a pretty bad backward compatibility problem. I'm wondering if the dictionary entry is in fact the way it was supposed to be implemented, meaning if the new parm isn't present the old encoding is used. You only care about the new encoding if you're storing unicode data in an array and doesn't seem like any more of an imposition to use the new parameter than having to use textEncode/Decode for other unicode operations. On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett e...@canelasoftware.com wrote: I think what you will have to do is this: Check the LC version; if it’s = 7 then arrayEncode(tData,6) — force the engine to use the old arrayEncoding else arrayEncode(tData) — older versions can not have the extra parameter end if LiveCode 7 will be smart enough to decode the array either way. Eric On Feb 19, 2015, at 12:49 PM, Peter Haworth p...@lcsql.com wrote: Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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
Re: Because LC can't do two things at once.
On Thu, Feb 19, 2015 at 10:32 AM, Mike Kerner mikeker...@roadrunner.com wrote: If you were prioritizing features for LC, would this be one of your top 5? It might make my top 10, but I don't know if it would be in my top 5. I can't see it any lower than my top 2 (the other of which would be postgres ssl support). -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: Vector export?
For high resolution export of vectors: open printing to pdf David Epstein ___ 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: More Unicode STuff
On Sat, Feb 14, 2015 at 2:23 AM, Peter Haworth p...@lcsql.com wrote: My brain is too fried to figure out why this should be so my plan is to just always encode/decode stuff when importing/displaying. Sorry for the slow reply, but I note your other post on your tentative move to LC 7 and the gotchas along the way, so this additional information will probably be timely and hopefully explanatory. This additional Important Note in the LC 7 dictionary under 'uniEncode/uniDecode' will be of interest: As of LiveCode 7.0 the uniEncode function has been deprecated. It will continue to work as in previous versions but shoud not be used in new code as the existing behaviour is incompatible with the new, transparent Unicode handling (the resulting value will be treated as binary data rather than text). This functions is only useful in combination with the also-deprecated uniDecode function and unicodeText field property. Also, as to why you need to do the two way encoding/decoding, it's better explained in the LC 7 dictionary under the 'textEncoding/textDecoding' entries: It is highly recommended that any time you interface with things outside LiveCode (files, network sockets, processes, etc) that you explicitly textEncode any text you send outside LiveCode and textDecode all text received into LiveCode. If this doesn't happen, a platform-dependent encoding will be used (which normally does not support Unicode text). It is not, in general, possible to reliably auto-detect text encodings so please check the documentation for the programme you are communicating with to find out what it expects. If in doubt, try UTF-8. ___ 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: Because LC can't do two things at once.
On Thu, Feb 19, 2015 at 5:48 PM, Dr. Hawkins doch...@gmail.com wrote: On Thu, Feb 19, 2015 at 3:05 PM, Mike Kerner mikeker...@roadrunner.com wrote: Wow, that's surprising. So what does your list look like - say for the top 5? Why is multithreading so important to you? Secure Postgres support Multithreading or slave processes Fixing the (*#^%*(m show-stopping bugs in the IDE (shadow variables, not watching globals, wandering off) Actually, put in PDF/A for #3--without it, I will have no choice but to use another platform, as it will be mandatory for ECF court filing in a couple of years. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: Faster way to get tabStops?
Datagrids… GOOD! Bob S On Feb 19, 2015, at 24:47 , BNig bernd.niggem...@uni-wh.de wrote: Hi Dan, I ran into the same problem and figured that acessing the field and ask for formattedWidth is slow. So I tried to minimize that. I took each tab delimited item an stuffed it into an array. For each column one key. You end up with each key holding the data of one column worth of data Then I put that column into a field that has the same properties as the original field and get the formattedWidth. This tells me the space I need to set the tabstops. That way I only access the field column times. This speeds up the whole process tremendously. To see it in action you can have a look: --- http://runtime-revolution.278305.n4.nabble.com/ANN-modified-Table-Field-0-2-9-td4683338.html#a4683384 -- watch for line breaks. look at the script of field fData handler mtfAdjustToWidthOfContent. Kind regards Bernd -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Faster-way-to-get-tabStops-tp4689049p4689064.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
Vector Export?
AFAICS when one does ‘export snapshot’, the result is a bitmap even though the original object or group may have been a vector image or made up of vector images. At least that’s what I’ve seen from experimenting with the ‘export’ features of LC Is there any way to export a vector image? What I’m actually trying to do is to export a screenshot that can have a higher resolution than that of the screen, for printing and so on. Other apps can do this, in effect (I mean they can have enlargement and/or resolution-changing features). What do people do when they want a high-res output? TIA Graham ___ 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
Because LC can't do two things at once.
That's a quote from another posting . . . this might be the rock on which Livecode founders. Other languages can do two, or more, things at once . . . I am either too out of touch with other computer languages, or I don't know enough about how computer languages talk to computers (which, de facto, is pretty much the same thing), but I wonder WHY Livecode cannot do two things at once . . . AND, could it be revamped so that it could do two things at once? Java can manage multi-threaded programming . . . I assume [] that more and more computer languages are in the process of becoming capable of multi-threading . . . A while back, just for fun, I ran up a silly little game where the end-user had to steer a rocket past some static planets to get to Earth. The reason the planets were static is just because I could think of no way of them precessing in their orbits while the end-user was pressing arrow keys. Before I look a complete, steaming nit, I am sure there is a work around; but, to be quite honest, I wonder how many work arounds are necessary before the bell rings. In the great scheme of things my silly little game is neither here nor there: what it did do for me was NOT demonstrate the super capabilities of Livecode [ after 14 years of messing around with Livecode I am pretty well aware of those ], BUT demonstrate some of its limitations . . . Now, I know that the initial idea of Livecode was this: Kevin designing a front-end for a UNIX clone of Hypercard that he felt was more user-friendly than the Metacard one. However, like the Rary, it grew out of control . . . --- Side line; extreme tangentialism coming up: skip down to next load of dotted lines if you have a problem drifting off-off-off-topic with Richmond. There was a Scotsman down to University in England, who was walking down the road and saw a matchbox lying in the road. Picking up the matchbox and opening it he found, inside, a small note written on a piece of paper and a small, black, spherical object that pulsated. The paper said; This matchbox contains a Rary; feed it and care for it and it will bring you good fortune. The Scotsman took the matchbox back to his student room and started to feed the Rary; after his 3 years (short degree courses in England) the Rary was about the size of a tennis ball; black and hairy with no obvious eyes, mouth or other orifices. The man went away back to his butt-and-ben in the hills to look after his ageing parents, and continued to feed the Rary; by the time his parents were gathered the thing was about the size of a large medicine ball. Over the years our man continued to care for the Rary until it became the size of a small tractor and the man was beggared with the feeding bills. He decide to get rid of the Rary; so he got the thing into a boat and rowed it all the way south down the West Coast and past France and Spain; left into the Mediterranean, through the Suez canal, all the way across the Indian ocean until he came to Japan. Arriving at Japan he rolled the Rary, at great personal expense to himself and his health, up to the top of a very high cliff. He was just about to push the Rary over the cliff when it turned to him and said: It's a long way to tip a Rary. Should this story really annoy you; I take no credit whatsoever for it; my father, Donald Mathewson, told it to me when I was about 7, and, at the risk of sounding incredibly juvenile, I haven't stopped laughing since. --- NOW, Livecode is no longer a UNIX clone of Hypercard with Kevin's GUI strapped on the front. Nor is it anything like what it was 10 years ago. So, it has to keep growing AND evolving to compete [ THAT is the magic word ] . . . - After all; if it ONLY grows, then it is going to get pushed off the cliff soon enough. - Possibly the next reasonable step is multi-threading ? Let the debate RAGE :) Richmond. ___ 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: Vector export?
Ha! Sounds promising. Midnight here, I’ll investigate tomorrow. Thanks Graham On 19 Feb 2015, at 23:33, dfepst...@comcast.net wrote: For high resolution export of vectors: open printing to pdf David Epstein ___ 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: Vector export?
David¹s right - PDF export is definitely the way to go. It¹s even good for bitmaps if you use high res images that have been sized down and locked within LC. Terry... On 20/02/2015 9:56 am, Graham Samuel livf...@mac.com wrote: Ha! Sounds promising. Midnight here, I¹ll investigate tomorrow. Thanks Graham On 19 Feb 2015, at 23:33, dfepst...@comcast.net wrote: For high resolution export of vectors: open printing to pdf David Epstein ___ 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: Because LC can't do two things at once.
What is PDF/A? It’s a TLA I’m unfamiliar with. Kee On Feb 19, 2015, at 6:21 PM, Dr. Hawkins doch...@gmail.com wrote: Actually, put in PDF/A for #3--without it, I will have no choice but to use another platform, as it will be mandatory for ECF court filing in a couple of years. ___ 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: 7.0 Issues
J. Landman Gay wrote: From what you've seen, it sounds like the default in 7.0 is to encode the new way, and the dictionary is misleading. Richard G. mentioned on the list that the default was the new encoding. To clarify, the new method is used where it exists. :) It works very much like stack file formats, where the default is the current format unless you specify otherwise. And as with file formats, you can save in older formats from the newer version. Also like file formats, apparently v6.7.x is at least somewhat aware of later array formats, even if it can't generate them. It allows you to use the optional second argument with arrayEncode - it won't actually do anything since v6.7 doesn't understand later encoding formats, but it won't choke on a second param either. This is rarely needed, for the few code bases that must run on both 6.7 and 7.0 during the same development cycle. It's much more common for development workflows to move forward, so this will be needed by very few. I happened to be one of them, since I have a projects that has v6 clients in the wild and uses v7 on the server, and I test my server code in a local ad hoc server emulator under v6.7. Can't imagine many need to run the same code in both environments, but if you do it seems to work well provided you're using a reasonably recent v6.7 build. -- 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
Re: Because LC can't do two things at once.
On Thu, Feb 19, 2015 at 3:05 PM, Mike Kerner mikeker...@roadrunner.com wrote: Wow, that's surprising. So what does your list look like - say for the top 5? Why is multithreading so important to you? Secure Postgres support Multithreading or slave processes Fixing the (*#^%*(m show-stopping bugs in the IDE (shadow variables, not watching globals, wandering off) Locally scoped variables (a la c) c-type tokens or whatever they're called that globally map strings to integers. Integer indexed arrays (would be faster than comparing keys) The ability to trade the ability to have evaluations for speed (if something will have a known value, let it compile all the way at compile time Ability to display eps/ pdf output processing and manipulation -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: Vector Export?
Sorry Jacque, I don’t understand. Suppose I have say a filled rectangle (‘draw' not ‘paint', thus a vector image). When I export it, I think this ends up as a bitmap with the resolution of the screen it was displayed in while in LC. Is this what you’re seeing? What about a group containing say vector items and also text? In theory this could be exported as an image with no inherent resolution, so capable of being reproduced at different resolutions as required. I don’t seem to get anything other than bitmaps. Graham On 19 Feb 2015, at 22:22, J. Landman Gay jac...@hyperactivesw.com wrote: On 2/19/2015 10:50 AM, Graham Samuel wrote: Is there any way to export a vector image? What I’m actually trying to do is to export a screenshot that can have a higher resolution than that of the screen, for printing and so on. Other apps can do this, in effect (I mean they can have enlargement and/or resolution-changing features). What do people do when they want a high-res output? I usually just run images through an image processing app after export if I need to alter them. I'm not aware of any way to change the resolution from within LC. -- 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 ___ 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: 7.0 Issues
Thanks Eric. I guess I'll have to go the do route. Your bug report is 13406, I just added a comment to it. On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett e...@canelasoftware.com wrote: Hi Peter, I forgot about that fact. I just checked some code in a library we use and indeed the arrayEncode for version 7 is wrapped in a do statement. I agree about the behavior. Mark W. made some comments to a bug report I submitted explaining the current functionality but I can not find it. eric On Feb 19, 2015, at 2:15 PM, Peter Haworth p...@lcsql.com wrote: Ho Eric, Spoke too soon. Your code wont compile in versions prior to 7 because of the extra parameter. I guess I could compile it in 7 but that would mean I would have to compile that script in 7 every time I wanted to make a change and there's a lot of handlers in it so high probability of changes. I suppose I could use a do statement (yuk). The more I think about this, the more it's a pretty bad backward compatibility problem. I'm wondering if the dictionary entry is in fact the way it was supposed to be implemented, meaning if the new parm isn't present the old encoding is used. You only care about the new encoding if you're storing unicode data in an array and doesn't seem like any more of an imposition to use the new parameter than having to use textEncode/Decode for other unicode operations. On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett e...@canelasoftware.com wrote: I think what you will have to do is this: Check the LC version; if it’s = 7 then arrayEncode(tData,6) — force the engine to use the old arrayEncoding else arrayEncode(tData) — older versions can not have the extra parameter end if LiveCode 7 will be smart enough to decode the array either way. Eric On Feb 19, 2015, at 12:49 PM, Peter Haworth p...@lcsql.com wrote: Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded data. I ran the LC7 version of the stack again and the runtime error did not occur. I restored the preferences file from a Time Machine backup that I know preceded my use of LC7, ran the application again with LC 6.6.2, and all worked fine. So it seems that something in either the array/base64 encode/decode functions changed between v6.6.2 and 7.0.1. I really want to use LC7 but stuff like this makes me very nervous. How many other inconsistencies like this are lurking out there. ___ 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
Re: Because LC can't do two things at once.
Wow, that's surprising. So what does your list look like - say for the top 5? Why is multithreading so important to you? On Thu, Feb 19, 2015 at 5:25 PM, Dr. Hawkins doch...@gmail.com wrote: On Thu, Feb 19, 2015 at 10:32 AM, Mike Kerner mikeker...@roadrunner.com wrote: If you were prioritizing features for LC, would this be one of your top 5? It might make my top 10, but I don't know if it would be in my top 5. I can't see it any lower than my top 2 (the other of which would be postgres ssl support). -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ 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: 7.0 Issues
OK, well this is getting really frustrating. I changed my code to check the version and issue the 7 version of arrayencode with the extra parm with a do command. I made a copy of the stack for use in LC7 and opened it in LC7. Now I get an error on the arrayencode because the stackfile version is 5.5 so it won't execute the command even though it's a perfectly valid in 7.0. I'd really like to use 7.0 for this project but I have to keep the pre 7 code base available for bug fixes. All this because the 7.0 version of arrayencode was implemented without a thought for backward compatibility. All that was needed was a preference setting for the default encoding to be used for arrayencode in 7.0. I've wasted the best part of the day trying to make this work and the arrays in question don't even contain any unicode characters! What really scares me is how many other gotchas I'll find if I go any further with this project. I will have the think carefully if it's worth the effort and hassle to try converting existing stacks over to 7 or just use it for brand new projects. On Thu Feb 19 2015 at 2:50:09 PM Peter Haworth p...@lcsql.com wrote: Thanks Eric. I guess I'll have to go the do route. Your bug report is 13406, I just added a comment to it. On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett e...@canelasoftware.com wrote: Hi Peter, I forgot about that fact. I just checked some code in a library we use and indeed the arrayEncode for version 7 is wrapped in a do statement. I agree about the behavior. Mark W. made some comments to a bug report I submitted explaining the current functionality but I can not find it. eric On Feb 19, 2015, at 2:15 PM, Peter Haworth p...@lcsql.com wrote: Ho Eric, Spoke too soon. Your code wont compile in versions prior to 7 because of the extra parameter. I guess I could compile it in 7 but that would mean I would have to compile that script in 7 every time I wanted to make a change and there's a lot of handlers in it so high probability of changes. I suppose I could use a do statement (yuk). The more I think about this, the more it's a pretty bad backward compatibility problem. I'm wondering if the dictionary entry is in fact the way it was supposed to be implemented, meaning if the new parm isn't present the old encoding is used. You only care about the new encoding if you're storing unicode data in an array and doesn't seem like any more of an imposition to use the new parameter than having to use textEncode/Decode for other unicode operations. On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett e...@canelasoftware.com wrote: I think what you will have to do is this: Check the LC version; if it’s = 7 then arrayEncode(tData,6) — force the engine to use the old arrayEncoding else arrayEncode(tData) — older versions can not have the extra parameter end if LiveCode 7 will be smart enough to decode the array either way. Eric On Feb 19, 2015, at 12:49 PM, Peter Haworth p...@lcsql.com wrote: Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put arrayDecode(base64Decode(it)) into gSettings end if Yesterday, I started working on this stack with LC7 and the prefs file was saved by the LC7 version of the stack. Today, I needed to go back to the non LC7 version of the stack. To my surprise, a runtime error was thrown on the put arrayDecode... statement above. The it variable looked like it contained base64 encoded
Re: 7.0 Issues
Sorry, final word on this subject. I loaded the stack, set the stackfileversion to 7.0 and saved the stack. Quit LC 7 and run again. Try to open the stack - spinning beachball of death, have to force quit. Done have any more time to waste on this so back to good old reliable 6.6. On Thu Feb 19 2015 at 3:59:18 PM Peter Haworth p...@lcsql.com wrote: OK, well this is getting really frustrating. I changed my code to check the version and issue the 7 version of arrayencode with the extra parm with a do command. I made a copy of the stack for use in LC7 and opened it in LC7. Now I get an error on the arrayencode because the stackfile version is 5.5 so it won't execute the command even though it's a perfectly valid in 7.0. I'd really like to use 7.0 for this project but I have to keep the pre 7 code base available for bug fixes. All this because the 7.0 version of arrayencode was implemented without a thought for backward compatibility. All that was needed was a preference setting for the default encoding to be used for arrayencode in 7.0. I've wasted the best part of the day trying to make this work and the arrays in question don't even contain any unicode characters! What really scares me is how many other gotchas I'll find if I go any further with this project. I will have the think carefully if it's worth the effort and hassle to try converting existing stacks over to 7 or just use it for brand new projects. On Thu Feb 19 2015 at 2:50:09 PM Peter Haworth p...@lcsql.com wrote: Thanks Eric. I guess I'll have to go the do route. Your bug report is 13406, I just added a comment to it. On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett e...@canelasoftware.com wrote: Hi Peter, I forgot about that fact. I just checked some code in a library we use and indeed the arrayEncode for version 7 is wrapped in a do statement. I agree about the behavior. Mark W. made some comments to a bug report I submitted explaining the current functionality but I can not find it. eric On Feb 19, 2015, at 2:15 PM, Peter Haworth p...@lcsql.com wrote: Ho Eric, Spoke too soon. Your code wont compile in versions prior to 7 because of the extra parameter. I guess I could compile it in 7 but that would mean I would have to compile that script in 7 every time I wanted to make a change and there's a lot of handlers in it so high probability of changes. I suppose I could use a do statement (yuk). The more I think about this, the more it's a pretty bad backward compatibility problem. I'm wondering if the dictionary entry is in fact the way it was supposed to be implemented, meaning if the new parm isn't present the old encoding is used. You only care about the new encoding if you're storing unicode data in an array and doesn't seem like any more of an imposition to use the new parameter than having to use textEncode/Decode for other unicode operations. On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett e...@canelasoftware.com wrote: I think what you will have to do is this: Check the LC version; if it’s = 7 then arrayEncode(tData,6) — force the engine to use the old arrayEncoding else arrayEncode(tData) — older versions can not have the extra parameter end if LiveCode 7 will be smart enough to decode the array either way. Eric On Feb 19, 2015, at 12:49 PM, Peter Haworth p...@lcsql.com wrote: Thanks Eric, yes that does indeed help. However, I'm still confused. The dictionary indicates that if the new parameter, version, is not present then arrays are encoded the old way. None of my calls include the new parameter so not sure how they ended up being inaccessible in pre7 versions. I guess the gist of my post was what else have I failed to account for? Is there a document somewhere that details what code structures may need attention when moving back and forth between LC7 and prior versions? I'm guessing that anything addressing char chunks or offset would need to be changed. On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett e...@canelasoftware.com wrote: Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than previous version due to Unicode. Check the dictionary on how to use arrayEncode in 7 to be able to decode in an earlier version. Eric On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote: I've been careful to create separate versions of my stack files and Livecode Preferences folder for use when running LC 7. However, it seems there other issues with compatibility. I save the preferences for my application in a file in the /Library/Application Support folder with the following statement: *write* base64Encode(arrayEncode(gSettings)) to file filepath These are then read in at startup with: read from file myPath until EOF if it is empty then put empty into gSettings else put
Re: Vector Export?
Right, I was talking about bitmaps. All screen exports are some kind of bitmap. If I need a higher resolution I open the file in Graphic Converter or Photoshop and increase the resolution. The PDF idea is interesting, I hadn't thought of that. On February 19, 2015 4:55:35 PM CST, Graham Samuel livf...@mac.com wrote: Sorry Jacque, I don’t understand. Suppose I have say a filled rectangle (‘draw' not ‘paint', thus a vector image). When I export it, I think this ends up as a bitmap with the resolution of the screen it was displayed in while in LC. Is this what you’re seeing? What about a group containing say vector items and also text? In theory this could be exported as an image with no inherent resolution, so capable of being reproduced at different resolutions as required. I don’t seem to get anything other than bitmaps. Graham On 19 Feb 2015, at 22:22, J. Landman Gay jac...@hyperactivesw.com wrote: On 2/19/2015 10:50 AM, Graham Samuel wrote: Is there any way to export a vector image? What I’m actually trying to do is to export a screenshot that can have a higher resolution than that of the screen, for printing and so on. Other apps can do this, in effect (I mean they can have enlargement and/or resolution-changing features). What do people do when they want a high-res output? I usually just run images through an image processing app after export if I need to alter them. I'm not aware of any way to change the resolution from within LC. -- 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 ___ 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 -- 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
