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 .
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
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
u
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
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 ho
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 handle
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 Garzi
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,
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 e
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 wrot
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
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
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
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 t
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
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 op
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
pref
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 butt
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 w
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
m
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
"alwaysBuffe
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
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 p
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:
> > Currentl
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
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 ki
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
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 y
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 synt
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 m
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 thre
> 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 firs
--- 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 cou
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 wo
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 Apple
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 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
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 instan
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 supp
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
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 ti
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
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
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
> >
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,l
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 yo
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 l
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
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
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
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
51 matches
Mail list logo
