Date   

shadertypes

BaiLong <teneigh...@...>
 

Hi everyone,
I'm just a simpel student and totaly new to this stuff.
I read the specifications as soon as I could download it.
Hopefully I can make it to set up the developing environment soon,
because this stuff seems to be awesome! ;)

I hope it's ok if I post here such basic questions, because right now
there is not much help on this topic out there... ;)

The first question that puzzles me is the shadertypes.
Because in section 4. of the spec there are 4 - 5 types (depends if
you count the light shadertype).
But in the formal language Grammar section there are also imager and
integrator shaders listet.
I just try a shot in the dark and guess that the imager shader is
similar to the ones in RenderMan...
But what is an integrator? Is it an already included type or just a
reserved one for future use? If it already exists, what is it used
for?

Thanks for the help!

Cheers
--Markus


Re: Compiling OpenShadingLanguage under Windows

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

Sorry about joining this thread late.

I think that any files that need these functions should 

  #include <OpenImageIO/fmath.h>

where many of these symbols and some of the missing functions are defined.  See fmath.h circa line 70 for M_PI and the like, and circa line 690 for log2f.  If there are more missing functions, we should add them to fmath.h (inside the '#ifdef _WIN32' near where log2f is defined).

-- lg


On Jan 17, 2010, at 8:51 PM, Wormszer 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


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.






<ATT00001..htm>

--
Larry Gritz




Re: Arbitrary derivatives

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

Well put, a very concise explanation of the basic idea.

-- lg


On Jan 19, 2010, at 7:09 AM, Henri wrote:

No, it does automatic differentiation.

The overall idea is that if your inputs know their derivatives ( for
instance, when raytracing a primitive, computing P, dP/dx and dP/dy is
easy )
and your shading library know how to differentiate all its operators,
you are able to maintain derivatives quantities while shading.

Look at http://jgt.akpeters.com/papers/Piponi04/ for a complete
reference.


Hopes this helps

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


Re: Arbitrary derivatives

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

On Jan 19, 2010, at 12:52 AM, Bo Schwarzstein wrote:

Hello folks,

In specification, it sais "Arbitrary derivatives without grids or
extra shading points.", but I really confused how it works without
explicit grid. Does it like the GPU, compute the derivatives on screen
space ?

Thanks.

Let's separate the language specification, from the implementation in this library, from what a renderer is expected to do when using the OSL library.

The language spec just requires that an implementation can take derivatives of any quantity with respect to "x" and "y". The definitions of x,y are purposely undefined, they are allowed to be anything convenient to the renderer as long as they are roughly perpendicular and that x and/or y change by approximately 1 from pixel to pixel (so derivatives can be used to estimate filter sizes). Also, the language itself doesn't really care how Dx() and Dy() are implemented.

