Post by thread:[OT][EE] How Easy To Use Is Python?

I've used python quite a bit and it is very portable and nice to program in. I think it's probably the nicest language I've worked with actually. I can't comment on the serial side of things as I haven't used it in python. Cheers, Zik On 8/13/07, Bob Axtell <spam_OUTengineerTakeThisOuTcotse.net> wrote: {Quote hidden}> I need to make a few programs that will stand alone and run under > Windoze 2K/XP and can be made into a Linux version with minimal > or NO expense to my client.. > > It has to have the ability to talk to PC Serial ports and VCP (emulated > serial ports, like under USB<>RS232 converters). > > I have been told that Python 2.51 works great like this. Is it true? Anybody > using it? > > --Bob Axtell > -

Bob Axtell wrote: > I need to make a few programs that will stand alone and run under > Windoze 2K/XP and can be made into a Linux version with minimal > or NO expense to my client.. > > It has to have the ability to talk to PC Serial ports and VCP (emulated > serial ports, like under USB<>RS232 converters). > > I have been told that Python 2.51 works great like this. Is it true? Anybody > using it? > > --Bob Axtell > I have some python stuff that works fine in both Linux and windows and uses the serial port. The hardest part I have found is python by default lacks a "byte" type variable, which can make communications with little micro's more difficult. I did find a method of doing the conversion but its not pretty and might need to be changed if it runs on 64bit hardware (I didn't look into it too far i was more interested in the hardware lol) I have seen a module out there that seems to be designed for making packets of data (like IP datagrams) in any format you like which might make things much easier. As far as UI type stuff wxPython is really nice and quite easy to use, the "style" is a little cluttered in it for legacy reasons (capitalisation and the like can be all over the place), it uses native widgets for whatever platform its on so in windows it looks like a windows program and in Linux it looks like Linux. You might need to do a little work for cross platform but mainly only things like where files are saved by default IE vista wont let programs save config changes in their own program directory without running with admin privileges. Which can make changing an ini file a hassle.

On 8/13/07, Bob Axtell <.....engineerKILLspam@spam@cotse.net> wrote: > I need to make a few programs that will stand alone and run under > Windoze 2K/XP and can be made into a Linux version with minimal > or NO expense to my client.. > > It has to have the ability to talk to PC Serial ports and VCP (emulated > serial ports, like under USB<>RS232 converters). > > I have been told that Python 2.51 works great like this. Is it true? Anybody > using it? > Python should be ok. You can use pyserial which works under Windows and Linux. The VCP things can be tricky under Linux. Some of them do not work well under Linux, especially the PL2303 or similar chips. If you use FTDI, you can even use pyusb (http://bleyer.org/pyusb/) under Windows. This pyusb is different from another pyusb which is a python wrapper for libusb. Regards, Xiaofan

What modules do you use for Serial Port usage? were they "addon" modules, or does Python have something internal for serial ports? --Bob A Jake Anderson wrote: {Quote hidden}> > I have some python stuff that works fine in both Linux and windows and > uses the serial port. > The hardest part I have found is python by default lacks a "byte" type > variable, which can make communications with little micro's more > difficult. I did find a method of doing the conversion but its not > pretty and might need to be changed if it runs on 64bit hardware (I > didn't look into it too far i was more interested in the hardware lol) > I have seen a module out there that seems to be designed for making > packets of data (like IP datagrams) in any format you like which might > make things much easier. > > As far as UI type stuff wxPython is really nice and quite easy to use, > the "style" is a little cluttered in it for legacy reasons > (capitalisation and the like can be all over the place), it uses native > widgets for whatever platform its on so in windows it looks like a > windows program and in Linux it looks like Linux. > > You might need to do a little work for cross platform but mainly only > things like where files are saved by default IE vista wont let programs > save config changes in their own program directory without running with > admin privileges. Which can make changing an ini file a hassle. > >

