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

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Python
. . -> [Subject]  Easy Text editor?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Easy Text editor?

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page


Pages: 1  2 3  4  5  

Posted by Shadowfyr   USA  (1,775 posts)  [Biography] bio
Date Reply #15 on Fri 23 Feb 2007 08:13 AM (UTC)  quote  ]

Amended on Fri 23 Feb 2007 08:34 AM (UTC) by Shadowfyr

Message
Hmm. Ok, part two of the three needed:

wxLuaState(wxEvtHandler *handler, wxWindowID id = wxID_ANY)

Creates a complete wxLuaState, but you can provide an event handler, eg. wxApp or wxWindow derived class, to get and handle the wxLuaEvents, see also Get/SetEventHandler.

Now the only question is if a) this works automatically even as in an existing GUI or b) how do you "inform" this handler of events external to wxLua....

Hmm. Edit to add this:

From the "state" features you get:

int m_wxluatag_wxEvent; // The lua tag for wxEvents

and

wxEvtHandler *m_evtHandler; // event handler to send wxLuaEvents to
wxWindowID m_id; // event id to send the events with

Which presumably should let you both identify what events are fired by wxLua objects "and" where to reflect them to in order to make it work. In theory. Not sure yet if there is some more direct means to send wxLua events, or even if you need to do that in the first place. Worst case is looking a lot easier. Especially since, with the above, one only needs to figure out which events "belong" to wxLua then throw them to the wxLua handler when detected. No need to even keep track of any of the functions locations, in theory.

Though, since there is a "GetEventHandler" function, which I forgot about already, you just need to know what ID to look for in the events.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #16 on Fri 23 Feb 2007 05:41 PM (UTC)  quote  ]
Message
I'm always amazed at the amount of things that you find can be added with just a complete reworking of how MUSHclient is written. It comes up in thread after thread... If you think it's so easy, just write your own client and be done with it.

The main issue, which you failed to notice or are ignoring, is bloat. Making a MC download 5-6 times it's current size to add a small amount of features just does not sound like a good idea. Yes, things may be a bit more convenient for some, but is it worth the extra time and space? Also, for many of these issues, MC already has quite a few quick workarounds.

ex: For what the original post has, just copy/paste what you need to notepad/textpad/whatever editor you want, edit the files, save, then send the file back to the MUD. It's a seperate window, and you can just rewrite the same file over and over again if you're concerned about having too much to keep track of. This is how I dealt with area creation for the MUD I play on a few years back so I could look at the help files on the server right next to the mobs or rooms. I still have the whole area backed up in a zip file.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #17 on Fri 23 Feb 2007 06:10 PM (UTC)  quote  ]
Message
I agree that bloat is an important issue but I think that the amount of time Nick would have to spend is a bigger issue. As you say, these changes only require a complete rewrite of the event and windowing system...

After all, if all this only took an hour for Nick to do, well maybe it would be worth distributing a version of MUSHclient with the bloat just to stop these discussions. :-) But the problem is that it'll take much more than an hour; it will involve lots of research, in addition to actually rewriting the code.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

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

Posted by Shadowfyr   USA  (1,775 posts)  [Biography] bio
Date Reply #18 on Fri 23 Feb 2007 08:00 PM (UTC)  quote  ]
Message
Bloody hell. What bloat? At this point it looks like we are maybe talking about 10-20 lines of fracking code, not 10 MB of extra data. And, as I said, even in the worst case, the damn thing is *already* doing 90% of what is needed to handle event calls, should I turn out to be dead wrong, just to support existing callbacks. We are not talking about brain surgery here, complete redesigns or even gluing an entire additional application onto the side of it. We are talking about what, even in the worst case, shouldn't be more than a *minor* change. And that is still assuming we even need one.

By comparison half the stuff that has been added in the last few major revisions *have* been huge changes that really did add additional bloat. We are talking about a few fracking k here at worst, and probably not even that. Get fracking real!

And just to be clear, it might take only an hour to impliment and **I** am the one doing the fracking research, since I seem to be the only person that *ever* does any at all on these things. Everyone else just whines about how, "Its probably too hard!", every time something comes up. Sorry if I am getting a tad fed up with that.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #19 on Fri 23 Feb 2007 09:20 PM (UTC)  quote  ]
Message
Why are you so surprised that you are the only one doing the research? You appear to be pretty much the only one who cares about this stuff so much.

