Re: An idea on multithreading implementation

[Richmond]

On 01/31/2011 09:58 PM, Keith Clarke wrote:

Bollox is the detailed rubbish - metabollox is the multi-faceted architecture 
of the detailed rubbish. A kind of virtual landfill!

Metal Buttocks is a completely different website! ;-)

...I'll get my coat...


Oh Dear: just don't start "Flash"-ing . . . :)


On 31 Jan 2011, at 19:43, Bob Sneidar wrote:


Wha?? Metal Buttocks?? I think we have a new ban category!!

All in fun,
Bob


On Jan 31, 2011, at 11:12 AM, Keith Clarke wrote:


I don't really know what I'm talking about here - this is probably all 
metabollocks.


___
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: An idea on multithreading implementation

[Keith Clarke]

Bollox is the detailed rubbish - metabollox is the multi-faceted architecture 
of the detailed rubbish. A kind of virtual landfill!

Metal Buttocks is a completely different website! ;-)

...I'll get my coat... 

On 31 Jan 2011, at 19:43, Bob Sneidar wrote:

> Wha?? Metal Buttocks?? I think we have a new ban category!! 
> 
> All in fun, 
> Bob
> 
> 
> On Jan 31, 2011, at 11:12 AM, Keith Clarke wrote:
> 
>> I don't really know what I'm talking about here - this is probably all 
>> metabollocks.
> 
> 
> ___
> 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: An idea on multithreading implementation

[Bob Sneidar]

Wha?? Metal Buttocks?? I think we have a new ban category!! 

All in fun, 
Bob


On Jan 31, 2011, at 11:12 AM, Keith Clarke wrote:

> I don't really know what I'm talking about here - this is probably all 
> metabollocks.


___
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: An idea on multithreading implementation

[Keith Clarke]

Taking Pete's idea a tad further, is there any mileage in considering shifting 
the 'threading' problem up from within the engine to the level of distributed 
computing/integration?

What if the main application could call upon an LC 'governor' library - with 
message broker/load balancer/workflow capabilities that could worry about state 
and overall application workflow, whilst using an SOA-like architecture, to 
spawn instances of LC engines, as needed, to run discrete processes (the 
'threads') and pass results back through the 'governor' application? Could a 
set of LiveCode, platform-independent REST-type messages - request, 
acknowledgement, response - be used to manage the communications? The governor 
app could also provide process control, monitoring the triggered LC engine 
instances and if necessary, killing and restarting, etc. Would such an approach 
also allow greater scalability, with multiple LC 'work-horse' engines running 
on one or more boxes? That might be tempting for Revserver situations? 

I don't really know what I'm talking about here - this is probably all 
metabollocks. However, perhaps the problems of managing a network of simple 
things might be easier than creating a bigger, monolithic, slower, riskier, 
multi-threading engine?
Best,
Keith..

On 31 Jan 2011, at 18:41, Peter Haworth wrote:

> I'll admit that I've never had the need to do this with LC but it feels like 
> it should be possible.  How about this.
> 
> Make your "Accounts Receivable" a separate standalone LC application and 
> start it up from your main application when it starts up. 
> 
> The AR program would have an appleEvent handler in it looking for messages 
> sent to it with a "send to program" command from your main App and use the 
> request appleEvent command to get whatever data you send to it.  Or your main 
> app could put the data in some place accessible to both programs, perhaps an 
> SQL table of pending requests.  
> 
> On receipt of the appleEvent, the AR program would do it's thing and send an 
> AppleEvent back to your main program when it's done or report progress back 
> at regular intervals, whatever you need it to do. 
> 
> When it's done, it would sit there waiting for another appleEvent to tell it 
> what to do next.   
> 
> There don't seem to be equivalents to send to program and appleEvent for 
> Windows but I'll bet some of the smart people on this list can suggest 
> something (and perhaps a better way of doing it on a Mac)
> 
> I'm sure this is an over-simplistic description but it seems like it oughta 
> work?
> 
> Pete Haworth
> 
> On Jan 31, 2011, at 9:56 AM, Bob Sneidar wrote:
> 
>> When I started this whole thread, what I had in mind was a simple method for 
>> allowing commands and even whole stacks to run concurrently with other 
>> stacks, while still being able to communicate with each other through the 
>> engine. All the stuff about enabling and disabling communications between 
>> things is to me irrelevant. Just compile 2 apps and they will not be able to 
>> talk natively to each other. Done deal. 
>> 
>> Some tell me that multithreading is not that simple. Well nothing under the 
>> hood of any app is simple, and triply so for a development environment. My 
>> idea was for the engine to handle communications between all of it's objects 
>> the way it does now, but have concurrent processes IF YOU WANTED. 
>> 
>> By default, I envision LiveCode working just the way it does now, with the 
>> OPTION to say something like: 
>> 
>> open stack "Accounts Receivable" with new thread
>> or 
>> do ReportGen with new thread
>> 
>> I could then check in on the state of a global from time to time in my 
>> Progress Bar modal stack or switch back to my "Order Entry" stack and 
>> continue entering my customer's order while the report generator was 
>> running. See? I personally do not have any interest whatsoever managing all 
>> the threading myself. I use LiveCode so I do not HAVE to know or understand 
>> that sort of thing. I am only one person. One of the things that LiveCode 
>> allows us to do, which is not talked about much, is to produce really nice 
>> and functional applications with incredibly minimal resources (like only one 
>> developer!)
>> 
>> Bob
>> 
>> 
>> On Jan 31, 2011, at 9:35 AM, form wrote:
>> 
>>> Even discounting games, I'd love to be able to designate a substack to being
>>> "threaded", disabling its access to objects in other stacks, and limiting
>>> communication to event/message passing.
>>> 
>>> It would be very much like using the open process command with a Windows
>>> command line program. (WHY doesn't it work with Mac command line
>>> programs?!?!)
>>> 
>>> I use open process is a stack to start a makefile and monitor its output
>>> while keeping the interface perfectly responsive. I do the same on a mac
>>> using a shell command outputting to a text file that I sample the tail from
>>> in another shell command. Hackier, but it gets the basic jo

Re: An idea on multithreading implementation

[Andre Garzia]

Bob,

thanks for the kind words.

My idea is that if we just had some more introspection power from the
engine, we could implement this and even more in pure livecode script,
if we did that in some smart way, others would benefit without
understanding the internals, just like SSL, I have no clue how that
work but I use it all the time! :-D

Cheers
andre

On Mon, Jan 31, 2011 at 4:36 PM, Bob Sneidar  wrote:
> Thanks Andre I read that. Good stuff. I was thinking it might be possible to 
> do really simply internally to the engine so pea brains like me wouldn't have 
> to wrap their minds around stateful programming. Maybe I am barking up the 
> wrong data tree.Bob
>
> Bob
>
>
> On Jan 31, 2011, at 10:30 AM, Andre Garzia wrote:
>
>> Folks,
>>
>> I've posted an email to this list with subject "on livecode idea"
>> dealing with some solutions for cooperative threading with state.
>>
>> cheers
>> andre
>
>
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.

___
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: An idea on multithreading implementation

[Peter Haworth]

I'll admit that I've never had the need to do this with LC but it feels like it 
should be possible.  How about this.

Make your "Accounts Receivable" a separate standalone LC application and start 
it up from your main application when it starts up. 

The AR program would have an appleEvent handler in it looking for messages sent 
to it with a "send to program" command from your main App and use the request 
appleEvent command to get whatever data you send to it.  Or your main app could 
put the data in some place accessible to both programs, perhaps an SQL table of 
pending requests.  

On receipt of the appleEvent, the AR program would do it's thing and send an 
AppleEvent back to your main program when it's done or report progress back at 
regular intervals, whatever you need it to do. 

When it's done, it would sit there waiting for another appleEvent to tell it 
what to do next.   

There don't seem to be equivalents to send to program and appleEvent for 
Windows but I'll bet some of the smart people on this list can suggest 
something (and perhaps a better way of doing it on a Mac)

I'm sure this is an over-simplistic description but it seems like it oughta 
work?

Pete Haworth

On Jan 31, 2011, at 9:56 AM, Bob Sneidar wrote:

> When I started this whole thread, what I had in mind was a simple method for 
> allowing commands and even whole stacks to run concurrently with other 
> stacks, while still being able to communicate with each other through the 
> engine. All the stuff about enabling and disabling communications between 
> things is to me irrelevant. Just compile 2 apps and they will not be able to 
> talk natively to each other. Done deal. 
> 
> Some tell me that multithreading is not that simple. Well nothing under the 
> hood of any app is simple, and triply so for a development environment. My 
> idea was for the engine to handle communications between all of it's objects 
> the way it does now, but have concurrent processes IF YOU WANTED. 
> 
> By default, I envision LiveCode working just the way it does now, with the 
> OPTION to say something like: 
> 
> open stack "Accounts Receivable" with new thread
> or 
> do ReportGen with new thread
> 
> I could then check in on the state of a global from time to time in my 
> Progress Bar modal stack or switch back to my "Order Entry" stack and 
> continue entering my customer's order while the report generator was running. 
> See? I personally do not have any interest whatsoever managing all the 
> threading myself. I use LiveCode so I do not HAVE to know or understand that 
> sort of thing. I am only one person. One of the things that LiveCode allows 
> us to do, which is not talked about much, is to produce really nice and 
> functional applications with incredibly minimal resources (like only one 
> developer!)
> 
> Bob
> 
> 
> On Jan 31, 2011, at 9:35 AM, form wrote:
> 
>> Even discounting games, I'd love to be able to designate a substack to being
>> "threaded", disabling its access to objects in other stacks, and limiting
>> communication to event/message passing.
>> 
>> It would be very much like using the open process command with a Windows
>> command line program. (WHY doesn't it work with Mac command line
>> programs?!?!)
>> 
>> I use open process is a stack to start a makefile and monitor its output
>> while keeping the interface perfectly responsive. I do the same on a mac
>> using a shell command outputting to a text file that I sample the tail from
>> in another shell command. Hackier, but it gets the basic job done.
>> 
>> But if I have LiveCode that I want to start and monitor, I'm out of luck.
>> (Without getting REALLY hacky, that is.)
>> 
>> ~ Chris Innanen
>> ~ Nonsanity
>> 
>> 
>> On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar  wrote:
>> 
>>> Well now that there is Livecode for iApps, a lot of people may want it, but
>>> I for one am never going to develop a game, even a simple one.
>>> 
>>> Bob
>>> 
>>> 
>>> On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
>>> 
 Hi All,
 
 It's nice to read discussions about features that
 enhance this platform, but now I have one doubt:
 
 How many developers (who use Livecode) want
 to see this platform converted in a game engine?
 
 Notice that the only DLL in my wish list for this
 platform is a SWF player, that allows to run
 movies inside a stack, just like the Quicktime
 externals. I do not want to see a Timeline
 in this platform...
 
 At least in my mind, you could not build (easily)
 the kind of applications created with Livecode
 if it were a game engine. Am I wrong?
 
 Or There are no boundaries anymore among
 Software Development tools?
 
 Al
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
 http://lists.runrev