I would still stick to C++ and C. Probably Java*when C++ and C is not adequate*.... Anyway just use a language you are comfortable with. John --- Bob Blick <EraseMEbbblickspam_OUTTakeThisOuTsbcglobal.net> wrote: {Quote hidden}> How about Visual Basic 6 under Windows and Gambas 2 > under Linux? > > Bob Axtell wrote: > > I need to make a few programs that will stand > alone and run under > > Windoze 2K/XP and can be made into a Linux version > with minimal > > or NO expense to my client.. > > > > It has to have the ability to talk to PC Serial > ports and VCP (emulated > > serial ports, like under USB<>RS232 converters). > > > > I have been told that Python 2.51 works great like > this. Is it true? Anybody > > using it? > --

John La Rooy wrote: > On 8/13/07, Jake Anderson <jakespam_OUTvapourforge.com> wrote: > >> I have seen a module out there that seems to be designed for making >> packets of data (like IP datagrams) in any format you like which might >> make things much easier. >> >> > > Are you thinking of the struct module? > http://docs.python.org/lib/module-struct.html > > John La Rooy > That's what I'm using now to convert to a 16 bit value. This other module (cant remember the name) basically you defined a class and set subclasses to define all the bits and bobs you wanted in your packet. Then you set the values for all your subclasses and such like (foo.left_motor_drive = 23) and it goes away and assembles everything how you want it with everything having the right number of bits/bytes etc. here's a sample program that sends the value received on the command line out the first serial port at 38400bps using struct and pyserial import sys import serial import struct import time ser = serial.Serial(0) #open first serial port print ser.portstr #check which port was really used ser.baudrate = 38400 pwm_val = int(sys.argv[1]) #get pwm value from command line print pwm_val ser.write(struct.pack('H',pwm_val)) #send data packed into a small int (2 bytes) ser.close() #close port

On 8/13/07, John Chung <@spam@kravnusKILLspamyahoo.com> wrote: > > I would still stick to C++ and C. Probably Java*when > C++ and C is not adequate*.... Anyway just use a > language you are comfortable with. > > John > Perhaps you could suggest which serial libraries/modules/packages to use with windows/linux for those languages. Some people find Python very easy to pick up, and much faster to develop with, so overall it may save time John La Rooy {Quote hidden}> > --- Bob Blick <KILLspambbblickKILLspamsbcglobal.net> wrote: > > > How about Visual Basic 6 under Windows and Gambas 2 > > under Linux? > > > > Bob Axtell wrote: > > > I need to make a few programs that will stand > > alone and run under > > > Windoze 2K/XP and can be made into a Linux version > > with minimal > > > or NO expense to my client.. > > > > > > It has to have the ability to talk to PC Serial > > ports and VCP (emulated > > > serial ports, like under USB<>RS232 converters). > > > > > > I have been told that Python 2.51 works great like > > this. Is it true? Anybody > > > using it? > > --

--- John La Rooy <RemoveMEpiclist.jlrTakeThisOuTlarooy.com> wrote: > On 8/13/07, John Chung <spamBeGonekravnusspamBeGoneyahoo.com> wrote: > > > > I would still stick to C++ and C. Probably > Java*when > > C++ and C is not adequate*.... Anyway just use a > > language you are comfortable with. > > > > John > > > Perhaps you could suggest which serial > libraries/modules/packages > to use with windows/linux for those languages. > Programming using C in Linux. tldp.org/HOWTO/Serial-Programming-HOWTO/index.html Programming in Windows using C http://msdn2.microsoft.com/en-us/library/ms810467.aspx I have to admit I am familar to Windows and Linux system api. John ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. answers.yahoo.com/dir/?link=list&sid=396545433

On Aug 12, 2007, at 6:53 PM, Jake Anderson wrote: > The hardest part I have found is python by default lacks a "byte" type > variable, which can make communications with little micro's more > difficult. Isn't one of the highly touted "features" of python, the ability to overload and/or add methods to various operators in the syntax, yourself? It seems odd that someone, somewhere, hasn't just hacked together a library that would overload the default types and add in "byte" already, if my understanding of the language's capabilities is correct. -- Nate Duehr TakeThisOuTnateEraseMEspam_OUTnatetech.com

On Aug 12, 2007, at 9:05 PM, John La Rooy wrote: >> I would still stick to C++ and C > Perhaps you could suggest which serial libraries/modules/packages > to use with windows/linux for those languages. A lot of things can get away with just reading/writing the appropriate device (/dev/tty05 or COM6: or whatever) as a standard file. Much of the rest may get away with "standardized" use of ioctl on such "files." I'm not sure when you'd need to start considering a special purpose library; it's all legacy technology... BillW