In the implementation of the OSL runtime library, we really wanted derivatives to work just as well for ray tracers that shade in arbitrary locations than for Reyes-like renderers that have grids. We chose to use a kind of "automatic differentiation" based on dual arithmetic that tracks the differentials correctly for every calculation (read Dan Piponi's paper from JGT 2004 for a good introduction), so then the implementation of Dx() and Dy() is simply looking up the x and y partials of the variable in question. The bottom line is that it does not require grids or extra shading points.

At SPI, our renderer is a pure ray tracer, so for us x and y are pixel coordinates and we use ray differentials when setting up shading batches (you need to pass things like dP/dx and dP/dy into OSL, then it handles all the rest).

If a Reyes-like renderer (shading on grids) wanted to use our OSL implementation, there's no reason why a shading batch couldn't be arranged in a rectilinear grid, and if they wanted their derivatives to be aligned to the grids, they could still pass the initial values using x==u*du and y==v*dv and mimic what would usually happen for Reyes (even though our library would not actually be differencing grid points to find the derivatives).

Similarly, a pure GPU-based implementation of OSL would be allowed to have x,y aligned to screen space and use the funny/awful "alternating forward and backward differences" that GPUs do naturally.

Does that all make sense?

(Aside: at this moment, we use the dual arithmetic for everything, leading to quite a bit of wasted math. Among other optimizations I'm currently working on is to use the dual arithmetic only for the subset of calculations that lead to expressions whose derivatives are actually used, this should eliminate most of the extra math, since so few derivatives are taken. I've done some experiments that indicate that we can save somewhere near 30% when this is done.)

-- lg

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


Re: Arbitrary derivatives

Henri <henri...@...>
 

On 19 jan, 09:52, Bo Schwarzstein <bo.sc...@...> wrote:
Hello folks,

In specification, it sais "Arbitrary derivatives without grids or
extra shading points.", but I really confused how it works without
explicit grid. Does it like the GPU, compute the derivatives on screen
space ?
No, it does automatic differentiation.

The overall idea is that if your inputs know their derivatives ( for
instance, when raytracing a primitive, computing P, dP/dx and dP/dy is
easy )
and your shading library know how to differentiate all its operators,
you are able to maintain derivatives quantities while shading.

Look at http://jgt.akpeters.com/papers/Piponi04/ for a complete
reference.


Hopes this helps

Henri


Thanks.


Arbitrary derivatives

Bo Schwarzstein <bo.schw...@...>
 

Hello folks,

In specification, it sais "Arbitrary derivatives without grids or
extra shading points.", but I really confused how it works without
explicit grid. Does it like the GPU, compute the derivatives on screen
space ?

Thanks.


Re: Compiling OpenShadingLanguage under Windows

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

You're quite right, Chris. I think this is just a bad cut-and-paste from the distant past and was never symptomatic, but definitely is wrong.

-- lg


On Jan 16, 2010, at 2:50 PM, Chris Foster wrote:
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?
--
Larry Gritz
l...@...


Re: Compiling OpenShadingLanguage under Windows

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

On Tue, Jan 19, 2010 at 2:48 PM, Wormszer <worm...@...> wrote:
For doing a gpu version of a shader this might work
A GPU only version is definitely interesting, but a very big job :)

but as a stand-in for
the C99 math i don't think it would be a good solution.
Heck no! Instead I imagine that most of the functions can be easily
implemented in terms of existing C89 functionality. For instance, AFAIK the
double version of log2 exists in C89, so

float log2f(float x) { return log2(x); }

even if I'm mistaken, natural log definitely exists, so you could use
something like

float log2f(float x)
{
// log2(x) = log(x)/log(2) ~= 1.4426950408889633 * log(x)
return 1.4426950408889633 * log(x);
}

~Chris.


Re: Review: fix derivatives of mod()

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

On Jan 16, 2010, at 2:07 PM, Chris Foster wrote:
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...
Oh yes, I've written AA'd versions of many of these at various times. "aastep" (aka "filterstep" in RMan-land) is there mostly for historical reasons. Other aa functions are a little trickier and tend to be in the private shader libraries of any decent shader department rather than making their way into the standard library, but there's no good reason for that.


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!
Thanks! I'd been wanting decent derivs of arbitrary calculations without needing grids or "extra points" (such as described in my JGT 1996 paper about BMRT), and had always hoped something like this approach would work. But I never worked out the details until now. It was nice to have Dan Piponi's paper "Automatic Differentiation, C++ Templates and Photogrammetry" (JGT, 2004) to point the way. Even as we were implementing it, I wasn't sure it was really going to work out, but it really does a quite satisfactory job.

By the way, after I wrote the Dual2<> template (based on Dan's paper) and the first few shadeops that used it, Cliff Stein implemented the bulk of the routines computing derivatives, and Chris Kulla went the extra mile of extending our noise routines and OIIO's texture lookups to *return* derivatives as well as values, when needed.

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


Re: Question about BSDFClosure functions

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

On Jan 15, 2010, at 8:55 AM, brecht wrote:

but looking at the source code
more closely, it's a weighted sum of different closures. That leaves
importance sampling and other things more to the rendering engine,
Yes, exactly.

but I guess
there's still closures written in OSL that could be used to get around
the limitation.
It's in the road map to eventually allow closure primitive functions and integrators to be written in OSL. But for now, both are built into the renderer.

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


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

4941 - 4960 of 5013