Re: [SWIPL] [John R. Towler] swipl, pl-6.3.5, xpce problem since Jan 2012 fixed, libXt, freetype.h preceding Xft.h, XtSetLanguageProc(), setlocale(3)

[jtowler%soncom.com@localhost (John R. Towler)]

bash-4.2$ Xorg -version

X.Org X Server 1.10.3
Release Date: 2011-07-08
X Protocol Version 11, Revision 0
Build Operating System: NetBSD/i386  -
Current Operating System: NetBSD peano.jtcl.org 6.0_STABLE NetBSD 6.0_STABLE 
(Peano6) #0: Tue Dec 11 22:24:48 CST 2012  
jtowler%peano.jtcl.org@localhost:/usr/obj/sys/arch/i386/compile/Peano6 i386
Build Date: 01 August 2011  01:01:00AM

Current version of pixman: 0.23.2
    Before reporting problems, check http://wiki.X.Org
    to make sure that you have the latest version.



Hello:
Since last Jan. 2012 (already!):
SWI-Prolog, (http://www.swi-prolog.org/) here version pl-6.3.5 but since
I upgraded to NetBSD-6.0_BETA and some with 5.1.2, and pl-6.0.2-4 has
had a problem with XtSetLanguageProc() and setlocale on my systems.  I
don't know about programming in X11/Xt and I spent time trying to find
out.

It appears from the code, that the problem is in the order of the calls
to XtSetLanguageProc(), before or instead wrapped inside of if
!(somefunc)) C code calls after XtDisplayInitialize()

from man XtSetLanguageProc()

A client wishing to use this mechanism to establish locale can do so by
       calling XtSetLanguageProc prior to XtDisplayInitialize.

The O'Reilly Xt Intrinisics examples with these calls works in the man
page fashion.  I don't know why or how the other working way Jan
Wielemaker got the XtSetLanguageProc(), XtDisplayInitialize() code to
work otherwise in 2004/5 which only recently failed for me on upgrading
NetBSD to 5.1.2 a bit, and specifically 6.0 with the cvs -r netbsd-6
pull.

Nonetheless, the following change to LC_ALL=en_US.UTF-8 made the code
base work w/o error.  Before I was getting core dumps due to
XtSetLanguageProc() and the like failing to have LANG and LC_ALL != "C",
dropping through automatic setting to "C" locale, then dumping core
rather than just working with the "C" locale.

Is this a NetBSD-6 or something  problem with libXt (which has
incremented in versions according to the cvs browser tree, X11R7.x which
we and not X.org (or Linux systems out there) are using, or with
setlocale(3), which I saw is being worked on in -current.

I only want to help the system be better.  i18n has moved forward on my
list, and this with locale settings and setlocale etc. is involved.

The swi-prolog author (Jan Wielemaker) writes in response to this post
that this change which did matter, should not.  (and builds on Linux
systems w/o incident which I knew from asking) I don't know the Xt/X11
programming answer about the code base, but if it is NetBSD and X11R7,
maybe someone needs to know and can adjust or adapt the problem I found
over the last 11 mos.   Thanks in advance, sorry to bother people.


John R. Towler
jtowler%soncom.com@localhost



swi-prolog Mailing list post via the bugs address reporting my success:

jtowler%soncom.com@localhost (John R. Towler) writes:

> I was looking at the Alpino code because of a post contemplated in drafts
> about the nature of a grammar posted in prolog, and Jan Wielemaker (et
> al) Porting Prolog papers; 
>
> subject thread: 5th n something rule 
> with move_mod/2 as move-\alpha.
>
> the Alpino INSTALL.swi file has a note about needing to set the locale to UTF8
> to build Alpino for swi-prolog.
>
>
> from the git pull, local subtree Alpino as project root
>
> Alpino/INSTALL.swi
>
> ---------
> 1. You need the very latest version of SWI-Prolog, at least a 
> version of april 2010 or later.
>
> 2. you must use an UTF8 locale setting.
>
> 3. you need to set the ALPINO_HOME environment variable to the
> directory that contains the Alpino stuff
>
> 4. you have to create a file Makefile.defs which should contain
> a few Makefile variable definitions. An example is available in
> the file Makefile.defs.swi
>
> 5. you might need to install a number of other packages
>
> TODO: this list is incomplete
>
> * tcl/tk libraries
> * s_fsa utilities from Jan Daciuk
> * libxml2, libxslt for some of the additional tools
> * boost libraries
>
> for s_fsa you need non-default value for the variable CPPFLAGS
> in the Makefile!
> ...
>
> ---- 
>
> So after reading a bit, I thought why not give this a shot.  It just
> might be the case that for whatever reasons of libXt and
> XtSetLanguageProc(), and setlocale(3), setting my now us-ascii/iso8859-1
> shell environments to some_something.UTF-8 in /usr/share/locale, and
> LANG="non-null lang code", might accidently work, as is the presumably
> default setup for a platform development build in the Netherlands.
>
> man locale, man setlocale, man 7 nls
>
> Tried it for pl-6.3.5 and with CPPFLAGS, LDFLAGS, LC_ALL=en_US.UTF-8,
> LANG="en".  
>
> Fixed xpce/src/x11/include.h to add 
> #include <freetype2/freetype/freetype.h> in
> #include <*/Xft.h> sequence in that file, 
> which Jan Wielemaker had decided was unnecessary and then removed from
> the xcpe source tree,
>
> and I only know that by my experience with building (also tried as changed)
> on my NetBSD-5,6 systems and the advice of the tech-11%NetBSD.org@localhost 
> list
> on my compilation errors,
> #include <*/freetype.h> needs to precede #include <*/Xft.h> for Xft.  So
> for me this is necessary, in spite of Jan Wielemaker's experience with
> xpce development etc. and X11 programming in doing so.
>
> xpce builds and installs. 
>
> bash-4.2$ swipl
>
> ?- emacs.
> ?- apropos("file_directory").
> ?- gxref.
> ?- ensure_loaded('xpce/demo/pce_demo').
> ?- pcedemo.
>
> all run, start X display windows, and do their stuff.
>
>
> gmake check in packages for those built, and in src with clib built and
> installed runs successfully.
>
> The swipl cmd line has some error stuff about parsing strings or
> something ---looks like a string was parsed into an all to familiar list
> of char codes, and odds are I gave it the wrong input type of argument
> without a recent look at the manual, and it worked anyway, the X based
> swipl programs run.
>
> Add jpl in to configure.in (commented out for now), see build notes on
> kaffe confgure problems.
>
> NetBSD pkgsrc has openjdk7 with remote code execution security
> vulnerabilities, so I won't run this now which is their recommendation
> for such listings.  
>
> There was a post to the list about a similar
> position in the configure file, with the same Gnu autoconf archive java
> test m4 files, for gcj something, and the m4 test failing to find gcj or
> somesuch on the same Test(.java) file written out by the
> ac_*java_works.m4 file.
>
>
>
> Then Cliopatria, and or SWAPP, and or thea.  Push go on Alpino and also
> study the grammar as implemented in the code.
>
> Post the LC_ALL=*UTF-8 and Alpine/INSTALL.swi notes to Mail.swi-prolog
> and get to working with it.
>
should read To: > Jan Wielemaker:
>
> Can this LC_ALL setting as necessary for NetBSD, and a note about the
> freetype.h change as I have found to be necessary be added as you see
> fit to the project toplevel README/INSTALL or a system specific
> {README,INSTALL}.netbsd file.  Then it should just build with the
> installation changes for a local NetBSD system for whatever architecture
> hardware (We have about 57 last I checked in the NetBSD-6.0 Installtion notes
> for the srcs or binaries.)
>
> More work to do on NetBSD's (set)locale stuff, but for now my current
> locale works for whatever LANG_LANG.UTF-8 files are there presumably.
>
>
>
> Next problem.
>
> John R. Towler
> jtowler%soncom.com@localhost
> _______________________________________________
> SWI-Prolog mailing list
> SWI-Prolog%lists.iai.uni-bonn.de@localhost
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog



Jan Wielemaker did write a reply to swi-prolog mailing list which
included this about #include <*/freetype.h> preceding #include
<*Xft.h>.  You know, and I only want to help NetBSD have a good
cross-Unix portable X11 version for getting my non-system software tools
etc. built and built easily.  Someone knows the right thing, and between
you and X.org, this can be worked out.

Jan Wielemaker:
> The latest change I can see to these files was after comments from you
> for NetBSD 6.0.  It seems that modern X11/Xft installations no longer
> need this.  It presumably has caused problems.  I'm happy to re-add
...