Nate Duehr wrote: > On Aug 12, 2007, at 6:53 PM, Jake Anderson wrote: > > >> The hardest part I have found is python by default lacks a "byte" type >> variable, which can make communications with little micro's more >> difficult. >> > > Isn't one of the highly touted "features" of python, the ability to > overload and/or add methods to various operators in the syntax, > yourself? > > It seems odd that someone, somewhere, hasn't just hacked together a > library that would overload the default types and add in "byte" > already, if my understanding of the language's capabilities is correct. > I haven't looked into it too deeply i have mainly used it for desktop stuff, I think the problem is python tries to get rid of types as much as possible. IE automagically changing from ints to long and arbritary length ints as required. The only real time you deal with "types" directly is when you are joining a number and a string or things of that nature. For most things you just assign a value to a variable and python works out how to deal with it, no worries about range or platform or whatever (its lovley lol).

Hi Bob; Give a look at http://www.rapideuphoria.com. And here, an example of a simple serial comunications program using Pcomm. http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=pcomm regards, Rubens At 20:36 12/8/2007, you wrote: {Quote hidden}>I need to make a few programs that will stand alone and run under >Windoze 2K/XP and can be made into a Linux version with minimal >or NO expense to my client.. > >It has to have the ability to talk to PC Serial ports and VCP (emulated >serial ports, like under USB<>RS232 converters). > >I have been told that Python 2.51 works great like this. Is it true? Anybody >using it? > >--Bob Axtell >

Alan B. Pearce wrote: >> It is Kylix, Borland Delphi in Linux. :) >> > > That is the one. No experience with it, but the concept seems good. > Actually, Delphi has been my choice for years. I have been a Pascal man since Borland Pascal 3 for DOS, about 1985. But Delphi's support is no longer there, and the newer Delphi versions seem to have large amounts of bugs, and the costs to purchase are enormous. Even locating new packages of D6 (Delphi 6, circa 2000) cost over $900 USD. I believe its OK to make a profit, its just too expensive to my clients, who are pushing me with Python. --Bob A

soliton wrote: > On 8/13/07, Alan B. Pearce <RemoveMEA.B.Pearcespam_OUTKILLspamrl.ac.uk> wrote: > >>> I would still stick to C++ and C. Probably Java*when >>> C++ and C is not adequate*.... Anyway just use a >>> language you are comfortable with. >>> >> Depending on programming style, another possibility would be Borlands >> Delphi >> and its Linux companion that I cannot remember the name of, if one wished >> to >> do Pascal style programming. >> >> > > It is Kylix, Borland Delphi in Linux. :) > > > and it is a dead project. It relies on GTK1 which is on its way out and I belive it also has issues with modern kernels/ there is also the free pascal lazarus project but that is far from mature.

On 8/13/07, Gerhard Fiedler <RemoveMElistsTakeThisOuTspamconnectionbrazil.com> wrote: > Bob Axtell wrote: > > > It has to have the ability to talk to PC Serial ports and VCP (emulated > > serial ports, like under USB<>RS232 converters). > > > > I have been told that Python 2.51 works great like this. Is it true? Anybody > > using it? > > IIRC, Wouter's programmer software is in Python and uses the serial port. > Might give you an idea how this can look like. But I have to point out that xwisp2 works better with cross-platform serial API in C (even OS/2). http://www.robh.nl/picsoft.php Regards, Xiaofan

Tony Smith wrote: >> You might need to do a little work for cross platform but >> mainly only things like where files are saved by default IE >> vista wont let programs save config changes in their own >> program directory without running with admin privileges. >> Which can make changing an ini file a hassle. >> > > > That's interesting. Still, not a bad thing as it might encourage people to > 'do it right', and put that stuff in %appdata%. (I'm assuming Vista lets > you play in there.) > > Nah, that won't happen :) > > Tony > > It actually lets the program think its writing there but silently shifts it to somewhere in the users directory. Makes for an incredibly frustrated system admin (IE - ME) when you change a setting and nothing smegging happens.

