[Dev] Milestone 0.3.18 :-(

[Morgen Sagen]

On my machine I added the following lines to the top of Chandler.py in  
both the 0.3.17 and 0.3.18 Windows/end-user distro to see if perhaps  
Python was having trouble importing modules:

out = file("output.txt", "w+")
import sys
for p in sys.path:
    out.write("%s\n" % p)
sys.exit(0)

In the 0.3.17 version it prints:

c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_17
c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_17\python23.zip
c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_17\DLLs
c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_17\lib
c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_17\lib\plat-win
c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_17\lib\lib-tk
c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_17
c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_17\lib\site-packages

But in the 0.3.18 version it prints this garbage:

c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_18
elease
c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_18\python23.zip
elease\DLLs
elease\lib
elease\lib\plat-win
elease\lib\lib-tk
c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_18

I also printed the exception that gets thrown:

"No module named logging"

However, that module is in the lib/ directory.  So for some reason  
sys.path is just messed up.  To test this theory, I added the following  
to the top of Chandler.py:

import sys
sys.path = [
"c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_18",
"c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_18\python23.zip",
"c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_18\DLLs",
"c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_18\lib",
"c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_18\lib\plat-win",
"c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_18\lib\lib-tk",
"c:\Documents and Settings\Morgen\Desktop\Chandler_win_0_3_18",
"c:\Documents and  
Settings\Morgen\Desktop\Chandler_win_0_3_18\lib\site-packages"
]

And sure enough, chandler.exe worked.  So something about the way our  
Python is built has changed recently (at least on Windows).

~morgen

On Jun 15, 2004, at 7:27 PM, John Anderson wrote:

> kinda looks like a problem with winlaunch.
>
> Py_Initialize() sets errno to ENOENT
>
> fp = fopen("Chandler.py", "r+"); sets errrno to EINVAL
>
> and even a
>
> fp = fopen("XXXX", "w+"); sets errorno to EINVAL
>
> I was able to get this failure even though I could run chandler from  
> wing.
>
> John
>
>
>
> Mark Jaffe wrote:
>
>> We have completed milestone 0.3.18; the bad news is that it's not  
>> quite useable. We will be debugging tomorrow and hope to have a  
>> solution very quickly.
>>
>> The CVS tree has been reopened.
>>
>> --  
>> Mark Jaffe | (415) 946-3028 (work)
>> Release Engineer | (408) 807-2093 (cell)
>> OSAF | (415) 946-3001 (FAX)
>> markie at osafoundation.org | http://www.osafoundation.org/
>> PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE
>>
>> ---------------------------------------------------------------------- 
>> --
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev