I did it!!!

Keep up to date with EG related information here.
User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Sun Jul 16, 2017 3:15 pm

i was just going to tell you to remove the process watcher plugin to see if this is what is causing the issue.

and that file will get locked if EG is running and you have the process watcher plugin installed or EG in debugging mode. because by having EG in debugging mode causes the loading of all of the plugins. Not the actual class it's self but the module. so if a plugin like the process watcher relies on an external dll file this is usually loaded at the module level. which in turn would cause the file to get locked even if you do not have it installed in your tree.

so best bet is to shutdown EG (after removing the plugin from the tree) and remove the plugin from the plugins folder and restart EG

see if the error goes away if you remove the process watcher plugin. This will point us to what to look at to fix the issue.
If you like the work I have been doing then feel free to Image

Diz
Experienced User
Posts: 121
Joined: Tue Jan 10, 2017 4:49 pm

Re: I did it!!!

Post by Diz » Sun Jul 16, 2017 3:42 pm

hmm... thats going to be a problem as i use the process watcher to trigger actions when processes open/close and also becasue of the seeming randomly occurring nature of the errors its hard to track down! :( i can cope with the file locking thing very easily with unlocker so im not worried about that but i thought you should know.

oh and i dont use debugging mode by the way.

User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Sun Jul 16, 2017 3:56 pm

@diz

ok give this a go and see if it works

I changed up the code to hopefully solve this problem. as I have only seen it 1 time and have not been able to replicate it i never knew what it was an thought it was resolved. But this might fix it we will see. it's either going to fix it or it will cause a different issue LOL

https://ci.appveyor.com/api/buildjobs/9 ... _Setup.exe
If you like the work I have been doing then feel free to Image

Diz
Experienced User
Posts: 121
Joined: Tue Jan 10, 2017 4:49 pm

Re: I did it!!!

Post by Diz » Sun Jul 16, 2017 4:02 pm

ok... so i just did quite a few start/exit/start cycles with and without the process watcher and the dll didnt lock and the big list of errors never showed up! if i can narrow it down any further i will let you know.

that was with the last version... you posted a new one while i was writing this but i have to go out now for a while so i will test later :)

User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Sun Jul 16, 2017 10:38 pm

alright let me know what you find out. But I have a feeling it has to do with an event coming in when everything is not loaded up. so I may have to put a boot lock on the events.
If you like the work I have been doing then feel free to Image

Diz
Experienced User
Posts: 121
Joined: Tue Jan 10, 2017 4:49 pm

Re: I did it!!!

Post by Diz » Mon Jul 17, 2017 4:58 pm

nothing to report on my other issue yet. got this different error earlier though, at startup, just after initializing all the plugins:

14:37:03 Unhandled exception in WorkerThread <EventThread>:
14:37:03 Callers stack:
14:37:03 File "wx\_core.pyc", line 8657, in MainLoop
14:37:03 File "wx\_core.pyc", line 7952, in MainLoop
14:37:03 File "wx\_core.pyc", line 16766, in <lambda>
14:37:03 Traceback (most recent call last) (WIP-2017.07.16-15.53.51):
14:37:03 File "D:\Automation\EventGhost\eg\Classes\ThreadWorker.py", line 253, in __DoOneEvent
14:37:03 self.HandleAction(action)
14:37:03 File "D:\Automation\EventGhost\eg\Classes\ThreadWorker.py", line 140, in HandleAction
14:37:03 action()
14:37:03 File "D:\Automation\EventGhost\eg\Classes\ThreadWorker.py", line 324, in __call__
14:37:03 self.returnValue = self.func(*self.args, **self.kwargs)
14:37:03 File "D:\Automation\EventGhost\eg\Classes\Event\EventThread.py", line 77, in StartSession
14:37:03 self.TriggerEvent(self.startupEvent[0], self.startupEvent[1])
14:37:03 IndexError: tuple index out of range

eg still seemed to run normaly afterwards though but i did a restart anyway just in case.

what does it mean when it says error in '<lambda>' instead of a function name anyway?

User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Mon Jul 17, 2017 7:49 pm

I am going to have to go and check that I am not sure why that error looks like that. I could have sworn I had fixed that issue already. But a lambda is a function just another kind of function.

were you trying to start EG with the -e or -event command line argument?
If you like the work I have been doing then feel free to Image

Diz
Experienced User
Posts: 121
Joined: Tue Jan 10, 2017 4:49 pm