{Quote hidden}> >> You might need to do a little work for cross platform but > mainly only > >> things like where files are saved by default IE vista wont let > >> programs save config changes in their own program > directory without > >> running with admin privileges. > >> Which can make changing an ini file a hassle. > >> > > > > > > That's interesting. Still, not a bad thing as it might encourage > > people to 'do it right', and put that stuff in %appdata%. (I'm > > assuming Vista lets you play in there.) > > > > Nah, that won't happen :) > > > > Tony > > > > > It actually lets the program think its writing there but > silently shifts it to somewhere in the users directory. > Makes for an incredibly frustrated system admin (IE - ME) > when you change a setting and nothing smegging happens. That's ok, sort of. Looks like it shifts it to the \Applications Data folder for you (as a bonus, it's a hidden folder). Possibly better than the alternative, which is not working. On the gripping hand, 'that's the way we've always done it' works too. I like the idea of splitting the app & its settings (I prefer .ini over the registry), it makes backups much simpler. I have noticed the %appdata% folder becoming a bit more populated of late. Tony Tony

Tony Smith wrote: >>>> You might need to do a little work for cross platform but mainly only >>>> things like where files are saved by default IE vista wont let >>>> programs save config changes in their own program directory without >>>> running with admin privileges. Which can make changing an ini file a >>>> hassle. That's nothing new to Vista; this has been this way since Win2k, IIRC. You had to be in the Administrator or Power User groups to have write access to the program files tree. Maybe new to Vista is that more users do not run as admins. But that's a good thing if anything. {Quote hidden}>>> That's interesting. Still, not a bad thing as it might encourage >>> people to 'do it right', and put that stuff in %appdata%. (I'm >>> assuming Vista lets you play in there.) >>> >> It actually lets the program think its writing there but silently shifts >> it to somewhere in the users directory. Makes for an incredibly >> frustrated system admin (IE - ME) when you change a setting and nothing >> smegging happens. > > That's ok, sort of. > > Looks like it shifts it to the \Applications Data folder for you (as a > bonus, it's a hidden folder). Possibly better than the alternative, > which is not working. On the gripping hand, 'that's the way we've > always done it' works too. > > I like the idea of splitting the app & its settings (I prefer .ini over > the registry), it makes backups much simpler. I have noticed the > %appdata% folder becoming a bit more populated of late. Yes, this is a good thing IMO too. Better yet would be if the location could be more easily configured -- and of course if more application programmers would think about a user who is not running as admin on his machine. Gerhard

Gerhard Fiedler wrote: > Tony Smith wrote: > > >>>>> You might need to do a little work for cross platform but mainly only >>>>> things like where files are saved by default IE vista wont let >>>>> programs save config changes in their own program directory without >>>>> running with admin privileges. Which can make changing an ini file a >>>>> hassle. >>>>> > > That's nothing new to Vista; this has been this way since Win2k, IIRC. You > had to be in the Administrator or Power User groups to have write access to > the program files tree. > I've always been in power users, otherwise you had to login as admin every 20 seconds to do anything. Some things don't like "run as". {Quote hidden}> Maybe new to Vista is that more users do not run as admins. But that's a > good thing if anything. > > >>>> That's interesting. Still, not a bad thing as it might encourage >>>> people to 'do it right', and put that stuff in %appdata%. (I'm >>>> assuming Vista lets you play in there.) >>>> >>>> >>> It actually lets the program think its writing there but silently shifts >>> it to somewhere in the users directory. Makes for an incredibly >>> frustrated system admin (IE - ME) when you change a setting and nothing >>> smegging happens. >>> >> That's ok, sort of. >> >> Looks like it shifts it to the \Applications Data folder for you (as a >> bonus, it's a hidden folder). Possibly better than the alternative, >> which is not working. On the gripping hand, 'that's the way we've >> always done it' works too. >> >> I like the idea of splitting the app & its settings (I prefer .ini over >> the registry), it makes backups much simpler. I have noticed the >> %appdata% folder becoming a bit more populated of late. >> > > Yes, this is a good thing IMO too. Better yet would be if the location > could be more easily configured -- and of course if more application > programmers would think about a user who is not running as admin on his > machine. > > Gerhard > > I'd prefer it if it wasn't silent. Silently moving things is just wrong. You should get asked how you want to handle the situation. The offending program was eagle it took me about 2 hours to work out why when i changed a library then copied it to the network drive I couldn't see the change.

