[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Lua
. . -> [Subject]  Using the socket library

Using the socket library

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Pages: 1  2  3 4  

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #30 on Mon 06 Dec 2004 04:46 PM (UTC)
Message
I beg to differ Ksilyan. Yes, Nick may have developed the event management for Mushclient, but scripts could not work as stand alone systems, unless the engine also had its own event manager. I am pretty sure they use 'that' handler for object events, since Mushclient *is not* the program creating the objects, the script engine is. It doesn't make a lot of sense for it to rely on the host application, which is apparently not even aware of such objects or able to communicate with them.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #31 on Mon 06 Dec 2004 06:45 PM (UTC)

Amended on Mon 06 Dec 2004 06:46 PM (UTC) by Nick Gammon

Message
Well, not really. I can't imagine personally how an external event (like a song change) can kick into action a piece of code that is pseudo code that needs to be executed by a script engine, which isn't running at that point. Maybe it can be done, I would be interested to hear how.

However I do know that at present your scripts don't "just respond" to external events, MUSHclient calls them in a predetermined way.

It goes like this:


  • MUSHclient is in its main Windows event loop

  • An event happens. Depending on what it is, it goes to the appropriate handler. eg. screen redraw causes it to repaint the screen (perhaps you had another window on top of it?).

  • A comms event (incoming TCP/IP data) eventually happens

  • It goes into its "process incoming text" routine

  • It handles ANSI codes, MXP etc.

  • Eventually a newline arrives

  • It goes into the "process the previously-arrived line" routine

  • This looks up triggers for that world (if active) and processes each one

  • For "send to script" or a trigger that needs to call a script it:

  • Activates the script engine, telling it to process either the named script event (ie. the trigger script) or simply sends the entire send box to the the script engine (as "send to script")

  • Now the script engine is active and does its thing, while it is doing it, MUSHclient waits for the script call to return.

  • When the script ends, MUSHclient goes on to do different scripts, then "omit from output", send replies etc.

  • MUSHclient processes other triggers

  • It goes back to its main loop



So you can see that trigger events don't just call your script without a considerable amount of intervention. Similarly for other scripted events, each happens at a well-define point in the execution process (eg. incoming chat message, incoming packet, world open, world close).

Now if you say to me that Winamp sends a Windows event (eg, the WM_XYZ_EVENT) then I can put in a check, that if that event (or any event you might define) happens it can call your script. However I haven't seen any suggestion so far that Winamp actually does put events into the event queue.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #32 on Mon 06 Dec 2004 07:52 PM (UTC)
Message
But Nick. My point is it *can't* send events to an application that is not aware of the control. The script engine itself does know about it, but as far as Mushclient is concerned such a control does not even exist. How can it recieve the event? However, for the script engine to take advantage of the ability to handle events through a connection point, there must be something 'in the engine itself' that does it. You have to realize that even though you are dealing with dlls, not an exe, and even though there is no 'window', the script engine is still an application and it does have its own internal event management. The only real question is if Mushclient's suspending the script execution also suspends the event manager in the script.

Now I may be wrong... It is possible that since you are running the script engine as a dll in Mushclient, that all its events are first passed through Mushclient, before being passed on to the engine, but that just means you can intercept them. It does not alter the fact that Lua having connection points would be a totally worthless feature, if it didn't also have a means to capture the events that arrive through that connection point. What would be the point of even allowing a script writter to make one if it didn't allow the engine to wake up the script and execute code in response to one? Answer: there wouldn't be a reason, since the 'only' things such connection points are used for is handling events. Properties, function calls, etc. are all exposed and available from the moment you create the control. The only thing the last 6 lines in the following code can or would do:

winampCOM = luacom.CreateObject("WinampCOM.Application")
events_handler = {}
function events_handler:SongChange()
  print "Song changed to " + winampCOM.CurrentSongTitle
end
events_obj = luacom.Connect(winampCOM, events_handler)

is set up a way to deal with the event fired by the ActiveX control.

The explaination for it is here:

http://216.239.57.104/search?q=cache:c-WDyJapmTMJ:www.tecgraf.puc-rio.br/~rcerq/luacom/pub/1.1/luacom-1.1-doc.pdf+lua+luacom.connect&hl=en

Basically, in the above. The first line provides access to everything except the events. The 2nd - 5th lines create a function in a table, so that is one called SongChange is detected, it executes that code. The last line 'connects' the event stream for the object in the first line to the table you provided, with the event functions in it. Now, you may not get how or why it could work, but it must somehow, or why provide the commands to do it?? The only real question is if I got the event name right and what if any effect Mushclient's suspending the script has on this feature. We just don't know. And again, I have no clue if Mushclient ever even sees the event in its own handler or if maybe the dll is treated as a 'sub-window' and gets automatically passed any events the client itself doesn't handle. I don't know how it works exactly with scripts.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #33 on Mon 06 Dec 2004 07:58 PM (UTC)
Message
Perhaps you could whip up a Windows application written in C++ and uses scripting engines that demonstrates this, Shadowfyr. Obviously Nick doesn't think it's possible with the model that he has, I would tend to agree with his judgment for a variety of reasons, so perhaps you could show us old dogs how it's done. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #34 on Mon 06 Dec 2004 08:16 PM (UTC)
Message
He may be right. I am just describing my understanding of how event management works and questioning why, if the engine can't do it, they even bothered providing a way 'for' it to do it. I don't think we need a seperate C++ application to test it. Even if I had a clue how to manage writing one. It either works as the Lua documentation and everything I have read about events says, or Nick is right and Mushclient is a special case where it won't. And that opens up a whole new can of worms. In any case, Nick would be more qualified to capture and examine what Mushclient does or doesn't recieve through it own even stream than I am. If the event does pass through it first, then it will appear as a packet in that stream. The problem is, even if it does, does Nick know how the script engine works well enough to say that such events don't end up handed off to that as well? I don't know any of it well enough to say either, but I tend to wonder when the people that develop a script engine give specific examples of how to do it. The question has to be asked, "If other programs that use this engine really do treat it in a significantly different way than Mushclient does, how and why does that make it not work in this case?" Do we even know that Mushclient uses it in that significantly different a fashion so as to prevent it?
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #35 on Mon 06 Dec 2004 08:50 PM (UTC)
Message
Could you show very specific examples in the Lua documentation of what you're talking about, and sample code that I suppose they provide to get it working in C++? If you've done so already I must have missed it. I didn't see the Winamp example in the reference manual you provided.

It also seems that this is about creating COM objects that Lua will use, and not hooking into already running, external objects (e.g. the Winamp application.) There's quite a significant difference between the two.
See page 14 of the reference manual:
http://216.239.57.104/search?q=cache:c-WDyJapmTMJ:www.tecgraf.puc-rio.br/~rcerq/luacom/pub/1.1/luacom-1.1-doc.pdf+lua+luacom.connect&hl=en

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #36 on Mon 06 Dec 2004 10:07 PM (UTC)
Message
Quote:

... the script engine is still an application and it does have its own internal event management ...


No, it isn't. It is a piece of code sitting inside MUSHclient, in much the same way as the spell checker. It has no life of its own, it doesn't get events, it is "dead" until it is called into life, say by a trigger firing.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #37 on Mon 06 Dec 2004 11:08 PM (UTC)
Message
Hmm. Servers me right for not looking closely at things.. Seems LuaCOM is a seperate modual:

http://www.tecgraf.puc-rio.br/~rcerq/luacom/#Release12

So the existing engine doesn't have support for COM at all. Including even 'basic' allowances for using ActiveX objects of any kind. The download link doesn't seem to work for me though. Basically, it is an addon library that adds the support. Wondered why the attempt I was trying wouldn't work at all.... :(

As for the document I showed. The examples in it are for Microsoft's calender gadget and some other basic things. The code I gave in my post was an adaptation, based on that. Obviously they are not going to have the same example.

Anyway, sorry for the confusion. Seems that you need an aditional library to support it at all. I was assuming that Lua was like Python and had such things built in as a more or less basic part of the language.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #38 on Mon 06 Dec 2004 11:20 PM (UTC)
Message
Lua is designed to be cross-platform (unlike, say, VBscript).

Its basic implementation has very little operating system-dependant stuff.

If I had added COM as part of the basic Lua package then I would be back to the problem I already have with the other script languages, you can't use them very reliably on Linux because COM isn't very reliable there.

However there is nothing stopping you from adding the LuaCOM package to your own copy (if you can get the download to work).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #39 on Mon 06 Dec 2004 11:41 PM (UTC)
Message
Not sure how exactly to manage that. The only examples seem to show Lua and LuaCOM being started through C++ in another application or just using the commands. Nothing about how to get Lua itself to use it.

As for the cross platform issue. Python is also cross platform, but it 'does' let you use COM, when on a system that has it. On others it might use CORBA, or it might use the std-in/std-out model, etc. If all you want to do is run a script, you don't need to worry about things like COM support, but the stuff people want to do goes way beyond that. If you did design a Linux version, then yes we would have to adapt, just like anyone confronted with the fact that inter-process/application communications do not work the same between platforms. But then I am not going to be using WinAmp on Linux and I would have to rewrite my Fireworks gadget, or anything else, for that platform anyway, at which time I would have to adopt a different method. However, right now, we have one that does work, is available through most of the script types and is only missing one thing to make it completely bi-directional, as originally intended. I think you can understand my endless frustration with this issue. ;)
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #40 on Tue 07 Dec 2004 12:03 AM (UTC)
Message
Quote:
As for the document I showed. The examples in it are for Microsoft's calender gadget and some other basic things. The code I gave in my post was an adaptation, based on that. Obviously they are not going to have the same example.
My point being that the examples were accomplishing very different things than what your "adaptation" was trying to accomplish.

For that matter, I'm still not entirely sure you're clear on what you're trying to accomplish or how to go about doing it; you simply assume that there must be a way since you want there to be one. :-) You should start by making this work in your own example application (that, yes, you'd have to write yourself, in C++) and then, if you get it working there, poke Nick, prove him (and me) wrong, and show us how it's done. :) To be honest I'd be very curious to see it working in the same conditions under which MUSHclient is running...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #41 on Tue 07 Dec 2004 02:52 AM (UTC)
Message
How precisely is mine different?? Here is another example, from http://www.promixis.com/php/drops/iTunes%20Interface%20v0-1.04