Re: I did it!!!

Post by Diz » Mon Jul 17, 2017 7:57 pm

no... i just double click the icon in windows, ive never used any command line arguments actually.

User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Tue Jul 18, 2017 4:13 am

self.TriggerEvent(self.startupEvent[0], self.startupEvent[1])

because of that line. it would only try to trigger an event on startup if for some reason eg.startupEvent was not None. and the only way it would be something other then None is if there was something passed to it from the command line. That being said. go and check the actual shortcut and see what is in there for the executable and see if there are any arguments after it.
If you like the work I have been doing then feel free to Image

Diz
Experienced User
Posts: 121
Joined: Tue Jan 10, 2017 4:49 pm

Re: I did it!!!

Post by Diz » Tue Jul 18, 2017 4:33 am

i dont use a shortcut either. i just double click the exe! trust me... no args were given... honestly! lol

User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Tue Jul 18, 2017 5:20 am

I will have a fix up for this shortly as I am adding some things to it.

But I have done some tests. Here is the xml for the 2 macros.

This first macro has no events. it has 2 actions. the TriggerEvents action will trigger 10 events that will start 10 threads all doing some math equations in a loop that can only be stopped by running the other action in this macro. The threads will randomly select numbers between 1 and 45 to perform the functions on but it will do them every 1 milliseconds. But you have to remember there are 10 of these suckers doing this at this speed.

My CPU time fluctuates between 0 and 1 % Unless I open up the log for one of the events then it goes up 1-2% for each concurrent log that is open and the maximum i can view is 4 at a time. I did find a bug in this due to scrolling and the log not actually being visible. because i do not destroy the control it will remain open and posting stuff to it. I am going to rework that alittle bit so that if it isn't visible it will destroy only the control not the frame so when the frame sees that it is in view again it will recreate the log control and populate it again. this will help to improve general overall EG performance if a log is open but not in view.

The copy I have running also remove the use of eg.TriggerEventWait. as this is a useless thing to have ta this point. it also removes the passing of the event between 3 different threads. it will now create the thread directly and inside the thread once it has been started if the event is already running there is a lock object that will cause the new thread to wait until the one before it is finished. it will continue to stack them in the order in which they were triggered. This is done on an event by event basis. so each unique event has it's own "event queue" so it will cause a block for like events. but this block does not affect the main program. only the new event thread that has been generated. These additions and removals is one of the reasons why the cpu impact is so low for so many things going on. But the boot time of EG has also improved. so much so that you can actually see it. I would have to put a timer in to test it to see how much faster.

expect another release of this either tonight or tomorrow in the morning.

You will need to copy both parts and put them in your tree for it to work.

Code: Select all

<?xml version="1.0" encoding="UTF-8" ?>
<EventGhost Version="WIP">
    <Macro Name="Python Script" XML_Guid="{DE13900F-84D3-4A62-9731-2C08AFB028BF}" Expanded="True">
        <Action Name="TriggerEvents" XML_Guid="{B3BB5B5C-4CCE-4A5D-AD39-25FF86359531}">
            EventGhost.PythonScript(u'for i in range(10):\n    eg.TriggerEvent(str(i))')
        </Action>
        <Action XML_Guid="{7A89651E-513A-491E-889D-A25F052F50AE}">
            EventGhost.PythonCommand(u'eg.globals.runEvents = False')
        </Action>
    </Macro>
</EventGhost>

Code: Select all

