Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Professional IDE for a cross-platform Perl application

Reply
Thread Tools

Professional IDE for a cross-platform Perl application

 
 
Bob
Guest
Posts: n/a
 
      06-29-2006
Hello,

I have a 15 years old application that I have written in perl without
any IDE. This
application has a PostgreSQL database as server side, a tk-based
client, and
both run on linux only. I feel trapped, because

- the client is not compiled, and thus runs slowly;
- the client must now run also on osx and windows, natively;
- the client's tk-based gui is limited, but I have no clue about
cross-platform alternatives;
- each time I try to port it to windows or osx I get missing components
and misbehaviours.

How do I reshape the client so that I can develop it in one machine and
generate
reliable and installable executables for other platforms?

Regards,
Bob

 
Reply With Quote
 
 
 
 
Dr.Ruud
Guest
Posts: n/a
 
      06-29-2006
Bob schreef:

> I have a 15 years old application that I have written in perl without
> any IDE. This
> application has a PostgreSQL database as server side, a tk-based
> client, and
> both run on linux only. I feel trapped, because
>
> - the client is not compiled, and thus runs slowly;
> - the client must now run also on osx and windows, natively;
> - the client's tk-based gui is limited, but I have no clue about
> cross-platform alternatives;
> - each time I try to port it to windows or osx I get missing
> components and misbehaviours.
>
> How do I reshape the client so that I can develop it in one machine
> and generate
> reliable and installable executables for other platforms?


wxWidgets, I suppose.

--
Affijn, Ruud

"Gewoon is een tijger."


 
Reply With Quote
 
 
 
 
Bob
Guest
Posts: n/a
 
      06-29-2006

> wxWidgets, I suppose.


I tried it last year. It was being ported into osx, which is my main
platform at this time,
so it was in alpha stage. It may solve the GUI side, but I still have
the chief problem of
generating executables for other platforms. I need an IDE that takes
care of the porting,
and generates an installable stand-alone application, possibily in
binary form.

Bob

 
Reply With Quote
 
Ala Qumsieh
Guest
Posts: n/a
 
      06-29-2006
Bob wrote:

> Hello,
>
> I have a 15 years old application that I have written in perl without
> any IDE. This
> application has a PostgreSQL database as server side, a tk-based
> client, and
> both run on linux only. I feel trapped, because


Hmm .. I don't think Perl/Tk is 15 years old, but I digress

> - the client is not compiled, and thus runs slowly;


Compiling won't speed it up. You have to look at where your client is
spending most of its time, and optimize that code.

> - the client must now run also on osx and windows, natively;


Perl is cross-platform for the most part. So unless you hard-code
linux-specific stuff, or you use platform-dependent modules, your code
should run fine on other platforms.

> - the client's tk-based gui is limited, but I have no clue about
> cross-platform alternatives;


Tk runs on most, if not all, platforms that Perl runs on. It certainly runs
well on windows, *nix and OSX. No need for alternatives.

> - each time I try to port it to windows or osx I get missing components
> and misbehaviours.


First thing, I guess, is to install any missing modules. What kind of
misbehaviours are you seeing?

> How do I reshape the client so that I can develop it in one machine and
> generate
> reliable and installable executables for other platforms?


make sure you don't use any platform-specific code, unless you have to. If
you do, then make sure you isolate the code, using something like
(untested):

BEGIN {
if ($^O =~ /win/i) {
require Win32::Specific::Module;
} elsif ($^O eq 'linux') {
require Linux::Specific::Module;
}
}

--Ala

 
Reply With Quote
 
Ch Lamprecht
Guest
Posts: n/a
 
      06-29-2006
Bob wrote:
> Hello,
>
> I have a 15 years old application


> This
> application has a PostgreSQL database as server side, a tk-based
> client,


> I feel trapped, because
> - the client is not compiled, and thus runs slowly;
> - the client must now run also on osx and windows, natively;
> - the client's tk-based gui is limited, but I have no clue about
> cross-platform alternatives;
> - each time I try to port it to windows or osx I get missing components
> and misbehaviours.


