[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fis-gtm



Title: Re: fis-gtm


On 07/22/2011 04:44 PM, Parenteau, Laurent wrote:

Thorsten,

On 07/22/11 13:56, Thorsten Alteholz wrote:
> Hi Laurent,
>
> On Thu, 21 Jul 2011, Laurent Parenteau wrote:
>> I think it would be better if the packages would have the version number
>> in the name, and maybe have fis-gtm depend on the latest release.  This
>> way, one could install multiple different versions of GT.M if needed.
>
> you could already do that now. If you don't purge the package, your
> old installation will remain in a directory containing the version
> string, like /usr/lib/fis-gtm/54002A. I saw a remark in some
> documentation that the old version should be always kept. The only
> problem would be that you can not install an older version after that
> was replaced by a new one on the repository server.
> Or do you really prefer something like postgresql? What about
> bugfixes? If there is a version 1.2.003 in the repository, do you
> provide bugfixes for such an old version?
Yes, we would like it if it would be possible to install older versions
from the repository.
As for bugfixes, we don't have "patch" releases, as you often see in
other software.  We only have full releases.  When there's an important
issue that requires a fix fast, we simply spin a new release (which will
have a letter suffix, like V5.4-002B) that will, among other things,
include the fix.  So once V5.4-003 will be out, there should never be a
V5.4-002C.

[KSB] That's not always the case.  Once we release a V5.4-002C, there will never be another release called V5.4-002C - once released, a GT.M release is frozen for all time - or at least till we start running out of numbers...  8-)

But although it is highly unlikely that there will be a release called V5.4-002C after a release called V5.4-003, it is technically possible and has happened once or twice in the last ten years.

One wrinkle is that it is possible for users to have 32- and 64-bit versions of GT.M to exist on the same system.  So, the recommended practice is to put _x86 or _x86_64 in the directory name under /usr/lib/fis-gtm.  Here is a listing from my laptop:

kbhaskar@bhaskarks:~$ ls -l /usr/lib/fis-gtm/
total 172
drwxr-xr-x 2 bin  bin  4096 2011-01-20 09:41 V5.1-001_x86
dr-xr-x--- 4 bin  gtc  4096 2010-02-11 16:25 V5.3-003_x86
dr-xr-x--- 4 root gtc  4096 2011-02-06 10:14 V5.3-004A_x86
dr-xr-x--- 5 bin  gtc  4096 2010-06-02 10:34 V5.4-000A_x86
dr-xr-xr-x 5 root bin  4096 2011-02-20 13:56 V5.4-000A_x86_64
dr-xr-x--- 5 root gtc  4096 2011-02-04 17:45 V5.4-001_x86
dr-xr-xr-x 5 root bin  4096 2011-03-05 13:07 V5.4-001_x86_64
dr-xr-xr-x 4 bin  bin  4096 2011-05-25 10:49 V5.4-002A_x86
dr-xr-xr-x 5 bin  bin  4096 2011-06-20 11:34 V5.4-002A_x86_64
dr-xr-xr-x 4 root root 4096 2011-07-21 15:26 V5.4-002B_x86_64
dr-xr-xr-x 5 root root 4096 2011-03-09 15:25 V5.4-002_x86_64
kbhaskar@bhaskarks:~$


(Notice that in some cases, I have restricted execution to a group - that is for testing purposes; the default installation would make it world accessible.)

So, I would suggest package names such as fis-gtm-5.4-002b.  A meta-package called fis-gtm could depend on some version of GT.M.  It would also be good to have a way select the preferred GT.M version (defaulting to the latest) through /etc/alternatives.

>
>> I don't think this had been tried.  Since someone else (Alan O'Neill)
>> was able to use Python script instead of the MUMPS code in the build
>
> Is this script available for everybody?
I'll let Alan answer, as he is the one who made them (there is more than
one script).  That said, using those scripts would require a modified
makefile (which Alan worked on as well, but did not yet succeeded with
that task), as the one that comes with the source code is use the MUMPS
code.

[KSB] If we can get GT.M into the repositories using the existing MUMPS bootstrap, that will probably be less work than completing the Python scripts.  The existing bootstrap works well and has been used for many years - that's what the upstream developers use to build GT.M.  All you need is a version of GT.M, any prior version.  You don't need the current version of GT.M to build GT.M.

The reason that Alan started on the Python scripts was that we thought, based on prior (historical) inquiries that even though a bootstrap was allowed for a package like gcc, a bootstrap would not be allowed for GT.M.  Now it seems that a bootstrap would be permissible to get GT.M into the repositories.  So, I suspect using the bootstrap would be the path of least resistance.

>
>> process, I don't see why it wouldn't be possible to do the same thing
>> with another MUMPS compiler.
>
> Do you have an idea how I can do any test to verify whether the newly
> build stuff works?
You should be able to simply source the gtmprofile script (which would
be in the root directory of the installed package) and then run 'gtm'.

[KSB] For a simple sanity check, you can also run the program at http://www.cs.duke.edu/csed/code/code2007/solutions/other/4/wordfreq.m which solves the problem described at http://www.cs.duke.edu/csed/code/code2007/ (get the poe.txt and poe.out files from there).  Assuming your compiled GT.M executables are in $HOME/mygtm/pro and your working directory is $HOME/tmp:

export gtm_dist=$HOME/mygtm/pro
export gtmroutines="$HOME/tmp $gtm_dist"
cd $HOME/tmp
cd $HOME/tmp
$gtm_dist/mumps -run wordfreq <poe.txt >poe.tmp
diff poe.tmp poe.out
ls -l wordfreq.o

There should be no output from the diff and the wordfreq.o should have a newer timestamp than wordfreq.m.  You can also run GT.M interactively to output Hello, world:

kbhaskar@bhaskarks:~/tmp$ $gtm_dist/mumps -direct

GTM>write "Hello, world"
Hello, world
GTM>halt
kbhaskar@bhaskarks:~/tmp$


Regards
-- Bhaskar


Laurent
>
>> I think the best documentation about that is the makefile itself, and
>> the M files used by the makefile.
>
> This seems to be a real challenge.
>
>   Thorsten


-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________

Reply to: