OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
I decided to try to help the cause of Bayesian statistics and the open source effort of the OpenBUGS group (http://www.openbugs.info/w/) by making some packages. In case you are not a statistically-inclined person, it is worth knowing that Bayesian Updating with Gibbs Sampling (BUGS) has caused something of a methodological landslide since the early 1990s, helping scholars to model processes that were thought to be too difficult.
In Linux, we do not have access to the OpenBUGS GUI, which
I've built deb and rpm packages for RedHat, Fedora and Ubuntu. They are available in my webspace and in the project.
I wish these could be in the official linux repositories, but I've not tried to put these into an official repository because there are 2 problems that seem prohibitive.
First, the (now open) code for OpenBugs is written in Object Pascal and it requires a compiler framework called "Black Box" which is, as far as I can understand, available only for MS Windows. The OpenBUGS team compiles that library, and then for linux we use some accessor scripts to send jobs to it.
This, of course, goes against the packaging policy that pre-compiled libraries are prohibited.
I was wondering if there could be an exception here, since the code is actually available and open. This is more reasonable than re-packaging the closed Nvidia drivers, for example.
Second, there is a little packaging problem for 64 bit systems. The library that is provided is only 32 bit, and to build it for a 64 bit system, there is a somewhat confusing situation. The library itself gets put into /usr/lib, which is supposed to be for 64 bit libraries. And to make the whole thing package up in a workable way, the arch ends up saying the packge is x86_64, even though it is only 32 bit. To run OpenBUGS on a 64 bit system, one h as to install the 32bit libc packages.
I've built the RPM on a 32bit system, it comes out with the proper x86 target in the file name,but that package will not instlal on the 64 bit systems. Should it? (As I said, I can build the package on the 64 bit system, and it comes out with a 64 bit file name, but it is really 32 bits.). Oh, bother, this is confusing to me, I can't imagine your situation.
http://pj.freefaculty.org/Fedora/14/i386/kups/packages/
On the other hand, the ones I build on a 64 bit system:
Show up with 64bit names even though they are 32 bit programs:
http://pj.freefaculty.org/Fedora/14/x86_64/openbugs-3.2.1-1.x86_64.rpm
In the current Fedora framework, I can't understand if that is supposed to happen.
I decided to try to help the cause of Bayesian statistics and the open source effort of the OpenBUGS group (http://www.openbugs.info/w/) by making some packages. In case you are not a statistically-inclined person, it is worth knowing that Bayesian Updating with Gibbs Sampling (BUGS) has caused something of a methodological landslide since the early 1990s, helping scholars to model processes that were thought to be too difficult.
In Linux, we do not have access to the OpenBUGS GUI, which
I've built deb and rpm packages for RedHat, Fedora and Ubuntu. They are available in my webspace and in the project.
I wish these could be in the official linux repositories, but I've not tried to put these into an official repository because there are 2 problems that seem prohibitive.
First, the (now open) code for OpenBugs is written in Object Pascal and it requires a compiler framework called "Black Box" which is, as far as I can understand, available only for MS Windows. The OpenBUGS team compiles that library, and then for linux we use some accessor scripts to send jobs to it.
This, of course, goes against the packaging policy that pre-compiled libraries are prohibited.
I was wondering if there could be an exception here, since the code is actually available and open. This is more reasonable than re-packaging the closed Nvidia drivers, for example.
f it's actually open, build from source. If it won't build from source due to a missing dependency, include that in Fedora, built from source. If that's not possible because something it needs isn't open, I don't see how this can be allowed.
-J
Second, there is a little packaging problem for 64 bit systems. The library that is provided is only 32 bit, and to build it for a 64 bit system, there is a somewhat confusing situation. The library itself gets put into /usr/lib, which is supposed to be for 64 bit libraries. And to make the whole thing package up in a workable way, the arch ends up saying the packge is x86_64, even though it is only 32 bit. To run OpenBUGS on a 64 bit system, one h as to install the 32bit libc packages.
I've built the RPM on a 32bit system, it comes out with the proper x86 target in the file name,but that package will not instlal on the 64 bit systems. Should it? (As I said, I can build the package on the 64 bit system, and it comes out with a 64 bit file name, but it is really 32 bits.). Oh, bother, this is confusing to me, I can't imagine your situation.
http://pj.freefaculty.org/Fedora/14/i386/kups/packages/
On the other hand, the ones I build on a 64 bit system:
Show up with 64bit names even though they are 32 bit programs:
http://pj.freefaculty.org/Fedora/14/x86_64/openbugs-3.2.1-1.x86_64.rpm
In the current Fedora framework, I can't understand if that is supposed to happen.
-- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2011-06-14 at 10:54 -0500, Jon Ciesla wrote:
I decided to try to help the cause of Bayesian statistics and the open source effort of the OpenBUGS group (http://www.openbugs.info/w/) by making some packages. In case you are not a statistically-inclined person, it is worth knowing that Bayesian Updating with Gibbs Sampling (BUGS) has caused something of a methodological landslide since the early 1990s, helping scholars to model processes that were thought to be too difficult.
In Linux, we do not have access to the OpenBUGS GUI, which
I've built deb and rpm packages for RedHat, Fedora and Ubuntu. They are available in my webspace and in the project.
I wish these could be in the official linux repositories, but I've not tried to put these into an official repository because there are 2 problems that seem prohibitive.
First, the (now open) code for OpenBugs is written in Object Pascal and it requires a compiler framework called "Black Box" which is, as far as I can understand, available only for MS Windows. The OpenBUGS team compiles that library, and then for linux we use some accessor scripts to send jobs to it.
This, of course, goes against the packaging policy that pre-compiled libraries are prohibited.
I was wondering if there could be an exception here, since the code is actually available and open. This is more reasonable than re-packaging the closed Nvidia drivers, for example.
f it's actually open, build from source. If it won't build from source due to a missing dependency, include that in Fedora, built from source. If that's not possible because something it needs isn't open, I don't see how this can be allowed.
Agreed, it sounds like the necessity of linking against a closed-source library is going to be unacceptable for Fedora proper. However, this is the sort of project that might be acceptable in RPM Fusion.
Paul Johnson wrote:
First, the (now open) code for OpenBugs is written in Object Pascal and it requires a compiler framework called "Black Box" which is, as far as I can understand, available only for MS Windows. The OpenBUGS team compiles that library, and then for linux we use some accessor scripts to send jobs to it.
This, of course, goes against the packaging policy that pre-compiled libraries are prohibited.
I was wondering if there could be an exception here, since the code is actually available and open. This is more reasonable than re-packaging the closed Nvidia drivers, for example.
The code must be compilable with a Free compiler. If it is not (which seems to be the case here, unfortunately), it must be fixed (ported) to be.
In this case, the most obvious candidates would probably be FreePascal/Lazarus and GPC, but porting to a completely different, more commonly used language (I'd suggest C++) might also be worth considering for upstream (depending on how hard it is to port to a Free Pascal compiler).
Second, there is a little packaging problem for 64 bit systems. The library that is provided is only 32 bit, and to build it for a 64 bit system, there is a somewhat confusing situation. The library itself gets put into /usr/lib, which is supposed to be for 64 bit libraries. And to make the whole thing package up in a workable way, the arch ends up saying the packge is x86_64, even though it is only 32 bit.
This is entirely unacceptable (and yet another reason why prebuilt binaries are unacceptable).
If a package cannot be built as 64-bit, it must be ExcludeArch: x86_64 and then it can be put on the multilib whitelist. But really, it needs to be fixed to be buildable natively instead! That mostly means getting it to compile with a Free compiler, then fixing 64-bit issues, if any, becomes rather easy in my experience.
To run OpenBUGS on a 64 bit system, one h as to install the 32bit libc packages.
That's exactly why such 32-bit stuff doesn't belong into an x86_64 package. In fact, Koji will not let you build 32-bit binaries in an x86_64 package, almost all 32-bit multilibs are explicitly blacklisted in the x86_64 repository configuration to prevent you from doing exactly that.
In the current Fedora framework, I can't understand if that is supposed to happen.
No. 32-bit binaries are not allowed in x86_64 packages.
Kevin Kofler
Kevin Kofler wrote:
In this case, the most obvious candidates would probably be FreePascal/Lazarus and GPC, but porting to a completely different, more commonly used language (I'd suggest C++) might also be worth considering for upstream (depending on how hard it is to port to a Free Pascal compiler).
Actually, maybe this can help: http://cp-dev.sourceforge.net/ (but it's 32- bit-x86-only and it might not be complete enough to build OpenBUGS yet, plus I still wonder why the .obc source files contain that binary metadata in addition to the Pascal-like code).
Kevin Kofler
On Tue, Jun 14, 2011 at 7:57 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Kevin Kofler wrote:
In this case, the most obvious candidates would probably be FreePascal/Lazarus and GPC, but porting to a completely different, more commonly used language (I'd suggest C++) might also be worth considering for upstream (depending on how hard it is to port to a Free Pascal compiler).
Actually, maybe this can help: http://cp-dev.sourceforge.net/ (but it's 32- bit-x86-only and it might not be complete enough to build OpenBUGS yet, plus I still wonder why the .obc source files contain that binary metadata in addition to the Pascal-like code).
Kevin Kofler
Thanks for the link. I did not know about that project yet, but it does point over to the OpenBUGS site.
I agree with you it is a bit weird that the BUGS source code is wrapped into those binary odc files. The most favorable interpretation I can give this is that it is a form of literate programming, where the code is wrapped into documentation and so forth.
To the ODC haters: I agree, but...
This *is* an open source project, if you have the right editor. I ran the free BlackBox program inside Wine just now. Putting code into ODC files is not conceptually different from wrapping a CPP program into LaTeX source code, or wrapping R code into an Rnw file. The fact that the code is not just a flat ascii file you can read with Emacs does not make it less open.
I will try to find out the historical reasons for relying on BlackBox. That decision was made in 1996 or so, and if you remember the state of the world then, the g++ did not work very well and there were competing/incomplete versions of the standard template library. Java did not exist, and Pascal was just about as widely used as C (moreso in the classroom). A lot of the bigger scientific programming projects of that era avoided C++. The other project with which I was intimately familiar is Swarm, which adopted Objective-C as its language, mostly for the same reasons.
pj
--
On Wed, Jun 15, 2011 at 10:34:46AM -0500, Paul Johnson wrote:
On Tue, Jun 14, 2011 at 7:57 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Kevin Kofler wrote:
In this case, the most obvious candidates would probably be FreePascal/Lazarus and GPC, but porting to a completely different, more commonly used language (I'd suggest C++) might also be worth considering for upstream (depending on how hard it is to port to a Free Pascal compiler).
Actually, maybe this can help: http://cp-dev.sourceforge.net/ (but it's 32- bit-x86-only and it might not be complete enough to build OpenBUGS yet, plus I still wonder why the .obc source files contain that binary metadata in addition to the Pascal-like code).
Kevin Kofler
Thanks for the link. I did not know about that project yet, but it does point over to the OpenBUGS site.
I agree with you it is a bit weird that the BUGS source code is wrapped into those binary odc files. The most favorable interpretation I can give this is that it is a form of literate programming, where the code is wrapped into documentation and so forth.
To the ODC haters: I agree, but...
This *is* an open source project, if you have the right editor. I ran the free BlackBox program inside Wine just now. Putting code into ODC files is not conceptually different from wrapping a CPP program into LaTeX source code, or wrapping R code into an Rnw file. The fact that the code is not just a flat ascii file you can read with Emacs does not make it less open.
Is there any editor on Fedora that can handle these files? I tried libreoffice but it appeared to crash.
Rich.
PS:
Paul Johnson wrote:
I was wondering if there could be an exception here, since the code is actually available and open.
Have you even looked at that "source code"? I just have:
1. They refer to the Window$ download for the code. That's a .EXE file created with some proprietary installer generator (probably something that's part of that "Black Box" crap), 7z cannot do anything with it (and it can unpack at least self extractors and NSIS installers). Rather than running that EXE in WINE to get at the .odc files, I decided to look elsewhere, and in fact found their repository, but:
2. Here's the "source code": http://openbugs.svn.sourceforge.net/viewvc/openbugs/openbugs/trunk/ Try to look at such a .odc file. You'll notice that ViewVC refuses to show you the file because it's a binary! Look at it, you'll see some Pascal code mixed with some opaque binary data which probably only "Black Box" (nomen est omen…) can interpret.
I don't see this as being "open" source code at all.
I guess the binary metadata is an essential part of the code.
Kevin Kofler
On 06/14/2011 07:41 PM, Kevin Kofler wrote:
PS:
Paul Johnson wrote:
I was wondering if there could be an exception here, since the code is actually available and open.
Have you even looked at that "source code"? I just have:
- They refer to the Window$ download for the code. That's a .EXE file
created with some proprietary installer generator (probably something that's part of that "Black Box" crap), 7z cannot do anything with it (and it can unpack at least self extractors and NSIS installers). Rather than running that EXE in WINE to get at the .odc files, I decided to look elsewhere, and in fact found their repository, but:
I'm wanting to use BUGS myself, so I've spent some time today poking around at it. Here's a report on what I've found; it might help in future analysis or further work on making this software usable and available.
They use Inno Setup for their installer, so it is "proprietary" in the sense that the format is not standardized, but Inno Setup is open source. Its source code has been used to write innounp[1], an unpacker for Inno Setup files.
Unfortunately, Inno Setup and innounp are written in Delphi, so the usefulness diminishes at that point. However, it should be possible to construct a portable unpacker using the innounp sources as a reference, and it may even be possble to build them with FreePascal, depending on how much Delphi-specific stuff they use.
Also, there is the cp-dev project[2] for building Component Pascal programs on Linux, but it seems to want plain text input (.cp rather than .odc) and also seems to require Black Box to bootstrap. I do not know if it is self-hosting after the initial bootstrap.
So, a from-source build is still a ways off, but not necessarily entirely unfeasible. If cp-dev is self-hosting, license-clean[3], and capable of building OpenBUGS, is there a way to get it in to Fedora? It seems it would require running an initial pre-compiled binary, bootstrapped with Black Box, to then be able to recompile cp-dev from SRPMs and use the recompiled version to keep it up to date.
There is still the issue of the lack of a free software viewer and editor for the .odc files, but that seems to be a separate issue from that of being able to re-build OpenBUGS with a completely free toolchain.
It could be that OpenBUGS will forever need to live in third-party repositories.
- Michael
1. http://innounp.sourceforge.net/ 2. http://cp-dev.sourceforge.net 3. cp-dev seems to not only use Black Box to bootstrap, but it also seems to use Black Box sources as a part of itself. I have not yet investigated whether this is true and, if true, how the relevant sources are licensed.
On 08/26/2011 12:13 PM, Michael Ekstrand wrote:
- cp-dev seems to not only use Black Box to bootstrap, but it also
seems to use Black Box sources as a part of itself. I have not yet investigated whether this is true and, if true, how the relevant sources are licensed.
BlackBox Component Builder's installation includes lots of source code and is licensed under what looks like the Sleepycat license (BSD + copyleft).
So it looks like the build and packaging toolchain for OpenBUGS does consist of open source software, but this software is built for Windows, may depend on GUIs for launching and controlling the build, and has a nontrivial bootstrap process.
- Michael
On 26 August 2011 19:50, Michael Ekstrand michael@elehack.net wrote:
On 08/26/2011 12:13 PM, Michael Ekstrand wrote:
- cp-dev seems to not only use Black Box to bootstrap, but it also
seems to use Black Box sources as a part of itself. I have not yet investigated whether this is true and, if true, how the relevant sources are licensed.
BlackBox Component Builder's installation includes lots of source code and is licensed under what looks like the Sleepycat license (BSD + copyleft).
So it looks like the build and packaging toolchain for OpenBUGS does consist of open source software, but this software is built for Windows, may depend on GUIs for launching and controlling the build, and has a nontrivial bootstrap process.
Perhaps JAGS is a better option for Fedora:
http://en.wikipedia.org/wiki/Just_another_Gibbs_sampler
"Its main advantage in comparison to the members of the original BUGS family (WinBUGS and OpenBUGS) is its platform independence. It is written in C++, while the BUGS family is written Component Pascal which is only available for Windows.[1][2] Therefore it is already part of many repositories of Linux distributions like Ubuntu. It can also be compiled as a 64-bits application on 64-bits platforms, thus making all the addressable space available to BUGS models."
J.
-
Jon Ciesla -
Jonathan Underwood -
Kevin Kofler -
Michael Ekstrand -
Paul Johnson -
Richard W.M. Jones -
Stephen Gallagher