In the past, I’ve no problem running the iDigi Dia v1.1.15. However, since the v1.2 is out, I’ve decided to give it a try of upgrade.
the output of the telnet session is as shown below:
Attempting to read “dia.pyr” in “WEB/python/dia.zip”…
iDigi Device Integration Application Version 1.2.19
Using settings file: dia.pyr
Traceback (most recent call last):
File “”, line 284, in ?
File “”, line 272, in main
File “C:\Users\Denz\Desktop\Digi Dia Program\src\core\core_services.py”, line
File “C:\Users\Denz\Desktop\Digi Dia Program\src\core\core_services.py”, line
File “C:\Users\Denz\Desktop\Digi Dia Program\src\core\scheduler.py”, line 36,
File “C:\Users\Denz\Desktop\Digi Dia Program\src\common\sched_async.py”, line
ImportError: No module named digi_sched
I don’t understand why is it not working as the version before? I’ve tried following the same steps as before, anybody out there with the same issues??
By the way, I’ve also tried looking into the dia.zip file for the module digi_sched. It’s present in there in site-pacakges\digi_sched.pyc. It fails to load it? How can I get it loaded if the error is as stated above?
I am using Dia 1.2.19 and so far it is working for me.
One thing I noticed that seemed to be different is that in my Dia.zip, digi_sched.pyc is located under the lib directory, and I do not have a site-packages directory at all.
How are you doing the compile of the Dia? Did you basically extract Dia 1.2.19 somewhere, then (using Python 2.4.3?) run “python make.py cfg/dia.yml”.
Here, take a look at my attachment. On the left image is Dia v1.2.19. On the right is Dia v1.1.15. As you can see, the digi_sched.pyc is located in the site-packages directory in v1.2.19 unlike v1.1.15 where it was located in lib directory.
Yes, I’m running on Python 2.4.3. I compiled the Dia just like I always do with Dia v1.1.15. Extract it onto a folder, then compile the dia.zip in the bin directory from the same folder; for example on command prompt I type:
there’s a new line I noticed on the cmd window though for v1.2.19:
Transforming settings file ‘demos\green_getting_started\green_getting_started.yml’ to ‘pyr’ format…
which I think won’t be the cause of it since it’s just compiling in pyr format. But just thought of just mentioning here.
By the way, can you tell me how can I include an attachment here? I noticed the option to do so, but it did not prompt me to include any attachment after ticking the box.
The only way I was able to re-create this was to copy the files from the lib directory in the Dia folder to the site-packages directory under my python installation.
So, could you check C:\Python24\Lib\site-packages (or wherever you have python 2.4.3 installed) and make sure digi_sched.py and the other files are not in there?
If that’s not the problem, I’m not sure what to suggest other than possibly trying to download Dia 1.2.19 and Python, because it’s hard to imagine what could be different between our systems where it works for me but not on your system. We might be able to throw some print statements in make.py or the underlying script that puts the zip file together.
I’m not sure how to do attachments yet either, still getting used to this new forum myself.
Yes, yes! That was the problem. I had them in there thinking it would be a convenience to run some testing via Eclipse, so I had external libraries (Dia’s libraries) stored there. I did not know it would happen to have issues. Now whenever I compiled the dia.zip, the digi_sched.py and other files are in their correct folders.
Can you explain how you came to knew the solution? Strangely, it doesn’t seem to be a problem in the previous version. Why is that so on v1.2.19?
Curious to know
I found it pretty weird that a folder that doesn’t come with Dia was showing up in the resultant Dia.zip. So, I searched and found that site-packages was a part of the Python distribution itself. I glanced through make.py to see how it went about building the directories to include. It looked like it mainly walked the different directories and put them on the path, so nothing overly complex.
So, all I could think of was throwing digi_sched.py in the site-packages folder and trying a make. By chance, it happened to recreate the problem.
The make process must have changed in some way between 1.1.x and 1.2.x, maybe it’s just checking the python distribution before the Dia libaries, not totally sure.