Re: An idea on multithreading implementation

[Bob Sneidar]

Thanks Andre I read that. Good stuff. I was thinking it might be possible to do 
really simply internally to the engine so pea brains like me wouldn't have to 
wrap their minds around stateful programming. Maybe I am barking up the wrong 
data tree. 

Bob


On Jan 31, 2011, at 10:30 AM, Andre Garzia wrote:

> Folks,
> 
> I've posted an email to this list with subject "on livecode idea"
> dealing with some solutions for cooperative threading with state.
> 
> cheers
> andre


___
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: An idea on multithreading implementation

[Bob Sneidar]

I don't understand how you could have a deadlock. If you mean call something 
from one threaded stack which in turn calls something in the first threaded 
stack, then I would say, don't do that! Same as I would say, don't write an 
infinite loop! Sure you can, why would you?

Bob


On Jan 31, 2011, at 10:25 AM, Geoff Canyon Rev wrote:

> How would you handle race conditions and deadlock in a livecode-like way? If
> the engine could make it as easy as "with new thread" that would be awesome,
> but I think we'd also need ways to prevent/handle the issues that come with
> concurrency.
> 
> gc
> 
> On Mon, Jan 31, 2011 at 11:56 AM, Bob Sneidar  wrote:
> 
>> When I started this whole thread, what I had in mind was a simple method
>> for allowing commands and even whole stacks to run concurrently with other
>> stacks, while still being able to communicate with each other through the
>> engine. All the stuff about enabling and disabling communications between
>> things is to me irrelevant. Just compile 2 apps and they will not be able to
>> talk natively to each other. Done deal.
>> 
>> Some tell me that multithreading is not that simple. Well nothing under the
>> hood of any app is simple, and triply so for a development environment. My
>> idea was for the engine to handle communications between all of it's objects
>> the way it does now, but have concurrent processes IF YOU WANTED.
>> 
>> By default, I envision LiveCode working just the way it does now, with the
>> OPTION to say something like:
>> 
>> open stack "Accounts Receivable" with new thread
>> or
>> do ReportGen with new thread
>> 
>> I could then check in on the state of a global from time to time in my
>> Progress Bar modal stack or switch back to my "Order Entry" stack and
>> continue entering my customer's order while the report generator was
>> running. See? I personally do not have any interest whatsoever managing all
>> the threading myself. I use LiveCode so I do not HAVE to know or understand
>> that sort of thing. I am only one person. One of the things that LiveCode
>> allows us to do, which is not talked about much, is to produce really nice
>> and functional applications with incredibly minimal resources (like only one
>> developer!)
>> 
>> Bob
>> 
>> 
>> On Jan 31, 2011, at 9:35 AM, form wrote:
>> 
>>> Even discounting games, I'd love to be able to designate a substack to
>> being
>>> "threaded", disabling its access to objects in other stacks, and limiting
>>> communication to event/message passing.
>>> 
>>> It would be very much like using the open process command with a Windows
>>> command line program. (WHY doesn't it work with Mac command line
>>> programs?!?!)
>>> 
>>> I use open process is a stack to start a makefile and monitor its output
>>> while keeping the interface perfectly responsive. I do the same on a mac
>>> using a shell command outputting to a text file that I sample the tail
>> from
>>> in another shell command. Hackier, but it gets the basic job done.
>>> 
>>> But if I have LiveCode that I want to start and monitor, I'm out of luck.
>>> (Without getting REALLY hacky, that is.)
>>> 
>>> ~ Chris Innanen
>>> ~ Nonsanity
>>> 
>>> 
>>> On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar  wrote:
>>> 
 Well now that there is Livecode for iApps, a lot of people may want it,
>> but
 I for one am never going to develop a game, even a simple one.
 
 Bob
 
 
 On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
 
> Hi All,
> 
> It's nice to read discussions about features that
> enhance this platform, but now I have one doubt:
> 
> How many developers (who use Livecode) want
> to see this platform converted in a game engine?
> 
> Notice that the only DLL in my wish list for this
> platform is a SWF player, that allows to run
> movies inside a stack, just like the Quicktime
> externals. I do not want to see a Timeline
> in this platform...
> 
> At least in my mind, you could not build (easily)
> the kind of applications created with Livecode
> if it were a game engine. Am I wrong?
> 
> Or There are no boundaries anymore among
> Software Development tools?
> 
> Al
> 
> ___
> 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

Re: An idea on multithreading implementation

[Andre Garzia]

Folks,

I've posted an email to this list with subject "on livecode idea"
dealing with some solutions for cooperative threading with state.

cheers
andre

On Mon, Jan 31, 2011 at 4:25 PM, Geoff Canyon Rev  wrote:
> How would you handle race conditions and deadlock in a livecode-like way? If
> the engine could make it as easy as "with new thread" that would be awesome,
> but I think we'd also need ways to prevent/handle the issues that come with
> concurrency.
>
> gc
>
> On Mon, Jan 31, 2011 at 11:56 AM, Bob Sneidar  wrote:
>
>> When I started this whole thread, what I had in mind was a simple method
>> for allowing commands and even whole stacks to run concurrently with other
>> stacks, while still being able to communicate with each other through the
>> engine. All the stuff about enabling and disabling communications between
>> things is to me irrelevant. Just compile 2 apps and they will not be able to
>> talk natively to each other. Done deal.
>>
>> Some tell me that multithreading is not that simple. Well nothing under the
>> hood of any app is simple, and triply so for a development environment. My
>> idea was for the engine to handle communications between all of it's objects
>> the way it does now, but have concurrent processes IF YOU WANTED.
>>
>> By default, I envision LiveCode working just the way it does now, with the
>> OPTION to say something like:
>>
>> open stack "Accounts Receivable" with new thread
>> or
>> do ReportGen with new thread
>>
>> I could then check in on the state of a global from time to time in my
>> Progress Bar modal stack or switch back to my "Order Entry" stack and
>> continue entering my customer's order while the report generator was
>> running. See? I personally do not have any interest whatsoever managing all
>> the threading myself. I use LiveCode so I do not HAVE to know or understand
>> that sort of thing. I am only one person. One of the things that LiveCode
>> allows us to do, which is not talked about much, is to produce really nice
>> and functional applications with incredibly minimal resources (like only one
>> developer!)
>>
>> Bob
>>
>>
>> On Jan 31, 2011, at 9:35 AM, form wrote:
>>
>> > Even discounting games, I'd love to be able to designate a substack to
>> being
>> > "threaded", disabling its access to objects in other stacks, and limiting
>> > communication to event/message passing.
>> >
>> > It would be very much like using the open process command with a Windows
>> > command line program. (WHY doesn't it work with Mac command line
>> > programs?!?!)
>> >
>> > I use open process is a stack to start a makefile and monitor its output
>> > while keeping the interface perfectly responsive. I do the same on a mac
>> > using a shell command outputting to a text file that I sample the tail
>> from
>> > in another shell command. Hackier, but it gets the basic job done.
>> >
>> > But if I have LiveCode that I want to start and monitor, I'm out of luck.
>> > (Without getting REALLY hacky, that is.)
>> >
>> > ~ Chris Innanen
>> > ~ Nonsanity
>> >
>> >
>> > On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar  wrote:
>> >
>> >> Well now that there is Livecode for iApps, a lot of people may want it,
>> but
>> >> I for one am never going to develop a game, even a simple one.
>> >>
>> >> Bob
>> >>
>> >>
>> >> On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
>> >>
>> >>> Hi All,
>> >>>
>> >>> It's nice to read discussions about features that
>> >>> enhance this platform, but now I have one doubt:
>> >>>
>> >>> How many developers (who use Livecode) want
>> >>> to see this platform converted in a game engine?
>> >>>
>> >>> Notice that the only DLL in my wish list for this
>> >>> platform is a SWF player, that allows to run
>> >>> movies inside a stack, just like the Quicktime
>> >>> externals. I do not want to see a Timeline
>> >>> in this platform...
>> >>>
>> >>> At least in my mind, you could not build (easily)
>> >>> the kind of applications created with Livecode
>> >>> if it were a game engine. Am I wrong?
>> >>>
>> >>> Or There are no boundaries anymore among
>> >>> Software Development tools?
>> >>>
>> >>> Al
>> >>>
>> >>> ___
>> >>> 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-livec

Re: An idea on multithreading implementation

[Geoff Canyon Rev]

How would you handle race conditions and deadlock in a livecode-like way? If
the engine could make it as easy as "with new thread" that would be awesome,
but I think we'd also need ways to prevent/handle the issues that come with
concurrency.

gc

On Mon, Jan 31, 2011 at 11:56 AM, Bob Sneidar  wrote:

> When I started this whole thread, what I had in mind was a simple method
> for allowing commands and even whole stacks to run concurrently with other
> stacks, while still being able to communicate with each other through the
> engine. All the stuff about enabling and disabling communications between
> things is to me irrelevant. Just compile 2 apps and they will not be able to
> talk natively to each other. Done deal.
>
> Some tell me that multithreading is not that simple. Well nothing under the
> hood of any app is simple, and triply so for a development environment. My
> idea was for the engine to handle communications between all of it's objects
> the way it does now, but have concurrent processes IF YOU WANTED.
>
> By default, I envision LiveCode working just the way it does now, with the
> OPTION to say something like:
>
> open stack "Accounts Receivable" with new thread
> or
> do ReportGen with new thread
>
> I could then check in on the state of a global from time to time in my
> Progress Bar modal stack or switch back to my "Order Entry" stack and
> continue entering my customer's order while the report generator was
> running. See? I personally do not have any interest whatsoever managing all
> the threading myself. I use LiveCode so I do not HAVE to know or understand
> that sort of thing. I am only one person. One of the things that LiveCode
> allows us to do, which is not talked about much, is to produce really nice
> and functional applications with incredibly minimal resources (like only one
> developer!)
>
> Bob
>
>
> On Jan 31, 2011, at 9:35 AM, form wrote:
>
> > Even discounting games, I'd love to be able to designate a substack to
> being
> > "threaded", disabling its access to objects in other stacks, and limiting
> > communication to event/message passing.
> >
> > It would be very much like using the open process command with a Windows
> > command line program. (WHY doesn't it work with Mac command line
> > programs?!?!)
> >
> > I use open process is a stack to start a makefile and monitor its output
> > while keeping the interface perfectly responsive. I do the same on a mac
> > using a shell command outputting to a text file that I sample the tail
> from
> > in another shell command. Hackier, but it gets the basic job done.
> >
> > But if I have LiveCode that I want to start and monitor, I'm out of luck.
> > (Without getting REALLY hacky, that is.)
> >
> > ~ Chris Innanen
> > ~ Nonsanity
> >
> >
> > On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar  wrote:
> >
> >> Well now that there is Livecode for iApps, a lot of people may want it,
> but
> >> I for one am never going to develop a game, even a simple one.
> >>
> >> Bob
> >>
> >>
> >> On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
> >>
> >>> Hi All,
> >>>
> >>> It's nice to read discussions about features that
> >>> enhance this platform, but now I have one doubt:
> >>>
> >>> How many developers (who use Livecode) want
> >>> to see this platform converted in a game engine?
> >>>
> >>> Notice that the only DLL in my wish list for this
> >>> platform is a SWF player, that allows to run
> >>> movies inside a stack, just like the Quicktime
> >>> externals. I do not want to see a Timeline
> >>> in this platform...
> >>>
> >>> At least in my mind, you could not build (easily)
> >>> the kind of applications created with Livecode
> >>> if it were a game engine. Am I wrong?
> >>>
> >>> Or There are no boundaries anymore among
> >>> Software Development tools?
> >>>
> >>> Al
> >>>
> >>> ___
> >>> 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 

Re: An idea on multithreading implementation

[Bob Sneidar]

When I started this whole thread, what I had in mind was a simple method for 
allowing commands and even whole stacks to run concurrently with other stacks, 
while still being able to communicate with each other through the engine. All 
the stuff about enabling and disabling communications between things is to me 
irrelevant. Just compile 2 apps and they will not be able to talk natively to 
each other. Done deal. 

Some tell me that multithreading is not that simple. Well nothing under the 
hood of any app is simple, and triply so for a development environment. My idea 
was for the engine to handle communications between all of it's objects the way 
it does now, but have concurrent processes IF YOU WANTED. 

By default, I envision LiveCode working just the way it does now, with the 
OPTION to say something like: 

open stack "Accounts Receivable" with new thread
or 
do ReportGen with new thread

I could then check in on the state of a global from time to time in my Progress 
Bar modal stack or switch back to my "Order Entry" stack and continue entering 
my customer's order while the report generator was running. See? I personally 
do not have any interest whatsoever managing all the threading myself. I use 
LiveCode so I do not HAVE to know or understand that sort of thing. I am only 
one person. One of the things that LiveCode allows us to do, which is not 
talked about much, is to produce really nice and functional applications with 
incredibly minimal resources (like only one developer!)

Bob


On Jan 31, 2011, at 9:35 AM, form wrote:

> Even discounting games, I'd love to be able to designate a substack to being
> "threaded", disabling its access to objects in other stacks, and limiting
> communication to event/message passing.
> 
> It would be very much like using the open process command with a Windows
> command line program. (WHY doesn't it work with Mac command line
> programs?!?!)
> 
> I use open process is a stack to start a makefile and monitor its output
> while keeping the interface perfectly responsive. I do the same on a mac
> using a shell command outputting to a text file that I sample the tail from
> in another shell command. Hackier, but it gets the basic job done.
> 
> But if I have LiveCode that I want to start and monitor, I'm out of luck.
> (Without getting REALLY hacky, that is.)
> 
> ~ Chris Innanen
> ~ Nonsanity
> 
> 
> On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar  wrote:
> 
>> Well now that there is Livecode for iApps, a lot of people may want it, but
>> I for one am never going to develop a game, even a simple one.
>> 
>> Bob
>> 
>> 
>> On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
>> 
>>> Hi All,
>>> 
>>> It's nice to read discussions about features that
>>> enhance this platform, but now I have one doubt:
>>> 
>>> How many developers (who use Livecode) want
>>> to see this platform converted in a game engine?
>>> 
>>> Notice that the only DLL in my wish list for this
>>> platform is a SWF player, that allows to run
>>> movies inside a stack, just like the Quicktime
>>> externals. I do not want to see a Timeline
>>> in this platform...
>>> 
>>> At least in my mind, you could not build (easily)
>>> the kind of applications created with Livecode
>>> if it were a game engine. Am I wrong?
>>> 
>>> Or There are no boundaries anymore among
>>> Software Development tools?
>>> 
>>> Al
>>> 
>>> ___
>>> 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: An idea on multithreading implementation

[form]

Even discounting games, I'd love to be able to designate a substack to being
"threaded", disabling its access to objects in other stacks, and limiting
communication to event/message passing.

It would be very much like using the open process command with a Windows
command line program. (WHY doesn't it work with Mac command line
programs?!?!)

I use open process is a stack to start a makefile and monitor its output
while keeping the interface perfectly responsive. I do the same on a mac
using a shell command outputting to a text file that I sample the tail from
in another shell command. Hackier, but it gets the basic job done.

But if I have LiveCode that I want to start and monitor, I'm out of luck.
(Without getting REALLY hacky, that is.)

 ~ Chris Innanen
 ~ Nonsanity


On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar  wrote:

> Well now that there is Livecode for iApps, a lot of people may want it, but
> I for one am never going to develop a game, even a simple one.
>
> Bob
>
>
> On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
>
> > Hi All,
> >
> > It's nice to read discussions about features that
> > enhance this platform, but now I have one doubt:
> >
> > How many developers (who use Livecode) want
> > to see this platform converted in a game engine?
> >
> > Notice that the only DLL in my wish list for this
> > platform is a SWF player, that allows to run
> > movies inside a stack, just like the Quicktime
> > externals. I do not want to see a Timeline
> > in this platform...
> >
> > At least in my mind, you could not build (easily)
> > the kind of applications created with Livecode
> > if it were a game engine. Am I wrong?
> >
> > Or There are no boundaries anymore among
> > Software Development tools?
> >
> > Al
> >
> > ___
> > 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: An idea on multithreading implementation

[Bob Sneidar]

Well now that there is Livecode for iApps, a lot of people may want it, but I 
for one am never going to develop a game, even a simple one. 

Bob


On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:

> Hi All,
> 
> It's nice to read discussions about features that
> enhance this platform, but now I have one doubt:
> 
> How many developers (who use Livecode) want
> to see this platform converted in a game engine?
> 
> Notice that the only DLL in my wish list for this
> platform is a SWF player, that allows to run
> movies inside a stack, just like the Quicktime
> externals. I do not want to see a Timeline
> in this platform...
> 
> At least in my mind, you could not build (easily)
> the kind of applications created with Livecode
> if it were a game engine. Am I wrong?
> 
> Or There are no boundaries anymore among
> Software Development tools?
> 
> Al
> 
> ___
> 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

on livecode based idea (was Re: An idea on multithreading implementation)

[Andre Garzia]

Folks,

>From working with livecode based servers for some year, I've drafted a
little plan about co-routines. I don't have access to the engine
internals, so when I think about solving a problem, I try to think in
terms of the livecode interface that is exposed to us. Even though I
would welcome threads, process forking and whatever, there is a way to
create co-routines in livecode by extending some simple routines. What
I will tell on this email will not add performance but it may add some
advantadge on how to express things.

The problem with "wait with 0 ticks" and other send in time routines
is that state is not preserved and that we cannot yield to the middle
of a handler. Our problem is not switching handlers, our problem is
state maintenance. So let us get the ball rolling.

The first thing we need is a way to freeze a computation in time. By
checking "the variableNames"
(http://docs.runrev.com/Function/variableNames) and looping thru "the
executionContexts" (http://docs.runrev.com/Property/executionContexts)
it is possible to get an "instantaneous image" of what the engine is
doing. Now, looping "the pendingMessages"
(http://docs.runrev.com/Property/pendingMessages) as well would get
what more is happening alongside the given script. We could then save
all this information in what I will call for the lack of better term
"the current continuation" (it is not a true continuation).

So after the above steps we have a chunk of what is happening saved
and stored. We now need a way to invoke a continuation, to restore a
given piece of state. Right now, I think the only way to do it (or to
fake it) is to use the debug routines. I think that is is possible to
create a script runtime breakpoint, then, by execution it with the
debug routines and stopping there, it is possible to manipulate the
environment to load the state that was preserved before. This script
should have the local and script local and global declarations needed
for the given state, then we change all these variables to contain the
data preserved from the desired continuation, we schedule the
pendingMessages as well. Now the tricky thing is, we need an
enhancement to the debugDo or some other debug internal command to
start executing a script from a specific line. The executionContexts
need to be used both ways, not only to peer on how we got to some
place but set so that we can restore a previous state. If we could set
the executionContexts and the next debugDo command would follow the
natural computation from the current set executionContexts, we would
be all set.

So trough the use of a save state routine in pure LiveCode script we
could save a continuation for later use. Using LiveCode powerful debug
routines with some enhancements, we would then be able to restore to a
given state in time. These two routines would be the basis that would
enable us to do the following items:

CO-ROUTINES (cooperative)

A simple scheduler would save and restore states using cooperative
threads where a given handler would call "yield" which would save his
current state and then be restored to that exact point when the
scheduler calls it again

BACKTRACKING

Some powerful decision making algorithms could be implemented. A
script could branch into multiple paths to solve a problem and if
found a wrong answer, it could chain call the restore state function
effectively backtracking in time all its contexts and variables till
the point of the branching where it could then follow some other
branch. Backtracking is cool because once you found the correct
decision path you were looking for it appears that you have a straight
path since all the wrong options were erased due to backtracking.
Think of it like solving a maze, every time you take a wrong turn, you
erase everything until the given turn and then you continue from there
to the other turn. When you solve the maze, you can see a straight
path from your start position to the exit with not a single error. If
you can't think of a practical use for backtracking, let me tell you
two:

1) Error handling: Oops an error happened, backtrack until you solve
it, no side effects.
2) Brute force anything: brute force something until you have the
correct answer.

CONTINUATION-PASSING STYLE WEB PROGRAMMING

This is the big one for me. The main bad thing that hurt all web
developers is that the web is stateless. There is a lot of code in
anyones project to deal with sessions and finding where in the
computation (in time) some user is. Requests all looks the same, you
need to peek into cookies, hidden vars, urls until you find what you
should be doing. This is a pain when trying to do things that need to
happen in order with input from the user. For example, doing multiple
page forms with runtime decisions about what to show is hard due to
all the state maintenance. If we had continuations, we could simply
save all the computation, present the page to the user and when he
return, we restore the computation. This makes sta

Re: An idea on multithreading implementation

[David C.]

Geoff wrote:
> To those proposing a SWF player, why would that be better than an
> improvement in native LC graphics performance?
Sorry for taking this discussion in a different direction folks as I
never even looked at the title of the thread... just replied to what I
read. ooophs.

But since you ask Geoff, can't speak for anyone else, but the static
graphics that I use for (a very few) of my projects don't require any
performance enhancements. A browser control and working plugin for
Linux as well as an embeddable SWF player however, opens up a lot of
new territory. It's all just a matter of perspective and I hope that
each group gets what they need eventually. ;)

...now back your *your* topic at hand that I'm stomping around in and
trashing unmercifully.

Best regards,
David C.

___
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: An idea on multithreading implementation