I use perl-tk 804 for a Pg client application and haven't encountered these
problems yet. The Tk-GUI is times faster than the Network / Server side.
I would recommend, that you do some profiling on your applications code to see
which parts of your code take most of its time. Otherwise you might be
disappointed after working for days on another GUI.
Porting from/to Linux/Windows works perfectly without changing any Tk-related code.
There is c.l.p.tk for perl-tk questions.

Christoph

--

perl -e "print scalar reverse q/(E-Mail Removed)/"
 
Reply With Quote
 
Bob
Guest
Posts: n/a
 
      06-30-2006
Re: Ala Qumsieh

> Hmm .. I don't think Perl/Tk is 15 years old, but I digress


The first version was written in a DOS-based database. The
unix-based perl/tk version is the latest of ports. The former
was perl/cgi running under a web browser.

>> - the client is not compiled, and thus runs slowly;

>
> Compiling won't speed it up. You have to look at where your client is
> spending most of its time, and optimize that code.


I profiled it, but is a complex client. I am thinking about converting
the main routines into C, and use them as libraries.

> > - the client must now run also on osx and windows, natively;

>
> Perl is cross-platform for the most part. So unless you hard-code
> linux-specific stuff, or you use platform-dependent modules, your code
> should run fine on other platforms.


The application uses linux-specific features, such as the use of the
shell
to trigger other languages and routines. Perl is sweet when
prototyping,
but there comes a time when one must tie all strings together.

> > - the client's tk-based gui is limited, but I have no clue about
> > cross-platform alternatives;

>
> Tk runs on most, if not all, platforms that Perl runs on. It certainly runs
> well on windows, *nix and OSX. No need for alternatives.


I need the client to be compiled.

> > - each time I try to port it to windows or osx I get missing components
> > and misbehaviours.

>
> First thing, I guess, is to install any missing modules. What kind of
> misbehaviours are you seeing?


Missing modules, yes. I cannot install cygwin and the whole world of
linux-like utilties and libraries into a machine that is now my own,
and
I cannot even ask people to install it by themselves, because it takes
time and skill they do not have. It is hard enough to run it in linux,
as
I have to keep it up with things breaking at package updates.

> > How do I reshape the client so that I can develop it in one machine and
> > generate reliable and installable executables for other platforms?

>
> make sure you don't use any platform-specific code, unless you have to. If
> you do, then make sure you isolate the code, using something like
> (untested):
>
> BEGIN {
> if ($^O =~ /win/i) {
> require Win32::Specific::Module;
> } elsif ($^O eq 'linux') {
> require Linux::Specific::Module;
> }
> }


Yes, thank you, but we are off road.

Bob

 
Reply With Quote
 
Bob
Guest
Posts: n/a
 
      06-30-2006
Re: Ch Lamprecht

> I use perl-tk 804 for a Pg client application and haven't encountered these
> problems yet. The Tk-GUI is times faster than the Network / Server side.


OK

> I would recommend, that you do some profiling on your applications code to see
> which parts of your code take most of its time. Otherwise you might be
> disappointed after working for days on another GUI.


At this time, there is no separation between the actual application and
the gui.
I want to divide them. I also do not want to work by hand on another
GUI.
As stated above, I am searching for an integrated development
environment
that would take care of the GUI and its porting. I do not want to type
code
for the GUI, and debug it, and port it, and and and. I am done with
that mess above.

> Porting from/to Linux/Windows works perfectly without changing any Tk-related code.
> There is c.l.p.tk for perl-tk questions.


Sorry, I am no longer interested in tk.

Bob

 
Reply With Quote
 
John Bokma
Guest
Posts: n/a
 
      06-30-2006
"Bob" <(E-Mail Removed)> wrote:

> At this time, there is no separation between the actual application
> and the gui.
> I want to divide them. I also do not want to work by hand on another
> GUI.
> As stated above, I am searching for an integrated development
> environment
> that would take care of the GUI and its porting. I do not want to type
> code
> for the GUI, and debug it, and port it, and and and. I am done with
> that mess above.


