Date   

Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

After looking at ATI's open cl I think its a little bit overkill. From initial look i think we would have to create kernels for each math function we wanted as well as create an open cl context to make use the the language features defined in the Open CL spec.

For doing a gpu version of a shader this might work but as a stand-in for the C99 math i don't think it would be a good solution.

Jeremy


On Mon, Jan 18, 2010 at 8:58 PM, Wormszer <worm...@...> wrote:
I tried the first link you mention but i end up with a different set of errors.

What did you do to get it working? I will play with it some more and see.

I got the defines enabled by defining the _USE_MATH_DEFINES like Chris mentioned and mentioned in the second link.

I agree on trying to use something like open CL. Do they provide CPU implementations for all the math functions?
But to take advantage of the real gpu speed up we would need to do it somewhere else where things can be batched.

I hope once i get this building to dig in and figure out what is going on in the shader execution and language parsing. With my goal trying to help with getting some kind of GPU based shader preview implementation going as mentioned in Larry's introduction.
Open CL I would think should be a good language to shoot towards as I am under the impression its supposed to replace nvidias cuda and ati's brook stream stuff. Or at least both vendors will support it.

Jeremy

On Mon, Jan 18, 2010 at 6:19 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

I have installed the latest cygwin version and was able to process all
flex/bison files. The cygwin flex version can handle "/" as path
separator, too :-) Apart from that I had the same problems compiling
"oslinfo", "oslquery", "oslcomp" and "exec" projects. I have found c99
macro definitions

here    http://lists.boost.org/Archives/boost/2005/12/97593.php

and

here    http://www.gamedev.net/community/forums/topic.asp?topic_id=127944

Maybe we can use CUDA or OpenCL (which is better, since available on
NVIDIA/ATI) for all missing math functions. Please see

- http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/docs/NVIDIA_CUDA_Programming_Guide_2.3.pdf,
page 120
- http://www.khronos.org/registry/cl/specs/opencl-1.0.43.pdf?q=specification,
page 168

Regards,
Oleg


On 18 Jan., 05:51, Wormszer <wo...@...> wrote:
> My generated code issues were from VS having not rebuilt the files with the
> new flex.
>
> So now I am just left with a bunch of missing math functions.
> It looks likes visual studios implementation of math. or cmath is missing a
> lot of the functions.
>
> Things like
> log2f, logbf, truncf, etc
> and defines like M_E, M_1_PI, M_PI_2 etc.
>
> See if you run into the same thing and then im not sure where to go from
> here.
>
> I guess we should get some feedback from others, maybe they are available
> somewhere else, or I could be missing something.
>
> Jeremy
>

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.






Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

I tried the first link you mention but i end up with a different set of errors.

What did you do to get it working? I will play with it some more and see.

I got the defines enabled by defining the _USE_MATH_DEFINES like Chris mentioned and mentioned in the second link.

I agree on trying to use something like open CL. Do they provide CPU implementations for all the math functions?
But to take advantage of the real gpu speed up we would need to do it somewhere else where things can be batched.

I hope once i get this building to dig in and figure out what is going on in the shader execution and language parsing. With my goal trying to help with getting some kind of GPU based shader preview implementation going as mentioned in Larry's introduction.
Open CL I would think should be a good language to shoot towards as I am under the impression its supposed to replace nvidias cuda and ati's brook stream stuff. Or at least both vendors will support it.

Jeremy

On Mon, Jan 18, 2010 at 6:19 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

I have installed the latest cygwin version and was able to process all
flex/bison files. The cygwin flex version can handle "/" as path
separator, too :-) Apart from that I had the same problems compiling
"oslinfo", "oslquery", "oslcomp" and "exec" projects. I have found c99
macro definitions

here    http://lists.boost.org/Archives/boost/2005/12/97593.php

and

here    http://www.gamedev.net/community/forums/topic.asp?topic_id=127944

Maybe we can use CUDA or OpenCL (which is better, since available on
NVIDIA/ATI) for all missing math functions. Please see

- http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/docs/NVIDIA_CUDA_Programming_Guide_2.3.pdf,
page 120
- http://www.khronos.org/registry/cl/specs/opencl-1.0.43.pdf?q=specification,
page 168

Regards,
Oleg


On 18 Jan., 05:51, Wormszer <wo...@...> wrote:
> My generated code issues were from VS having not rebuilt the files with the
> new flex.
>
> So now I am just left with a bunch of missing math functions.
> It looks likes visual studios implementation of math. or cmath is missing a
> lot of the functions.
>
> Things like
> log2f, logbf, truncf, etc
> and defines like M_E, M_1_PI, M_PI_2 etc.
>
> See if you run into the same thing and then im not sure where to go from
> here.
>
> I guess we should get some feedback from others, maybe they are available
> somewhere else, or I could be missing something.
>
> Jeremy
>

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.





Re: Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Hi Jeremy,

I have installed the latest cygwin version and was able to process all
flex/bison files. The cygwin flex version can handle "/" as path
separator, too :-) Apart from that I had the same problems compiling
"oslinfo", "oslquery", "oslcomp" and "exec" projects. I have found c99
macro definitions

here http://lists.boost.org/Archives/boost/2005/12/97593.php

and

here http://www.gamedev.net/community/forums/topic.asp?topic_id=127944

Maybe we can use CUDA or OpenCL (which is better, since available on
NVIDIA/ATI) for all missing math functions. Please see

- http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/docs/NVIDIA_CUDA_Programming_Guide_2.3.pdf,
page 120
- http://www.khronos.org/registry/cl/specs/opencl-1.0.43.pdf?q=specification,
page 168

Regards,
Oleg

On 18 Jan., 05:51, Wormszer <wo...@...> wrote:
My generated code issues were from VS having not rebuilt the files with the
new flex.

So now I am just left with a bunch of missing math functions.
It looks likes visual studios implementation of math. or cmath is missing a
lot of the functions.

Things like
log2f, logbf, truncf, etc
and defines like M_E, M_1_PI, M_PI_2 etc.

See if you run into the same thing and then im not sure where to go from
here.

I guess we should get some feedback from others, maybe they are available
somewhere else, or I could be missing something.

Jeremy


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

Thanks Chris,

I got the defines included but after searching around and trying some various things I have been unable to find a solution to the missing math functions.

The closest I got was to using the boost library's, but they are missing two functions logbf and exp2f i believe.

I found implementations of them in the glibc but they are in assembly and need pre-processing first at least. And the licensing probably doesn't match up.
And then there is probably no guarantee VS assembler will like them.

I found a commercial implementation, but couldn't really find anything for windows open source.

So my best solutions so far is to use the boost libraries and then implementing the couple of missing functions.

But some kind of wrapper or library seems like it might be a good idea for speed or possible enhancements later on like gpu etc.

Jeremy


On Mon, Jan 18, 2010 at 12:32 AM, Chris Foster <chri...@...> wrote:
On Mon, Jan 18, 2010 at 2:51 PM, Wormszer <worm...@...> wrote:
> My generated code issues were from VS having not rebuilt the files with the
> new flex.
>
> So now I am just left with a bunch of missing math functions.
> It looks likes visual studios implementation of math. or cmath is missing a
> lot of the functions.
>
> Things like
> log2f, logbf, truncf, etc

These are all C99 math functions, not available on windows I guess...  I had a
look in boost (they implement some of the C99 functions there) but
unfortunately these ones aren't implemented yet :-(

It may be best to implement versions of these in a compatibility header for
platforms which don't have full C99 support yet.  (Maybe there is a handy C99
math library under an appropriate license from which the functions can be
taken?)

> and defines like M_E, M_1_PI, M_PI_2 etc.

The M_PI etc constants are nonstandard, but may be obtained on windows by
#defining _USE_MATH_DEFINES before you include math.h.

> See if you run into the same thing and then im not sure where to go from
> here.
>
> I guess we should get some feedback from others, maybe they are available
> somewhere else, or I could be missing something.

When you've got this figured out, it's best to submit a patch and one of the
developers will check it in, possibly after a few improvements have been made.

AFAIK there's no official guide yet for how to submit patches, but I'm going
to take a guess that the procedure won't be too much different from Larry's
other open source project, OIIO, apart from the use of codereview.appspot.com
for code reviews rather than the mailing list:

http://openimageio.org/wiki/index.php?title=Developing_OIIO


Cheers,
~Chris.

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.





Re: Compiling OpenShadingLanguage under Windows

Chris Foster <chri...@...>
 

On Mon, Jan 18, 2010 at 2:51 PM, Wormszer <worm...@...> wrote:
My generated code issues were from VS having not rebuilt the files with the
new flex.

So now I am just left with a bunch of missing math functions.
It looks likes visual studios implementation of math. or cmath is missing a
lot of the functions.

Things like
log2f, logbf, truncf, etc
These are all C99 math functions, not available on windows I guess... I had a
look in boost (they implement some of the C99 functions there) but
unfortunately these ones aren't implemented yet :-(

It may be best to implement versions of these in a compatibility header for
platforms which don't have full C99 support yet. (Maybe there is a handy C99
math library under an appropriate license from which the functions can be
taken?)

and defines like M_E, M_1_PI, M_PI_2 etc.
The M_PI etc constants are nonstandard, but may be obtained on windows by
#defining _USE_MATH_DEFINES before you include math.h.

See if you run into the same thing and then im not sure where to go from
here.

I guess we should get some feedback from others, maybe they are available
somewhere else, or I could be missing something.
When you've got this figured out, it's best to submit a patch and one of the
developers will check it in, possibly after a few improvements have been made.

AFAIK there's no official guide yet for how to submit patches, but I'm going
to take a guess that the procedure won't be too much different from Larry's
other open source project, OIIO, apart from the use of codereview.appspot.com
for code reviews rather than the mailing list:

http://openimageio.org/wiki/index.php?title=Developing_OIIO


Cheers,
~Chris.


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

My generated code issues were from VS having not rebuilt the files with the new flex.

So now I am just left with a bunch of missing math functions.
It looks likes visual studios implementation of math. or cmath is missing a lot of the functions.

Things like
log2f, logbf, truncf, etc
and defines like M_E, M_1_PI, M_PI_2 etc.

See if you run into the same thing and then im not sure where to go from here.

I guess we should get some feedback from others, maybe they are available somewhere else, or I could be missing something.

Jeremy