[Alejandro Tejada]

Hi Geoff,


Geoff Canyon Rev wrote:
> 
> To those proposing a SWF player, why would that be better than an
> improvement in native LC graphics performance?
> 

Better? No, I could not say this, but less time to implement...
Yes, definitively less time. Notice that NeoBook had a SWF player
as an optional DLL many years ago and now it's part of the
default installation.

And Now, for a completely unrelated display of awesomeness,
visit this page with Google Chrome:
http://www.effectgames.com/demos/canvascycle/

8 bit color cycling was my second help request to
Scott Raney, back in the beginning of time... :-D

Al 

-- 
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/An-idea-on-multithreading-implementation-tp3224097p3246832.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: An idea on multithreading implementation

[Geoff Canyon Rev]

To those proposing a SWF player, why would that be better than an
improvement in native LC graphics performance?
___
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: An idea on multithreading implementation

[Geoff Canyon Rev]

On Sat, Jan 29, 2011 at 3:31 PM, Jeffrey Massung  wrote:

> Geoff (btw, Jeff here ;-)),
>
> Okay, I think I completely understand where the disconnect lies - and it's
> with my understanding of the LC internals. I put together a very simple
> stack that's nothing more than a field "Test" and a button. The button
> script looks like this:
>
...

>
> Now, if LC essentially already had coroutines, when done, the output in the
> field should be something like "1a2b3c..." (with newlines of course).
> However, that's not what's in the field. Instead the output is
> "123456...abcdef..." This is likely what you were alluding to and I wasn't
> getting, and this puts an entirely different face on the conversation.
>

Yep, that's what I was talking about. Sorry I wasn't clearer.


>
> The issue isn't coroutines vs. whatever so much as LC doesn't actually
> allow (from what I can tell) for multiple execution contexts. Coroutines -
> obviously - is one method of achieving this goal, and I would agree that it
> is a preferred solution.


> I hope the test above puts this discussion to rest and is a hint to the Rev
> team on a direction they can take.
>

I'd vote for that.


>
> Now, not to be pedantic, but your last paragraph didn't really make much
> sense [to me]. Coroutines - since they must yield and don't run in parallel
> - are are still single-threaded. This means that you could run 100 contexts
> on 100 HW threads, and your program will run at exactly the same speed as if
> they were on 1 HW thread (this assumes that the OS isn't hyperthreading your
> application with others).
>
>
In what way do you think threads would speed up performance?
___
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: An idea on multithreading implementation

[David C.]

On Sat, Jan 29, 2011 at 7:06 PM, Alejandro wrote:

> Notice that the only DLL in my wish list for this
> platform is a SWF player, that allows to run
> movies inside a stack, just like the Quicktime
> externals. I do not want to see a Timeline
> in this platform...

Hi Al,
An SWF player that will work on all three platforms and/or at least a
browser control (and plugin) for Linux would be awesome! Where do we
sign up?  ;-)

Best regards,
David C.

___
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: An idea on multithreading implementation

[Alejandro Tejada]

Hi All,

It's nice to read discussions about features that
enhance this platform, but now I have one doubt:

How many developers (who use Livecode) want
to see this platform converted in a game engine?

Notice that the only DLL in my wish list for this
platform is a SWF player, that allows to run
movies inside a stack, just like the Quicktime
externals. I do not want to see a Timeline
in this platform...

At least in my mind, you could not build (easily)
the kind of applications created with Livecode
if it were a game engine. Am I wrong?

Or There are no boundaries anymore among
Software Development tools?

Al

___
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: An idea on multithreading implementation

[Richard Gaskin]

Scott Rossi wrote:
> But fast graphics processing would be a very welcome addition.

Here's one option that would give order-of-magnitude speed increases to 
any object that takes advantage of the current graphic effects, 
implementable by merely extending existing syntax to allow an 
"alwaysBuffer" property for all controls:




As it is, any object that uses the otherwise-powerful graphic effects 
cannot be selected, moved or animated without prohibitive cost to 
performance.


We could convert such objects to bitmaps ourselves if not for a design 
decision not to allow it:



I'd be okay with the current lack of buffering of the rendering of 
graphic effects and a default of not allowing one to export snapshots of 
such objects as long as there were options to do otherwise.


But as it is, I find myself not using graphic effect nearly as often as 
I'd like to, instead making such treatments in other programs and then 
importing the masked PNGs


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

___
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: An idea on multithreading implementation

[Jeffrey Massung]

Geoff (btw, Jeff here ;-)),

Okay, I think I completely understand where the disconnect lies - and it's with 
my understanding of the LC internals. I put together a very simple stack that's 
nothing more than a field "Test" and a button. The button script looks like 
this:

on mouseUp
   putNumbers
   putLetters
end mouseUp

command putNumbers
   repeat with i = 1 to 26
  put i & cr after fld "Test" 
  wait 0 ticks with messages
   end repeat
end putNumbers

command putLetters
   repeat for each char x in "abcdefghijklmnopqrstuvwxyz"
  put x & cr after fld "Test"
  wait 0 ticks with messages
   end repeat
end putLetters


Now, if LC essentially already had coroutines, when done, the output in the 
field should be something like "1a2b3c..." (with newlines of course). However, 
that's not what's in the field. Instead the output is "123456...abcdef..." This 
is likely what you were alluding to and I wasn't getting, and this puts an 
entirely different face on the conversation.

The issue isn't coroutines vs. whatever so much as LC doesn't actually allow 
(from what I can tell) for multiple execution contexts. Coroutines - obviously 
- is one method of achieving this goal, and I would agree that it is a 
preferred solution.

I hope the test above puts this discussion to rest and is a hint to the Rev 
team on a direction they can take.

Now, not to be pedantic, but your last paragraph didn't really make much sense 
[to me]. Coroutines - since they must yield and don't run in parallel - are are 
still single-threaded. This means that you could run 100 contexts on 100 HW 
threads, and your program will run at exactly the same speed as if they were on 
1 HW thread (this assumes that the OS isn't hyperthreading your application 
with others).

Anyway, yes, coroutines is one very nice way of achieving "parallelism" is LC 
w/o needing locks. However, I still think LC needs pre-emption in at least a 
basic form (like my example of forcing a coroutine to become live every so 
often).

Cheers, and hope you are having a good weekend!

Jeff M.
___
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: An idea on multithreading implementation

[Scott Rossi]

On Jan 29, 2011, at 9:53 AM, Geoff Canyon Rev  wrote:

> based on your OpenGL comment, I
> think we're both agreed that for game-style graphics performance, neither
> coroutines nor threads will fix the problem -- what's needed (if indeed
> people want this) is a new graphics library, either as a plugin or directly
> in the engine.

+100

Have wanted this for years.  Even moving a single object around on a card can 
result in tearing (though after recently learning about the syncRate property, 
one might be able work around this to a degree).  But fast graphics processing 
would be a very welcome addition.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design




___
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: An idea on multithreading implementation

[Geoff Canyon Rev]

I think we're talking apples and oranges. As I said, the difference between
yield() and wait 0 ticks is that one supports two (or more) pieces of code
running in parallel (not simultaneously) with state, and the other doesn't.
This would be a big benefit when programming things like:


> > Currently it is very difficult simply to program any sort of
> > background task whatsoever: processing a log file, making aliens attack,
> > etc. "wait 0 ticks" simply isn't a good answer for those sorts of issues.
> > Ask Malte what he could do for animationEngine (and how much more simply)
> > with coroutines.
>
> Agreed that "wait 0 ticks" isn't a good solution to these sorts of issues,
> and I wasn't trying to imply that it was (if my original email came across
> that way).
>

So I think we're agreed that coroutines would make this easier than wait 0
ticks.


> Coroutines are not pre-emptive.
>

I didn't say they were. I also didn't say they'd improve performance.
Coroutines would make several types of programming problems much easier to
code. I'm not saying they'd make them run faster, except that there are
things that are prohibitively hard to do with wait that would be easy with
yield. Those things would run much faster, since they can't run at all now.


> As long as someone took the time to make an OpenGL plugin for LC, rendering
> could be made fast enough for most simple 2D games
>

Yes, of course if you bolt an engine on your bicycle it will go faster. I'm
not saying LiveCode _can't_ be made faster, just that threads + the current
architecture is still way too slow. Threading current LiveCode
graphics across 2, 4, or even 8 cores is going to give you a sucky game that
eats batteries and still can't compete with Flash on graphics, let alone
native code.

The problem with yielding (or "waiting" in LC terms) is that it basically
> puts me back into the Atari 2600 days of cycle counting, without the
> precision of being able to actually count cycles ;-). I have no idea how
> often I should yield in order to make things nice and smooth. It would be
> SOOO much more convenient if I could just make LC pre-emptive and wait for
> me like so:
>
> send "renderFrame" to me every 30 milliseconds
>

Agreed that pre-emptive threads (or messages if you like) would make this
easier to manage.

Summary:
>
> * What people seem to want here is pre-emption (however that happens).
>

Well, _I_ would be happy with coroutines, and I think I I understand what
I'm asking for ;-)


> * Coroutines are cooperative threads, which means they are not pre-emptive.
>

Yep, totally agreed. I still want them.


> * If you have to yield, it doesn't matter how many HW threads you use.
>

Perhaps agreed. If the underlying engine breaks up tasks and can run them
across multiple cores your whole app will be faster, but that's independent
of what we're doing above the engine. And based on your OpenGL comment, I
think we're both agreed that for game-style graphics performance, neither
coroutines nor threads will fix the problem -- what's needed (if indeed
people want this) is a new graphics library, either as a plugin or directly
in the engine.

regards,

Geoff
___
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: An idea on multithreading implementation

[Jeffrey Massung]

On Jan 28, 2011, at 7:59 AM, Geoff Canyon Rev wrote:

> On Fri, Jan 28, 2011 at 1:16 AM, Jeffrey Massung  wrote:
> 
>> 
>> Coroutines have absolutely no advantage over what's already provided by LC.
>> There's zero difference between saying "yield()" and "wait 0 ticks with
>> messages".
>> 
> 
> I realized that, apart from the fact that this isn't true, 

It is. I'm sorry. I wish it weren't. :-(


>> The purpose of mutli-threading is to take advantage of one or more of the
>> following: a completely separate hardware thread (program/code runs 100% in
>> parallel with another program/set of code - the only bottlenecks being
>> memory and I/O) or preemptive threading, typically by way of hyper-threading
>> on a single hardware thread (basically letting the hardware or OS decide
>> when to context switch for you).
>> 
> 
> This is true, but it's not a fair description of the current limitations of
> livecode. Currently it is very difficult simply to program any sort of
> background task whatsoever: processing a log file, making aliens attack,
> etc. "wait 0 ticks" simply isn't a good answer for those sorts of issues.
> Ask Malte what he could do for animationEngine (and how much more simply)
> with coroutines.

Agreed that "wait 0 ticks" isn't a good solution to these sorts of issues, and 
I wasn't trying to imply that it was (if my original email came across that 
way).