<?xml version="1.0" encoding="UTF-8" ?>
<EventGhost Version="WIP">
    <Macro Name="Python Script" XML_Guid="{3BBD3015-E88C-4F84-90C8-AB5D166D6AA7}">
        <Event Name="Main.0" XML_Guid="{9C6AE744-31CB-4802-AF56-29875767C37F}" />
        <Event Name="Main.1" XML_Guid="{8BAB63DA-B8CA-4C0E-B0C0-A875286C9F58}" />
        <Event Name="Main.2" XML_Guid="{41C417FC-34AE-469D-963B-2E6082603D61}" />
        <Event Name="Main.3" XML_Guid="{C315E84E-F23F-4D6F-9F89-061987DF6C33}" />
        <Event Name="Main.4" XML_Guid="{BB4B28FA-BF68-4AA6-85C6-DDC60AD43689}" />
        <Event Name="Main.5" XML_Guid="{04B86A63-5F43-4AEC-A216-70F076C732DA}" />
        <Event Name="Main.6" XML_Guid="{2737D9C5-B710-4FF2-990B-9E8597AE9C97}" />
        <Event Name="Main.7" XML_Guid="{16DF98E1-DA8E-415A-84CD-A7706CEFB983}" />
        <Event Name="Main.8" XML_Guid="{6A6F7CE6-B068-4000-ADB7-6D88F53A85B4}" />
        <Event Name="Main.9" XML_Guid="{D9D12AEB-3A1A-48E6-BE8C-5C50DE6F0114}" />
        <Action XML_Guid="{B54B432A-9F05-4767-AAF4-7E6C1FAA10BD}">
            EventGhost.PythonScript(u"import threading\nimport time\nimport random\nimport math\n\neg.globals.runEvents = True\n\n\nwhile eg.globals.runEvents:\n    args1 = random.randint(1, 45)\n    args2 = random.randint(1, 45)\n    result = 0\n    for i in range(args1):\n        angle_rad = math.radians(args2)\n        result += math.tanh(angle_rad)/math.cosh(angle_rad)/args1\n        \n    eg.PrintNotice(str(threading.currentThread()) + ' : ' + str(result) + ' : ' + eg.eventString)\n    time.sleep(0.01)\n")
        </Action>
    </Macro>
</EventGhost>
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Tue Jul 18, 2017 5:34 am

this line.

self.TriggerEvent(self.startupEvent[0], self.startupEvent[1])

could be getting set for the Main.OnInit event. I am going to have to do some further testing. but what i believe is happening is that the Autostart macro is a macro without an event. and it to gets run in it's own thread at startup. to process everything in it. I may have to reset the firing position of the Main.Oninit to be before the plugins actually start to load. This will fix an issue in EG where unless you put the creation of a specific global before the plugin gets loaded and that plugin produces an event which runs a macro and that macro is dependent on that global and the global hasn't been created yet.. you get an error. so in all realidy the Main.OnInit was triggered in the wrong place in the original code. always should have been put before the loading of the plugins. so it could be used to set up any global attributes or do specific tasks that you would want to do when G starts it's initialization process. and at the end of that init process it would start a plugin init process. which could be another event that is triggered that starts this up. but it can be used to perform other things the user may want to do at plugin load time.

That's a thought of something that could/should be done if I have to tinker about with the Main.OnInit event.
If you like the work I have been doing then feel free to Image

Diz
Experienced User
Posts: 121
Joined: Tue Jan 10, 2017 4:49 pm

Re: I did it!!!

Post by Diz » Tue Jul 18, 2017 1:33 pm

umm... ok... i have no idea what these two macros are doing and i didnt understand much of what you were saying about them! do i need these? what for? lol :mrgreen:

anyway the second one didnt work:

Traceback (most recent call last):
Python script "10", line 17, in <module>
eg.PrintNotice(str(threading.currentThread()) + ' : ' + str(result) + ' : ' + eg.eventString)
TypeError: cannot concatenate 'str' and 'NoneType' objects

the first one sent my cpu usage straight up to about 50%!!!

oh yeah... the indents are still there when you use the 'select all' button :(

Diz
Experienced User
Posts: 121
Joined: Tue Jan 10, 2017 4:49 pm

Re: I did it!!!

Post by Diz » Tue Jul 18, 2017 2:03 pm

ok wait... the 50% cpu thing is because of the global monitor plugin thing i got from one of your threads somewhere! i had tried it and forgotten it was still there lol! anyway without that plugin the cpu usage during the first macro is negligable like yours :wink:

i hadnt noticed it before but now that im looking at cpu usage that global monitor thing makes eg idle at 6% cpu all the time :o so ive removed that permanently.

User avatar
kgschlosser
Site Admin
Posts: 3115
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: I did it!!!

Post by kgschlosser » Tue Jul 18, 2017 2:37 pm

I know the global monitor thing does. my coding skills have greatly imporved since then. and it is something that i can make to run extremely slow as well. it has to do with the fact that it is still being shown. it's technically not the global monitor causing the high CPU use this is one of the reasons why I personally would like to see wx gone in favor of a web gui.

wx = the component in EventGhost that handles the GUI.

but there are things that i can put into place that do not cause constant updates of the GUI. similar to how I handled it with the event logs. tho it does need some refinement the basic underlying bits of it work just fine. I have to actually close the control if you scroll the log off the window instead of simply hiding it.
If you like the work I have been doing then feel free to Image

Post Reply