...

function iTunes.Connect ()

  if iTunes.Connected then
    return iTunes.Version
  end

  if not luacom then
    UnloadLuaCom ()
  end

  LoadLuaCom ()

  iTunes.com = luacom.CreateObject("iTunes.Application")

  if not iTunes.com then
    return nil, "iTunes: unable to connect"
  end

  iTunes.Connection = luacom.Connect(iTunes.com,iTunesEvent)
  if not iTunes.Connection then
    return nil, "iTunes: unable to link events"
  end
  iTunes.Version =iTunes.com.Version
  iTunes.Connected = 1
  return iTunes.Version
end

...

iTunesEvent = {}
function iTunesEvent:OnPlayerPlayingTrackChangedEvent (iTrack)
  iTunes.CallEventHandlers (3)
end

function iTunesEvent:OnPlayerStopEvent(iTrack)
  iTunes.CallEventHandlers (2)
end

function iTunesEvent:OnPlayerPlayEvent  (iTrack)
  iTunes.CallEventHandlers (1)
end

function iTunesEvent:OnDatabaseChangedEvent (deletedObjectIDs, changedObjectIDs)
  iTunes.CallEventHandlers (4)
end

function iTunesEvent:OnCOMCallsDisabledEvent  (reason)
  if reason == 2 then -- itunes is quitting
    iTunes.Disconnect ()
    iTunes.CallEventHandlers (6)
    return
  end
  iTunes.CallEventHandlers (6)
  iTunes.Disabled = reason
