Compiling Aqsis on Snow Leopard (OS X 10.6.x)

[Jonathan Merritt-2]

Hi Everyone,

Just wondering: is anyone currently compiling Aqsis under Snow  
Leopard?  If so, are there any wiki instructions that I could follow?

I've just started the process, using MacPorts (instead of hand-
compiling everything as I have done in the past).  However, it seems  
there is a problem with FLTK.  AFAICT, MacPorts is compiling  
everything as 64-bit by default (which is also the Snow Leopard  
default), but FLTK can only be compiled in 32-bit mode because it  
still uses Carbon as the OS X interface layer.  As a result, I get  
"file is not of the required architecture" errors with FLTK if I use  
the default CMake setting (x86_64), or with Boost and other libraries  
if I try to force i386.  Does someone already have a compilation  
recipe that works?  Or some appropriate kung-fu to make MacPorts  
behave? :-)

It seems as though I need to make all of the libraries 32-bit.  Is  
there some way to make MacPorts generate both 32-bit and 64-bit  
versions of libraries?  And if so, how does that work out at run-time?

Thanks,

Jonathan Merritt.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Tobias Sauerwein-2]

Hi Jonathan,

even if I'm not building under Snow Leopard yet, and despite the fact
that I have been very pro MacPorts in the past I switched to "build
everything by hand" because its easier to get a propper universal
binary than forcing MacPorts to do the right thing there.
But I know that Leon uses mainly MacPorts for our official build, so
he certainly has some tips for you.
Writing that up on the wiki would be great for other people who are
having the same issues. Saying that, I'll have to upgrade to SL
anyway, maybe today, so I might give it a chance this weekend.

Cheers,
 Tobias





On Fri, Nov 6, 2009 at 2:55 AM, Jonathan Merritt <merritt@...> wrote:

> Hi Everyone,
>
> Just wondering: is anyone currently compiling Aqsis under Snow
> Leopard?  If so, are there any wiki instructions that I could follow?
>
> I've just started the process, using MacPorts (instead of hand-
> compiling everything as I have done in the past).  However, it seems
> there is a problem with FLTK.  AFAICT, MacPorts is compiling
> everything as 64-bit by default (which is also the Snow Leopard
> default), but FLTK can only be compiled in 32-bit mode because it
> still uses Carbon as the OS X interface layer.  As a result, I get
> "file is not of the required architecture" errors with FLTK if I use
> the default CMake setting (x86_64), or with Boost and other libraries
> if I try to force i386.  Does someone already have a compilation
> recipe that works?  Or some appropriate kung-fu to make MacPorts
> behave? :-)
>
> It seems as though I need to make all of the libraries 32-bit.  Is
> there some way to make MacPorts generate both 32-bit and 64-bit
> versions of libraries?  And if so, how does that work out at run-time?
>
> Thanks,
>
> Jonathan Merritt.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Aqsis-development mailing list
> Aqsis-development@...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Jonathan Merritt-2]

Hi Tobias (+ List :-),

Have you had any success with a Snow Leopard compile?

Just an update on my progress... I've been able to compile Aqsis without FLTK (actually as a 64-bit application), and it works fine without the framebuffer display driver.  However, I *haven't* yet gone through the process of either:
  a) compiling FLTK with a 64-bit Quartz back-end, or
  b) compiling all Aqsis libs as 32-bit so they cooperate with FLTK, or
  c) obtaining an alternate framebuffer display driver; maybe writing my own (!)
Option a) would be the best for me, but my naive efforts at compiling FLTK (version 1.3.x-r6916) as 64-bit have failed.  I'm not even 100% sure it's possible.

I may be able to spend some more time tinkering with this next week...

Jonathan.

On 06/11/2009, at 6:00 PM, Tobias Sauerwein wrote:

> Hi Jonathan,
>
> even if I'm not building under Snow Leopard yet, and despite the fact
> that I have been very pro MacPorts in the past I switched to "build
> everything by hand" because its easier to get a propper universal
> binary than forcing MacPorts to do the right thing there.
> But I know that Leon uses mainly MacPorts for our official build, so
> he certainly has some tips for you.
> Writing that up on the wiki would be great for other people who are
> having the same issues. Saying that, I'll have to upgrade to SL
> anyway, maybe today, so I might give it a chance this weekend.
>
> Cheers,
> Tobias
>
> On Fri, Nov 6, 2009 at 2:55 AM, Jonathan Merritt <merritt@...> wrote:
>> Hi Everyone,
>>
>> Just wondering: is anyone currently compiling Aqsis under Snow
>> Leopard?  If so, are there any wiki instructions that I could follow?
>>
>> I've just started the process, using MacPorts (instead of hand-
>> compiling everything as I have done in the past).  However, it seems
>> there is a problem with FLTK.  AFAICT, MacPorts is compiling
>> everything as 64-bit by default (which is also the Snow Leopard
>> default), but FLTK can only be compiled in 32-bit mode because it
>> still uses Carbon as the OS X interface layer.  As a result, I get
>> "file is not of the required architecture" errors with FLTK if I use
>> the default CMake setting (x86_64), or with Boost and other libraries
>> if I try to force i386.  Does someone already have a compilation
>> recipe that works?  Or some appropriate kung-fu to make MacPorts
>> behave? :-)
>>
>> It seems as though I need to make all of the libraries 32-bit.  Is
>> there some way to make MacPorts generate both 32-bit and 64-bit
>> versions of libraries?  And if so, how does that work out at run-time?
>>
>> Thanks,
>>
>> Jonathan Merritt.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Thu, Nov 19, 2009 at 7:47 PM, Jonathan Merritt
<merritt@...> wrote:

Sorry I can't really help with this Jonathan, just a minor off topic note...

>  c) obtaining an alternate framebuffer display driver; maybe writing my own (!)

There's been some speculation that the image viewer (iv) from OIIO will be
controllable by a socket interface sometime in the future and would be a
possible alternative to piqsl (it uses qt).

You're probably after something quick & simple, but on the off chance that
you're interested I think that extending iv in this way would be a highly
worthwhile project.

~Chris

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Jonathan Merritt-2]

Hi Chris,

On 19/11/2009, at 10:18 PM, Chris Foster wrote:

> On Thu, Nov 19, 2009 at 7:47 PM, Jonathan Merritt
> <merritt@...> wrote:
>
> Sorry I can't really help with this Jonathan, just a minor off topic note...
>
>>  c) obtaining an alternate framebuffer display driver; maybe writing my own (!)
>
> There's been some speculation that the image viewer (iv) from OIIO will be
> controllable by a socket interface sometime in the future and would be a
> possible alternative to piqsl (it uses qt).
>
> You're probably after something quick & simple, but on the off chance that
> you're interested I think that extending iv in this way would be a highly
> worthwhile project.

Thanks for the link.  I'll check out OIIO and iv sometime next week.  I have also been contemplating writing a JVM-based display.  I think that the cross-platform benefits and the multiple GUI toolkit options (JavaFX, Swing, SWT, etc.) might make it worthwhile.  I also have far more experience with the various JVM languages than with C/C++ these days. :-)

Jonathan.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Tobias Sauerwein-2]

I haven't upgraded to Leopard yet but will do that this weekend,
probably tomorrow.
After that I'll give it a go and let you know how it went.

About using a qt-based viewer: while qt looks nice the framework is
quite heavy, so I'd be cautious, but then you only mentioned it as a
possible alternative. I wonder if switching to fltk2 would be
difficult and much work, presumed it compiles as 64bit. But also if it
is already stable enough and would offer any benefit over the fltk
version we're currently using.

Cheers,
 Tobias

On Thu, Nov 19, 2009 at 12:45 PM, Jonathan Merritt
<merritt@...> wrote:

> Hi Chris,
>
> On 19/11/2009, at 10:18 PM, Chris Foster wrote:
>> On Thu, Nov 19, 2009 at 7:47 PM, Jonathan Merritt
>> <merritt@...> wrote:
>>
>> Sorry I can't really help with this Jonathan, just a minor off topic note...
>>
>>>  c) obtaining an alternate framebuffer display driver; maybe writing my own (!)
>>
>> There's been some speculation that the image viewer (iv) from OIIO will be
>> controllable by a socket interface sometime in the future and would be a
>> possible alternative to piqsl (it uses qt).
>>
>> You're probably after something quick & simple, but on the off chance that
>> you're interested I think that extending iv in this way would be a highly
>> worthwhile project.
>
> Thanks for the link.  I'll check out OIIO and iv sometime next week.  I have also been contemplating writing a JVM-based display.  I think that the cross-platform benefits and the multiple GUI toolkit options (JavaFX, Swing, SWT, etc.) might make it worthwhile.  I also have far more experience with the various JVM languages than with C/C++ these days. :-)
>
> Jonathan.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Aqsis-development mailing list
> Aqsis-development@...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Matthias Baas-3]

Jonathan Merritt wrote:
> Thanks for the link.  I'll check out OIIO and iv sometime next week.
> I have also been contemplating writing a JVM-based display.  I think
> that the cross-platform benefits and the multiple GUI toolkit options
> (JavaFX, Swing, SWT, etc.) might make it worthwhile.  I also have far
> more experience with the various JVM languages than with C/C++ these
> days. :-)

Have you considered implementing this framebuffer as an Eclipse view? I
think together with an editor plugin that supports SL, this would be a
nice IDE for writing shaders (for example, the framebuffer view could
automatically update while you write the shader and there could be GUI
controls for tweaking the shader parameters, etc.)

(Being able to write Eclipse plugins is one of the reasons I've actually
started looking into Java (Android is another one), but so far, I have
no idea how a RenderMan display device would be implemented in Java...)

- Matthias -


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Jonathan Merritt-2]

Hi Matthias,

On 20/11/2009, at 7:59 AM, Matthias Baas wrote:

> Jonathan Merritt wrote:
>> Thanks for the link.  I'll check out OIIO and iv sometime next week.
>> I have also been contemplating writing a JVM-based display.  I think
>> that the cross-platform benefits and the multiple GUI toolkit options
>> (JavaFX, Swing, SWT, etc.) might make it worthwhile.  I also have far
>> more experience with the various JVM languages than with C/C++ these
>> days. :-)
>
> Have you considered implementing this framebuffer as an Eclipse view? I
> think together with an editor plugin that supports SL, this would be a
> nice IDE for writing shaders (for example, the framebuffer view could
> automatically update while you write the shader and there could be GUI
> controls for tweaking the shader parameters, etc.)

That sounds like a great idea!  Using Eclipse or Netbeans as the IDE backbone of a node-based editor would also make a nice project one day... :-)

I was hoping to do something more general initially... a layered approach:

    Piqsl XML-based socket communication
                  |
    Data layer of interfaces containing
    bucket data, listeners that are
    notified when buckets become
    available, etc.
                  |
    Display layer; components in various
    toolkits (Swing, JavaFX, SWT) for
    displaying the data layer.

With an appropriate "model" (in the MVC arrangement) that includes listeners, an adaptor-style hookup to any of the GUI toolkits should be easy.

> (Being able to write Eclipse plugins is one of the reasons I've actually
> started looking into Java (Android is another one), but so far, I have
> no idea how a RenderMan display device would be implemented in Java...)

I'm into the JVM mostly for the available languages... I love being able to switch between Java, Groovy, JRuby, Python and Scala.  I know some people hate the current "language explosion", but I think it's fantastic, especially in the way it's getting to the guts of various issues like static-vs-dynamic typing, functional-vs-imperative styles, etc., and the way all of those work in a real development environment.

The java.net package is the place to start for socket listening:
    http://java.sun.com/javase/6/docs/api/java/net/package-summary.html
Basically, you open a socket and end up with a java.io.Reader, which you can treat just like a FileReader or whatever else you're familiar with:
    http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html
That could then listen for output from the normal Aqsis socket writer (see src/tools/piqsl).  I think that the low-level Dspy*-to-socket stuff still belongs in C/C++ however.

Two questions I do have:
  1. Is there a spec / reference for the XML format that piqsl uses for socket communication?  I can construct most of it from src/tools/piqsl/piqsl.cpp#processMessage, but documentation would be good.
  2. How easy is it to separate the socket writing stuff in piqsl from the FLTK GUI?  (Would it be just as easy for me to start from scratch with the Dspy* stuff?)

Thanks,

Jonathan.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Fri, Nov 20, 2009 at 5:33 PM, Jonathan Merritt
<merritt@...> wrote:
> That could then listen for output from the normal Aqsis socket writer (see
> src/tools/piqsl).  I think that the low-level Dspy*-to-socket stuff still
> belongs in C/C++ however.

Sounds right to me.

> Two questions I do have:
>  1. Is there a spec / reference for the XML format that piqsl uses for
> socket communication?  I can construct most of it from
> src/tools/piqsl/piqsl.cpp#processMessage, but documentation would be good.

There's some docs from the early days of piqsl development here:

http://wiki.aqsis.org/dev/eqshibit

I think they're still current; Paul will know better than me.  I'm tempted to
make the XML format a bit more consistent here and there, but it does work so
maybe it's best to leave it alone ;-)

>  2. How easy is it to separate the socket writing stuff in piqsl from the
> FLTK GUI?

It should be very easy, in fact the code is already in separate directories in
the new source layout.  From memory, the only thing you will need to change
will be the program which the piqsl display automatically runs.  I'd be happy
to accept a patch which adds a display parameter allowing arbitrary framebuffer
programs to be invoked (if this can't be done already that is).

You may also need to change the cmake setup so that piqsl display is built
independently of whether the necessary libraries exist to build piqsl itself.

~Chris

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Paul Gregory-4]

2009/11/20 Chris Foster <chris42f@...>

There's some docs from the early days of piqsl development here:

http://wiki.aqsis.org/dev/eqshibit

I think they're still current; Paul will know better than me.  I'm tempted to
make the XML format a bit more consistent here and there, but it does work so
maybe it's best to leave it alone ;-)

Yes, those docs are pretty much valid, although a little sparse. Couple of points to note:

1. The Open sample shows a number of Parameters, this isn't fixed, it passes any specified parameters from the Aqsis side of the interface using that syntax, so you'd need to iterate over each parameter, deal with it's type, and decide if you understand/need it using the name.
2. The CDATA in the data message is base64 encoded.


Paul

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Matthias Baas-3]

Hi Jonathan,

> I was hoping to do something more general initially... a layered approach:
>
>     Piqsl XML-based socket communication
>                   |
>     Data layer of interfaces containing
>     bucket data, listeners that are
>     notified when buckets become
>     available, etc.
>                   |
>     Display layer; components in various
>     toolkits (Swing, JavaFX, SWT) for
>     displaying the data layer.
>
> With an appropriate "model" (in the MVC arrangement) that includes
> listeners, an adaptor-style hookup to any of the GUI toolkits should
> be easy.

Sounds good. I suppose once this is all done, integrating it into
Eclipse should be relatively straightforward. The other stuff like an SL
editor or a node-based editor are independent from that anyway (and I
suppose, at the beginning, it would also be fine to just use the C/C++
editor from the CDT plugin to write shaders).

> I'm into the JVM mostly for the available languages... I love being
> able to switch between Java, Groovy, JRuby, Python and Scala.  I know

I didn't know there are so many languages that can be run on the JVM! I
heard about Jython, but never really knew how it actually works (another
thing to look into eventually. There are just too many interesting
things around... ;) )
Does that mean I could write applets or Eclipse plugins in one of the
above languages instead of Java? (it's interesting how all the languages
start interleaving. Recently, I found "Pyjamas" which is a port of
Google's Web Toolkit which means you can implement web applications in
Python just as if it was a desktop GUI application. Pyjamas then
translates the Python code into a set of JavaScript/HTML files and you
can run the application inside a browser. If the regression test tool
ever gets an overhaul, this might be an option to consider... :) )

> The java.net package is the place to start for socket listening:
>     http://java.sun.com/javase/6/docs/api/java/net/package-summary.html
> Basically, you open a socket and end up with a java.io.Reader, which
> you can treat just like a FileReader or whatever else you're familiar with:
>     http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html
> That could then listen for output from the normal Aqsis socket writer
> (see src/tools/piqsl).  I think that the low-level Dspy*-to-socket
> stuff still belongs in C/C++ however.

Thanks for the pointers! I wasn't sure if Java would provide other
options as well and I also wasn't aware (anymore?) that piqsl uses a
socket-based approach using XML.
I suppose if the piqsl display driver could be generalized a bit, so
that it can also launch other tools and communicate with them then half
of the problem is already solved.

Cheers,

- Matthias -


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development