If you're so fed up with this whole thing, I earnestly urge you to try writing your own client that supports this. The whole community will benefit, and everybody will learn from it, you most of all from having actually written some code to make it work.

My impression is that you are putting an awful lot of blame on Nick, continually insinuating that he is almost stupid for not seeing how simple the change is. It doesn't matter how simple the change "should be" according to you, what matters is how simple the change is or is not.

He has told you several times that it is very non-trivial from his perspective and you keep throwing it back in his face. There have been several conversations on this forum where you continuously bring up the same points and yet you have not, to my knowledge, written a single, even very small, C++ program demonstrating these supposedly extremely simple changes.

I don't want to be too blunt here but I think it would really, really help you to go out and write some code and see for yourself. Try to see things from Nick's perspective of how the world is instead of what you (and apparently pretty much only you) want the world to be.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

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

Posted by Shadowfyr   USA  (1,775 posts)  [Biography] bio
Date Reply #20 on Fri 23 Feb 2007 11:07 PM (UTC)  quote  ]
Message
I am sorry, but no one here has given a good reason to say its non-trivial, save for the excuse, "I don't know how to do it, so it must be non-trivial." With all do respect to Nick, this isn't a valid argument. There have been 1-2 other case where things "seemed" non-trivial but proved far less complicated that expected.

Note, I finally managed to ask the question right, I guess, on the wxLua list. And according to the poster I am on the right track. Which means, the solution may be as simple as the pseudocode:

OnMessage_Reflect (event) {
  current_engine = 0
  do while more engines {
    result = current_engine.handler(event);
    if result = false exit loop;
    current_engine ++;
  }
}


Plus maybe 1-2 more lines to create this as a reflection point for event messages in a Mushclient class. Wow!!! That's just a huge amount of bloody bloat....

Agruments from ignorance are not useful. And last I looked, I only see *two* people actively complaining here that I should just give up.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by Nick Gammon   Australia  (19,169 posts)  [Biography] bio   Forum Administrator
Date Reply #21 on Fri 23 Feb 2007 11:07 PM (UTC)  quote  ]
Message
Quote:

... half the stuff that has been added in the last few major revisions *have* been huge changes that really did add additional bloat.


Go to this URL:

http://www.gammon.com.au/files/mushclient/

You can see there every released MUSHclient version, including its size. From version 3.00, released in 2001, which is 1.2 Mb, to version 3.84 in December 2006, which is 1.8 Mb, there has been a very gradual creep of file size. This has generally been caused by the extra features that everyone is pleased with, like spellchecker, Lua scripting, extra scripting functionality, multi-line triggers, and so on. However the point is that the file size of the installer has only gradually changed in size.

Look at at year ago (version 3.69), which is 1.7 Mb, to today, which is 1.8 Mb. I don't see how this can be described as "huge changes that ... add additional bloat". That is only 0.1 Mb change over a year.

You have asked me to change from straight Lua (129 Kb DLL) to wxLua (5.3 Mb installer). Surely this change alone would be enormous bloat, compared to the 0.1 Mb change over the last 12 months?

You are talking about adding 10-20 lines of code (your figures) but bypassing the problem of needing the extra 5 Mb of wxLua which those 10 lines of code need to call.

It also isn't clear if this additional to ordinary Lua. Do you want every scripter who uses Lua to switch to wxLua? If not, then possibly the client has to support another script language, which is not part of the Windows scripting model.

I'm not trying to be difficult, but it simply isn't clear to me that I can solve your problems by "just adding 10 lines of code". If I could, I would.

- Nick Gammon

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

Posted by Nick Gammon   Australia  (19,169 posts)  [Biography] bio   Forum Administrator
Date Reply #22 on Fri 23 Feb 2007 11:11 PM (UTC)  quote  ]
Message
Quote:

Plus maybe 1-2 more lines to create this as a reflection point for event messages in a Mushclient class.


Yes, but how does wxLua come into the equation? Does it get distributed with MUSHclient? Is it an optional extra? When does the engine get created? Do we need another script language in the list? Does the support for plugins need to be changed to allow for that too?

Can you say that the person that gave that psuedo code (and pseudo code is a bit doubtful when someone "thinks this should work") is referring to implementing it into a C++ program which has its own event loop, and is written with MFC?

- Nick Gammon

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

Posted by Shadowfyr   USA  (1,775 posts)  [Biography] bio
Date Reply #23 on Fri 23 Feb 2007 11:53 PM (UTC)  quote  ]
Message
Hmm. Didn't realize wxLua was that big... Might be easier, ironically, to try to fix Python, since its an optional and has the same issue, where wxLua would probably be "replacing" Lua.

As for the psuedocode. That is mine, based on what I have uncovered. And its not yet clear if that is even needed. The person I am talking to implied that the OS takes a bottom up approach to handling event handlers and might automatically talk to the wxLua one "first", then pass it up the chain to the MFC client. I don't think that is the case.

As to bloat.. What if someone makes a 3MB file that displays icons, which everyone likes so much that they "insist" they need it, then someone else makes a 5MB mapper, then someone else makes a code editor, which is another 10MB. Sure, the client isn't any more "bloated", but it just means 17MB of unsupported third party applications you still have to download to get what amounts to 1-2MB of completely redundant junk that each of those use (not including things like VB Runtimes), which is part of that 5MB extra.

But, ok, I see your point. As nice as providing the casual coder with real tools to do something with may be, it does have what could be unaccectable overhead. How to fix that, such as making a Windows Scripting version that can be optional instead, is something I need to consider. It may turn out that the issue with *it* is a similar enough issue to what already exists for "all" event supporting software, that solving this problem can provide a less bloating solution for everything, without having to use wxLua at all.

As for how wxLua came into the equation in the case of the psuedocode. It *does* have its own event handlers. The point of "message reflection", which is an MFC feature, in case you missed that, would have been to redirect events that belong to wxLua to the engines handler(s), instead of throwing them out. In other words, it allows you to intercept such messages in an MFC application, when **normally** all those things are completely hidden from you.

Python may have the same issues. However, it is optional, not supplied with the client and does use Windows Scripting as an interface. It may be a better candidate under the circumstances. The only problem I see in solving for "it" is that someone is bound to wonder what stops Lua from doing the same thing, and the whole can of worms crops up again.

But yeah. I didn't really think about the size issue in this particular solution. Sigh... Need to think some more about how to avoid depending on wxwidgets as a wrapper for the API layer. :( Would be so much easier if that was installed standard on most systems. Not that it would help as much as I would like, looks like the purely wxLua parts are over 3MB... Grr..

Ok. Maybe I will drop persuit of this one solution. Time to see if you can directly wrap specific API functions in Lua itself and how to get LuaCOM to work right (same issue, so same solution, I think). That should leave overhead almost "entirely" in the script itself, plus one measly extra dll, not the engine. I assume you wouldn't object to making LuaCOM standard, *if* I could find a way to make it integrate? Wasn't that big, if I remember right.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #24 on Sat 24 Feb 2007 12:19 AM (UTC)  quote  ]
Message
It's very easy to wrap around C functions in Lua. What's harder is wrapping around data, and unfortunately to properly wrap C functions you often need to wrap the data as well.

Quote:
And last I looked, I only see *two* people actively complaining here that I should just give up.

By that logic: I only see *one* person actively trying to make this happen. :-)
(BTW, your choice of the word "complaining" is pretty interesting...)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

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

Posted by Nick Gammon   Australia  (19,169 posts)  [Biography] bio   Forum Administrator
Date Reply #25 on Sat 24 Feb 2007 01:40 AM (UTC)  quote  ]
Message
Quote:

Time to see if you can directly wrap specific API functions in Lua itself and how to get LuaCOM to work right (same issue, so same solution, I think).


You can access any API function my writing a small DLL that is installed via Lua, as I have shown in various posts on this forum. Thus, the client can be made to do virtually anything.

What is hard, and what you are partly asking about as well, is catching operating system events, and getting them to somehow appear inside a script.

As for making LuaCOM standard, I supply on this site a DLL which is compiled for Lua 5.1 (http://www.gammon.com.au/files/mushclient/lua5.1_extras/luacom.zip), for anyone that needs to use COM. Although this file is small (only 90 Kb), I think an optional extra is all that is needed here, as I doubt lots of people have a need for COM.

- Nick Gammon

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

Posted by Rakon   USA  (123 posts)  [Biography] bio
Date Reply #26 on Sat 24 Feb 2007 09:35 AM (UTC)  quote  ]
Message
I've really always wanted to stay away from COM. Unneeded really, and I don't like mucking around with it I think Shadowfyr has a decent idea down, but to actually think about implementing wxLua?? As Nick states, the installer for that alone is huge. Python already includes the Tk/TCL libraries in its download, and since I/anyone who has python and uses it, will already have Tk, its why Im choosing to use it for this project.

Quote:

I'm always amazed at the amount of things that you find can be added with just a complete reworking of how MUSHclient is written. It comes up in thread after thread... If you think it's so easy, just write your own client and be done with it.


Currently I am also doing just that.
Essentially, Its my version of a MUSHclient port for Linux. Xpertmud, Kmuddy, a few other Linux clients out there are pretty decent, however in terms of speed, scripting uses and user friendliness they are entirely lacking.
So in creating this client (as in the very very early stages of it), I am writing my own client in Python, to function much as MUSHclient does, but for Linux.

IE:
Speed
User friendly, without being too buttonish/newbiefied
Memory managment
Scripting choices(Python, Perl, Ruby)
Other features and neccesities(Fast triggers, Reqexp, Ect)

So, feel free to continue telling people to write thier own clients, Thanks!

Yes, I am a criminal.
My crime is that of curiosity.
My crime is that of judging people by what they say and think, not what they look like.
My crime is that of outsmarting you, something that you will never forgive me for.
[Go to top] top

Posted by Shadowfyr   USA  (1,775 posts)  [Biography] bio
Date Reply #27 on Sat 24 Feb 2007 07:36 PM (UTC)  quote  ]
Message
Well two points. 1) making a DLL to wrapper the API calls is basically doing nothing *except* replacing wx with your own API dll, not a huge improvement. lol 2) The only practical approach to using objects, instead of being stuck with the existing GUI elements or coding non-editable, compiled extensions, which still can't do events (it damn silly that we have to reinvent the wheel by having OnCallPlugin do what the event manager is supposed to be doing imho), is COM. Why? Because presumably LuaCOM includes connection point handling, which handles those same sorts of events.

Now, here is the real silly bit with the argument. Has anyone tried connecting events to event sinks when using LuaCOM yet? Because one would assume its got the "same" problem as Python and the rest because of it. If not, then... Damn, I wish I understood this stuff better.


main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #28 on Sat 24 Feb 2007 10:19 PM (UTC)  quote  ]

Amended on Sat 24 Feb 2007 10:20 PM (UTC) by Shaun Biggs

Message
Please read this if you think that Luacom is just Nick's API: http://www.gammon.com.au/forum/?id=6022
It's a luaforge project to add all COM functions into lua, which in effect can do pretty much anything with Windows that you want... just in a very messy Microsoft fashion.

As for using objects, the event have nothing to do with object oriented programming, since events are objects themselves, they cannot possibly be the core of the design. The main benefits are inheritance and polymorphism, which is covered in any computer science 101 class in existance. This makes things like the aliases and triggers not have to be written completely differently, or passed differently when called. The many scripting language interfaces are probably each inheriting from one class, letting them be called identically within the program.

And for the OnCallPlugin part... I'm very confused what exactly you're saying there. How is the event manager supposed to do anything different? You still have to code what events do, and how the class reacts. Calling plugins really shouldn't even be possible, since the whole point of a plugin is that it is something that can be completely removed from the rest of the world you have.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Shadowfyr   USA  (1,775 posts)  [Biography] bio
Date Reply #29 on Sun 25 Feb 2007 08:24 PM (UTC)  quote  ]
Message
Sigh.. Look. When you create and object, like a button, they have an *event* generator in them. In the case of a Button, this is usually "Click". So, when you create and object like that you usually do this:

mybutton = object_Handler.create("Button")
'Silly I know, but you have to put it on something. And this is an example only.
mybutton.parent = world.GetFrame
mybutton.name="Fred"
object_handler.connect("Fred_Click", "OnClick")


This is so that when you click the button it automatically calls "OnClick" in your program/script. Events are **not** objects. Objects are descreat chuncks of code that actually execute something. Events are simply data dumped into the system messaging archetecture using "FireEvent". Some place in "Botton" is a bit of code that says something like:

FireEvent(self.name + "_Click");


The event handler, I presume, keeps a table lookup that says, "The event Fred_Click should trigger a call to the address of "OnClick", which happens to be 'blah'."

