gmtk @1.1.1 new port submission for the Graphical Models Toolkit

[rprogers@…]

GMTK is an open source toolkit for rapidly prototyping dynamic Bayesian networks.

[ryandesign (Ryan Carsten Schmidt)]

This should use ${frameworks_dir} instead of ${prefix}/Library/Frameworks. Or possibly it should use the wxWidgets 1.0 portgroup.

[rprogers@…]

Patch to use wxWidgets portgroup to find wx-config

[rprogers@…]

Thanks for the feedback. From the docs, it looks like I should send the fixes as patches, but if you prefer I can send the updated Portfile.

[ryandesign (Ryan Carsten Schmidt)]

For new ports not yet committed to the repository, you should provide the complete portfile. For existing ports already committed to the repository, you should provide a unified diff.

Your change does not look sufficient. You're only including the portgroup, but not making use of it. I could not find documentation of this portgroup either in the guide or in comments in the portgroup file, so I'm Cc'ing the developer of that portgroup who can explain how it is used.

[mojca (Mojca Miklavec)]

I'm unable to download the source. Maybe the server is partially down.

But see: ​https://j.ee.washington.edu/trac/gmtk/ticket/369 I believe that we should push the devs to make the changes proposed there (and to make their own copy of wxwin.m4, not to rely on an external one).

You need to add

wxWidgets.use wxWidgets-3.0

to pick which version of wxWidgets you want to use (I assume it's not 2.8). Then you need to add a dependency on the port with

depends_lib[-append] port:${wxWidgets.port}

and finally the configure script needs to find the wxWidgets, with something like:

configure.args[-append] --with-wxdir=${wxWidgets.wxdir}

but that probably won't work out of the box until they close the above mentioned ticket (I'm unable to check).

You could in principle replace

configure.env-append PATH=${prefix}/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin:$env(PATH)

with

configure.env-append PATH=${wxWidgets.wxdir}:$env(PATH)

(and you can do it now if all you want is to make the port work), but in the long run the ./configure script should become more clever about searching for wxWidgets.

[rprogers@…]

GMTK 1.2.0 is releasing today, which fixes ​https://j.ee.washington.edu/trac/gmtk/ticket/369 and incorporates the suggestions in comment:4. The updated Portfile is attached.

[anddam (Andrea D'Amore)]

The port builds fine but in destroot there's just a bunch of executables in bin/ that is going to be installed. I see at least COPYING, NEWS and README files in source dir that should go in share/doc/ (cf. porthier(7) ), are there any further manual, documentation or example files that should go along?

Also if you don't need a strict control over the port add openmaintainer to the maintainer list, that says minor changes can be committed by anyone.

[rprogers@…]

Replying to and.damore@…:

The port builds fine but in destroot there's just a bunch of executables in bin/ that is going to be installed. I see at least COPYING, NEWS and README files in source dir that should go in share/doc/ (cf. porthier(7) ),

I've updated the port file to install COPYING, README, and NEWS.

are there any further manual, documentation or example files that should go along?

Some outdated documentation is available at ​http://melodi.ee.washington.edu/gmtk. We are working on updated documentation, but it will probably be a long time before it's complete. These documents are 700+ books, so it might be somewhat awkward to include them directly in the package. There are several other tutorials and many examples available at the above web site, but these are also far too large (some over 1 GiB) to include in the package.

Also if you don't need a strict control over the port add openmaintainer to the maintainer list, that says minor changes can be committed by anyone.

Done.

[rprogers@…]

I discovered a build failure in GMTK 1.3.2 on OS X 10.8 with the Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) compiler. Newer Clang compilers and recent GCCs should work fine. I've fixed both the code that triggered the failure and updated the Autoconf test so it will realize that old versions of Clang are missing the required bits of C++11, but I probably can't do a 1.3.3 release until Monday 6/15. We should also have a 1.4 release in the next week or so including some new functionality.

[rprogers@…]

GMTK portfile updated for GMTK 1.4.1 release

[rprogers@…]

GMTK (#46252) needs the C++ bindings for HDF5, which are currently available as a variant. It appears not to be possible to depend on a variant (#126). So can there be an HDF5 C++ subport (see #48472)? If not, what's the proper way to test if the C++ bindings are installed and if not report the problem in the GMTK port file?

[rprogers@…]

The 1.4.2 release now includes man pages.

[mojca (Mojca Miklavec)]

The command

port -v -t configure gmtk

fails to find wxWidgets. I would like to understand the reason for this.

I would suggest adding pkgconfig to the list of build dependencies. The configure scripts also mention BLAS. What's with BLAS? Is it needed?

[mojca (Mojca Miklavec)]

It's really weird. I injected some debug prints into tksrc/configure:

checking for wxWidgets version >= 2.9.0...

THIS GETS EXECUTED: '/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin/wx-config --inplace  --version'
AND THIS IS THE REPLY: 

          Warning: No config found to match: /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin/wx-config --inplace --version
                   in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/config
          If you require this configuration, please install the desired
          library build.  If this is part of an automated configuration
          test and no other errors occur, you may safely ignore it.
          You may use wx-config --list to see all configs available in
          the default prefix.

It looks as if files provided by the wxWidgets port would not be accessible during configuration. Or maybe some other trivial tools like awk misbehave when they come from stock Apple. I need help.

(All these experiments were done on 10.7.)

[mojca (Mojca Miklavec)]

There's one more tiny "problem". If I compile the program with trace mode, it attempts to build against X11 (but I didn't manage to compile it as it didn't find wxWidgets anyway). If I switch the trace mode off, the program somehow opportunistically links against X11 libraries and also launches X11 when starting gmtkViz. I don't understand why the program would want to start X11.

[mojca (Mojca Miklavec)]

How does one test the program?

[rprogers@…]

Replying to mojca@…:

The command

port -v -t configure gmtk

fails to find wxWidgets. I would like to understand the reason for this.

I'm not able to reproduce this on OS X 10.10 or 10.9 - it seems to work fine there. The only other Mac we have is running OS X 10.5, but it's in use at the moment. I'll test it there when the machine is free.

I would suggest adding pkgconfig to the list of build dependencies. The configure scripts also mention BLAS. What's with BLAS? Is it needed?

pkgconfig is only used to check for BLAS, and BLAS is not needed. It uses the ​PHiPAC dgemm (by the same author as GMTK) included in the GMTK source unless the user requests a specific BLAS or MKL via configure.

[neverpanic (Clemens Lang)]

Looking into the trace mode behavior now and will let you know my findings.

[neverpanic (Clemens Lang)]

Works for me:

:info:configure checking for wx-config... /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin/wx-config
:info:configure checking for wxWidgets version >= 2.9.0... yes (version 3.0.2)
:info:configure checking for wxWidgets static library... no
:info:configure checking whether wxWidgets works without -D_WCHAR_H_CPLUSPLUS_98_CONFORMANCE_... no
:info:configure checking whether wxWidgets works with -D_WCHAR_H_CPLUSPLUS_98_CONFORMANCE_... yes

However, the port fails to build without a dependency on xorg-libX11:

:info:build gmtkViz.cc:75:9: fatal error: 'X11/Xlib.h' file not found
:info:build #include<X11/Xlib.h>
:info:build         ^

Please add port:xorg-libX11 to depends_lib. Other than that, this looks good to go for me. Mojca, do you commit this?

[rprogers@…]

Simple test files for GMTK

[mojca (Mojca Miklavec)]

Weird. So why does it fail for me then?

Rather than adding xord-libX11 to the list of dependencies it would make sense to figure out how to get rid of it. But yes, I see that there are some hardcoded X11 commands. Those should be removed by upstream developers ASAP. Maybe our temporary workaround could be included the dependencies, but really just as a temporary measure.

If you have tested it already, I would be grateful if you could commit it. I feel a bit uncomfortable with all these weird issues on my machine.

[rprogers@…]

Replying to mojca@…:

How does one test the program?

For a very simple test, you can download the ​GMTK-test.tar attachment and do

gmtkTriagulate -strF test.str 
gmtkViterbi -strF test.str -inputM test.mtr -of1 test.flat -ni1 1 -fmt1 flatascii -vitVals -

The correct output from the last command should look like

Creating Junction Tree
DONE creating Junction Tree
Segment 0, after CE, viterbi log(prob(evidence)) = -1.386294, per frame =-0.693147, per numUFrams = -0.693147
========
Segment 0, number of frames = 2, viterbi-score = -1.386294
Printing random variables from (P,C,E)=(1,1,0) sections
Ptn-0 P: q(0)=hello
Ptn-1 C: q(1)=world
Total data log prob for all segments is: -1.386294361e+00
### Final time (seconds) just for decoding stage: User: 0.000000, System: 0.000000, CPU 0.000000
____ PROGRAM ENDED SUCCESSFULLY WITH STATUS 0 AT Thursday October 29 2015, 14:32:55 PDT ____

For more extensive testing we have a bunch of models and tutorials available at ​http://melodi.ee.washington.edu/gmtk/. Many of these are quite large, so we don't distribute them by default.

[rprogers@…]

Replying to mojca@…:

Rather than adding xord-libX11 to the list of dependencies it would make sense to figure out how to get rid of it. But yes, I see that there are some hardcoded X11 commands. Those should be removed by upstream developers ASAP. Maybe our temporary workaround could be included the dependencies, but really just as a temporary measure.

I will work on removing the X11 calls for the next release (​580) - probably in a month or 2.

If you have tested it already, I would be grateful if you could commit it. I feel a bit uncomfortable with all these weird issues on my machine.

It would be great to report to my boss that this has finally been committed :)

[rprogers@…]

GMTK 1.4.3 portfile with no X11 dependency

[rprogers@…]

It turned out that the X11 calls were trivial to remove, so I went ahead and did a 1.4.3 release that no longer uses X on OS X. The updated portfile is attached.

[mojca (Mojca Miklavec)]

Did you further modify the tarball on the server? Because I get different checksums than you.

[mojca (Mojca Miklavec)]

In tksrc/Makefile.(in|am) you still have -lX11.

[mojca (Mojca Miklavec)]

I now committed the port in r141868. But we should fix that remaining X11 issue in the future (and I need to figure out why trace mode doesn't work on my machine). We should also figure out what is going on with the checksums.

[rprogers@…]

Fix checksums and remove -lX11 from Mackefile

[rprogers@…]

I've fixed the -lX11. I'm still calling it the 1.4.3 release since it hasn't been announced publicly yet.

I think the checksum issue was just a glitch on my part copying the tarball to our server. The current version with the above diff should be good to go.

I haven't been able to get access yet to a machine running anything older than OS X 10.9, but trace mode works for me on 10.9 ad 10.10.