So, if you only *use* the library·and don't change the QT *source* itself, then you can keep your IP... (unless, of course, the use is so complicated that you want to keep that as IP ?)
Or am I misunderstanding this?
RE wxWidgets --- you got me curious about them again... looks like they've come along way since I used them last. PERL support too [noparse]:)[/noparse])
@ariba: Finally got a copy of OSX 10.4.5 running, and loaded a copy of the latest PureBASIC, but when I try to compile I get "[noparse][[/noparse]COMPILER] Line 26: Warning: Deprecated function 'CreateGadgetList()' used." and "Assembler error!".
Probably something I'm doing wrong, but thought you might like to know.
@Simon, Does the Java program I provided run on your OS X ?
@Howard, That's how I interpret it mostly.
The fine line seems to be:
If you use only the library form of Qt (.so .dll), you keep your IP sources if you choose.
If you compile the libraries (.o .a) with your application, you must distribute your IP.
The wxWidgets "Exception" (wxWindows for legal purposes) specifically allows you to compile
the libraries with your application without requiring you go release your IP sources.
Usually, you can charge a fee for any application that uses GPL or LGPL as long as you follow the rules.
I guess PyQt has some exception.
BTW: In the Microsoft C# or C++ EULA, there is a line that seems to restrict .net to Microsoft O/S,
platforms, or technologies. It is part of the "I Agree" install terms. I wonder what it means exactly.
Can't find an online copy. Does it mean, you can't distribute your program for use on Linux?
> In the Microsoft C# or C++ EULA, there is a line that seems to restrict .net to Microsoft O/S,
> ... I wonder what it means exactly... Does it mean, you can't distribute your program for use on Linux?
It really means "you can do what ever you want - until you make enough money to be interesting enough to us, or to compete enough against us; and we can simply sue you if we don't like your hairstyle."
LOL --- well, I suppose as long as you don't try to rewrite .Net stuff directly, then you wouldn't be the target - the folks who've attempt .Net on other OS'es might end up having a bad hair day.
BTW, are you still interested in the PyQt approach?
Only if you have copious spare time.... I would like to see how some PyQt GUI would look and function and how easy it would be for users. I was going to use the built-in Tkinter stuff to do it since I wouldn't have to download some other "this that and the other thing" component. I've run simple Tkinter "frame" scripts, but seems to be a lot like building Java GUI without the Netbeans IDE GUI maker ... tedious, very tedious.
Assuming you install using defaults, the example will end up here:
C:\Program Files\Python31\Lib\site-packages\PyQt4\examples\designer\calculatorform
I've not studied what minimum libs you'd need for distro since the licensing issue may trump.
The sample code is attached.
I'm assuming you've overcome the machine failure ... Have you made any progress with wxWidgets?· It would be nice to learn what you've found out.
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (CounterRotatingProps) : 9/23/2009 9:30:52 PM GMT
jazzed said...
@Simon, Does the Java program I provided run on your OS X ?
@Howard, That's how I interpret it mostly.
The fine line seems to be:
If you use only the library form of Qt (.so .dll), you keep your IP sources if you choose.
If you compile the libraries (.o .a) with your application, you must distribute your IP.
If you statically link your code with any LGPL library that does not have a static link exception you can comply by supplying your .o files and instructions on how to re-link them with a different version of the library at the users discretion. This complies with the letter of the license. You don't need to distribute your source.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
@Howard, I was able to get the GUI running after installing Python31 and PyQt on my laptop (about 34MB total).
My desktop is still down, but I was able to get my files. I'm running from my laptop now ....
I have dropped hints now about a Quadcore PC She fired back with hints about a new couch
I'll start pulling some things together with wxWidgets and C++ for Windows and Ubuntu/Gnome starting tomorrow.
I don't have a Mac, so I won't be making that. I'll share my source with anyone who wants to do the Mac version.
The "perl2exe" stuff is required only for bundling into an omnibus .exe that includes the entire Perl interpreter. For this program, that .exe was 1.9MB and too big to post, even after zipping. Here's what the output looks like in Windows:
I use the free ActivePerl from www.activestate.com for development on Windows. Perl is almost always included with Linux and OS/X. I'll add screenshots from those later.
__________________
Later...
Here's the same , unmodified program running under X11 on OS/X (ver. 10.3/PowerPC):
(Perl runs natively under OS/X; but the Tk package does not, having only been ported to X-windows under X11.)
As to Linux, my Ubuntu Feisty Fawn doesn't have Tk installed. To install it from CPAN requires some X-windows dev files that have also not been installed, and the apt-get repository for Feisty seems to be offline already. So that test won't get done until I can update my Linux box to a more recent version. (What are we up to now, Moronic Moose?)
__________________
Later still...
I remembered I had an ancient version of Mandrake Linux (9.1) running on an equally ancient Thinkpad laptop. So I fired it up and tried the program. It choked because Tk::Spinbox wasn't included with the Tk version that was installed. So back to CPAN for a complete new Tk installation. Tried it — again with no modification. It worked:
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 9/29/2009 6:31:17 AM GMT
Amazing that you don't like C [noparse]:)[/noparse] I recognize those Tk thingy's. Have you tried wxPerl by chance?
Can you put the executable package on a server so that we can test the program?
User experience comparison will be difficult using Perl and CPAN. Have you tried PAR?
Phil Pilgrim (PhiPi) said...
Here's my entry (Perl):
As to Linux, my Ubuntu Feisty Fawn doesn't have Tk installed. To install it from CPAN requires some X-windows dev files that have also not been installed, and the apt-get repository for Feisty seems to be offline already. So that test won't get done until I can update my Linux box to a more recent version. (What are we up to now, Moronic Moose?)
I tend to stick to the LTS releases on my development systems so I only have to upgrade every 2 years or so. That way it's also supported long term and you don't get issues of repositories going off line quite so quickly. I stuck with 6.06 until 8.04 was a couple of months old and starting to mature. It solves some of the issues you get with early adopters [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Phil I can run your example on my PC after installing ActivePerl and getting TK using PPM. Did not try it on my linux box yet.
I tried using perl2exe, but ran into an unresolvable dependency with "unicore" ... ???
Also tried to get PP and PAR running, but I can't build PP or find a windoze binary.
I'm just a little too disheartened to keep trying I guess as sharing here has recently become less rewarding.
It may be that the newest version of perl2exe has resolved some issues with Unicode and that all but the first include in my program are no longer necessary. Try it without them and see. If you get weird characters like I do, the includes are still needed. I have no idea what they do exactly; they're just some boilerplate I found on the web to solve a problem.
There are some issues installing Perl stuff that rquires compiling from C code (like PAR) on Windows when you're using ActivePerl. It has to do with make, nmake, or somesuch, being incompatible with the version used by Activestate. My memory on this is pretty haziy. I just remember throwing in the towel and sticking with ppm and perl2exe. Perl2exe is a commercial product, and it's always worked well for me. One could use Perl under Cygwin, I suppose, but that's no better than .NET, IMO — possibly worse.
Even though Perl is a "mere scripting language", I've found it to be fast, scalable, and robust enough for large projects. The Scribbler robot GUI, for example, is written entirely in Perl/Tk and compiled with perl2exe.
I deleted the "unicore" includes and was able to build and run the app with perl2exe and perl-5.10.0 on Windows. Do you use the "pro" version of perl2exe?
I was also able to get the script running on ubuntu hardy heron by installing perl-tk (not via cpan) via: sudo apt-get install perl-tk ... I had to remove "use strict" for it to work (the unicore stuff was not in the file).
Considering the amount of work required for all this, I see no real advantage in using Perl over Java or other development methods given here. Still, I will attempt to do something useful with it. I have never considered using a serial port with perl. Do you have any tasty links that might help me on such a journey?
I guess it's whatever you're used to. I chose Perl mainly for the language's expressiveness and depth of support via the modules in CPAN. I use the pro version of perl2exe, since it allows the -GUI option, which eliminates the annoying DOS box in Windows-only apps.
Hmm, Perl must've gotten stricter in the latest version! What kind of error was solved by removing the use strict? It's always a good idea to include this pragma, since it forces adherence to good programming practices and eliminates a lot of bugs in the process.
For serial I/O on Windows, I use the Win32::SerialPort module. Yeah, I know: that's where portability ends, unfortunately. Here's the typical startup code I use to initialize it for the Propeller. This gets copied from one program to another:
my $result = `"$Init{compiler}" /ID`;
if ($result =~ m/EVT:505[noparse][[/noparse]^\n\r]+(COM\d+)/i) {
my $portname = "\\\\.\\" . $1;
if ($Port = new Win32::SerialPort($portname)
and $Port->baudrate(9600)
and $Port->parity('none')
and $Port->databits(8)
and $Port->stopbits(2)
and $Port->handshake('none')
and $Port->buffers(4096,4096)
and $Port->binary(1)
and $Port->datatype('raw')
and $Port->dtr_active('N')
and $Port->write_settings)
{
The hash value $Init{compiler} is preloaded with the path and filename of propellent.exe. Invoking it (via the backstroke) with the /ID argument yields a usable com port name if a Prop is connected. (You have to prepend the \\.\ for ports above COM9 to be accessible.) Then it's off to the races.
For Linux serial I/O, you can use Device::SerialPort, which emulates the Win32::SerialPort functions (but not the port names).
-Phil
Addendum: I nearly forgot. There's an issue with not closing the serial port gracefully before exiting your program. You can read about it here: www.perlmonks.org/?node_id=442706. (To add some context: "Dr. Mu" is me. "Anonymous" Bill is Bill Birthisel, the author of Win32::SerialPort.) PerlMonks is a great forum for Perl issues, BTW.
Post Edited (Phil Pilgrim (PhiPi)) : 9/29/2009 7:08:54 PM GMT
Phil Pilgrim (PhiPi) said...
What kind of error was solved by removing the use strict?
With "use strict", the compiler complained about the line $sum = ... in the add_em_up event method and the my (@x, $sum);
Don't remember the details exactly and I'm away from the ubuntu box.
What is the highest safe baud rate to use with the serial port? I noticed the eeprom program used 19.2K.
I've been searching for a one size fits all solution ... that is one source code base that
works on all platforms rather than multiple code base variations for each platform.
The following table summarizes the results so far:
VM/Platform .net Java Perl Python Wine
GUI Operation:
Windows OK OK OK OK OK
Linux OK OK OK OK OK
Mac OS/X ? ? ? ? ?
Mac OS/X-X11 ? ? OK* ? ?
Serial Port:
Windows OK OK OK OK OK
CygWin ? ? ? ? Win32 OK
Linux Fails Fails OK* ? OK
Mac OS ? ? ? ? ?
*According to Phil
.net assumes linux running mono
Java assumes JVM and RXTX installed
Python on Windows tested as source interpreted
Perl GUI on Linux tested as source interpreted
Perl on Windows also packaged executable
Wine on Linux running Win32 API programs
Mac OS ? I don't have a Mac and need input.
So far, the GUI VM technologies work fine, but serial ports results (high performance or
otherwise) are very disappointing with .net and Java.
The only serial port bright point so far for me at least is running a Win32 program on Wine.
The Win32 version of spud worked perfectly on Wine. Of course Wine is a 60MB download,
so that is unreasonable for non-broadband users.
Frustration? Yea ... there is no magic solution [noparse]:)[/noparse]
To create a viable widely deployable application product will require more work or capital
than I'm willing to put forth at this time, so unless there is a great return on effort
opportunity, I won't bother. Supporting 3 different source code bases/platforms in possibly
as many languages is completely unreasonable, writing Win32 only programs is restrictive
and Wine is probably no better for most users than java, etc... anyway, and I don't have a
Mac or any plan to buy one.
Conclusions?
I'll distribute whatever program I develop that suits my needs, in the language I like, on the
platform of my choice, on the schedule I can keep, and forget the rest. Less stress [noparse]:)[/noparse]
Thanks Jazzed for putting this together...
Looking at the business side of cross-platform development is very sobering:
For limited markets where the number of Windows customers is in the low thousands, Linux/Mac customers will be in the low hundreds. If you profit $20/item * 100 additional customers, that's $2k. Probably won't pay the bills. Thankfully, emulation and virtual machines are getting better all the time, so hopefully soon people's choice of platform won't limit them from using software built for other platforms.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!
@Phil,
Thanks for Perl input. Interpreted was a bad term; what I meant was, I had source code that ran with the interpreter and not an executable.
@Hanno,
It's pretty clear that return on sweat equity could be higher if the audience was bigger (possible?). Until the extra effort is justified, .net is just fine.
The problem I have with writing tools for people who use Unix/Linux is that the users are often resourceful enough to not really need the tools [noparse]:)[/noparse]
jazzed said...
...what I meant was, I had source code that ran with the interpreter and not an executable.
Well, truth be known, even the so-called .exe file is interpreted! The interpreter is just bundled in with the .exe, which is what makes perl2exe files so freaking big.
Comments
RE: PyQt license... reviewing some of the docs, I came across this:
http://qt.nokia.com/products/licensing/licensing
License Comparison Chart
[noparse][[/noparse]My underlining]
So, if you only *use* the library·and don't change the QT *source* itself, then you can keep your IP... (unless, of course, the use is so complicated that you want to keep that as IP ?)
Or am I misunderstanding this?
RE wxWidgets --- you got me curious about them again... looks like they've come along way since I used them last. PERL support too [noparse]:)[/noparse])
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Probably something I'm doing wrong, but thought you might like to know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
@Howard, That's how I interpret it mostly.
The fine line seems to be:
If you use only the library form of Qt (.so .dll), you keep your IP sources if you choose.
If you compile the libraries (.o .a) with your application, you must distribute your IP.
The wxWidgets "Exception" (wxWindows for legal purposes) specifically allows you to compile
the libraries with your application without requiring you go release your IP sources.
Usually, you can charge a fee for any application that uses GPL or LGPL as long as you follow the rules.
I guess PyQt has some exception.
BTW: In the Microsoft C# or C++ EULA, there is a line that seems to restrict .net to Microsoft O/S,
platforms, or technologies. It is part of the "I Agree" install terms. I wonder what it means exactly.
Can't find an online copy. Does it mean, you can't distribute your program for use on Linux?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
> ... I wonder what it means exactly... Does it mean, you can't distribute your program for use on Linux?
It really means "you can do what ever you want - until you make enough money to be interesting enough to us, or to compete enough against us; and we can simply sue you if we don't like your hairstyle."
LOL --- well, I suppose as long as you don't try to rewrite .Net stuff directly, then you wouldn't be the target - the folks who've attempt .Net on other OS'es might end up having a bad hair day.
BTW, are you still interested in the PyQt approach?
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Just as I stumbled across a (Py)Qt·example that does exactly what you asked for, I came across this too:
" PyQt, unlike Qt, is not available under the LGPL " - ouch.
OK, for the sake of completeness...
For the recent version of PyQt, you'll need Python 3.1 @:
http://www.python.org/download/releases/3.1/
Latest is:
http://www.python.org/download/releases/3.1.1/
It might also work on Python 3.0, but I didn't test it.
(I've not yet come across an Win based machine that also included Python out of the box - too bad actually).
So obviously, you'd have to require it.
For Dev, get PyQt4 from the bottom of the page @:
http://www.riverbankcomputing.com/software/pyqt/download
Assuming you install using defaults, the example will end up here:
C:\Program Files\Python31\Lib\site-packages\PyQt4\examples\designer\calculatorform
I've not studied what minimum libs you'd need for distro since the licensing issue may trump.
The sample code is attached.
I'm assuming you've overcome the machine failure ... Have you made any progress with wxWidgets?· It would be nice to learn what you've found out.
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (CounterRotatingProps) : 9/23/2009 9:30:52 PM GMT
Fortunately Nokia is working on that little problem: www.pyside.org/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here's another link that we all might want to look at:
http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
Even includes "why you shouldn't use Wx" --- fair and balanced GUIism? :-P
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Hey, since this is sort of cross language as well as cross platform [noparse]:)[/noparse] I was looking today too at WxWidgets for PERL ...
I prefer "Strawberry Perl" over ActivePerl because it works better for me with CPAN...
[noparse][[/noparse]EDIT - ahhh the old DLL version mismatch ... let's see if I can make this work...]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (CounterRotatingProps) : 9/24/2009 12:05:27 AM GMT
If you statically link your code with any LGPL library that does not have a static link exception you can comply by supplying your .o files and instructions on how to re-link them with a different version of the library at the users discretion. This complies with the letter of the license. You don't need to distribute your source.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
@Howard, I was able to get the GUI running after installing Python31 and PyQt on my laptop (about 34MB total).
My desktop is still down, but I was able to get my files. I'm running from my laptop now ....
I have dropped hints now about a Quadcore PC
I'll start pulling some things together with wxWidgets and C++ for Windows and Ubuntu/Gnome starting tomorrow.
I don't have a Mac, so I won't be making that. I'll share my source with anyone who wants to do the Mac version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
use strict; use Tk; #perl2exe_include Tk::Spinbox; #perl2exe_include "utf8_heavy.pl"; #perl2exe_include "unicore/lib/SpacePer.pl"; #perl2exe_include "unicore/To/Lower.pl"; #perl2exe_include "unicore/To/Upper.pl"; #perl2exe_include "unicore/To/Fold.pl"; #perl2exe_include "unicore/lib/Digit.pl"; #perl2exe_include "unicore/lib/Word.pl"; #perl2exe_include "Encode/Unicode.pm"; my $mw = Tk::MainWindow->new(-title => 'TestFest Entry'); my (@x, $sum); foreach (0, 1) { $mw->Spinbox( -from => 0, -to => 100, -width => 3, -textvariable => \$x[noparse][[/noparse]$_], -command => \&Add_em_up )->pack(-side => 'left', -padx => 4); $mw->Label(-text => ('+', '=')[noparse][[/noparse]$_])->pack(-side => 'left', -padx => 4, -pady => 20); } $mw->Label( -background => 'WHITE', -relief => 'sunken', -border => 2, -textvariable => \$sum, -width => 3, )->pack(-side => 'left', -padx => 4); Add_em_up(); MainLoop(); sub Add_em_up { $sum = sprintf('%3.1d', $x[noparse][[/noparse]0] + $x) }The "perl2exe" stuff is required only for bundling into an omnibus .exe that includes the entire Perl interpreter. For this program, that .exe was 1.9MB and too big to post, even after zipping. Here's what the output looks like in Windows:
I use the free ActivePerl from www.activestate.com for development on Windows. Perl is almost always included with Linux and OS/X. I'll add screenshots from those later.
__________________
Later...
Here's the same , unmodified program running under X11 on OS/X (ver. 10.3/PowerPC):
(Perl runs natively under OS/X; but the Tk package does not, having only been ported to X-windows under X11.)
As to Linux, my Ubuntu Feisty Fawn doesn't have Tk installed. To install it from CPAN requires some X-windows dev files that have also not been installed, and the apt-get repository for Feisty seems to be offline already. So that test won't get done until I can update my Linux box to a more recent version. (What are we up to now, Moronic Moose?)
__________________
Later still...
I remembered I had an ancient version of Mandrake Linux (9.1) running on an equally ancient Thinkpad laptop. So I fired it up and tried the program. It choked because Tk::Spinbox wasn't included with the Tk version that was installed. So back to CPAN for a complete new Tk installation. Tried it — again with no modification. It worked:
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 9/29/2009 6:31:17 AM GMT
Can you put the executable package on a server so that we can test the program?
User experience comparison will be difficult using Perl and CPAN. Have you tried PAR?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
-Phil
Update: The .exe (testfest.zip) is now available here: www.phipi.com/propeller
Post Edited (Phil Pilgrim (PhiPi)) : 9/28/2009 5:47:15 AM GMT
-P.
I tend to stick to the LTS releases on my development systems so I only have to upgrade every 2 years or so. That way it's also supported long term and you don't get issues of repositories going off line quite so quickly. I stuck with 6.06 until 8.04 was a couple of months old and starting to mature. It solves some of the issues you get with early adopters [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
-Phil
I tried using perl2exe, but ran into an unresolvable dependency with "unicore" ... ???
Also tried to get PP and PAR running, but I can't build PP or find a windoze binary.
I'm just a little too disheartened to keep trying I guess as sharing here has recently become less rewarding.
It may be that the newest version of perl2exe has resolved some issues with Unicode and that all but the first include in my program are no longer necessary. Try it without them and see. If you get weird characters like I do, the includes are still needed. I have no idea what they do exactly; they're just some boilerplate I found on the web to solve a problem.
There are some issues installing Perl stuff that rquires compiling from C code (like PAR) on Windows when you're using ActivePerl. It has to do with make, nmake, or somesuch, being incompatible with the version used by Activestate. My memory on this is pretty haziy. I just remember throwing in the towel and sticking with ppm and perl2exe. Perl2exe is a commercial product, and it's always worked well for me. One could use Perl under Cygwin, I suppose, but that's no better than .NET, IMO — possibly worse.
Even though Perl is a "mere scripting language", I've found it to be fast, scalable, and robust enough for large projects. The Scribbler robot GUI, for example, is written entirely in Perl/Tk and compiled with perl2exe.
-Phil
That's just sad.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I deleted the "unicore" includes and was able to build and run the app with perl2exe and perl-5.10.0 on Windows. Do you use the "pro" version of perl2exe?
I was also able to get the script running on ubuntu hardy heron by installing perl-tk (not via cpan) via: sudo apt-get install perl-tk ... I had to remove "use strict" for it to work (the unicore stuff was not in the file).
Considering the amount of work required for all this, I see no real advantage in using Perl over Java or other development methods given here. Still, I will attempt to do something useful with it. I have never considered using a serial port with perl. Do you have any tasty links that might help me on such a journey?
I guess it's whatever you're used to. I chose Perl mainly for the language's expressiveness and depth of support via the modules in CPAN. I use the pro version of perl2exe, since it allows the -GUI option, which eliminates the annoying DOS box in Windows-only apps.
Hmm, Perl must've gotten stricter in the latest version! What kind of error was solved by removing the use strict? It's always a good idea to include this pragma, since it forces adherence to good programming practices and eliminates a lot of bugs in the process.
For serial I/O on Windows, I use the Win32::SerialPort module. Yeah, I know: that's where portability ends, unfortunately. Here's the typical startup code I use to initialize it for the Propeller. This gets copied from one program to another:
my $result = `"$Init{compiler}" /ID`; if ($result =~ m/EVT:505[noparse][[/noparse]^\n\r]+(COM\d+)/i) { my $portname = "\\\\.\\" . $1; if ($Port = new Win32::SerialPort($portname) and $Port->baudrate(9600) and $Port->parity('none') and $Port->databits(8) and $Port->stopbits(2) and $Port->handshake('none') and $Port->buffers(4096,4096) and $Port->binary(1) and $Port->datatype('raw') and $Port->dtr_active('N') and $Port->write_settings) {The hash value $Init{compiler} is preloaded with the path and filename of propellent.exe. Invoking it (via the backstroke) with the /ID argument yields a usable com port name if a Prop is connected. (You have to prepend the \\.\ for ports above COM9 to be accessible.) Then it's off to the races.
For Linux serial I/O, you can use Device::SerialPort, which emulates the Win32::SerialPort functions (but not the port names).
-Phil
Addendum: I nearly forgot. There's an issue with not closing the serial port gracefully before exiting your program. You can read about it here: www.perlmonks.org/?node_id=442706. (To add some context: "Dr. Mu" is me. "Anonymous" Bill is Bill Birthisel, the author of Win32::SerialPort.) PerlMonks is a great forum for Perl issues, BTW.
Post Edited (Phil Pilgrim (PhiPi)) : 9/29/2009 7:08:54 PM GMT
Don't remember the details exactly and I'm away from the ubuntu box.
What is the highest safe baud rate to use with the serial port? I noticed the eeprom program used 19.2K.
Thanks
Oh cripes! That must mean that each my declaration has to be on its own line now.
I've used 115,200 baud with Perl in Windows. No problem.
-Phil
works on all platforms rather than multiple code base variations for each platform.
The following table summarizes the results so far:
So far, the GUI VM technologies work fine, but serial ports results (high performance or
otherwise) are very disappointing with .net and Java.
The only serial port bright point so far for me at least is running a Win32 program on Wine.
The Win32 version of spud worked perfectly on Wine. Of course Wine is a 60MB download,
so that is unreasonable for non-broadband users.
Frustration? Yea ... there is no magic solution [noparse]:)[/noparse]
To create a viable widely deployable application product will require more work or capital
than I'm willing to put forth at this time, so unless there is a great return on effort
opportunity, I won't bother. Supporting 3 different source code bases/platforms in possibly
as many languages is completely unreasonable, writing Win32 only programs is restrictive
and Wine is probably no better for most users than java, etc... anyway, and I don't have a
Mac or any plan to buy one.
Conclusions?
I'll distribute whatever program I develop that suits my needs, in the language I like, on the
platform of my choice, on the schedule I can keep, and forget the rest. Less stress [noparse]:)[/noparse]
Post Edited (jazzed) : 10/8/2009 8:58:45 PM GMT
2. Mac OS/X requires two rows: native OS/X and OS/X+X11.
3. Under GUI:OS/X+X11:Perl, you can add an OK (using Perl/Tk).
4. Windows could also use two rows: native Windows and Windows+Cygwin. (Cygwin is a UNIX-like shell for Windows.)
5. Also "interpreted operation" in Perl is actually quite fast, since it's precompiled into bytecodes.
-Phil
Looking at the business side of cross-platform development is very sobering:
For limited markets where the number of Windows customers is in the low thousands, Linux/Mac customers will be in the low hundreds. If you profit $20/item * 100 additional customers, that's $2k. Probably won't pay the bills. Thankfully, emulation and virtual machines are getting better all the time, so hopefully soon people's choice of platform won't limit them from using software built for other platforms.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!
Thanks for Perl input. Interpreted was a bad term; what I meant was, I had source code that ran with the interpreter and not an executable.
@Hanno,
It's pretty clear that return on sweat equity could be higher if the audience was bigger (possible?). Until the extra effort is justified, .net is just fine.
The problem I have with writing tools for people who use Unix/Linux is that the users are often resourceful enough to not really need the tools [noparse]:)[/noparse]
-Phil