> [... Snipped some iPhone video game examples ..]
> 
> I'd be happy to be proven wrong.

Coroutines are not pre-emptive. They are called "cooperative threads" because 
you have to manage them with your own scheduling. That means yielding within a 
single hardware thread, which means you get no more benefit out of them than 
what LC already provides (except maybe a slightly different engine architecture 
that *might* be faster, but that's unprovable - or disprovable - by us without 
the LC source code). This isn't to say coroutines aren't great - Lua and other 
languages use them to much fanfare. Just that you pretty much have them already.

As far as games go, I also have to disagree there (that LC will always be too 
slow by orders of magnitude). This is an area I know a *lot* about and do this 
for a living. Now, I'm not suggesting that LC is what I would jump up and down 
to use to make my next video game with, but most video games are broken into 
two bits: simulation and rendering. 

As long as someone took the time to make an OpenGL plugin for LC, rendering 
could be made fast enough for most simple 2D games (the real issue would be the 
fact that "Everthing Is A String" in LC - and manipulating matrices with 
strings would be **SLOW**). So that leaves simulation. 

The problem with yielding (or "waiting" in LC terms) is that it basically puts 
me back into the Atari 2600 days of cycle counting, without the precision of 
being able to actually count cycles ;-). I have no idea how often I should 
yield in order to make things nice and smooth. It would be SOOO much more 
convenient if I could just make LC pre-emptive and wait for me like so:

send "renderFrame" to me every 30 milliseconds

And I'm done with it. It's like pretending to be a fake "green thread". All I 
care about is that it's pre-emptive. Anyway, I'd love to talk about this more 
offline if you want -- just shoot me an email. 

Summary:

* What people seem to want here is pre-emption (however that happens).
* Coroutines are cooperative threads, which means they are not pre-emptive.
* If you have to yield, it doesn't matter how many HW threads you use.

Jeff M,
___
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: An idea on multithreading implementation

[Geoff Canyon Rev]

On Fri, Jan 28, 2011 at 1:16 AM, Jeffrey Massung  wrote:

>
> Coroutines have absolutely no advantage over what's already provided by LC.
> There's zero difference between saying "yield()" and "wait 0 ticks with
> messages".
>

I realized that, apart from the fact that this isn't true, it's also kind of
my point: from a developer standpoint, coroutines work fairly similarly to
what many already do when they want to have two or three things going at
once. Hence they would be a significant improvement (because they maintain
state automatically) with very little effort required on the part of
livecode developers.

>
> The purpose of mutli-threading is to take advantage of one or more of the
> following: a completely separate hardware thread (program/code runs 100% in
> parallel with another program/set of code - the only bottlenecks being
> memory and I/O) or preemptive threading, typically by way of hyper-threading
> on a single hardware thread (basically letting the hardware or OS decide
> when to context switch for you).
>

This is true, but it's not a fair description of the current limitations of
livecode. Currently it is very difficult simply to program any sort of
background task whatsoever: processing a log file, making aliens attack,
etc. "wait 0 ticks" simply isn't a good answer for those sorts of issues.
Ask Malte what he could do for animationEngine (and how much more simply)
with coroutines.

Yes, threads are filled with awesome powah, but they're also a lot of work
to get right, and filled with pitfalls. Coroutines, by comparison, are easy,
and would make a lot of things easy to do that are currently hard or
impossible.

One other thing, just in case -- anyone who thinks threads will make
livecode a powerhouse for developing videogames is mistaken. That would
require an overhaul of the graphics engine. You can devote 100% of
livecode's attention to moving stuff around on the screen and come up short
on performance by a couple orders of magnitude. I don't say that to
criticize livecode, it's just that graphics performance isn't their focus,
never has been, and doesn't seem as though it will be any time soon.

Flight Control is well within livecode's capabilities now. Angry Birds might
be a stretch. Fruit Ninja would be a real achievement, and forget about Real
Racing.

I'd be happy to be proven wrong.

Ooo -- I just had an idea for a flight-control-like game. Guess I need to
get that iOS license after all...

gc
___
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: An idea on multithreading implementation

[David Bovill]

Hi Chris - I'd agree with this way of thinking about things for
multi-threading. I think it is intuitive, I don't think that restricting any
threaded code to it's own stack will cause any real limitations, and is
probably good practice. I do think conceptually it gives us a solid visual
metaphor of what is going on and how we can use messages to communicate
between processes.

My thoughts on this would be absolutely not to reveal the internal message
list of stacks, but rather use explicit "send" / dispatch syntax possibly
with some specific new system messages. I think the more radically the
internals of the thread are shielded from the rest of the environment the
better.

Finally I'd say we can do this already, without any changes to the existing
engine, simply by using multiple compiled apps within the existing IDE set
up. That way we get full threaded implementation with each thread running in
it's own process. All we need to add is some minimal message handling
support by the way of a standard library and a port
mapper
.

Ok - each thread may be 1mb or so larger in size than "needed" - but such
RAM requirements only rule out a subset of applications. Later RunRev can
add smaller footprint multithreading using the stack metaphor and existing
syntax, which would enable larger thread pools in server applications and so
forth.

Using the StackRunner / glxApp framework approach it would be entirely
possible for dynamic creation of threads simply by duplicating a standard
engine - stacks can be launched by these dynamic pools of engines, and
indeed be created on one process and used by another.

I can see no reason at all not to use the operating system to provide
threads in their own OS processes, as indeed other (low level) architectures
do. We can start simple, and produce useful multi-threaded additions to the
IDE and distributed applications without needing to wait for engine
enhancements. RunRev can pick up on this and help optimise things - but
there is nothing stopping us doing this in a fully robust way right now. All
our environments would be dramatically enhanced if we ran the IDE using
multiple engines - people are doing it already in a haphazard way. Trevor
and others like to run a separate engine for packaging apps - PowerDebug and
tRev (now something horsey) use this method to debug and edit scripts. A few
tweaks and we could all do this easily with existing syntax.

Or have I missed something. Anything wrong with the above?


On 27 January 2011 19:04, form  wrote:

> Just mulling the thought over... If a substack was tagged as being
> Threaded,
> then it couldn't "see" objects or events outside of itself. It would have
> its own event list that runs separately. So if the main stack is in the
> middle of a long process, the substack would still be interactive.
>
> The threaded stack CAN see the message list of the mainstack's thread, or
> at
> least it can drop something onto it. That would be how they pass
> information
> between them, sending messages.
>
> So you could make a threaded substack with a progress bar and a Cancel
> button. the mainstack can be deep in a single long function, sending
> progress update events to the threaded substack. While the mainstack would
> be unresponsive to the user - as it would be now - the progress dialog
> would
> still work.
>
> Clicking the Cancel button would send a message to the mainstack, to be
> executed when possible. Or while in a long function, the code can check to
> see if the cancel event is queued up, and abort early.
>
> The advantage to this method of threading is that it doesn't require the
> users to handle resource locking (which is a pain) or require the engine to
> have built-in resource locking on EVERY command (which would slow
> everything
> down). It puts the built-in locking in just one place, the message queue.
>
> My example can also be turned around so that the substack is doing the
> heavy
> lifting, and might not even be visible to the user. Probably a better
> design
> pattern. When its done it can send the results of its labors to the
> mainstack as an event with parameters. Meanwhile, the mainstack remains
> fully interactive to the user.
>
> Anyway, just an idle thought about how to quickly add a very usable version
> of threading to LiveCode without major code changes.
>
>  ~ Chris Innanen
>  ~ Nonsanity
> ___
> 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: An idea on multithreading implementation

[Geoff Canyon Rev]

The example given at wikipedia makes it obvious that this isn't true.
Coroutines are inherently stateful. Managing that by hand using wait 0 ticks
with messages is a disaster. I've done it.

As one brief example, suppose you have two lists that need to be processed
simultaneously. With coroutines you could use repeat for each line L in
whatever for each of the routines. With wait 0 ticks you would have to break
both lists up into arrays ahead of time or otherwise pay the performance
penalty.

Yes, threading and coroutines are not the same things. There are advantages
to threads, but as has already been pointed out, there are significant
disadvantages as well. Coroutines would enable many techniques that today
are awkward or impossible, with seemingly minimal muss and fuss.

gc



On Fri, Jan 28, 2011 at 1:16 AM, Jeffrey Massung  wrote:

>
> On Jan 27, 2011, at 10:54 PM, Geoff Canyon Rev wrote:
>
> > I'd suggest coroutines: http://en.wikipedia.org/wiki/Coroutine
> >
> > They have the advantage of being fairly similar to what some of us have
> done
> > already with send.in to get this sort of behavior, and probably wouldn't
> > break existing syntax.
>
>
> Coroutines have absolutely no advantage over what's already provided by LC.
> There's zero difference between saying "yield()" and "wait 0 ticks with
> messages".
>
> The purpose of mutli-threading is to take advantage of one or more of the
> following: a completely separate hardware thread (program/code runs 100% in
> parallel with another program/set of code - the only bottlenecks being
> memory and I/O) or preemptive threading, typically by way of hyper-threading
> on a single hardware thread (basically letting the hardware or OS decide
> when to context switch for you).
>
> Sorry. :-(
>
> Jeff M.
>
>
> ___
> 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: An idea on multithreading implementation

[Jeffrey Massung]

On Jan 27, 2011, at 10:54 PM, Geoff Canyon Rev wrote:

> I'd suggest coroutines: http://en.wikipedia.org/wiki/Coroutine
> 
> They have the advantage of being fairly similar to what some of us have done
> already with send.in to get this sort of behavior, and probably wouldn't
> break existing syntax.


Coroutines have absolutely no advantage over what's already provided by LC. 
There's zero difference between saying "yield()" and "wait 0 ticks with 
messages". 

The purpose of mutli-threading is to take advantage of one or more of the 
following: a completely separate hardware thread (program/code runs 100% in 
parallel with another program/set of code - the only bottlenecks being memory 
and I/O) or preemptive threading, typically by way of hyper-threading on a 
single hardware thread (basically letting the hardware or OS decide when to 
context switch for you).

Sorry. :-(

Jeff M.


___
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: An idea on multithreading implementation

[Geoff Canyon Rev]

I'd suggest coroutines: http://en.wikipedia.org/wiki/Coroutine

They have the advantage of being fairly similar to what some of us have done
already with send.in to get this sort of behavior, and probably wouldn't
break existing syntax.
___
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: An idea on multithreading implementation

[form]

Just mulling the thought over... If a substack was tagged as being Threaded,
then it couldn't "see" objects or events outside of itself. It would have
its own event list that runs separately. So if the main stack is in the
middle of a long process, the substack would still be interactive.

The threaded stack CAN see the message list of the mainstack's thread, or at
least it can drop something onto it. That would be how they pass information
between them, sending messages.

So you could make a threaded substack with a progress bar and a Cancel
button. the mainstack can be deep in a single long function, sending
progress update events to the threaded substack. While the mainstack would
be unresponsive to the user - as it would be now - the progress dialog would
still work.

Clicking the Cancel button would send a message to the mainstack, to be
executed when possible. Or while in a long function, the code can check to
see if the cancel event is queued up, and abort early.

The advantage to this method of threading is that it doesn't require the
users to handle resource locking (which is a pain) or require the engine to
have built-in resource locking on EVERY command (which would slow everything
down). It puts the built-in locking in just one place, the message queue.

My example can also be turned around so that the substack is doing the heavy
lifting, and might not even be visible to the user. Probably a better design
pattern. When its done it can send the results of its labors to the
mainstack as an event with parameters. Meanwhile, the mainstack remains
fully interactive to the user.

Anyway, just an idle thought about how to quickly add a very usable version
of threading to LiveCode without major code changes.

 ~ Chris Innanen
 ~ Nonsanity
___
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: An idea on multithreading implementation

[Mike Kerner]

> connect to application "A" on port 5674 tell application "A"
> "doSomethingCool"


You had me right up to "cool".  Then I was gone.


For the really scared of trying to do this with sockets, you can of course
also simulate semaphores and IP comm just using some shared text files.

-- 
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: An idea on multithreading implementation

[Jan Schenkel]

--- On Tue, 1/18/11, Bob Sneidar  wrote:
> Hey I had a great idea on how to
> implement multithreading without jacking up anyone's legacy
> code. Have LiveCode work along a single thread as usual, but
> add the keywords "in new thread" to the do command or open
> stack command. That way someone could invoke a new threaded
> process, or launch a stack in a new thread etc if they
> wanted, but not hose anything someone had already written.
> You could launch a progress bar that you could monitor the
> state of an operation and provide real feedback for
> instance, without having to poke your head out of a running
> command from time to time. 
> 
> Any thoughts?
> 
> Bob
> 

The problem of multi-threading is not executing multiple blocks of code 
simultaneously, it's management the concurrent access to state, and in 
particular to shared, mutable state, that's the trick. If your new thread were 
to work in complete isolation, not sharing script-local variables or any 
control properties, there would be no issue. But that would be an extremely 
limiting environment to work in.

Suppose the RunRev team makes container access thread-safe, so:
- put x into y
- put "Smurf" after field "Figurines"
- add 9 to line 3 of field "Numbers"
- ...
would protect the 'target' of the operation, you're still faced with race 
conditions. Take a script as simple as this:
##
answer field 1 & field 1
if field 2 < 9 then
  answer field 2 && "is less than 9. Destroying civilization now..."
end if
##
Think it through, and you'll see multiple potential issues:
- on the first line, there could be a change to the field content in between 
the two reads of the text of the field
- similarly, in between checking the text of field 2 in the if statement, and 
showing it in the answer box, it could very well have changed

The only solution is to add complexity to the language to allow locking and 
'synchronization" (in Java parlance) to protect resources during the execution 
of certain code blocks. And even then, you can never be quite sure what the 
hardware will do, as it tries to optimize behind your back - in fact, these 
days a short-circuit AND operation can be slower than the variant which first 
evaluates both operators and then applies the operator.
A very interesting read in this regard, is the presentation "Not Your Father's 
Von Neumann Machine" by Java concurrency gurus Dr. Cliff Click and
Brian Goetz, which explains how times have changed:


What the LiveCode does offer in terms of multi-threading, is socket 
communication with callback methods: accept, read and write can happen on 
separate threads and when the work is done, your control receives a message so 
that it can take the logical next step. No two such messages are processed at 
the same time.
This is an easy system to reason in, and performs quite well, as long as we 
keep the 'unit of work' small, a LiveCode server socket aplication is a very 
good workhorse and responsive to sizeable group of users. Frankly, I wish 
they'd extend the callback mechanism to file, process and database read/write 
operations, before implementing full multi-threading.

Jan Schenkel.
=
Quartam Reports & PDF Library for LiveCode
www.quartam.com

=
"As we grow older, we grow both wiser and more foolish at the same time."  (La 
Rochefoucauld)



  

___
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: An idea on multithreading implementation

[Bob Sneidar]

I was thinking of something a lot more "native" than that. All threads in a 
multithreaded IDE or standalone could theoretically have access to all the 
objects and processes in all threaded processes. The engine would be 
responsible for internally keeping track of everything, and the developer would 
never need to be concerned about which thread. If Stack A running in one thread 
wanted to know the contents of a field or button on a card in stack B running 
in another thread, you would just code as normal. 

The advantage and goal would be to have entire stacks or just certain commands 
or functions running in their own thread so that a long process in one stack 
would not prevent another from running. 

But maybe it all works because it's only in my head. 

Bob


On Jan 18, 2011, at 6:17 PM, Jeffrey Massung wrote:

> Well, TCP works great, you just have to define your protocol and go. This 
> wouldn't be too difficult to implement. That said, a native method of letting 
> LC apps inter-communicate w/o having to program it [much] would be slick. 
> Taking some ideas from AppleScript:
> 
> 
> ## app "A":
> 
> start script server on port 5674
> 
> 
> 
> ## app "B"
> 
> connect to application "A" on port 5674
> tell application "A" "doSomethingCool"
> 
> 
> 
> The real questions: 
> 
> * Security. Is there a [with password] parameter for the server app? SSL?
> * Is "doSomethingCool" a stack handler or is there an "on clientMessage" type 
> handler?
> * Do you allow only loopback (localhost) connections or also remote 
> connections?
> 
> 
> Simply put, this is really just a way of having RPC calls across LC 
> applications. But, I admit, it'd be really cool. Certainly with the LC 
> language it would be trivial to setup 2-way communication this way, having 
> application "B" identifying itself to application "A", etc.
> 
> Jeff M.
> 
> 
> 
> On Jan 18, 2011, at 6:29 PM, Bob Sneidar wrote:
> 
>> Right... but they cannot communicate easily, or I should say natively with 
>> each other.
>> 
>> Bob
>> 
>> 
>> On Jan 18, 2011, at 5:26 PM, Phil Davis wrote:
>> 
>>> Hi Bob,
>>> 
>>> On 1/18/11 5:05 PM, Bob Sneidar wrote:
 Maybe I am using the wrong term here. Often in Windows an application will 
 open multiple instances of an application, and each instance will be it's 
 own process. An explorer window for example is it's own instance of 
 Windows Explorer, and runs on it's own regardless of what the other window 
 is doing. If that is not multithreading, then I am talking about something 
 else.
>>> 
>>> I'm not entirely sure what this is called either, but you can do it on a 
>>> Mac too - just duplicate LiveCode. Then you can run 2 IDEs simultaneously.
> 
> 
> ___
> 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: An idea on multithreading implementation

[J. Landman Gay]

On 1/18/11 8:17 PM, Jeffrey Massung wrote:

Well, TCP works great, you just have to define your protocol and go.
This wouldn't be too difficult to implement. That said, a native
method of letting LC apps inter-communicate w/o having to program it
[much] would be slick. Taking some ideas from AppleScript:


## app "A":

start script server on port 5674



## app "B"

connect to application "A" on port 5674 tell application "A"
"doSomethingCool"



Oh, I so like this idea.


--
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: An idea on multithreading implementation

[Jeffrey Massung]

Well, TCP works great, you just have to define your protocol and go. This 
wouldn't be too difficult to implement. That said, a native method of letting 
LC apps inter-communicate w/o having to program it [much] would be slick. 
Taking some ideas from AppleScript:


## app "A":

start script server on port 5674



## app "B"

connect to application "A" on port 5674
tell application "A" "doSomethingCool"



The real questions: 

* Security. Is there a [with password] parameter for the server app? SSL?
* Is "doSomethingCool" a stack handler or is there an "on clientMessage" type 
handler?
* Do you allow only loopback (localhost) connections or also remote connections?


Simply put, this is really just a way of having RPC calls across LC 
applications. But, I admit, it'd be really cool. Certainly with the LC language 
it would be trivial to setup 2-way communication this way, having application 
"B" identifying itself to application "A", etc.

Jeff M.



On Jan 18, 2011, at 6:29 PM, Bob Sneidar wrote:

> Right... but they cannot communicate easily, or I should say natively with 
> each other.
> 
> Bob
> 
> 
> On Jan 18, 2011, at 5:26 PM, Phil Davis wrote:
> 
>> Hi Bob,
>> 
>> On 1/18/11 5:05 PM, Bob Sneidar wrote:
>>> Maybe I am using the wrong term here. Often in Windows an application will 
>>> open multiple instances of an application, and each instance will be it's 
>>> own process. An explorer window for example is it's own instance of Windows 
>>> Explorer, and runs on it's own regardless of what the other window is 
>>> doing. If that is not multithreading, then I am talking about something 
>>> else.
>> 
>> I'm not entirely sure what this is called either, but you can do it on a Mac 
>> too - just duplicate LiveCode. Then you can run 2 IDEs simultaneously.


___
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: An idea on multithreading implementation

[Phil Davis]

On 1/18/11 5:29 PM, Bob Sneidar wrote:

Right... but they cannot communicate easily, or I should say natively with each 
other.

Bob


Right.



On Jan 18, 2011, at 5:26 PM, Phil Davis wrote:


Hi Bob,

On 1/18/11 5:05 PM, Bob Sneidar wrote:

Maybe I am using the wrong term here. Often in Windows an application will open 
multiple instances of an application, and each instance will be it's own 
process. An explorer window for example is it's own instance of Windows 
Explorer, and runs on it's own regardless of what the other window is doing. If 
that is not multithreading, then I am talking about something else.

I'm not entirely sure what this is called either, but you can do it on a Mac 
too - just duplicate LiveCode. Then you can run 2 IDEs simultaneously.
--
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net


___
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



--
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net


___
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: An idea on multithreading implementation

[Bob Sneidar]

Right... but they cannot communicate easily, or I should say natively with each 
other.

Bob


On Jan 18, 2011, at 5:26 PM, Phil Davis wrote:

> Hi Bob,
> 
> On 1/18/11 5:05 PM, Bob Sneidar wrote:
>> Maybe I am using the wrong term here. Often in Windows an application will 
>> open multiple instances of an application, and each instance will be it's 
>> own process. An explorer window for example is it's own instance of Windows 
>> Explorer, and runs on it's own regardless of what the other window is doing. 
>> If that is not multithreading, then I am talking about something else.
> 
> I'm not entirely sure what this is called either, but you can do it on a Mac 
> too - just duplicate LiveCode. Then you can run 2 IDEs simultaneously.
> -- 
> Phil Davis
> 
> PDS Labs
> Professional Software Development
> http://pdslabs.net
> 
> 
> ___
> 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: An idea on multithreading implementation

[Bob Sneidar]

Oh I just thought of what really set me thinking about this. Let's say you 
wanted a command to check every 10 seconds for the state of a folder, and then 
have your stack ready to do other things meanwhile. You cannot do that. A 
handler has to be running to make the call to check status. 

I suppose you can have a recursive function that calls itself in time, but can 
LiveCode be doing other things at the same time? I dunno. 

Bob


On Jan 18, 2011, at 5:16 PM, Andre Garzia wrote:

> On Tue, Jan 18, 2011 at 11:09 PM, Richard Gaskin > wrote:
> 
>> Bob Sneidar wrote:
>>> Well my thought was that LC would benefit hugely if 2 or more stacks
>>> could be running in their own thread. Take for example an accounting
>>> app. Normally you could have the Customer Entry form open, and the
>>> Accounts Receivable window open in most well written apps. Sure you
>>> could in LC too... so long as one of the windows was not in the
>>> process of doing anything, like oh say compiling data for a really
>>> large report.
>> 
>> If RunRev would reenable being able to run an app from the command line,
>> conceivably you could run the report processing using a second standalone
>> facelessly.
>> 
>> Sure, it's a bit of a kludge, but would be dirt-simple to implement, and
>> wouldn't expose the treachery of race conditions to the masses. :)
>> 
>> 
> been there but it is hard to exchange messages between the instances... :-/
> 
> 
> 
>> --
>> Richard Gaskin
>> Fourth World
>> LiveCode training and consulting: http://www.fourthworld.com
>> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
>> LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
>> 
>> 
>> ___
>> 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
>> 
> 
> 
> 
> -- 
> http://www.andregarzia.com All We Do Is Code.
> ___
> 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: An idea on multithreading implementation

[Phil Davis]

Hi Bob,

On 1/18/11 5:05 PM, Bob Sneidar wrote:

Maybe I am using the wrong term here. Often in Windows an application will open 
multiple instances of an application, and each instance will be it's own 
process. An explorer window for example is it's own instance of Windows 
Explorer, and runs on it's own regardless of what the other window is doing. If 
that is not multithreading, then I am talking about something else.


I'm not entirely sure what this is called either, but you can do it on a Mac too 
- just duplicate LiveCode. Then you can run 2 IDEs simultaneously.

--
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net


___
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: An idea on multithreading implementation

[Bob Sneidar]

Very un-livecode-ish. 

Bob


On Jan 18, 2011, at 5:16 PM, Kee Nethery wrote:

> My two cents on how Livecode could implement this is to mimic the get URL and 
> URLstatus functionality paired with functions. For example:
> 
> This is a simple pseudo-code example of calling a threaded function 7 times 
> and then waiting until all 7 threads are complete:
> 
> on domythreads
>   global lat,long,countryName
>   put myThreadFunction(1,lat[1],long[1]) into countryName[1]
>   put myThreadFunction(2,lat[2],long[2]) into countryName[2]
>   put myThreadFunction(3,lat[3],long[3]) into countryName[3]
>   put myThreadFunction(4,lat[4],long[4]) into countryName[4]
>   put myThreadFunction(5,lat[5],long[5]) into countryName[5]
>   put myThreadFunction(6,lat[6],long[6]) into countryName[6]
>   put myThreadFunction(7,lat[7],long[7]) into countryName[7]
> 
>   repeat until threadStatus(1) = "complete" \
>  and threadStatus(2) = "complete" \
>  and threadStatus(3) = "complete" \
>  and threadStatus(4) = "complete" \
>  and threadStatus(5) = "complete" \
>  and threadStatus(6) = "complete" \
>  and threadStatus(7) = "complete" 
> wait 1 second
>   end repeat
> end domythreads
> 
> This is what I envision the generic thread call looks like, similar to a 
> function except it has a unique ID and it cannot use globals or data in the 
> stack. Everything it is going to use has to be passed into it as a parameter. 
> 
> thread myThreadFunction requiredThreadIdParameter, optionalThreadParameter1, 
> optionalThreadParameter2, etc.
>  set threadStatus = "started" -- allow the thread to communicate while it is 
> working
>  do stuff
>  call functions in the stack that do not have globals nor use data stored in 
> the stack
>  send to commands to objects in the stack that do not have globals nor use 
> data stored in the stack
>  no reads or writes from any field or button data stored in the stack 
>  set threadStatus = "almost done"
>  OK to get or write stuff from/to external things like URLs or serial ports 
> or files
>  package up a result
>  return allTheResults
>  -- after the return the status goes to "complete"
> end thread
> 
> The way I see it, thread is like a function. You give it a unique ID 
> (requiredThreadIdParameter) and then call it with the parameters you want it 
> to have. What would happen next is Livecode would execute the scripts using 
> the scripts in the stacks that are marked as thread safe using the data 
> provided as parameters. 
> 
> The other part to this is the threadStatus function. In the above example the 
> code just looks for the status to be complete but since the thread can set 
> threadStatus, the main program can watch it's progress.
> 
> I guess my final thread request would be a way to kill a thread that has gone 
> rogue. For example, perhaps a function like 
> killThread(requiredThreadIdParameter)
> 
> As I see it, each function or command (or thread) in a script would get a 
> marker declaring it thread safe or not. A thread could only call thread safe 
> code. If the code had a global in it, not thread safe. if the code looked in 
> a field, not thread safe.
> 
> Anyway that's my two cents on multithreading if I ruled the Livecode world. 
> Seems like it would be easy enough to implement in the existing code base but 
> still quite powerful.
> 
> I do something similar to this with URLs. A stack running as a HTTP server / 
> cgi gets hit and it doles out a bunch of URL requests to various other 
> servers. All those servers work in parallel and when they are done and the 
> urlStatus for each request is "cached", I grab the results and return a 
> summary to the client.
> 
> Kee Nethery
> not holding my breath.
> 
> 
> ___
> 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: An idea on multithreading implementation

[Bob Sneidar]

Do you mean like when the race track is really muddy but they run the horses 
anyway?

Actually, you could be on to something, with the caveat that the processes 
would be isolated from each other. I am thinking that you could still have one 
stack get information about some field in another stack while that stack was 
doing some long drawn out task. 

I dunno, maybe it's a non starter. 

Bob


On Jan 18, 2011, at 5:09 PM, Richard Gaskin wrote:

> Sure, it's a bit of a kludge, but would be dirt-simple to implement, and 
> wouldn't expose the treachery of race conditions to the masses. :)


___
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: An idea on multithreading implementation

[Bob Sneidar]

This "seems" to work because you are envisioning each call to a command or 
function in time as running separately. This is an illusion. If any of the 
commands or functions take longer than one second, say 5 seconds, your calling 
command will not get control back until the other is done. Because things run 
so fast in LC and people rarely write code that takes really long times to 
execute, this is normally not a problem. 

Where it shows up is when you are processing a lot of things, and you want to 
show some kind of progress bar. Well you can't, unless your process involves a 
loop and you can make calls to update your progress bar inside that loop. 

But say you were accessing a very large database remotely, and each call to the 
database took several seconds. Then parsing the data took another couple. Then 
formatting and printing the report took another 10. Even if you used a send in 
time, nothing else in LC would happen until those calls were done. 

It REALLY starts showing up in games or graphic oriented things. Right now you 
have to loop through each object, move one, then the next, then the next, but 
what if you could call the function that moved each object as a separate 
thread? Each object would truly be moving independently. 

Again maybe I am not talking about multithreading but multiprocessing or some 
such thing. 

Bob


On Jan 18, 2011, at 5:00 PM, Alex Tweedly wrote:

> 
> Other than the issue of hitting a breakpoint, can't you simulate this very 
> closely already.
> 
> on addToTimers pMessage, pObject, pFrequency
>-- store this info
>put pFrequency &TAB& pMessage &TAB& pObject &TAB& pFrequency & CR after 
> sTimerList
> end addToTimers
> 
> on removeFromTimers pObject
> -- remove from stored list
> -- details left as an exercise
> end removeFromTimers pObject
> 
> on pauseTimers
>   put false into gTimersAreActive
> end pauseTimers
> 
> on repetitivelyFireTimers
>put empty into tNewList
>if gTimersAreActive then
>  repeat for each line L in sTimerList
> subtract 1 from item 1 of L
> if item 1 of L = 0 then
>send item 2 of L to item 3 of L
>put item 4 of L into item 1 of L
>end if
>put L & CR after tNewList
> end repeat
> put tNewList into sTimerList
>  end if
>  send "repetitivelyFireTimers" to me in 1 second
> end repetitivelyFireTimers
> 
> P.S. of course, there should be error checking, and you could handle 
> sub-second (or non-integer second) timers as well - but this general idea
> 
> P.P.S I just typed the above script lines in - not tested, not a technique I 
> generally use.
> 
> -- Alex.
> end repetitivelyFireTimers
> 
> 
> On 18/01/2011 23:57, Jeff Massung wrote:
>> 
>> I - personally - would be much happier if two things were done:
> 
>> *** Create a timer control or some method of doing the same thing in code.
>> It can be sort of simulated right now like so:
>> 
>> send "foo" to me in 5 seconds
>> 
>> on foo
>>   ... do stuff ...
>>   send "foo" to me in 5 seconds
>> end
>> 
>> But this has issues (for example, if I have a bug in "foo" so I fail to send
>> again, or I hit a breakpoint in "foo" and have to stop execution), and
>> sometimes I want to be able to pause send messages, etc. Being able to just
>> create an interval that responds well to various situations would be very
>> desirable:
>> 
>> send "foo" to me every 5 seconds ## done!
>> 
>> suspend the result ## the message is paused temporarily
>> resume the result ## the message will continue from where it left off
>> 
>> Those few things would be very useful to me.
>> 
>> Jeff M.
>> ___
>> 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: An idea on multithreading implementation

[Andre Garzia]

On Tue, Jan 18, 2011 at 11:09 PM, Richard Gaskin  wrote:

> Bob Sneidar wrote:
> > Well my thought was that LC would benefit hugely if 2 or more stacks
> > could be running in their own thread. Take for example an accounting
> > app. Normally you could have the Customer Entry form open, and the
> > Accounts Receivable window open in most well written apps. Sure you
> > could in LC too... so long as one of the windows was not in the
> > process of doing anything, like oh say compiling data for a really
> > large report.
>
> If RunRev would reenable being able to run an app from the command line,
> conceivably you could run the report processing using a second standalone
> facelessly.
>
> Sure, it's a bit of a kludge, but would be dirt-simple to implement, and
> wouldn't expose the treachery of race conditions to the masses. :)
>
>
been there but it is hard to exchange messages between the instances... :-/



> --
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting: http://www.fourthworld.com
>  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
>  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
>
>
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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: An idea on multithreading implementation

[Kee Nethery]

My two cents on how Livecode could implement this is to mimic the get URL and 
URLstatus functionality paired with functions. For example:

This is a simple pseudo-code example of calling a threaded function 7 times and 
then waiting until all 7 threads are complete:

on domythreads
   global lat,long,countryName
   put myThreadFunction(1,lat[1],long[1]) into countryName[1]
   put myThreadFunction(2,lat[2],long[2]) into countryName[2]
   put myThreadFunction(3,lat[3],long[3]) into countryName[3]
   put myThreadFunction(4,lat[4],long[4]) into countryName[4]
   put myThreadFunction(5,lat[5],long[5]) into countryName[5]
   put myThreadFunction(6,lat[6],long[6]) into countryName[6]
   put myThreadFunction(7,lat[7],long[7]) into countryName[7]

   repeat until threadStatus(1) = "complete" \
  and threadStatus(2) = "complete" \
  and threadStatus(3) = "complete" \
  and threadStatus(4) = "complete" \
  and threadStatus(5) = "complete" \
  and threadStatus(6) = "complete" \
  and threadStatus(7) = "complete" 
 wait 1 second
   end repeat
end domythreads

This is what I envision the generic thread call looks like, similar to a 
function except it has a unique ID and it cannot use globals or data in the 
stack. Everything it is going to use has to be passed into it as a parameter. 

thread myThreadFunction requiredThreadIdParameter, optionalThreadParameter1, 
optionalThreadParameter2, etc.
  set threadStatus = "started" -- allow the thread to communicate while it is 
working
  do stuff
  call functions in the stack that do not have globals nor use data stored in 
the stack
  send to commands to objects in the stack that do not have globals nor use 
data stored in the stack
  no reads or writes from any field or button data stored in the stack 
  set threadStatus = "almost done"
  OK to get or write stuff from/to external things like URLs or serial ports or 
files
  package up a result
  return allTheResults
  -- after the return the status goes to "complete"
end thread

The way I see it, thread is like a function. You give it a unique ID 
(requiredThreadIdParameter) and then call it with the parameters you want it to 
have. What would happen next is Livecode would execute the scripts using the 
scripts in the stacks that are marked as thread safe using the data provided as 
parameters. 

The other part to this is the threadStatus function. In the above example the 
code just looks for the status to be complete but since the thread can set 
threadStatus, the main program can watch it's progress.

I guess my final thread request would be a way to kill a thread that has gone 
rogue. For example, perhaps a function like 
killThread(requiredThreadIdParameter)

As I see it, each function or command (or thread) in a script would get a 
marker declaring it thread safe or not. A thread could only call thread safe 
code. If the code had a global in it, not thread safe. if the code looked in a 
field, not thread safe.

Anyway that's my two cents on multithreading if I ruled the Livecode world. 
Seems like it would be easy enough to implement in the existing code base but 
still quite powerful.

I do something similar to this with URLs. A stack running as a HTTP server / 
cgi gets hit and it doles out a bunch of URL requests to various other servers. 
All those servers work in parallel and when they are done and the urlStatus for 
each request is "cached", I grab the results and return a summary to the client.

Kee Nethery
not holding my breath.


___
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: An idea on multithreading implementation

[Richard Gaskin]

Bob Sneidar wrote:
> Well my thought was that LC would benefit hugely if 2 or more stacks
> could be running in their own thread. Take for example an accounting
> app. Normally you could have the Customer Entry form open, and the
> Accounts Receivable window open in most well written apps. Sure you
> could in LC too... so long as one of the windows was not in the
> process of doing anything, like oh say compiling data for a really
> large report.

If RunRev would reenable being able to run an app from the command line, 
conceivably you could run the report processing using a second 
standalone facelessly.


Sure, it's a bit of a kludge, but would be dirt-simple to implement, and 
wouldn't expose the treachery of race conditions to the masses. :)


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

___
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: An idea on multithreading implementation

[Bob Sneidar]

Well my thought was that LC would benefit hugely if 2 or more stacks could be 
running in their own thread. Take for example an accounting app. Normally you 
could have the Customer Entry form open, and the Accounts Receivable window 
open in most well written apps. Sure you could in LC too... so long as one of 
the windows was not in the process of doing anything, like oh say compiling 
data for a really large report. 

Under those circumstances, it would not be possible to have LC do this because 
while that process was going on the other window would be unresponsive. This is 
one of the things holding LC back from being a true enterprise development 
environment. 

I dunno, maybe we don't want to go there. But if it were not too much trouble 
for the dev team to implement some basic form of multithreading on demand, for 
those who need it, it could be available, and for those who don't, well LC 
would just run the way it always has. 

Maybe I am using the wrong term here. Often in Windows an application will open 
multiple instances of an application, and each instance will be it's own 
process. An explorer window for example is it's own instance of Windows 
Explorer, and runs on it's own regardless of what the other window is doing. If 
that is not multithreading, then I am talking about something else. 

Bob


On Jan 18, 2011, at 3:57 PM, Jeff Massung wrote:

> Multi-threading is mutli-threading. The problems exist regardless of the
> format/syntax.
> 
> At the end of the day it comes down to thread safety manipulating properties
> and the most commonly used data control in the toolbox: the field. (This is
> coming from someone who does MT programming all the time). Plus, I don't
> think the average LC developer wants to even -think- about locks, mutexes,
> semaphores, etc. ;-)


___
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: An idea on multithreading implementation

[Alex Tweedly]

Other than the issue of hitting a breakpoint, can't you simulate this 
very closely already.


on addToTimers pMessage, pObject, pFrequency
-- store this info
put pFrequency &TAB& pMessage &TAB& pObject &TAB& pFrequency & CR 
after sTimerList

end addToTimers

on removeFromTimers pObject
 -- remove from stored list
 -- details left as an exercise
end removeFromTimers pObject

on pauseTimers
   put false into gTimersAreActive
end pauseTimers

on repetitivelyFireTimers
put empty into tNewList
if gTimersAreActive then
  repeat for each line L in sTimerList
 subtract 1 from item 1 of L
 if item 1 of L = 0 then
send item 2 of L to item 3 of L
put item 4 of L into item 1 of L
end if
put L & CR after tNewList
 end repeat
 put tNewList into sTimerList
  end if
  send "repetitivelyFireTimers" to me in 1 second
end repetitivelyFireTimers

P.S. of course, there should be error checking, and you could handle 
sub-second (or non-integer second) timers as well - but this general idea


P.P.S I just typed the above script lines in - not tested, not a 
technique I generally use.


-- Alex.
end repetitivelyFireTimers


On 18/01/2011 23:57, Jeff Massung wrote:


I - personally - would be much happier if two things were done:



*** Create a timer control or some method of doing the same thing in code.
It can be sort of simulated right now like so:

send "foo" to me in 5 seconds

on foo
   ... do stuff ...
   send "foo" to me in 5 seconds
end

But this has issues (for example, if I have a bug in "foo" so I fail to send
again, or I hit a breakpoint in "foo" and have to stop execution), and
sometimes I want to be able to pause send messages, etc. Being able to just
create an interval that responds well to various situations would be very
desirable:

send "foo" to me every 5 seconds ## done!

suspend the result ## the message is paused temporarily
resume the result ## the message will continue from where it left off

Those few things would be very useful to me.

Jeff M.
___
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: An idea on multithreading implementation

[Jeff Massung]

On Tue, Jan 18, 2011 at 2:57 PM, Bob Sneidar  wrote:

> Hey I had a great idea on how to implement multithreading without jacking
> up anyone's legacy code. Have LiveCode work along a single thread as usual,
> but add the keywords "in new thread" to the do command or open stack
> command. That way someone could invoke a new threaded process, or launch a
> stack in a new thread etc if they wanted, but not hose anything someone had
> already written. You could launch a progress bar that you could monitor the
> state of an operation and provide real feedback for instance, without having
> to poke your head out of a running command from time to time.
>
> Any thoughts?
>
>

Multi-threading is mutli-threading. The problems exist regardless of the
format/syntax.

At the end of the day it comes down to thread safety manipulating properties
and the most commonly used data control in the toolbox: the field. (This is
coming from someone who does MT programming all the time). Plus, I don't
think the average LC developer wants to even -think- about locks, mutexes,
semaphores, etc. ;-)

