New version of pyk (0.3)
Mark Rages
cosmetic changes.
Changes:
- Added README file
- Added INSTALL file
- Added COPYING file (GPL v2)
- Calculate terminal width for progress bar. Should solve display
problems in Windows.
- Fixed --quiet bug.
- Added version number, displayed with pyk --help.
I arbitrarily chose 0.3 for the version number.
Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie
Xiaofan Chen
> - Calculate terminal width for progress bar. Should solve display
> problems in Windows.
This is not working under Windows. I have to revert back to the old
progress_bar.py (but keep the last part: the --quiet bug fix) so that
pyk-0.3 will work under Windows.
E:\Coding\pyk\pyk-0.3>pyk.py --quiet --bootload PK2V010003.hex
found 3 busses
found 3 busses
found 3 busses
Traceback (most recent call last):
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 644, in ?
main()
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 621, in main
pk.bootload(bootloadfilename)
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 371, in bootload
self.pb=self.get_prog_bar(bytecount,'Bootload Program')
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 277, in get_prog_bar
pb=pbclass(length,label)
File "E:\Coding\pyk\pyk-0.3\progress_bar.py", line 87, in __init__
self.width=guess_width()
File "E:\Coding\pyk\pyk-0.3\progress_bar.py", line 68, in guess_width
x=guess_width_unix()
File "E:\Coding\pyk\pyk-0.3\progress_bar.py", line 36, in guess_width_unix
return terminal_size()[0]
File "E:\Coding\pyk\pyk-0.3\progress_bar.py", line 34, in terminal_size
return none,none
NameError: global name 'none' is not defined
If I revert the sequence of guess_width_win32() and guess_width_linux()
in function guess_width(), the following error message pops up.
E:\Coding\pyk\pyk-0.3>pyk.py --quiet --bootload PK2V010003.hex
found 3 busses
found 3 busses
found 3 busses
Traceback (most recent call last):
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 644, in ?
main()
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 621, in main
pk.bootload(bootloadfilename)
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 371, in bootload
self.pb=self.get_prog_bar(bytecount,'Bootload Program')
File "E:\Coding\pyk\pyk-0.3\pyk.py", line 277, in get_prog_bar
pb=pbclass(length,label)
File "E:\Coding\pyk\pyk-0.3\progress_bar.py", line 87, in __init__
self.width=guess_width()
File "E:\Coding\pyk\pyk-0.3\progress_bar.py", line 68, in guess_width
x=guess_width_win32()
File "E:\Coding\pyk\pyk-0.3\progress_bar.py", line 49, in guess_width_win32
from ctypes import windll, create_string_buffer
ImportError: No module named ctypes
> - Fixed --quiet bug.
Yes this is fixed.
Regards,
Xiaofan
Mark Rages
>
> return none,none
> NameError: global name 'none' is not defined
>
Ok, this was a stupid typo. fixed.
> If I revert the sequence of guess_width_win32() and guess_width_linux()
> in function guess_width(), the following error message pops up.
>
> ImportError: No module named ctypes
>
You need to install the ctypes module:
http://starship.python.net/crew/theller/ctypes/
I think some versions of Python come with ctypes installed already.
Here's version 0.31
Xiaofan Chen
> You need to install the ctypes module:
> http://starship.python.net/crew/theller/ctypes/
>
> I think some versions of Python come with ctypes installed already.
>
> Here's version 0.31
>
Excellent. Now it runs under Windows very smoothly. I do not
need to make any patch except the build.bat script to suit for
different version of Python and Swig I have.
The progress bar now works the same across Windows and Linux.
Regards,
Xiaofan
Xiaofan Chen
By the way, I was busy installing Fedora core 4 for the past several days
and it looks quite okay. pk2 and pyk both work under FC4. Actually I only
boot to Windows for about 30 minutes in the past few days to test pyk-0.31
on Windows.
Still one thing is not working on my FC4 box. The hotplug seems to work
(from dmesg I can see that pyk is working when I plug in PICkit 2)
but I still need to run pyk/pk2 as root. I think the problem is not related
to the hotplug but some setting in the system. For example, I add myself
to the uucp account to access the com port but it is not working with
minicom/gtkterm still complain the wrong permission of /dev/ttyS0 and
/dev/ttyS1. I need to chmod them to 666 to work with com ports.
Any idea what could be wrong?
Regards,
Xiaofan
Mark Rages
Check what groups you are in (run 'groups' as your user). Anyone in
the 'pickit' groups should be able to access the PICkit.
I have noticed thet following hotplug limitations on my FC2 system.
1) the PIckit MUST be hotplugged. That is, if the pickit is already
plugged in on bootup, the permissions don't get set properly.
2) Bootloading isn't working right. I think when the device enters
bootload mode, the hotplug scripts don't get run again. I haven't
verified this -- I just do bootloading as root.
Xiaofan Chen
> >
> > Still one thing is not working on my FC4 box. The hotplug seems to work
> > (from dmesg I can see that pyk is working when I plug in PICkit 2)
> > but I still need to run pyk/pk2 as root. I think the problem is not related
> > to the hotplug but some setting in the system. For example, I add myself
> > to the uucp account to access the com port but it is not working with
> > minicom/gtkterm still complain the wrong permission of /dev/ttyS0 and
> > /dev/ttyS1. I need to chmod them to 666 to work with com ports.
> >
> > Any idea what could be wrong?
> >
>
> Check what groups you are in (run 'groups' as your user). Anyone in
> the 'pickit' groups should be able to access the PICkit.
Strange, today it works. I can run pyk and pk2 as a normal user.
> I have noticed thet following hotplug limitations on my FC2 system.
>
> 1) the PIckit MUST be hotplugged. That is, if the pickit is already
> plugged in on bootup, the permissions don't get set properly.
Today both are okay for me. Tomorrow to test again. ;-)
> 2) Bootloading isn't working right. I think when the device enters
> bootload mode, the hotplug scripts don't get run again. I haven't
> verified this -- I just do bootloading as root.
I think this is related to the fact that you have not update the
bootloader firmware.
One more thing, I can not use the global installed pyk for bootloader.
I can only run the local pyk to do that.
Another thing, it makes sense to have a file named pyk.py (the
same as pyk with .py extension) for Windows. Windows needs
that extension to call python.
xiaofan@localhost:~/Desktop/build/pyk/pyk-0.31$ pyk --on
Found PICkit 2 Firmware 1.0.3
xiaofan@localhost:~/Desktop/build/pyk/pyk-0.31$ pyk --bootload=PK2V010003.hex
Found PICkit 2 Firmware 1.0.3
Traceback (most recent call last):
File "/usr/local/bin/pyk", line 647, in ?
main()
File "/usr/local/bin/pyk", line 624, in main
pk.bootload(bootloadfilename)
File "/usr/local/bin/pyk", line 374, in bootload
self.pb=self.get_prog_bar(bytecount,'Bootload Program')
File "/usr/local/bin/pyk", line 274, in get_prog_bar
import progress_bar
ImportError: No module named progress_bar
xiaofan@localhost:~/Desktop/build/pyk/pyk-0.31$ ./pyk --bootload=PK2V010003.hex
Found PICkit 2 Firmware 1.0.3
Bootload Program |===========================================>|7354/7354 (100%)
Bootload Verify |===========================================>|7354/7354 (100%)
Verify successful!
Regards,
Xiaofan
Xiaofan Chen
> Today both are okay for me. Tomorrow to test again. ;-)
It still works so it is really working.
> One more thing, I can not use the global installed pyk for bootloader.
> I can only run the local pyk to do that.
I know the reason. There is a minor bug in the permission setting of
progress_bar.py. After I chmod it to 644 and redo the install process
(su -c "make install"), the global installed pyk works.
xiaofan@localhost:~/Desktop/build/pyk/pyk-0.31$ ls -la progress_bar.py
-rwx--x--x 1 xiaofan xiaofan 3716 Dec 13 23:17 progress_bar.py
xiaofan@localhost:~/Desktop/build/pyk/pyk-0.31$ chmod 644 progress_bar.py
Regards,
Xiaofan
Mark Rages
Is it that way in the distribution? The version control software I
use (subversion) keeps track of permissions and ownership, but I don't
understand the details.
Chen Xiao Fan
> From: Mark rages
> From: pickit...@googlegroups.com
> Sent: Tuesday, December 20, 2005 11:54 PM
> To: pickit...@googlegroups.com
> Subject: Re: New version of pyk (0.3)
> > xiaofan@localhost:~/Desktop/build/pyk/pyk-0.31$
> > ls -la progress_bar.py
> > -rwx--x--x 1 xiaofan xiaofan 3716 Dec 13 23:17 progress_bar.py
> > xiaofan@localhost:~/Desktop/build/pyk/pyk-0.31$ chmod 644
> > progress_bar.py
>
> Is it that way in the distribution? The version control software I
> use (subversion) keeps track of permissions and ownership, but I don't
> understand the details.
>
Yes that is from pyk-0.31 distribution.
Regards,
Xiaofan
Xiaofan Chen
I think this is a bit strange. I download pyk-0.31 again and check
the permission of the file progress_bar.py and it is not correct.
xiaofan@localhost:~/Desktop/pyk-0.31$ ls -la pr*
-rw-r--r-- 1 xiaofan xiaofan 20528 Dec 13 23:17 programming_specs.py
-rwx--x--x 1 xiaofan xiaofan 3716 Dec 13 23:17 progress_bar.py
I boot to Windows and under MSys I can see that the permission
is correct.
Test@PCAMD64 /e/Coding/pyk/targz/pyk-0.31
$ ls -la pr*
-rwxr-xr-x 1 Test Administ 20528 Dec 13 23:17 programming_specs.py
-rwxr-xr-x 1 Test Administ 3716 Dec 13 23:17 progress_bar.py
Could it be I have a bug in my Fedora Core 4 system? But I tend to
believe that MSys under Windows may not truly appreciate the
permission under Linux.
Mark: could you confirm the real permission of this file?
Regards,
Xiaofan