Ah, yeah, the magical IDE. I think it's called outsourcing

>> Porting from/to Linux/Windows works perfectly without changing any
>> Tk-related code. There is c.l.p.tk for perl-tk questions.

>
> Sorry, I am no longer interested in tk.


Nor in programming, so it seems.


I doubt if you will find an "IDE" that takes your Perl/TK application and
magically transforms it into a fast running cross platform product you
just have to plug some C into.

Probably best thing to do is reverse engineer it, and redesign it in a
language that matches todays requirements, and maybe for a few years to
come.

BTW, Perl *does* compile. But if you want it to compile to hide secrets,
you are mistaken. If you want to compile it to bundle it, have a look at
PAR. If you want to "compile" to speed things up: a close look at the code
might improve it.

--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
 
Reply With Quote
 
Tad McClellan
Guest
Posts: n/a
 
      06-30-2006
Bob <(E-Mail Removed)> wrote:


> The first version was written in a DOS-based database. The
> unix-based perl/tk version is the latest of ports. The former
> was perl/cgi running under a web browser.



A Perl CGI program *never* runs under a browser.

CGI programs run on web *servers*.


> The application uses linux-specific features,



Then an IDE will not help in porting it.


--
Tad McClellan SGML consulting
http://www.velocityreviews.com/forums/(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
Bob
Guest
Posts: n/a
 
      06-30-2006
Re: John Bokma

> Ah, yeah, the magical IDE. I think it's called outsourcing


No, it is called IDE.

> >> Porting from/to Linux/Windows works perfectly without changing any
> >> Tk-related code. There is c.l.p.tk for perl-tk questions.

> >
> > Sorry, I am no longer interested in tk.

>
> Nor in programming, so it seems.


Excuse me? No, I am not interested in programming GUI. There are so
many
GUIs around, and keep improving. Should I recode the application each
time I change the interface? I have been doing it for 15 years, I know
what
I am talking about, and I want to step away from it. I want to separate
the actual routines from the GUI, and let an IDE deal with the GUI and
the
port to various platforms.

> I doubt if you will find an "IDE" that takes your Perl/TK application and
> magically transforms it into a fast running cross platform product you
> just have to plug some C into.


I share the doubt. Indeed I have to make the cut by hand, rebuild the
GUI
into the IDE, and then glue the routines to the new GUI.

> Probably best thing to do is reverse engineer it, and redesign it in a
> language that matches todays requirements, and maybe for a few years to
> come.


I start entertaining the belief that I have to rewrite the whole
application again.
Yes, perl compiles, but it failes with my application; it is too
complex. I think
I'll have to write the core SQL-related routines into C, and call them
from
within perl, to ensure that I am not breaking anything. When all these
routines
are converted, I can detach the GUI, make the new one, and attach the
new
routines to it. However, this is wishful thinking, as I have no clue of
how the
IDE would interface with my routines. The nasty bit are the global
variables...

> BTW, Perl *does* compile. But if you want it to compile to hide secrets,
> you are mistaken. If you want to compile it to bundle it, have a look at
> PAR. If you want to "compile" to speed things up: a close look at the code
> might improve it.


PAR? I've never heard of it. I'll look into it.

Thanks,
Bob

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[ANN} Komodo 3.5.1 -- a professional Ruby IDE Curt Hibbs Ruby 39 12-13-2005 08:50 PM
Office Professional 97 vs Office Professional 2000 SR-1 Me/PDX Computer Support 4 04-18-2005 12:32 AM
Python IDE like NetBeans/Delphi IDE fowlertrainer@anonym.hu Python 5 04-06-2005 05:56 AM
enhanced ide vs ide AndyPaul Computer Information 1 01-01-2004 03:30 AM
XP professional vs. WINDOWS 2000 Professional Harold Microsoft Certification 4 12-15-2003 03:04 PM



Advertisments