end

function iTunesEvent:OnCOMCallsEnabled  ()
  iTunes.Disabled = nil
  iTunes.CallEventHandlers (7)
end

function iTunesEvent:OnQuittingEvent  ()
  iTunes.Disconnect () -- this routine calls the eventhandlers
end
...

This is 'identical' to what I am attempting, except that it uses the iToons player, instead of WinAMP. If not, then how does it differ?

The steps above are exactly the same as my example. Create an instance of the control (in the case if WinampCOM, this also opens the player), then create a connection point, which links the event handling functions to the event stream of the object. What do you think I have been trying to do that is not the same?
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #42 on Tue 07 Dec 2004 03:37 AM (UTC)
Message
Well, I'm not sure what luacom offers, but does this application do anything else, except wait for tunes to change?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #43 on Tue 07 Dec 2004 09:07 AM (UTC)
Message
Like I said, Shadowfyr, I'll be convinced the day you come up with sample code in C++ that gets this to work and, as Nick said, does something other than sitting around waiting for iTunes. That is, a full-blown application (say, similar to MUSHclient), that oh-just-so-happens to have this little scripting component that can listen to external events.

Note that the sample script you gave works in an application caleld 'Girder', which claims to be a "Windows automation tool". Chances are, the whole point of the program is to sit around waiting for this kind of event - it is not at all like MUSHclient.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #44 on Tue 07 Dec 2004 04:57 PM (UTC)
Message
Well Nick. LuaCOM is a "COM" library for Lua. It is what allows you to use ActiveX at all. My Fireworks gadget, the mapper for a BattleTech based mud and virtually every other example of using an external application from insides a script all use ActiveX. If you do a google search on 'ActiveX Lua', the **only** pages that list are either the LuaCOM ones or adaptations of LuaCOM as plugins for other applications. Lua itself cannot do it natively, even though every other one, including I suspect PHP, all provide at least basic support for it. So yes, it does do more, since it is more or less 100% necessary to even connect to and control 90% of all the applications currently written for windows.

And Ksilyan.. Yes, Girder is designed to "control programs like WinAmp and Windows Media Player using infrared and wireless remote controls so you can sit back and enjoy your digital library from your couch." I am not sure what if anything the difference technically is between that and driving things from a text stream. This applications seems to have to respond to a wide number of different devices and while the scripts may define what to do about the signals recieved, the major portion of the application likely involved calling several different scripts/plugins, depending on 'which' remote or device signals it. Sounds a lot like triggers firing and calling scripts, but heh, what do I know. LuaCOM just happens to be one of the things installed to extend functionality. Apparently, it is used to drive a LCD Master component, which displays information about what one or more of the devices being controlled is doing.

In any case, I am not at all sure what the heck you seem to want Ksilyan. I don't know C++ well enough to even try writing an example and no examples I have given, including one that uses C++, is good enough for you. You can't seem to get past the potential delusion that Mushclient is so horribly different that it isn't even worth investigation by someone that actually can code something to test it. For now, Lua is useless to me, even for what I have already been using other languages to do.
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


132,632 views.

This is page 3, subject is 4 pages long:  [Previous page]  1  2  3 4  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]