On Sun, Jan 17, 2010 at 11:29 PM, Wormszer <worm...@...> wrote:
Ok I was able to get
oslquery
oslinfo
oslcomp
oslc
all to build. I am still working on oslexec

Here is what I had to change to get it to build, see if these changes work for you or match what you figured out.


oslquery
==============================================================
Add include lib path for tbb lib.
I had to change
class DLLPUBLIC OSLQuery {
to
class DLLEXPORT OSLQuery {
I was having an issue where the __declspec(dllimport) was not allowing nparams to be called from the OSOReaderQuery class. I think this possibly has something to do with dllimport and inline functions.
I have not used dllimport when not importing from a library and from some quick reading i didn't see anything that stuck out as a possible issue other than inlining.


oslinfo
==============================================================
Add include lib path for tbb lib.


oslcomp
==============================================================
Add include lib path for tbb lib.

I was having an issue with some const operator() calls.
Digging in to the code the fix i found was here in ustring.h located in the OIIO includes
I had to add a const version of the hash/comparison operator. The non const version could probably be removed.

class ustringHash
#ifdef _WIN32
    : public hash_compare<ustring>
#endif
{
public:
    size_t operator() (const ustring &s) const { return s.hash(); }
#ifdef _WIN32
    bool operator() (const ustring &a, const ustring &b) {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }
    bool operator() (const ustring &a, const ustring &b) const {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }

#endif
};

That should allow for oslcomp to build.
But there were no symbols being exported from the library, so no lib was being generated.
So I changed oslcomp.h to export the OSLCompiler class borrowing the exports.h from the other libraries.
And a lib file is now generated.

#ifndef OSLCOMP_H
#define OSLCOMP_H

#include "export.h"

#ifdef OSL_NAMESPACE
namespace OSL_NAMESPACE {
#endif

namespace OSL {


class DLLEXPORT OSLCompiler {
public:


oslc
==============================================================
export symbols from oslcomp library


<unistd>
==============================================================
I use the following <unistd> file for the projects that need it.

#ifndef __STRICT_ANSI__

#include <io.h>
#include <process.h>

#define    F_OK    0
#define    R_OK    4
#define    W_OK    2
#define    X_OK    1

#endif

CMAKE
==============================================================
And there were various other CMake tweaks i had to make as well to get it to generate the project correctly and find some of the libraries.
I think the only change i was unsure why i had to make was I had to change the libsxxxx projects from LIBRARY to ARCHIVE. I'm not sure why.

oslexec
==============================================================
I am getting a lot of errors relating to the generated code and a ton of missing math functions it looks like. I will dig into this project next.


And then to see if it works after all this.
Let me know where you get.

Jeremy



On Sun, Jan 17, 2010 at 7:18 PM, Wormszer <worm...@...> wrote:
Thanks Oleg,

I am using flex 2.5.35 and bison 2.3 in cygwin 1.7.

I am pretty sure that my flex version is newer even though the version number is earlier. But im not sure about bison.
I have the GNUwin32 versions as well and tried those before. Most of the issues I had were in the flexer.h.

Hmm, I had a issue with that version of bison or flex i don't remember which that it wouldn't work with spaces in the file path when it called m4 internally.
Also I had to make sure my environment variables were defined using slashes and not backslashes otherwise CMake gave some errors.

Did you have an nparams() error in olsquerry? I am getting a linking error saying it can't find it.
Even though its looks like it should be able to find it. I will have to look closer at it and see why.

Other linker errors I had after defining R_OK were a boost library being linked twice and a missing tbb.lib.
The library errors i think come from cmake rather than vs2008. I didn't see a obvious reference to the tbb.lib in the project settings I wonder if there is a #pragma somewhere asking for it.


The error I am getting on olscomp for hash_map is


1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(648) : while compiling class template member function 'std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation> stdext::_Hash<_Traits>::lower_bound(const ustring &) const'
1>        with
1>        [
1>            _Ty=std::pair<const ustring,OSL::pvt::Symbol *>,
1>            _Ax=std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,
1>            _Secure_validation=true,
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\hash_map(88) : see reference to class template instantiation 'stdext::_Hash<_Traits>' being compiled
1>        with
1>        [
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        d:\projects\graphics\oslproject\osl\src\liboslcomp\symtab.h(258) : see reference to class template instantiation 'stdext::hash_map<_Kty,_Ty,_Tr>' being compiled
1>        with
1>        [
1>            _Kty=ustring,
1>            _Ty=OSL::pvt::Symbol *,
1>            _Tr=ustringHash
1>        ]
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(654) : error C3849: function-style call on an expression of type 'const ustringHash' would lose const and/or volatile qualifiers for all 2 available operator overloads

I was hoping SP1 might of corrected something in the stdext::hash_map but it didn't seem to help.

I haven't dug in really deep yet to track down exactly whats going on yet. I will probably try and do that later tonight.

I am running Windows 7 x64 and using the project files generated from CMake 2.8.0.

Jeremy

On Sun, Jan 17, 2010 at 5:39 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

I'm using the following versions of flex/bison:

 - flex,    GnuWin32 distribution, version 2.5.4
 - bison, GnuWin32 distribution, version 2.4.1

and having the same problems. I have simply commented out <unistd.h>
includes and compiled the corresponding files again. The another
problem is that this flex version cannot use slashes as path separator
for generated files, so I have replaced slashes by backslashes for
every flex file.

The "access" function is defined in "io.h" header file under Windows,
so I have changed the "oslquery.cpp" file as follows:

#ifdef __unix__
   #include <unistd.h>
   #define EXIST F_OK
   #define EXEC  X_OK
   #define WRITE W_OK
   #define READ  R_OK
#else
   #include <io.h>
   #define EXIST 00
   #define EXEC  01
   #define WRITE 02
   #define READ  04
#endif

The "hash_map" class is defined in "stdext" namespace under Windows/VS
2008. I think you can use it without SP1, but I'm not sure.

Regards,
Oleg


On 17 Jan., 22:52, wormszer <wo...@...> wrote:
> I too have been trying to build under windows and ran across the same
> problem with the t variable.
> Assuming gcc allows it for some reason, by default is_closure() is
> false so that is what i set it too.
>
> I am having trouble with some includes particulary
> #include <unistd.h>
>
> I have one error in oslquery a missing R_OK which is defined i believe
> through this file.
> I can dig it up and add it but I think i will run into more problems
> later on in the other projects.
>
> I am also getting a hash_map error when building oslcomp.
>
> What version of flex and bison are you using? I had found a gnuwin32
> builds of both but flex was pretty out of date.
> I have installed cygwin to use the latest versions from there to run
> flex and bison. Which generates files that have better includes
> <iostream> vs <iostream.h> etc.
>
> Hopefully we can get this figured out.
> I am using visual studio 2008 as well. I just realized i might not
> have sp1. I will update and see if that helps at all.
>
> Thanks
> Jeremy

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.







Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

Ok I was able to get
oslquery
oslinfo
oslcomp
oslc
all to build. I am still working on oslexec

Here is what I had to change to get it to build, see if these changes work for you or match what you figured out.


oslquery
==============================================================
Add include lib path for tbb lib.
I had to change
class DLLPUBLIC OSLQuery {
to
class DLLEXPORT OSLQuery {
I was having an issue where the __declspec(dllimport) was not allowing nparams to be called from the OSOReaderQuery class. I think this possibly has something to do with dllimport and inline functions.
I have not used dllimport when not importing from a library and from some quick reading i didn't see anything that stuck out as a possible issue other than inlining.


oslinfo
==============================================================
Add include lib path for tbb lib.


oslcomp
==============================================================
Add include lib path for tbb lib.

I was having an issue with some const operator() calls.
Digging in to the code the fix i found was here in ustring.h located in the OIIO includes
I had to add a const version of the hash/comparison operator. The non const version could probably be removed.

class ustringHash
#ifdef _WIN32
    : public hash_compare<ustring>
#endif
{
public:
    size_t operator() (const ustring &s) const { return s.hash(); }
#ifdef _WIN32
    bool operator() (const ustring &a, const ustring &b) {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }
    bool operator() (const ustring &a, const ustring &b) const {
        return strcmp (a.c_str(), b.c_str()) < 0;
    }

#endif
};

That should allow for oslcomp to build.
But there were no symbols being exported from the library, so no lib was being generated.
So I changed oslcomp.h to export the OSLCompiler class borrowing the exports.h from the other libraries.
And a lib file is now generated.

#ifndef OSLCOMP_H
#define OSLCOMP_H

#include "export.h"

#ifdef OSL_NAMESPACE
namespace OSL_NAMESPACE {
#endif

namespace OSL {


class DLLEXPORT OSLCompiler {
public:


oslc
==============================================================
export symbols from oslcomp library


<unistd>
==============================================================
I use the following <unistd> file for the projects that need it.

#ifndef __STRICT_ANSI__

#include <io.h>
#include <process.h>

#define    F_OK    0
#define    R_OK    4
#define    W_OK    2
#define    X_OK    1

#endif

CMAKE
==============================================================
And there were various other CMake tweaks i had to make as well to get it to generate the project correctly and find some of the libraries.
I think the only change i was unsure why i had to make was I had to change the libsxxxx projects from LIBRARY to ARCHIVE. I'm not sure why.

oslexec
==============================================================
I am getting a lot of errors relating to the generated code and a ton of missing math functions it looks like. I will dig into this project next.


And then to see if it works after all this.
Let me know where you get.

Jeremy


On Sun, Jan 17, 2010 at 7:18 PM, Wormszer <worm...@...> wrote:
Thanks Oleg,

I am using flex 2.5.35 and bison 2.3 in cygwin 1.7.

I am pretty sure that my flex version is newer even though the version number is earlier. But im not sure about bison.
I have the GNUwin32 versions as well and tried those before. Most of the issues I had were in the flexer.h.

Hmm, I had a issue with that version of bison or flex i don't remember which that it wouldn't work with spaces in the file path when it called m4 internally.
Also I had to make sure my environment variables were defined using slashes and not backslashes otherwise CMake gave some errors.

Did you have an nparams() error in olsquerry? I am getting a linking error saying it can't find it.
Even though its looks like it should be able to find it. I will have to look closer at it and see why.

Other linker errors I had after defining R_OK were a boost library being linked twice and a missing tbb.lib.
The library errors i think come from cmake rather than vs2008. I didn't see a obvious reference to the tbb.lib in the project settings I wonder if there is a #pragma somewhere asking for it.


The error I am getting on olscomp for hash_map is


1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(648) : while compiling class template member function 'std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation> stdext::_Hash<_Traits>::lower_bound(const ustring &) const'
1>        with
1>        [
1>            _Ty=std::pair<const ustring,OSL::pvt::Symbol *>,
1>            _Ax=std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,
1>            _Secure_validation=true,
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\hash_map(88) : see reference to class template instantiation 'stdext::_Hash<_Traits>' being compiled
1>        with
1>        [
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        d:\projects\graphics\oslproject\osl\src\liboslcomp\symtab.h(258) : see reference to class template instantiation 'stdext::hash_map<_Kty,_Ty,_Tr>' being compiled
1>        with
1>        [
1>            _Kty=ustring,
1>            _Ty=OSL::pvt::Symbol *,
1>            _Tr=ustringHash
1>        ]
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(654) : error C3849: function-style call on an expression of type 'const ustringHash' would lose const and/or volatile qualifiers for all 2 available operator overloads

I was hoping SP1 might of corrected something in the stdext::hash_map but it didn't seem to help.

I haven't dug in really deep yet to track down exactly whats going on yet. I will probably try and do that later tonight.

I am running Windows 7 x64 and using the project files generated from CMake 2.8.0.

Jeremy

On Sun, Jan 17, 2010 at 5:39 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

I'm using the following versions of flex/bison:

 - flex,    GnuWin32 distribution, version 2.5.4
 - bison, GnuWin32 distribution, version 2.4.1

and having the same problems. I have simply commented out <unistd.h>
includes and compiled the corresponding files again. The another
problem is that this flex version cannot use slashes as path separator
for generated files, so I have replaced slashes by backslashes for
every flex file.

The "access" function is defined in "io.h" header file under Windows,
so I have changed the "oslquery.cpp" file as follows:

#ifdef __unix__
   #include <unistd.h>
   #define EXIST F_OK
   #define EXEC  X_OK
   #define WRITE W_OK
   #define READ  R_OK
#else
   #include <io.h>
   #define EXIST 00
   #define EXEC  01
   #define WRITE 02
   #define READ  04
#endif

The "hash_map" class is defined in "stdext" namespace under Windows/VS
2008. I think you can use it without SP1, but I'm not sure.

Regards,
Oleg


On 17 Jan., 22:52, wormszer <wo...@...> wrote:
> I too have been trying to build under windows and ran across the same
> problem with the t variable.
> Assuming gcc allows it for some reason, by default is_closure() is
> false so that is what i set it too.
>
> I am having trouble with some includes particulary
> #include <unistd.h>
>
> I have one error in oslquery a missing R_OK which is defined i believe
> through this file.
> I can dig it up and add it but I think i will run into more problems
> later on in the other projects.
>
> I am also getting a hash_map error when building oslcomp.
>
> What version of flex and bison are you using? I had found a gnuwin32
> builds of both but flex was pretty out of date.
> I have installed cygwin to use the latest versions from there to run
> flex and bison. Which generates files that have better includes
> <iostream> vs <iostream.h> etc.
>
> Hopefully we can get this figured out.
> I am using visual studio 2008 as well. I just realized i might not
> have sp1. I will update and see if that helps at all.
>
> Thanks
> Jeremy

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.






Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

Thanks Oleg,

I am using flex 2.5.35 and bison 2.3 in cygwin 1.7.

I am pretty sure that my flex version is newer even though the version number is earlier. But im not sure about bison.
I have the GNUwin32 versions as well and tried those before. Most of the issues I had were in the flexer.h.

Hmm, I had a issue with that version of bison or flex i don't remember which that it wouldn't work with spaces in the file path when it called m4 internally.
Also I had to make sure my environment variables were defined using slashes and not backslashes otherwise CMake gave some errors.

Did you have an nparams() error in olsquerry? I am getting a linking error saying it can't find it.
Even though its looks like it should be able to find it. I will have to look closer at it and see why.

Other linker errors I had after defining R_OK were a boost library being linked twice and a missing tbb.lib.
The library errors i think come from cmake rather than vs2008. I didn't see a obvious reference to the tbb.lib in the project settings I wonder if there is a #pragma somewhere asking for it.


The error I am getting on olscomp for hash_map is


1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(648) : while compiling class template member function 'std::list<_Ty,_Ax>::_Const_iterator<_Secure_validation> stdext::_Hash<_Traits>::lower_bound(const ustring &) const'
1>        with
1>        [
1>            _Ty=std::pair<const ustring,OSL::pvt::Symbol *>,
1>            _Ax=std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,
1>            _Secure_validation=true,
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\hash_map(88) : see reference to class template instantiation 'stdext::_Hash<_Traits>' being compiled
1>        with
1>        [
1>            _Traits=stdext::_Hmap_traits<ustring,OSL::pvt::Symbol *,ustringHash,std::allocator<std::pair<const ustring,OSL::pvt::Symbol *>>,false>
1>        ]
1>        d:\projects\graphics\oslproject\osl\src\liboslcomp\symtab.h(258) : see reference to class template instantiation 'stdext::hash_map<_Kty,_Ty,_Tr>' being compiled
1>        with
1>        [
1>            _Kty=ustring,
1>            _Ty=OSL::pvt::Symbol *,
1>            _Tr=ustringHash
1>        ]
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(654) : error C3849: function-style call on an expression of type 'const ustringHash' would lose const and/or volatile qualifiers for all 2 available operator overloads

I was hoping SP1 might of corrected something in the stdext::hash_map but it didn't seem to help.

I haven't dug in really deep yet to track down exactly whats going on yet. I will probably try and do that later tonight.

I am running Windows 7 x64 and using the project files generated from CMake 2.8.0.

Jeremy


On Sun, Jan 17, 2010 at 5:39 PM, Oleg <ode...@...> wrote:
Hi Jeremy,

I'm using the following versions of flex/bison:

 - flex,    GnuWin32 distribution, version 2.5.4
 - bison, GnuWin32 distribution, version 2.4.1

and having the same problems. I have simply commented out <unistd.h>
includes and compiled the corresponding files again. The another
problem is that this flex version cannot use slashes as path separator
for generated files, so I have replaced slashes by backslashes for
every flex file.

The "access" function is defined in "io.h" header file under Windows,
so I have changed the "oslquery.cpp" file as follows:

#ifdef __unix__
   #include <unistd.h>
   #define EXIST F_OK
   #define EXEC  X_OK
   #define WRITE W_OK
   #define READ  R_OK
#else
   #include <io.h>
   #define EXIST 00
   #define EXEC  01
   #define WRITE 02
   #define READ  04
#endif

The "hash_map" class is defined in "stdext" namespace under Windows/VS
2008. I think you can use it without SP1, but I'm not sure.

Regards,
Oleg


On 17 Jan., 22:52, wormszer <wo...@...> wrote:
> I too have been trying to build under windows and ran across the same
> problem with the t variable.
> Assuming gcc allows it for some reason, by default is_closure() is
> false so that is what i set it too.
>
> I am having trouble with some includes particulary
> #include <unistd.h>
>
> I have one error in oslquery a missing R_OK which is defined i believe
> through this file.
> I can dig it up and add it but I think i will run into more problems
> later on in the other projects.
>
> I am also getting a hash_map error when building oslcomp.
>
> What version of flex and bison are you using? I had found a gnuwin32
> builds of both but flex was pretty out of date.
> I have installed cygwin to use the latest versions from there to run
> flex and bison. Which generates files that have better includes
> <iostream> vs <iostream.h> etc.
>
> Hopefully we can get this figured out.
> I am using visual studio 2008 as well. I just realized i might not
> have sp1. I will update and see if that helps at all.
>
> Thanks
> Jeremy

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.





Re: Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Hi Jeremy,

I'm using the following versions of flex/bison:

- flex, GnuWin32 distribution, version 2.5.4
- bison, GnuWin32 distribution, version 2.4.1

and having the same problems. I have simply commented out <unistd.h>
includes and compiled the corresponding files again. The another
problem is that this flex version cannot use slashes as path separator
for generated files, so I have replaced slashes by backslashes for
every flex file.

The "access" function is defined in "io.h" header file under Windows,
so I have changed the "oslquery.cpp" file as follows:

#ifdef __unix__
#include <unistd.h>
#define EXIST F_OK
#define EXEC X_OK
#define WRITE W_OK
#define READ R_OK
#else
#include <io.h>
#define EXIST 00
#define EXEC 01
#define WRITE 02
#define READ 04
#endif

The "hash_map" class is defined in "stdext" namespace under Windows/VS
2008. I think you can use it without SP1, but I'm not sure.

Regards,
Oleg

On 17 Jan., 22:52, wormszer <wo...@...> wrote:
I too have been trying to build under windows and ran across the same
problem with the t variable.
Assuming gcc allows it for some reason, by default is_closure() is
false so that is what i set it too.

I am having trouble with some includes particulary
#include <unistd.h>

I have one error in oslquery a missing R_OK which is defined i believe
through this file.
I can dig it up and add it but I think i will run into more problems
later on in the other projects.

I am also getting a hash_map error when building oslcomp.

What version of flex and bison are you using? I had found a gnuwin32
builds of both but flex was pretty out of date.
I have installed cygwin to use the latest versions from there to run
flex and bison. Which generates files that have better includes
<iostream> vs <iostream.h> etc.

Hopefully we can get this figured out.
I am using visual studio 2008 as well. I just realized i might not
have sp1. I will update and see if that helps at all.

Thanks
Jeremy


Re: Compiling OpenShadingLanguage under Windows

wormszer <worm...@...>
 

I too have been trying to build under windows and ran across the same
problem with the t variable.
Assuming gcc allows it for some reason, by default is_closure() is
false so that is what i set it too.

I am having trouble with some includes particulary
#include <unistd.h>

I have one error in oslquery a missing R_OK which is defined i believe
through this file.
I can dig it up and add it but I think i will run into more problems
later on in the other projects.

I am also getting a hash_map error when building oslcomp.

What version of flex and bison are you using? I had found a gnuwin32
builds of both but flex was pretty out of date.
I have installed cygwin to use the latest versions from there to run
flex and bison. Which generates files that have better includes
<iostream> vs <iostream.h> etc.

Hopefully we can get this figured out.
I am using visual studio 2008 as well. I just realized i might not
have sp1. I will update and see if that helps at all.

Thanks
Jeremy

On Jan 17, 8:23 am, Oleg <od...@...> wrote:
Hi Chris,

Thank you very much for your reply. It works!

Here comes the next problem compiling the "osllex.cpp" file generated
by flex from "osllex.l" :-(

D:/Src/OpenShadingLanguage/src/liboslcomp/osllex.l(118) : error C2065:
'osllloc' : undeclared identifier

Here is the corresponding cpp code:

#define yylloc osllloc

void preprocess (const char *yytext);

// Macro that sets the yylloc line variables to the current parse
line.
#define SETLINE yylloc.first_line = yylloc.last_line = oslcompiler-

lineno()
And here is the lex code:

#define yylloc osllloc

void preprocess (const char *yytext);

// Macro that sets the yylloc line variables to the current parse
line.
#define SETLINE yylloc.first_line = yylloc.last_line = oslcompiler-

lineno()
%}

%%

 /************************************************
  * Lexical matching rules
  ************************************************/

 /* preprocessor symbols */
{CPP}                   {  preprocess (YYText()); SETLINE; }             //
<--- LINE 118


Realy funny jokes about director)

NormanKolins <hyep...@...>
 

aaa))))that is sooooo cool))thx) http://gwy.in/jokesoffice


Re: problem building on macos

Larry Gritz <l...@...>
 

I do a most of my day-to-day development on Snow Leopard, so I know this can be made to work.

Are you building OIIO by checking out the "external" project and trying to build the whole thing? If so, that may be more trouble than it's worth. The "external" project is not needed, it serves mainly to guarantee to be the same dependency versions among all developers, independent of anything else installed on the system, or for people who lack permissions to install the packages in the right places in their system.

I would get rid of the "external" project and just compile OIIO straight -- it will find the dependencies it needs in your system. The only ones it really needs in order to be useful for OSL are boost, libtiff, ilmbase, and openexr, and it's pretty easy to install those with Macports if you don't already have them on your system. (OIIO's build system will handle other missing dependencies by just not building the parts that need them -- typically plugins for other image formats, none of which are especially useful for OSL's texturing.)

Another alternative is to post to the OIIO list and attach the actual output. ("libtiff doesn't build" is a tad vague, maybe it's an easy fix we can suggest.)

-- lg


On Jan 16, 2010, at 11:49 PM, Nick Porcino wrote:

I'm having some difficulty building OpenImageIO on macos (Snow
Leopard), as a required pre-requisite for building OSL. The build of
the external packages fails because libtiff doesn't build. Everything
else does.

I simply did a clean pull from the repository and followed the
instructions (and I've built dozens of open source things before, so
the issue is not unfamiliarity with make systems or anything like
that).

I've done all the usual sorts of troubleshooting, but nothing strikes
me as obviously wrong with the set up. Before I dig in seriously to
work out why the build is failing, I thought I would potentially save
some time by asking here first if anyone has successfully built on
macos after a fresh pull of OIIO and OSL, and if not, what issues and
resolutions might have got things working.

Thanks
<ATT00001..txt>
--
Larry Gritz
l...@...


Re: Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Hi Chris,

Thank you very much for your reply. It works!

Here comes the next problem compiling the "osllex.cpp" file generated
by flex from "osllex.l" :-(

D:/Src/OpenShadingLanguage/src/liboslcomp/osllex.l(118) : error C2065:
'osllloc' : undeclared identifier



Here is the corresponding cpp code:

#define yylloc osllloc

void preprocess (const char *yytext);

// Macro that sets the yylloc line variables to the current parse
line.
#define SETLINE yylloc.first_line = yylloc.last_line = oslcompiler-
lineno()


And here is the lex code:

#define yylloc osllloc

void preprocess (const char *yytext);

// Macro that sets the yylloc line variables to the current parse
line.
#define SETLINE yylloc.first_line = yylloc.last_line = oslcompiler-
lineno()
%}


%%

/************************************************
* Lexical matching rules
************************************************/

/* preprocessor symbols */
{CPP} { preprocess (YYText()); SETLINE; } //
<--- LINE 118


problem building on macos

Nick Porcino <nick....@...>
 

I'm having some difficulty building OpenImageIO on macos (Snow
Leopard), as a required pre-requisite for building OSL. The build of
the external packages fails because libtiff doesn't build. Everything
else does.

I simply did a clean pull from the repository and followed the
instructions (and I've built dozens of open source things before, so
the issue is not unfamiliarity with make systems or anything like
that).

I've done all the usual sorts of troubleshooting, but nothing strikes
me as obviously wrong with the set up. Before I dig in seriously to
work out why the build is failing, I thought I would potentially save
some time by asking here first if anyone has successfully built on
macos after a fresh pull of OIIO and OSL, and if not, what issues and
resolutions might have got things working.

Thanks


Re: Compiling OpenShadingLanguage under Windows

Chris Foster <chri...@...>
 

On Sun, Jan 17, 2010 at 8:25 AM, Oleg <ode...@...> wrote:
| simple_typename IDENTIFIER arrayspec initializer_list
                {
                    TypeDesc simple = lextype ($1);
                    simple.arraylen = $3;
                    TypeSpec t (simple, t.is_closure
());                                        // <--- LINE 274
                    ASTvariable_declaration *var;
                    var = new ASTvariable_declaration (oslcompiler,
t,
                                     ustring ($2), $4, false,
                                     true /* ismeata */, false /
*output */,
                                     true /* initializer list */);
                    $$ = var;
                }
        ;

I'm not familiar with bison... Any help is welcome :-)
The chunk of code between the '{' and '}' is just C++ (mostly, except for the
$ markers of course). Looking at this, the line

TypeSpec t (simple, t.is_closure());

doesn't make any sense to me, since it appears to use t before it's constructed.
(Why does this even compile elsewhere? Maybe there's another variable t in the
scope?)

To me it seems this should be

TypeSpec t (simple, false);

since the metadata can never be a closure. I'm not an expert though (not by
any means!); does this sound right guys?

~Chris


Compiling OpenShadingLanguage under Windows

Oleg <ode...@...>
 

Hi All,

I'm trying to compile the OpenShadingLanguage library under Windows
using VisualStudio 2008. I was able to compile the following projects
so
far:
- oslquery
- oslinfo

There is a problem compiling the "oslgram.cpp" file generated by
bison.
The compiler complains that "TypeSpec" type used in "oslgram.y", line
274, is unknown:

Error 22 error C2065: 't' : undeclared identifier D:\Src
\OpenShadingLanguage\src\liboslcomp\oslgram.y 274

Error 23 error C2228: left of '.is_closure' must have class/
struct/union D:\Src\OpenShadingLanguage\src\liboslcomp\oslgram.y
274


Here is the corresponding code in "oslgram.y":

| simple_typename IDENTIFIER arrayspec initializer_list
{
TypeDesc simple = lextype ($1);
simple.arraylen = $3;
TypeSpec t (simple, t.is_closure
()); // <--- LINE 274
ASTvariable_declaration *var;
var = new ASTvariable_declaration (oslcompiler,
t,
ustring ($2), $4, false,
true /* ismeata */, false /
*output */,
true /* initializer list */);
$$ = var;
}
;

I'm not familiar with bison... Any help is welcome :-)

Regards,
Oleg


P.S.: It's great that Sony Pictures ImageWorks shares this technology!


Re: Review: fix derivatives of mod()

Chris Foster <chri...@...>
 

Hi guys,

On Sat, Jan 16, 2010 at 4:15 PM, Larry Gritz <l...@...> wrote:
Well, there's "math" and then there's "what's useful in shaders."  In the
strict mathematical sense, the derivative is undefined at the discontinuity
(x==d), though you could speak of the limit as you approach from x<d versus
x>d.  My guess is going to match at least one of those!  I'm not sure what we
can do that's any smarter or more useful in a case like this.
After quite some thought I agree that

d/dx mod(x,a) == 1

is about about the best you can do, even though it doesn't make sense at
the discontinuity.

It is possible to make sense of the derivative of mod() using the Dirac
delta distribution, but that's definitely a "math" thing rather than a
"what's useful in shaders" thing :-)


I had a think about alternatives, and ended up concluding that the only
other possiblity is analytical antialiasing of the derivative at the
discontinuity. However, that doesn't seem to be right because
1) It only makes sense when mod() is being used in certian ways for
pattern generation.
2) It means that mod needs to take derivatives of its arguments which
presumably makes things less efficient.
3) Surely if the derivative is being antialiased, the function value
itself should be?


That leads me to idly wonder if there's any call for an antialiased
version of mod (or more likely, floor(), since the user can then
trivially construct their own antialiased version of mod)? I notice
that you've included an aastep(), but that's arguably more useful than
aafloor() and easier to implement too...


By the way, I very much like what you're doing here with OSL. I think
the use of dual arithmetic for derivatives is particularly neat. I've
toyed with the idea before, but you guys have done all the hard work to
actually implement it, wow!

~Chris


Re: Review: fix derivatives of mod()

Jonathan Gibbs <jono...@...>
 

Well, there's "math" and then there's "what's useful in shaders."
Agreed. You answer seems the most useful one.

--jono


Re: Review: fix derivatives of mod()

Larry Gritz <l...@...>
 

On Jan 15, 2010, at 8:54 PM, Jonathan Gibbs wrote:
Well, I'm not sure what to think. The derivatives of mod(x,y) is the
same as x most of the time, but at the discontinuity? Not sure what
else you could really do since the function isn't continuous...

Well, there's "math" and then there's "what's useful in shaders." In the strict mathematical sense, the derivative is undefined at the discontinuity (x==d), though you could speak of the limit as you approach from x<d versus x>d. My guess is going to match at least one of those! I'm not sure what we can do that's any smarter or more useful in a case like this.

--
Larry Gritz
l...@...


Re: Review: fix derivatives of mod()

Jonathan Gibbs <jono...@...>
 

The mod() function was zeroing out derivs. I think it's pretty simple, mod(x,y)
has the same derivs as x, right?
Well, I'm not sure what to think. The derivatives of mod(x,y) is the
same as x most of the time, but at the discontinuity? Not sure what
else you could really do since the function isn't continuous...

--jono

On Fri, Jan 15, 2010 at 8:37 PM, Larry Gritz <l...@...> wrote:
Anybody?


On Jan 14, 2010, at 11:58 AM, Larry Gritz wrote:

http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.
--
Larry Gritz
l...@...





--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.



4941 - 4960 of 5003