Jake Anderson wrote: >>>>>> You might need to do a little work for cross platform but mainly >>>>>> only things like where files are saved by default IE vista wont let >>>>>> programs save config changes in their own program directory without >>>>>> running with admin privileges. Which can make changing an ini file >>>>>> a hassle. >> >> That's nothing new to Vista; this has been this way since Win2k, IIRC. >> You had to be in the Administrator or Power User groups to have write >> access to the program files tree. >> > I've always been in power users, otherwise you had to login as admin > every 20 seconds to do anything. Some things don't like "run as". Right. The problem are really the programmers who don't understand the concept of separation between programs and data, and the different respective permissions involved, and who never ever read much documentation about the system for which they are programming. This is nothing new; AFAIK it's more than 10 years old, and some still don't know it. {Quote hidden}>>> Looks like it shifts it to the \Applications Data folder for you (as a >>> bonus, it's a hidden folder). Possibly better than the alternative, >>> which is not working. On the gripping hand, 'that's the way we've >>> always done it' works too. >>> >>> I like the idea of splitting the app & its settings (I prefer .ini >>> over the registry), it makes backups much simpler. I have noticed the >>> %appdata% folder becoming a bit more populated of late. >> >> Yes, this is a good thing IMO too. Better yet would be if the location >> could be more easily configured -- and of course if more application >> programmers would think about a user who is not running as admin on his >> machine. > > I'd prefer it if it wasn't silent. Silently moving things is just wrong. > You should get asked how you want to handle the situation. The offending > program was eagle it took me about 2 hours to work out why when i > changed a library then copied it to the network drive I couldn't see the > change. Yes, I understand this frustration. OTOH, are you sure that it wasn't CadSoft who changed the location where they store the settings when running under Vista? How can you tell that it is Vista and not the program? Gerhard

> Right. The problem are really the programmers who don't understand the > concept of separation between programs and data, and the different > respective permissions involved, and who never ever read much documentation > about the system for which they are programming. This is nothing new; AFAIK > it's more than 10 years old, and some still don't know it. > > The problem is some software is more than 10 years old. And/or the original writers aren't around any more. Its not like a car, people don't come along ripping up the road then saying your car isn't compatible with the new road any more. That bugs me and in large part there's no alternative. That bugs me more. (That's why I'm using python to write the replacement software for the particular "car" that my clients have problems with, once they move to linux my support times will drop) {Quote hidden}> >>>> Looks like it shifts it to the \Applications Data folder for you (as a >>>> bonus, it's a hidden folder). Possibly better than the alternative, >>>> which is not working. On the gripping hand, 'that's the way we've >>>> always done it' works too. >>>> >>>> I like the idea of splitting the app & its settings (I prefer .ini >>>> over the registry), it makes backups much simpler. I have noticed the >>>> %appdata% folder becoming a bit more populated of late. >>>> >>> Yes, this is a good thing IMO too. Better yet would be if the location >>> could be more easily configured -- and of course if more application >>> programmers would think about a user who is not running as admin on his >>> machine. >>> >> >> I'd prefer it if it wasn't silent. Silently moving things is just wrong. >> You should get asked how you want to handle the situation. The offending >> program was eagle it took me about 2 hours to work out why when i >> changed a library then copied it to the network drive I couldn't see the >> change. >> > > Yes, I understand this frustration. OTOH, are you sure that it wasn't > CadSoft who changed the location where they store the settings when running > under Vista? How can you tell that it is Vista and not the program? > > Gerhard > > Because the origional libraries (as installed) were still in c:\program files The altered libraries were buried somewhere in the app data folder (in the place microsoft said to look for where it silently moves things). Its not insurmountable but it is still frustrating.

