Professional IDE for a cross-platform Perl application

B

Bob

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
 
D

Dr.Ruud

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.
 
B

Bob

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
 
A

Ala Qumsieh

Bob said:
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
 
C

Ch Lamprecht

Bob said:
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
 
B

Bob

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.
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.
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.
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.
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.
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
 
B

Bob

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
 
J

John Bokma

Bob said:
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 :-D
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.
 
T

Tad McClellan

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.
 
B

Bob

Re: John Bokma
Ah, yeah, the magical IDE. I think it's called outsourcing :-D

No, it is called IDE.
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
 
B

Bob

Re: Tad McClellan
A Perl CGI program *never* runs under a browser.

CGI programs run on web *servers*.

I can assure you that my perl/cgi application was running on a web
browser.
Bloody slowly, and with serious limitations, but it was running. I
managed
to gain in speed and functionality with Tk. I hope I will gain further
speed
and functionality with a better GUI.
Then an IDE will not help in porting it.

An IDE will not do the porting for me, that's for sure. But it will
help me
in spotting all the OS dependent parts, so that I can change them.

Bob
 
B

Bob

For you to understand what I mean, have a look at the following:

http://www.activestate.com/Perl.plex?hdr=1

What I am in search for, is your wisdom about similar products.
I would like to have pointers to other similar products, together
with your comments on whether they cut the mustard, so to speak.

Bob
 
A

Ala Qumsieh

Bob said:
I start entertaining the belief that I have to rewrite the whole
application again.

I was about to suggest that. A 15-year old application is just too old to
port around to different platforms given the leaps and bounds that happened
in computing since then. You have a major new requirement now: portability.
With that in mind, start from a clean slate.

--Ala
 
J

John Bokma

Bob said:
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.

That's odd.
I think
I'll have to write the core SQL-related routines into C,

Why on earth? If you don't handle the data that comes out of SQL queries
efficiently, it might be that you want to move more of the handling into
SQL itself (stored procedures). I have seen too often people doing the
weirdest things in language X which should have been done in SQL.
routines to it. However, this is wishful thinking, as I have no clue
of how the
IDE would interface with my routines.

That's where the programming bit jumps in :)
The nasty bit are the global
variables...

Like I said: write a new functional specification, and drop this piece of
junk, since that is how it sounds.
PAR? I've never heard of it. I'll look into it.

It packs all modules + script + interpreter into one file. I use it now
and then on Windows, I get one exe (quite large, even a small script is 2+
MB) without the need of installing Perl.
 
J

John Bokma

Bob said:
For you to understand what I mean, have a look at the following:

http://www.activestate.com/Perl.plex?hdr=1

What I am in search for, is your wisdom about similar products.
I would like to have pointers to other similar products, together
with your comments on whether they cut the mustard, so to speak.

An IDE is just a fancy knife. You have to provide the mustard, and do the
cutting :)
 
B

Bob

Re: John Bokma

Yes, a fresh functional specification is the way to go. The application
has been growing
with reasonably good structured programming, but has also bent to the
need of the GUI.
There are parts of it that fetch data from the SQL engine, presents it
like a spreadsheet,
and one can only change values by first clicking on a line and then
editing on a special
made window; this was built from scratch, it works, but is cumbersome
and not portable.
I want to replace it with something that is closer to the functionality
of a spreadsheet.
Of course, it is not a spreadsheet, but I arranged the data in a way
that looks like one.
Another part where data and gui get together is a window that should
display data
continuously; given the limitations of perl/tk in this task, I had to
find a compromise.

Anyway... PAR sounds good. I wonder how big my .exe would be, if it is
portable,
and if the source code would show up in it.
An IDE is just a fancy knife. You have to provide the mustard, and do the cutting :)

Portability and GUI are the two components of any application that
require a great deal
of patience and also knowledge and skill about platforms that you may
not have in house.
Think about coding in windows for an application that must now run in
solaris! The IDE
is an attempt to automate this work reliably. Just code once, and get
the ports for free.
It is a lot of code, if you think about it, and the separation between
GUI and core
algorithms contributes to good design, at least in my Idiosyncratic
view of things.
The alternative is Java, but I want a swift application... Java is too
hungry for resources.

Bob
 
A

A. Sinan Unur

Re: John Bokma


Portability and GUI are the two components of any application that
require a great deal of patience and also knowledge and skill about
platforms that you may not have in house.
True.

The IDE is an attempt to automate this work reliably. Just code once,
and get the ports for free.

I am not sure how an IDE would provide that. I think you are confused
about what IDE means. I think, you are confusing it with a framework.

Sinan
 
B

Bob

Re: A. Sinan Unur
I am not sure how an IDE would provide that. I think you are confused
about what IDE means. I think, you are confusing it with a framework.

Framework is synonymous for an Integrated Development Environment,
or IDE, which is the term that I see more often. Some people intend the

IDE for an editor that assists you with the different files and their
dependences,
other intend it for a GUI editor, and other intend it for a combination
of the two
with the added benefit of porting and package generation. We are
talking
about professional frameworks, of course.

Bob
 
A

A. Sinan Unur

Re: A. Sinan Unur


Framework is synonymous for an Integrated Development Environment,
or IDE, which is the term that I see more often.


Absolutely not. An IDE is GUI application that provides editing,
debugging, project management and other facilities.

IDE's closely tied with a GUI framework also provide GUI designers to
facilitate using the framework.
We are talking about professional frameworks, of course.

Perl/TK is a very professional framework. GUI applications you write using
Perl/TK are very much write once/run most places if you do not introduce
other (non-GUI) platform dependencies in your code. This is true whether
you used an IDE or a GUI designer or just coded the GUI by hand.

Sinan
 
J

John Bokma

Bob said:
Another part where data and gui get together is a window that should
display data
continuously; given the limitations of perl/tk in this task, I had to
find a compromise.

AFAIK, this is just possible. Another option, if you want to go the Perl
way, might be wxWindows/wxWidgets. I have little experience with Tk, but
do know that wx has support for tables/spreadsheet constructs in a Window.
Anyway... PAR sounds good. I wonder how big my .exe would be, if it is
portable,

AFAIK you have to make a version for each platform, since perl itself is
not portable. (perl, not Perl)
and if the source code would show up in it.

Yes, but if reverse engineering is an issue, you probably shouldn't
release the program :)
Think about coding in windows for an application that must now run in
solaris!

Java, and maybe C# (MONO).
The IDE
is an attempt to automate this work reliably. Just code once, and get
the ports for free.

You're mistaken.
The alternative is Java, but I want a swift application... Java is too
hungry for resources.

Depends a lot on the programmer. It seems that a lot of Java programmers
mistake garbage collection and Swing for a free programmer that comes with
the language.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top