Re: LC & Mac M1 Chip

[panagiotis merakos via use-livecode]

Hello all,

Just a clarification - the bug about dashes in menus in standalones on Big
Sur is:

https://quality.livecode.com/show_bug.cgi?id=23009

and not https://quality.livecode.com/show_bug.cgi?id=23013

BTW, could someone that has a M1 Mac confirm that in the LC 9.6.2 RC-1 IDE
there are no dashes in front of the menus - in other words that this bug is
fixed:
https://quality.livecode.com/show_bug.cgi?id=22955

Thank you!

Kind regards,
Panos
--

On Fri, 8 Jan 2021 at 01:07, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Paul:
>
>  > we have several customer who have said
>  > they are upgrading to M1 laptops
>
> Yes; important to support! I'm looking in that direction too. It'll be
> popular, plus it's what I can afford. Many people in the same boat.
>
> (Backstory: Apple's biz model forces Apple to force us to spend on
> hardware. The mobile herd sticks with Apple, so the dev herd does too,
> so wallets must open and notes must rain down. But not satisfied yet
> with the rain from software tweaks, so now hardware tweaks too.)
>
> I'm planning to get an M1 Mac this year, to get back on the bleeding
> edge for a while. It's time. My old Mac hardware is still perfectly
> good, it was well-built and has zero issues, but finally has been pushed
> into what will soon be an untenable corner by the combo of new OS to
> support and new chip to support. But the older Mac will continue to
> serve for testing and for transition dev if needed.
>
>  > a sense of when LC 9.6.2 STABLE may be out?
>
> Could be roughly predicted, maybe, by looking at what they are working
> on. I actually agree with LC's anti release date policy; announcing firm
> dates is just begging for another issue to pop up. But since Apple's biz
> model places so much pressure on devs to keep up, a sense would be good.
> Especially since third-party addons and widgets also have to keep up
> with our ecosystem.
>
> (Another backstory: Don't forget the stable/stable linguistic play; I've
> seen RCs here that were actually more "stable" than the final, because
> glitches, regressions, and extra bugs are sometimes - perhaps often -
> introduced in the very process of fixing bugs. Depending on a stable to
> be stable is a gamble, and depending on the specific features in an app,
> there are times when the RC is more reliable. Nevertheless I really hate
> to publish anything with an RC; only when forced to do so.)
>
> BTW, Paul knows all of this very well. I'm just replying publicly in
> case the backstories will benefit other readers here in the process. :)
>
> Best wishes,
>
> Curry Kenworthy
>
> Custom Software Development
> "Better Methods, Better Results"
> LiveCode Training and Consulting
> http://livecodeconsulting.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: LC & Mac M1 Chip

[Andre Garzia via use-livecode]

Hi Panos,

Just updated https://quality.livecode.com/show_bug.cgi?id=22955 with a
screenshot from 9.6.2-rc-1 running on my M1 machine.

I can't reproduce the bug, I guess it is fixed.

On Fri, 8 Jan 2021 at 10:35, panagiotis merakos via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hello all,
>
> Just a clarification - the bug about dashes in menus in standalones on Big
> Sur is:
>
> https://quality.livecode.com/show_bug.cgi?id=23009
>
> and not https://quality.livecode.com/show_bug.cgi?id=23013
>
> BTW, could someone that has a M1 Mac confirm that in the LC 9.6.2 RC-1 IDE
> there are no dashes in front of the menus - in other words that this bug is
> fixed:
> https://quality.livecode.com/show_bug.cgi?id=22955
>
> Thank you!
>
> Kind regards,
> Panos
> --
>
> On Fri, 8 Jan 2021 at 01:07, Curry Kenworthy via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > Paul:
> >
> >  > we have several customer who have said
> >  > they are upgrading to M1 laptops
> >
> > Yes; important to support! I'm looking in that direction too. It'll be
> > popular, plus it's what I can afford. Many people in the same boat.
> >
> > (Backstory: Apple's biz model forces Apple to force us to spend on
> > hardware. The mobile herd sticks with Apple, so the dev herd does too,
> > so wallets must open and notes must rain down. But not satisfied yet
> > with the rain from software tweaks, so now hardware tweaks too.)
> >
> > I'm planning to get an M1 Mac this year, to get back on the bleeding
> > edge for a while. It's time. My old Mac hardware is still perfectly
> > good, it was well-built and has zero issues, but finally has been pushed
> > into what will soon be an untenable corner by the combo of new OS to
> > support and new chip to support. But the older Mac will continue to
> > serve for testing and for transition dev if needed.
> >
> >  > a sense of when LC 9.6.2 STABLE may be out?
> >
> > Could be roughly predicted, maybe, by looking at what they are working
> > on. I actually agree with LC's anti release date policy; announcing firm
> > dates is just begging for another issue to pop up. But since Apple's biz
> > model places so much pressure on devs to keep up, a sense would be good.
> > Especially since third-party addons and widgets also have to keep up
> > with our ecosystem.
> >
> > (Another backstory: Don't forget the stable/stable linguistic play; I've
> > seen RCs here that were actually more "stable" than the final, because
> > glitches, regressions, and extra bugs are sometimes - perhaps often -
> > introduced in the very process of fixing bugs. Depending on a stable to
> > be stable is a gamble, and depending on the specific features in an app,
> > there are times when the RC is more reliable. Nevertheless I really hate
> > to publish anything with an RC; only when forced to do so.)
> >
> > BTW, Paul knows all of this very well. I'm just replying publicly in
> > case the backstories will benefit other readers here in the process. :)
> >
> > Best wishes,
> >
> > Curry Kenworthy
> >
> > Custom Software Development
> > "Better Methods, Better Results"
> > LiveCode Training and Consulting
> > http://livecodeconsulting.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
>


-- 
https://www.andregarzia.com 
Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
___
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: Threads in LC

[David Bovill via use-livecode]

I would find it very helpful if we would share some code in this “thread” about 
threads?

At the moment I have a need to break up a heavy indexing task on a LiveCode 
server into a series of smaller steps that execute asynchronously.

The web server receives a webhook  notifying it that there is some new data 
that needs indexing, and should reply immediately notifying receipt of the 
webhook.

This is one of the “easy” cases Bob was referring too I think. But I’m not sure 
until I see and can test the code what the right approach is. Approaches could 
be:

1) In LiveCode server return “put” a response the after use wait / send in time 
to do indexing. Does this work and not lockup the server?

2) Schedule cron jobs with LiveCode

3) Use shell commands such as “at” to schedule a task at a future time.

4) Use tools that can manage spawning of LiveCode server pseudo-threads

While this example might be server centric, I suspect that many of the 
principles carry over to the desktop and it is the most common use case for a 
need for “threads”
On 8 Jan 2021, 10:32 +, Graham Samuel via use-livecode 
, wrote:
> On a purely personal note (does that make it OT?), I think I am beginning to 
> accept, at a pretty advanced age, that just understanding LC coding is not 
> really enough to get stuff done. Linux for example I have managed to avoid, 
> and many other technologies… perhaps learning all this stuff is good use of 
> one’s time in lockdown (I’m in the UK at the moment). Can’t spend all one’s 
> time on the bike trainer…
>
> So, Richard, if you have time to expand a bit on Linux virtual directories, 
> I’d be grateful. But only if you have time.
>
> Graham
>
> > On 8 Jan 2021, at 07:19, Richard Gaskin via use-livecode 
> >  wrote:
> >
> > Peter Bogdanoff wrote:
> >
> > > On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
> > >
> > > > Maybe.
> > > >
> > > > Does your Pi_gpio_output function use file I/O calls to the virtual
> > > > file system in /run, or call an LCB or external using a lower-level
> > > > interface for GPIO?
> > >
> > >
> > > Maybe. Maybe not. In spite of all events, this may be the most
> > > challenging, nay, inscrutable question I have seen this year.
> >
> > From you I'll take that as a compliment. :)
> >
> > If this is interesting I don't mind breaking that down for people who don't 
> > yet spend as much time on the Raspberry Pi. Linux virtual directories are a 
> > pretty nifty invention.
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> > Software Design and Development for the Desktop, Mobile, and the Web
> > 
> > ambassa...@fourthworld.com http://www.FourthWorld.com
> >
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

POST does not work under lock messages

[Neville Smythe via use-livecode]

It took me a while to figure this one out. I have a number of scripts which 
POST to LiveCode Server .lc scripts. All were working fine except one which 
always returned the output from whatever POST had last been executed. Evidently 
the previous form request was being resubmitted. Turns out I had a lock 
messages command before calling POST. 

Seems to me that shouldna oughta happen —either it’s a bug, or it should be 
documented 

(I think there is a documented warning about DataGrids needing Lock messages 
off? And wasn’t there a discussion a while back about Lock messages needing 
levels? The current documentation for Lock messages says it blocks “setProp 
triggers, getProp and certain other messages” where “certain”  is left 
undefined.)

Neville
___
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: Threads in LC

[Graham Samuel via use-livecode]

On a purely personal note (does that make it OT?), I think I am beginning to 
accept, at a pretty advanced age, that just understanding LC coding is not 
really enough to get stuff done. Linux for example I have managed to avoid, and 
many other technologies… perhaps learning all this stuff is good use of one’s 
time in lockdown (I’m in the UK at the moment). Can’t spend all one’s time on 
the bike trainer…

So, Richard, if you have time to expand a bit on Linux virtual directories, I’d 
be grateful. But only if you have time.

Graham

> On 8 Jan 2021, at 07:19, Richard Gaskin via use-livecode 
>  wrote:
> 
> Peter Bogdanoff wrote:
> 
> > On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
> >
> >> Maybe.
> >>
> >> Does your Pi_gpio_output function use file I/O calls to the virtual
> >> file system in /run, or call an LCB or external using a lower-level
> >> interface for GPIO?
> >
> >
> > Maybe. Maybe not. In spite of all events, this may be the most
> > challenging, nay, inscrutable question I have seen this year.
> 
> From you I'll take that as a compliment. :)
> 
> If this is interesting I don't mind breaking that down for people who don't 
> yet spend as much time on the Raspberry Pi. Linux virtual directories are a 
> pretty nifty invention.
> 
> --
> 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: LC & Mac M1 Chip

[Paul Dupuis via use-livecode]

Andre and Panos,

Thank you both. That given us some confidence we can release under LC 
9.6.2rc1 so that customers can go ahead with their M! Big Sur systems as 
they want to.




On 1/8/2021 6:46 AM, Andre Garzia via use-livecode wrote:

Hi Panos,

Just updated https://quality.livecode.com/show_bug.cgi?id=22955 with a
screenshot from 9.6.2-rc-1 running on my M1 machine.

I can't reproduce the bug, I guess it is fixed.

On Fri, 8 Jan 2021 at 10:35, panagiotis merakos via use-livecode <
use-livecode@lists.runrev.com> wrote:


Hello all,

Just a clarification - the bug about dashes in menus in standalones on Big
Sur is:

https://quality.livecode.com/show_bug.cgi?id=23009

and not https://quality.livecode.com/show_bug.cgi?id=23013

BTW, could someone that has a M1 Mac confirm that in the LC 9.6.2 RC-1 IDE
there are no dashes in front of the menus - in other words that this bug is
fixed:
https://quality.livecode.com/show_bug.cgi?id=22955

Thank you!

Kind regards,
Panos
--

On Fri, 8 Jan 2021 at 01:07, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:


Paul:

  > we have several customer who have said
  > they are upgrading to M1 laptops

Yes; important to support! I'm looking in that direction too. It'll be
popular, plus it's what I can afford. Many people in the same boat.

(Backstory: Apple's biz model forces Apple to force us to spend on
hardware. The mobile herd sticks with Apple, so the dev herd does too,
so wallets must open and notes must rain down. But not satisfied yet
with the rain from software tweaks, so now hardware tweaks too.)

I'm planning to get an M1 Mac this year, to get back on the bleeding
edge for a while. It's time. My old Mac hardware is still perfectly
good, it was well-built and has zero issues, but finally has been pushed
into what will soon be an untenable corner by the combo of new OS to
support and new chip to support. But the older Mac will continue to
serve for testing and for transition dev if needed.

  > a sense of when LC 9.6.2 STABLE may be out?

Could be roughly predicted, maybe, by looking at what they are working
on. I actually agree with LC's anti release date policy; announcing firm
dates is just begging for another issue to pop up. But since Apple's biz
model places so much pressure on devs to keep up, a sense would be good.
Especially since third-party addons and widgets also have to keep up
with our ecosystem.

(Another backstory: Don't forget the stable/stable linguistic play; I've
seen RCs here that were actually more "stable" than the final, because
glitches, regressions, and extra bugs are sometimes - perhaps often -
introduced in the very process of fixing bugs. Depending on a stable to
be stable is a gamble, and depending on the specific features in an app,
there are times when the RC is more reliable. Nevertheless I really hate
to publish anything with an RC; only when forced to do so.)

BTW, Paul knows all of this very well. I'm just replying publicly in
case the backstories will benefit other readers here in the process. :)

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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






___
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: Threads in LC

[JeeJeeStudio via use-livecode]

Not that I know of. When using LC it uses the GPIO library/api from the 
Master Library in which it was embedded. If I recall correct that uses 
access to the GPIO library which is on the Raspberry.


For this i can't recall if i needed to install something via terminal, 
which i needed to do for use with Python.


It just uses LC script, no LCB. So therefore my unknown wissdom about 
multi-threading / multi-core thought simplistic that one core could do 
the gui (would be more GPU then) and one core the GPIO handling. But you 
see my knowledge about it is minor.


Of course i could also just use Python without GUI and ask for some 
input setting from the user, if in the end a Python GUI might also be to 
heavy (read interference from any mouse movements).


For the beginning i have Start and stop buttons running in SimplePyGui , 
it needs input for how many steps, speed and size of the steps and how 
much it has to be repeated.




Op 8-1-2021 om 00:07 schreef Richard Gaskin via use-livecode:

JeeJeeStudio wrote:

> So what i actually meant is multiprocessing, would that give
> advantage?

Maybe.

Does your Pi_gpio_output function use file I/O calls to the virtual 
file system in /run, or call an LCB or external using a lower-level 
interface for GPIO?




___
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: LC & Mac M1 Chip

[Richmond via use-livecode]

Your back stories made me fire up a G5 iMac I have here running macOS 10.5
and download the latest LiveCode to work on it . . . .

Love and lunacy, Richmond.

On 8.01.21 1:06, Curry Kenworthy via use-livecode wrote:


Paul:

> we have several customer who have said
> they are upgrading to M1 laptops

Yes; important to support! I'm looking in that direction too. It'll be 
popular, plus it's what I can afford. Many people in the same boat.


(Backstory: Apple's biz model forces Apple to force us to spend on 
hardware. The mobile herd sticks with Apple, so the dev herd does too, 
so wallets must open and notes must rain down. But not satisfied yet 
with the rain from software tweaks, so now hardware tweaks too.)


I'm planning to get an M1 Mac this year, to get back on the bleeding 
edge for a while. It's time. My old Mac hardware is still perfectly 
good, it was well-built and has zero issues, but finally has been 
pushed into what will soon be an untenable corner by the combo of new 
OS to support and new chip to support. But the older Mac will continue 
to serve for testing and for transition dev if needed.


> a sense of when LC 9.6.2 STABLE may be out?

Could be roughly predicted, maybe, by looking at what they are working 
on. I actually agree with LC's anti release date policy; announcing 
firm dates is just begging for another issue to pop up. But since 
Apple's biz model places so much pressure on devs to keep up, a sense 
would be good. Especially since third-party addons and widgets also 
have to keep up with our ecosystem.


(Another backstory: Don't forget the stable/stable linguistic play; 
I've seen RCs here that were actually more "stable" than the final, 
because glitches, regressions, and extra bugs are sometimes - perhaps 
often - introduced in the very process of fixing bugs. Depending on a 
stable to be stable is a gamble, and depending on the specific 
features in an app, there are times when the RC is more reliable. 
Nevertheless I really hate to publish anything with an RC; only when 
forced to do so.)


BTW, Paul knows all of this very well. I'm just replying publicly in 
case the backstories will benefit other readers here in the process. :)


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: POST does not work under lock messages

[Brian Milby via use-livecode]

The docs don’t list all messages but do say that navigation and object creation 
messages are not sent.  It gives a couple examples of each.  This is in 
addition to get/set prop.

Sent from my iPhone

> On Jan 8, 2021, at 6:33 AM, Neville Smythe via use-livecode 
>  wrote:
> 
> It took me a while to figure this one out. I have a number of scripts which 
> POST to LiveCode Server .lc scripts. All were working fine except one which 
> always returned the output from whatever POST had last been executed. 
> Evidently the previous form request was being resubmitted. Turns out I had a 
> lock messages command before calling POST. 
> 
> Seems to me that shouldna oughta happen —either it’s a bug, or it should be 
> documented 
> 
> (I think there is a documented warning about DataGrids needing Lock messages 
> off? And wasn’t there a discussion a while back about Lock messages needing 
> levels? The current documentation for Lock messages says it blocks “setProp 
> triggers, getProp and certain other messages” where “certain”  is left 
> undefined.)
> 
> Neville
> ___
> 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: Threads in LC

[Alex Tweedly via use-livecode]

On 08/01/2021 01:51, Bob Sneidar via use-livecode wrote:

I have thought about this a bit. If what you mean by multiprocessing is that a 
new process can be spawned while your app can go off and do other things and 
get notified later that something happened, then this is quite doable. If what 
you mean is that you want to make the app spawning the processes operate more 
efficiently by launching the same process over and over in multiple instances, 
then I don’t think so. At some point the parent process is going to have to get 
the result of each thread and do something about it.


I did something like this, but didn't spawn a new process for each 
asynch task being launched.


What I did instead was have a very general purpose 'task handler' app, 
and have multiple instances of this 'server app' running all the time; 
as long as they're not doing any task, that's a negligible "cost" in 
resources. Each instance would accept a socket connection on a different 
port (e.g. 6000, 6001, 6002, ...) and would be passed "requests" to 
handle a specific task. It would queue up multiple tasks, handle them in 
turn, and pass the result back over the connection to whichever app 
requested it.


Then there was a client library, which would handle all the "messiness" 
for the client, so the app need not be too involved. The app itself 
would simply 'start using' the library, tell it which tasks it wanted to 
be able to do (see below), and then pass in multiple requests through 
library calls. The library would determine how many task-handler apps 
were available, parcel out the requests between them, and provide the 
responses to the client (if needed).


For each task (or set of tasks) you would write a library stack, which 
would have handlers to perform the task(s), and respond.



Example (trivial and may contain typos).

(you have to imagine that generating random numbers was very time 
consuming :-),


1. Write a library stack to perform some tasks.

stack "randomstuff"
global gResultData, gResultObject   -- remember - one task at a time, so 
no race conditions


on randomint pData
   local tmp, tMin, tMax
   put word 1 of pData into tMin
   put word 2 of pData into tMax
   put random(tMax - tMin + 1) into tmp
   put tmp-1 + tMin into gResultData
   send "completedTask" to gResultObject in 1 millisec
end randomint


2. In the client app, determine the tasks to be handled

(within, say, openstack)

   taskClientLoadStack "randomstuff.livecodescript"


3. when you need a number of random integers

  repeat 1000 times
    put taskClientSendARequest("randomstuff", "randomint 12 17", the 
long ID of me) into tmp

  end repeat
   -- (the return value is a request id - often can be ignored).
...
on taskcomplete pID, pResult
   -- pID is the request ID, pResult is the returned data from that request
   put pResult  after sNumbers   -- or whatever
...
end taskcomplete

In addition, there were various 'admin' taks you could request (close 
connection, cancel pending tasks, get count of remaining tasks pending, 
...). The initial version of the client library simply round-robined the 
task requests between the task-handlers, but the 'status' request would 
allow for more intelligent load-balancing i fneeded.



I did all this many years ago (2006 ??) and had this up on the earliest 
version of revonline (which subsequently got deleted). I developed it to 
help with indexing (including md5hash) of large numbers of image files. 
Using 4 task handlers, it was able to do the indexing in around 1/3 of 
the time the single-threaded version took.


I still have the code - but unfortunately I can't find the write-up / 
documentation on how to use it. And, I admit I absolutely cringe now to 
look at the code - it *seriously* needs to be re-written, or heavily 
revised.


I'll clean up the code, write up how to use it and post it somewhere for 
anyone who wishes to try it out.


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