> Because the origional libraries (as installed) were still in c:\program > files > The altered libraries were buried somewhere in the app data folder (in > the place microsoft said to look for where it silently moves things). > Its not insurmountable but it is still frustrating. > MS was stuck between a rock and a hard place on this one. Users running as admin all the time was a lot of what earnt them thier bad security reputation but the only way to make things usable as non admin was to put in hacks to deal with the old software that didn't do things properly.

Jake Anderson wrote: >> Right. The problem are really the programmers who don't understand the >> concept of separation between programs and data, and the different >> respective permissions involved, and who never ever read much documentation >> about the system for which they are programming. This is nothing new; AFAIK >> it's more than 10 years old, and some still don't know it. >> > The problem is some software is more than 10 years old. And/or the > original writers aren't around any more. Now, come on... Last time I checked, CadSoft was still around, publishing updates and making money with their product. Ten plus years should have been enough to implement a separation between program and data. That's not rocket science (or embedded programming :) If OTOH you're talking about some other software that was written for Win9x or even Win3.x or MS-DOS, and it still runs on Vista, you should be glad... > Its not like a car, people don't come along ripping up the road then > saying your car isn't compatible with the new road any more. Not exactly that, but something along a better analogy. The first car I bought in the US was an old Pontiac station wagon, and I bought it in Ohio. At the time it was made, it was perfectly legal both in CA and in OH. At the time I bought it, it was still legal in OH, but when I moved to CA, I had to sell it. CA had in the meantime changed the emissions regulations. And I couldn't get an upgrade from GM (like you may get from CadSoft :) > That bugs me and in large part there's no alternative. Alternative 1 may be not to run Vista. I think so far there are few reasons that really make you use Vista. Alternative 2 may be to get CadSoft's latest version (if that fixes things). Alternative 3 may be to let CadSoft know that their paying customers would like software that's written according to the specs of the system it's written for. (Maybe they could document this behavior, if they didn't and don't want to fix it and add it to their Vista FAQ <http://www.cadsoftusa.com/faq.htm#22020701>.) It's not always the system that's at fault when an app does weird things. > (That's why I'm using python to write the replacement software for the > particular "car" that my clients have problems with, once they move to > linux my support times will drop) Possibly, but then maybe partly because people who run Linux wouldn't accept applications that write their data just anywhere. And if the app doesn't have write permissions on Linux for the place where it wants to store data, the system doesn't prompt either and lets the user choose where to put the data... :) Gerhard

