pRPN Files

      pRPN, a portable RPN calculator inspired by HP.
      ===============================================

$LastChangedDate: 2010-08-15 16:49:20 +0200 (dim. 15 août 2010) $

Contents:

      I. WHAT IS PRPN?
     II. WHY PRPN?
    III. LICENCE
     IV. COMPILATION AND INSTALLATION



I.    WHAT IS PRPN?

It is an RPN calculator based on WxWidgets for the GUI, that provides the
following objects: Reals, Complex, Vectors, Matrices, Binaries, Lists,
Expressions, Strings and Programs.
Expressions are minimalistic right now, they are not usable as such. On the
other hand, programs are almost fully implemented.
pRPN also provides a terminal interface if launched with -c option (see the
note in section IV about Windows version.)



II.   WHY PRPN?

I like to use my genuine HP-28S, and I didn't find any program close to the
power it brings with a similar simple interface. I managed to program it. Big
deal! About half the work is done as of August 2010, the big remaining piece to
program is expressions management.



III.  LICENCE

See COPYING file that comes along with the package the program belongs to.



IV.   COMPILATION AND INSTALLATION

The file of name INSTALL, distributed with pRPN source files, gives
instructions to compile and install the program, using the usual
    ./configure, make and sudo make install sequence.
This INSTALL file is the one provided by default by autotools.
Below is found information specific to this package.

- Linux compilation

    The configure script provides the following options in addition to the
    defaults.
    --disable-gui
        Compile without WxWidgets GUI => build a console-only executable
    --enable-debug
        Activate pRPN debug information (has nothing to do with WxWidgets debug
        system)
    --disable-nls
        Deactivate internationalization,
    --enable-maintainer-mode
        This option causes documentation to be rebuilt if necessary

    Note
        Bakefile files (.bkl extension) are used for Windows. Under Linux, the
        standard automake/autoconf couple is used, without any bakefile piece.
        Bakefile provides a half-a-way solution to get mixed with autotools
        (bakefilize, that replaces automake but keep using autoconf), that
        isn't in use here.
        Using bakefile generated makefiles under Linux is presumed to work
        fine but has not been tested for a while.

- Windows compilation

    1) Borland C++
        At first prpn program used to be compiled using Borland C++ 5.5. It
        worked well until the program becomes bigger and caused a known bug in
        Borland to block compilation. The bug is in the linker and occurs when
        the target is too big. A workaround to this is to compile WxWidgets
        library without debug. To be more precise:
            By default, to compile WxWidgets in Windows using Borland C++ 5.5,
            you execute the command:
                cd %WXWIN%\build\msw
                %BORLAND_BIN%\make -f makefile.bcc
            To build the library without debug support, you have to execute:
                cd %WXWIN%\build
                %BORLAND_BIN%\make -f makefile.bcc BUILD=release WX_DEBUG=0
            If you forget the <<BUILD=release>> sequence above, WxWidgets
            compilation will be successful BUT linkage of prpn will produce a
            cryptic error.

        * IMPORTANT *
            Borland C++ doesn't work with libintl nor libiconv. Therefore it
            can't be used any longer to compile the definitive (and packaged)
            binary.

        Borland C++ 5.5 can be downloaded for free, from
            http://edn.embarcadero.com/article/20633

    2) Mingw
        Mingw32 has also been used successfully, however, the resulting
        executable size is very big. Compilation of pRPN 0.5.0 (released early
        June) was 30MB wide, whereas BCC55 compilation produced a 3MB wide
        executable. Removing DEBUG code improves the situation.
        Remind: to compile pRPN with Mingw, you've got to compile WxWidgets
        with it as well, executing:
            cd %WXWIN%\build\msw
            %MINGW32_BIN%\mingw32-make -f makefile.gcc

        Mingw is used to compile the packaged, final, binary (included in
        Windows installer.) It uses the options BUILD=release WX_DEBUG=0 to
        optimize the code.

        Mingw32 is licensed under GPL mostly, its homepage is found here
            http://www.mingw.org

    3) Microsoft Visual C++ 2010 Express
        Compiles well. To first compile WxWidgets with msvc, you've got to
        open a msvc custom shell window (similar to cmd.exe window but tuned
        to match msvc command-line tools requirements), and execute
            cd %WXWIN%\build\msw
            %MINGW32_BIN%\nmake -f makefile.vc

        * IMPORTANT *
        msvc has been seen NOT run successfully while enabling debugging.

        Microsoft Visual C++ 2010 Express can be downloaded for free, from
            http://msdn.microsoft.com/fr-fr/express/aa975050.aspx

    4) Makefiles generation
        As Windows doesn't provide the usual configure/make/make install
        mechanism (provided you are not using an environment like cygwin), the
        solution used is WxWidgets default, bakefile. You can find it from
            http://www.bakefile.org

    5) Note about the console version
        Under Linux, a single executable is produced, that enables both GUI
        version (default) and the console version when launched with the -c
        option in the command line.
        Under Windows, things are different. By default, WxWidgets disconnects
        itself from the controlling terminal, making it impossible to interact
        with the console. Note this point is unclear to me, maybe it is more
        of a Windows default behavior than WxWidgets... Any way.
        To workaround this characteristic, Windows build produces two
        executables, prpn.exe (GUI) and prpnc.exe (console.)

        Last minute update
            It has been seen that even while providing the -c option under
            Linux, prpn still initializes Gtk stuff and fails to start if Gtk
            initialization fails. In particular, executing the following
                DISPLAY="" prpn -c
            won't work.
            Therefore a future version of prpn will likely add a prpnc
            executable, even under Linux, compiled with no link at all to the
            WxWidgets library. Or, if I can manage to hack WxWidgets in order
            not to initialize Gtk, it'll be even cleaner.

- Known builds done so far

    Ubuntu 9.10 / gcc 4.3.3, 32 bits, WxWidgets 2.8.10

    Ubuntu 10.4 beta / gcc 4.4.3, 64 bits, WxWidgets 2.8.10

    Windows XP SP3 / mingw32-gcc 3.4.5 (mingw-vista special r3), 32 bits,
    WxWidgets 2.8.10
        WxWidgets and prpn compiled with BUILD=release WX_DEBUG=0
        Used to package the binary included in Windows installer

    Windows XP SP3 / bcc55 5.5.1 (Borland C++), 32 bits, WxWidgets 2.8.10
        WxWidgets and prpn compiled with BUILD=release WX_DEBUG=0
        * Borland doesn't work with NLS (gettext, setlocale(), ...) *

    Windows XP SP3 / Microsoft Visual C++ 2010 Express (16.00.303019.01 for
    80x86)
        WxWidgets and prpn compiled with BUILD=release WX_DEBUG=0