I don't know where you get the idea that events are objects... But, point here is that the event handler architecture in most applications will start at the farthest "child" of the application, let it attempt to handle the event, then if that doesn't, it gets passed to the next highest level in the application. I.e. if a world window doesn't handle an event, then the main window is handed the event instead. MFC does things **way** differently. It handles "all events" in the main window code. this means every button, every scroll bar, every what ever, all gets passed "only" to the main window. No children ever see it, unless you use MFC's "message reflection" trick to explicitly redirect those messages to another object in the hierarchy, to give it a shot at dealing with the event first.

Now, most script engines don't have their own handler at all, or it relies on its "host" to do so. VBScript for example lets you return a reference to the script function, but requires that you pass that reference to a "connection point" handler in the hosting application. Fine if using IE, since IE also supplies the means to create the objects *and* it supplies the needed connection point system. You still can't use "createobject" to make something, then expect events to work with it, because IE doesn't have the reference data for the object to correctly inform its event generator who to "inform" about the event.

What is bloody confusing though is that connection points seem to imply that they directly call the code, since you are passing a reference to the specific address of the function to them. This may only be in the case of ActiveX though. Non-ActiveX may be forced to use the messaging system, which then means that inside an MFC application its not clear if LuaCOM or anything else will ever *see* the events, sicne they are children of an MFC application, which "shouldn't" pass any of that on to the script engine.

Its confusing as hell.

Now, the issue of using OnCallPlugin is simple. If events can't be handled in the *existing* system, then you need some way to capture and redirect them *external* to that system. What this means is creating all your GUI elements in an ActiveX EXE. This runs independently from Mushclient, but probably, for it to work right, also uses the Mushclient script bindings, like CallPlugin. Now, lets say this is a toolbar with 5 icons, which you click to cast spells, lets say "Light", "Heal", "Fireball", "Fear", "Heal: Fred". The last one heals a party member, so I can show why the code below "needs" to work the way it does. Each of these "could" simply be an event, which when clicked call the specific function needed. Without event management, you have to reinvent the wheel somehow to do this:

function OnCallPlugin (data)
  if data contains "Light" then
    call Cast_Light(right(data, len(data) - 10))
  end if
  if data contains "Heal" then
    call Cast_Heal(right(data, len(data) - 10))
  end if
  ...
end function

function Cast_Light(data)
  send "cast light"
end function

function Cast_Heal(data)
  if data <> "" then
    send "cast heal " & data
  else
    send "cast heal"
  end if
end function


In other words, the only way to handle a GUI system "not" created in scripting itself, or even "in" that scripting, without event management is to reinvent event management using OnCallPlugin as the "manager". And this just gets absurd when dealing with some pre-existing, closed source, 3rd party application. Lets say one that has 2-3 actually functions, none of which return the "state" of any part of the application, and two dozen *events* which are supposed to automatically inform the application that links to it of what those internal states are... Am I really the only person that thinks that having to code a new EXE for "every" such case, just to translate all the interfaces and events of that application to Mushclient function calls is a) rediculous and b) not something that probably more than 90% of the users of Mushclient are going to be able, never mind want, to do?

Its not about how many instances we "know about" right now where this is a problem or what work arounds exist for them. The issue is how many things are "no one" going to even bother trying to use with it, because the only way to do so is complicated, convoluted and completely redundant to what already existed to do the same thing.

Now.. I might be less frustrated if there was some "easy" way to make a generic EXE that was small, compact and worked by taking the lookup tables in an application/dll and building the correct internal lookups to make it work, including exposing all the same functions and data retrieval points. In other words you would tell "it" to connect the function name to the event and it would automatically translate the correct call to something the script could use... Its one idea I fiddled with, but it "still" requires, at the moment, using "OnCallPlugin" to handle the translated events. And it would be a pain in the ass to code in the first place.

There are many solutions. A lot of them are way more trouble and would waste even more time to get working right than just figuring out why events can't work in the present context and what needs to be done to fix it. The easiest, if we knew how, would be to fix it in the client. Everything else is bending the client, the component you are trying to host *and* the OS into a pretzel to accomidate the problem. And I don't mind doing that **if** its really necessary. I still don't think it actually is *yet*.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[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.


21,144 views.

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

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

[Home]

Written by Nick Gammon - 5K

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

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]