Professional IDE for a cross-platform Perl application

Discussion in 'Perl Misc' started by Bob, Jun 29, 2006.

  1. Bob

    Bob Guest

    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
    Bob, Jun 29, 2006
    #1
    1. Advertising

  2. Bob

    Dr.Ruud Guest

    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."
    Dr.Ruud, Jun 29, 2006
    #2
    1. Advertising

  3. Bob

    Bob Guest


    > 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
    Bob, Jun 29, 2006
    #3
  4. Bob

    Ala Qumsieh Guest

    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
    Ala Qumsieh, Jun 29, 2006
    #4
  5. Bob

    Ch Lamprecht Guest

    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//"
    Ch Lamprecht, Jun 29, 2006
    #5
  6. Bob

    Bob Guest

    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
    Bob, Jun 30, 2006
    #6
  7. Bob

    Bob Guest

    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
    Bob, Jun 30, 2006
    #7
  8. Bob

    John Bokma Guest

    "Bob" <> 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 :-D

    >> 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/
    John Bokma, Jun 30, 2006
    #8
  9. Bob <> 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
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Jun 30, 2006
    #9
  10. Bob

    Bob Guest

    Re: John Bokma

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


    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
    Bob, Jun 30, 2006
    #10
  11. Bob

    Bob Guest

    Re: 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*.


    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.

    > > The application uses linux-specific features,

    >
    > 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
    Bob, Jun 30, 2006
    #11
  12. Bob

    Bob Guest

    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
    Bob, Jun 30, 2006
    #12
  13. Bob

    Ala Qumsieh Guest

    Bob wrote:

    > 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
    Ala Qumsieh, Jun 30, 2006
    #13
  14. Bob

    John Bokma Guest

    "Bob" <> wrote:

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

    --
    John Bokma Freelance software developer
    &
    Experienced Perl programmer: http://castleamber.com/
    John Bokma, Jun 30, 2006
    #14
  15. Bob

    John Bokma Guest

    "Bob" <> wrote:

    > 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 :)

    --
    John Bokma Freelance software developer
    &
    Experienced Perl programmer: http://castleamber.com/
    John Bokma, Jun 30, 2006
    #15
  16. Bob

    Bob Guest

    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
    Bob, Jul 1, 2006
    #16
  17. "Bob" <> wrote in
    news::

    > Re: John Bokma
    >
    >>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.


    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
    A. Sinan Unur, Jul 1, 2006
    #17
  18. Bob

    Bob Guest

    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
    Bob, Jul 1, 2006
    #18
  19. "Bob" <> wrote in news:1151768476.544626.221660
    @m73g2000cwd.googlegroups.com:

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



    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
    A. Sinan Unur, Jul 1, 2006
    #19
  20. Bob

    John Bokma Guest

    "Bob" <> wrote:

    > 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 :)

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

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

    --
    John Bokma Freelance software developer
    &
    Experienced Perl programmer: http://castleamber.com/
    John Bokma, Jul 1, 2006
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Heikki Toivonen

    Cross-platform application restart?

    Heikki Toivonen, Sep 6, 2006, in forum: Python
    Replies:
    1
    Views:
    274
    faulkner
    Sep 7, 2006
  2. Blasting Cap

    cross-platform application & encryption

    Blasting Cap, Oct 4, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    323
    Blasting Cap
    Oct 4, 2006
  3. james_027

    gui application on cross platform

    james_027, May 28, 2007, in forum: Python
    Replies:
    7
    Views:
    312
    Stefano Canepa
    May 29, 2007
  4. Hendrik van Rooyen
    Replies:
    0
    Views:
    238
    Hendrik van Rooyen
    Aug 22, 2007
  5. Brock Weaver
    Replies:
    48
    Views:
    448
    tony summerfelt
    Aug 29, 2005
Loading...

Share This Page