Thorsten --
Thank you for your message and apologies for this delayed reply.
Depending on where I am, I use three different clients to view e-mail one
of which does not give me the opportunity to mark e-mails as Unread to be
read again later on a friendlier client. After seeing your message
there, I overlooked it later with the volume of e-mail in my Inbox. Mea
culpa.
More comments below - look for [KSB3].
Regards
-- Bhaskar
On 08/02/2011 01:55 PM, Thorsten Alteholz wrote:
>
> Hi Bhaskar,
>
> On Mon, 25 Jul 2011, Bhaskar, K.S wrote:
>
[KSB3] <...snip...>
>
>
> > Even though they are compiled from the same source code, the 32-
> > and 64-bit binaries of GT.M are different and packaged & installed
> > separately.
>
> Yes, but in case I want to create the 32-bit version on a 64-bit CPU, I
> need
> to call make twice and do a 'setenv OBJECT_MODE 32' in between, right?
>
[KSB3] That is correct.
>
>
> > Why do you say that you don't expect anyone to run GT.M on arm?
>
> While working with ARM processors there have been always resource problems
> sooner or later. But you are right, I didn't thought about those things
> you mentioned. So we need a bootstrap for arm :-).
>
[KSB3] I agree wholeheartedly!
>
>
> > [KSB2] Someone installing a new version would choose the latest release.
> > But we have users who distribute applications on top of GT.M. They may
> > have a periodic repackage / release cycle, and if they are running
> > stably, there is less work for them to do to continue using an existing
> > GT.M version until their next cycle.
>
> Ok, but we are talking about the distribution via Debian/Ubuntu or
> whatever derivate. So if someone has another application that depends on
> one release, then of course due to this dependency this release won't be
> deleted. If someone uses Debian as a basis and adds his own stuff before
> distributing it, he should either announce this fact and the needed
> release won't be deleted. Or he does his own thing and uses "his" release
> in any way.
> So I don't see any problem that unused releases might be deleted in a new
> Debian release. In this case deleting doesn't mean that the packages
> disappears. All of the next 23 releases will remain in the archive and can
> be used!
>
[KSB3] OK
>
>
> > If GT.M is unfriendly to other UTF-8 locales, I definitelyt want to know
> > so that we can fix it. If GT.M requires en_US.utf8 that may be
> > unfriendly, and we'll consider what we can do about it.
>
> There are severeal lines like:
> utflocale=`locale -a | grep -i en_us ...`
> in configure and later there is a test:
> if [ $utflocale = "" ]; then
> or:
> if [ "$found_icu" -ne 0 -a "$utflocale" != "" ] ; then
> doutf8=1
> else
> doutf8=0
> fi
> May I say that this is an unfriendly behaviour?
>
[KSB] We will look into this. To support UTF-8 mode, GT.M requires a
.utf8 locale, any utf8 locale, except on z/OS where it requires
en_US.utf8 because of certain platform dependencies. The configure
script is old and this part of it has probably not been looked at for a
long time. Perhaps the Debian package will not even need it.
But, if you look at the (newer) gtmprofile script that a user would
source to set up a GT.M environment, notice that it uses the first
available utf8 locale. For example, on my laptop, even though I am in
the US:
kbhaskar@bhaskarks:~$ gtm_chset=UTF-8 /usr/lib/fis-gtm/V5.4-002B_x86/gtm
GTM>write $ztrnlnm("LC_CTYPE")
en_AG.utf8
GTM>halt
kbhaskar@bhaskarks:~$
I have to explicitly set en_US.utf8 to get it:
kbhaskar@bhaskarks:~$ LC_CTYPE=en_US.utf8 gtm_chset=UTF-8
/usr/lib/fis-gtm/V5.4-002B_x86/gtm
GTM>write $ztrnlnm("LC_CTYPE")
en_US.utf8
GTM>halt
kbhaskar@bhaskarks:~$
History is what history is - we try to do better today than we did
yesterday. and we'll try to do better tomorrow than we do today.
>
>
> There is another issue. After updating my sid machine it wasn't possible
> to build the package from sources. It says something about missing
> include file. Other packages replaced the -I- with -iquote which does not
> work in your case. After adding the attached patch, everything was fine
> again.
>
[KSB3] This was on our list of things to do. I know that the changes are
small, but since GT.M is built from a highly common code base across a
wide variety of platforms and released under a variety of licenses, both
free / open source (e.g., GT.M for Linux on x86) and proprietary (e.g,.
GT.M for proprietary UNIX flavors), would you please make a statement
that you make no claim of copyright to the patch? Thank you very much.
--
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.
_____________