I - personally - would be much happier if two things were done:

*** Make LC multi-threaded internally where possible (honestly, it might be
already and at the end of the day I don't care if hamsters are powering the
engine if it runs fast... but due to a few oddities, I think it's fair to
say that it isn't MT in it's current form). Primarily I think debugging
would benefit from being completely separated (thread-wise) from engine
code; there's been several times a stack will just hang and I have to kill
the process. Wanna see it in action? Put a breakpoint in the stackResize
handler.

*** Create a timer control or some method of doing the same thing in code.
It can be sort of simulated right now like so:

send "foo" to me in 5 seconds

on foo
  ... do stuff ...
  send "foo" to me in 5 seconds
end

But this has issues (for example, if I have a bug in "foo" so I fail to send
again, or I hit a breakpoint in "foo" and have to stop execution), and
sometimes I want to be able to pause send messages, etc. Being able to just
create an interval that responds well to various situations would be very
desirable:

send "foo" to me every 5 seconds ## done!

suspend the result ## the message is paused temporarily
resume the result ## the message will continue from where it left off

Those few things would be very useful to me.

Jeff M.
___
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: An idea on multithreading implementation

[Bob Sneidar]

There is no more RunRev team. It's the LiveCode team now! Maybe they will be 
more receptive to the idea...   ;-)

Bob


On Jan 18, 2011, at 2:38 PM, Damien Girard wrote:

> 
> I like the idea and that would be awesome, but the Runrev team will have a
> lot of fun to implement this lol
> 
> Damien


___
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: An idea on multithreading implementation

[Damien Girard]

I like the idea and that would be awesome, but the Runrev team will have a
lot of fun to implement this lol

Damien

-Message d'origine-
De : use-livecode-boun...@lists.runrev.com
[mailto:use-livecode-boun...@lists.runrev.com] De la part de Bob Sneidar
Envoyé : mardi 18 janvier 2011 22:58
À : How to use LiveCode
Objet : An idea on multithreading implementation


Hey I had a great idea on how to implement multithreading without jacking up
anyone's legacy code. Have LiveCode work along a single thread as usual, but
add the keywords "in new thread" to the do command or open stack command.
That way someone could invoke a new threaded process, or launch a stack in a
new thread etc if they wanted, but not hose anything someone had already
written. You could launch a progress bar that you could monitor the state of
an operation and provide real feedback for instance, without having to poke
your head out of a running command from time to time. 

Any thoughts?

Bob



___
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

An idea on multithreading implementation

[Bob Sneidar]

Hey I had a great idea on how to implement multithreading without jacking up 
anyone's legacy code. Have LiveCode work along a single thread as usual, but 
add the keywords "in new thread" to the do command or open stack command. That 
way someone could invoke a new threaded process, or launch a stack in a new 
thread etc if they wanted, but not hose anything someone had already written. 
You could launch a progress bar that you could monitor the state of an 
operation and provide real feedback for instance, without having to poke your 
head out of a running command from time to time. 

Any thoughts?

Bob



___
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