> I need to make a few programs that will stand alone and run > under Windoze 2K/XP and can be made into a Linux version with > minimal or NO expense to my client.. > > It has to have the ability to talk to PC Serial ports and > VCP (emulated serial ports, like under USB<>RS232 converters). > > I have been told that Python 2.51 works great like this. Is > it true? Anybody using it? (I saw you also asked me privately, but I'll respond here) XWisp works that way. I wrote it and use it on Windows, but I got reports from all kinds of Linux (including Mac) users that it works OK for them. The drawback is that on Windows you need to install Python and the Win32 extensions, which is a bit tedious for an end-user. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

wouter van ooijen wrote: >> I need to make a few programs that will stand alone and run under >> Windoze 2K/XP and can be made into a Linux version with minimal or NO >> expense to my client.. >> >> It has to have the ability to talk to PC Serial ports and VCP >> (emulated serial ports, like under USB<>RS232 converters). >> >> I have been told that Python 2.51 works great like this. Is it true? >> Anybody using it? > XWisp works that way. I wrote it and use it on Windows, but I got reports > from all kinds of Linux (including Mac) users that it works OK for them. > The drawback is that on Windows you need to install Python and the Win32 > extensions, which is a bit tedious for an end-user. I think there is a way to create a stand-alone Win32 .exe file from Python sources. I've never done it, but it didn't look too complicated when I looked into it. Gerhard

wouter van ooijen wrote: {Quote hidden}>> I need to make a few programs that will stand alone and run >> under Windoze 2K/XP and can be made into a Linux version with >> minimal or NO expense to my client.. >> >> It has to have the ability to talk to PC Serial ports and >> VCP (emulated serial ports, like under USB<>RS232 converters). >> >> I have been told that Python 2.51 works great like this. Is >> it true? Anybody using it? >> > > (I saw you also asked me privately, but I'll respond here) > > XWisp works that way. I wrote it and use it on Windows, but I got > reports from all kinds of Linux (including Mac) users that it works OK > for them. The drawback is that on Windows you need to install Python and > the Win32 extensions, which is a bit tedious for an end-user. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > Thanks, Wouter. Yes, I did send a note before any of the others. But I got the info I needed. I am trying Euphoria right now; if it doesn't do the job, I'll drop back to Python. --Bob A

Hi Bob, If you need help with Euphoria, just write directly to me. Good Luck, Rubens At 12:59 19/8/2007, you wrote: {Quote hidden}>wouter van ooijen wrote: > >> I need to make a few programs that will stand alone and run > >> under Windoze 2K/XP and can be made into a Linux version with > >> minimal or NO expense to my client.. > >> > >> It has to have the ability to talk to PC Serial ports and > >> VCP (emulated serial ports, like under USB<>RS232 converters). > >> > >> I have been told that Python 2.51 works great like this. Is > >> it true? Anybody using it? > >> > > > > (I saw you also asked me privately, but I'll respond here) > > > > XWisp works that way. I wrote it and use it on Windows, but I got > > reports from all kinds of Linux (including Mac) users that it works OK > > for them. The drawback is that on Windows you need to install Python and > > the Win32 extensions, which is a bit tedious for an end-user. > > > > Wouter van Ooijen > > > > -- ------------------------------------------- > > Van Ooijen Technische Informatica: http://www.voti.nl > > consultancy, development, PICmicro products > > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > > > > > >Thanks, Wouter. > >Yes, I did send a note before any of the others. But I got the info I >needed. >I am trying Euphoria right now; if it doesn't do the job, I'll drop back >to Python. > >--Bob A >

> -----Original Message----- > From: RemoveMEpiclist-bouncesKILLspammit.edu On Behalf Of Gerhard Fiedler > Sent: Sunday, August 19, 2007 10:44 AM > <snip> > > I think there is a way to create a stand-alone Win32 .exe file from Python > sources. I've never done it, but it didn't look too complicated when I > looked into it. I've done it and it was not difficult. There is one catch, the resulting exe requires a MS licensed DLL so, to distribute your complete package you must have the redistribution license from the MS tool (VisC++ .NET 2005, IIRC). Paul > > Gerhard

> I think there is a way to create a stand-alone Win32 .exe > file from Python sources. I've never done it, but it didn't > look too complicated when I looked into it. You can create a single .exe, but it needs a 'support' directory with a few Mb of files (including the Python interpreter wrapped in a .dll). Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Bob Axtell wrote: > I need to make a few programs that will stand alone and run under > Windoze 2K/XP and can be made into a Linux version with minimal > or NO expense to my client.. Use Python 2.5, or Python2.4 if you want to support older versions. Pretty much every Linux distro will include at least Python2.4. For Windows, use py2exe. > It has to have the ability to talk to PC Serial ports and VCP (emulated > serial ports, like under USB<>RS232 converters). Add on pyserial, and pywin32 for the Windows versions. Once you use py2exe, it all gets packed up into a small self-contained directory with a .exe to run the program. > I have been told that Python 2.51 works great like this. Is it true? Anybody > using it? I've done it for a bootloader application for a project. I used 2.4, mainly because I didn't feel like upgrading my own system to 2.5. Of course, it runs under 2.5 as well, it's just that I had to code around some features of 2.5 that I didn't get to use use. It worked well. -- Hector Martin (hectorSTOPspamspam_OUTmarcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc

Hi, OK, thanks. Will put it on my to try list (which seems to be growing for every day). /Ruben {Quote hidden}> Ruben Jönsson wrote: > > Hi, > > > > > >> I am trying Euphoria right now; if it doesn't do the job, I'll drop back > >> to Python. > >> > >> --Bob A > >> -- > >> > > > > I have been following this thread and also got interested in Euphoria. Could > > You share your experience when done? > > > > > Hi, Ruben, > > It seems to work well with DOS (or in XP, on the CMD prompt). Data types > are ATOMS and SEQUENCES, > pretty strange, but it seems to work. > > I am trying to switch to Windows GUI, having install problems right now. > > --Bob > -