ReZound

On Thu, 2003-08-28 at 06:56, guenter geiger wrote:
> 
> Hi there,
> 
> I am trying to compile rezound on alpha and ia64 machines,
> and I encounter the attached problem:
> 
ooo.. I would expect there to be problems :)  the warnings are certainly
because the pointers are 64bit and I'm casting to FXint (32bit int)

Big endian-ness on the alpha is going to be the biggest problem, I will
need to probably address this myself at some point.  At present I think
the endian conversions will be isolated really only in TPoolFile.cpp if
all the audio I/O libraries do the job themselves.


> (also see
> http://buildd.debian.org/build.php?&pkg=rezound&ver=0.8.3beta-2&arch=alpha&file=log)
> 
> 
> Any ideas how to fix this ?
> (until now I fixed that by calling the full constructor,but there
> must be a solution in istring itself ...)
> 

Hmm, well see I made istring have template constructors (really cute if
I do say so myself :)).  

What version of gcc was that using? (3.3.2?)

At least on the i86 platform I've been using so far with gcc-3.2.2 or
lesser I haven't had this issue.

I'm intending that the constructor on line istring:85 be called and it
choose false as the last parameter, but gcc is thinking that the 2 may
possibly be intended as a bool so it's saying that the constructor on
line 83 is also a candidate for being called. 

I'm not sure how familiar you are with template choice deduction, but
it's a beast.

To surely disambiguate the code, you could pass 'false' as a 4th
argument so it doesn't have to consider using the default value on that
parameter.  Then the number of arguments pass disqualifies the
constructor on line 83 as a candidate.

I would really only like that to be a temporary work-around.  Perhaps I
need to get gcc-3.3.2 (if that's infact the version having the trouble)
and see if I get the same issue.  Perhaps the gcc dev team 'fixed'
something with template deduction and it broke this.

Thanks, and wow, I did't know anyone was going to try to make this work
on a big endian platform yet.

I'm now working on LADSPA finally.. I'm fairly determined not to make
the next release until it's ready and useful.

-- Davy

> Greetings,
> Guenter
> 
> 
> alpha-linux-g++ -DHAVE_CONFIG_H -I. -I. -I../../config -I../../src/misc
> -I../../src/misc/missing/generated -I../../src/PoolFile -g -Wall
> -Wno-unused-function -Wno-unused-variable -Wno-unused -I/usr/include
> -I/usr/include -I/usr/include -MT CMainWindow.lo -MD -MP -MF
> .deps/CMainWindow.Tpo -c CMainWindow.cpp
> CMainWindow.cpp: In member function `long int
>    CMainWindow::onSoundListChange(FXObject*, unsigned int, void*)':
> CMainWindow.cpp:396: warning: cast from pointer to integer of different
> size
> CMainWindow.cpp: In member function `long int
>    CMainWindow::onSoundListHotKey(FXObject*, unsigned int, void*)':
> CMainWindow.cpp:438: warning: cast to pointer from integer of different
> size
> In file included from ../backend/Generate/GenerateActions.h:26,
>                  from CMainWindow.cpp:672:
> ../backend/Generate/CGenerateNoiseAction.h:56:26: warning: #warning this
> should be defined by the selection, or give the user a choice
> CMainWindow.cpp: In member function `long int
>    CMainWindow::onShuttleChange(FXObject*, unsigned int, void*)':
> CMainWindow.cpp:1337: error: call of overloaded `istring(float&, int,
> int)' is
>    ambiguous
> ../../src/misc/istring:85: error: candidates are: std::istring::istring(T,
> int,
>    long int, bool) [with T = float]
> ../../src/misc/istring:83: error:                 std::istring::istring(T,
> int,
>    bool) [with T = float]
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> -------------------------------------------------------
> ReZound-users mailing list
> ReZound-users@...
> Subscribe/Unsubscribe and change options
> https://lists.sourceforge.net/lists/listinfo/rezound-users
> ReZound-users mailing list archive
> http://sourceforge.net/mailarchive/forum.php?forum=rezound-users

Hi Davy,

On 28 Aug 2003, Davy Durham wrote:
> > I am trying to compile rezound on alpha and ia64 machines,
> > and I encounter the attached problem:
> >
> ooo.. I would expect there to be problems :)  the warnings are certainly
> because the pointers are 64bit and I'm casting to FXint (32bit int)
>
> Big endian-ness on the alpha is going to be the biggest problem, I will
> need to probably address this myself at some point.  At present I think
> the endian conversions will be isolated really only in TPoolFile.cpp if
> all the audio I/O libraries do the job themselves.

big endian-ness is not a problem (I think big-endian alpha machines are
basically non-existant  .. yes, the alpha can be both big-endian and
little).

I am compiling for PowerPC too, there we have to be careful. The problem
is that I am only compiling for these architectures, but I do not have
the possibilty to test yet.

> > (also see
> > http://buildd.debian.org/build.php?&pkg=rezound&ver=0.8.3beta-2&arch=alpha&file=log)
> >
> >
> > Any ideas how to fix this ?
> > (until now I fixed that by calling the full constructor,but there
> > must be a solution in istring itself ...)
> >
>
> Hmm, well see I made istring have template constructors (really cute if
> I do say so myself :)).
>
> What version of gcc was that using? (3.3.2?)

doesn't matter ... its a problem of sizes of integer types (64 vs. 32 bit)
see later ..

<snip>
> To surely disambiguate the code, you could pass 'false' as a 4th
> argument so it doesn't have to consider using the default value on that
> parameter.  Then the number of arguments pass disqualifies the
> constructor on line 83 as a candidate.

Thats what I have done so far (In already too many places, thats why I
was looking for a "better" solution).

> I would really only like that to be a temporary work-around.  Perhaps I
> need to get gcc-3.3.2 (if that's infact the version having the trouble)
> and see if I get the same issue.  Perhaps the gcc dev team 'fixed'
> something with template deduction and it broke this.
>

Further investigation revealed the problem:

template<class T> explicit istring(const T val,const int min_width,const
streamsize precision,const bool zero_pad=false)

streamsize seems to be a "long int", which means the compiler can not find
a perfect match on 64 bit architectures, because there,
long int = 64 bit
int = 32 bit
( ... the constructor gets called with an constant integer from different
places in the code)

Because of this it gets confused and doesn't know which of the two
constructors it should use.

If I change the prototype in istring to: (note the "int precision")

template<class T> explicit istring(const T val,const int min_width,const
int precision,const bool zero_pad=false)

then it works, and I do not have to change anything else in the code.


> I'm now working on LADSPA finally.. I'm fairly determined not to make
> the next release until it's ready and useful.

Thats good news :)

Thanks for your help with the problem,

Greetings,

Guenter


>
> -- Davy
>
> > Greetings,
> > Guenter
> >
> >
> > alpha-linux-g++ -DHAVE_CONFIG_H -I. -I. -I../../config -I../../src/misc
> > -I../../src/misc/missing/generated -I../../src/PoolFile -g -Wall
> > -Wno-unused-function -Wno-unused-variable -Wno-unused -I/usr/include
> > -I/usr/include -I/usr/include -MT CMainWindow.lo -MD -MP -MF
> > .deps/CMainWindow.Tpo -c CMainWindow.cpp
> > CMainWindow.cpp: In member function `long int
> >    CMainWindow::onSoundListChange(FXObject*, unsigned int, void*)':
> > CMainWindow.cpp:396: warning: cast from pointer to integer of different
> > size
> > CMainWindow.cpp: In member function `long int
> >    CMainWindow::onSoundListHotKey(FXObject*, unsigned int, void*)':
> > CMainWindow.cpp:438: warning: cast to pointer from integer of different
> > size
> > In file included from ../backend/Generate/GenerateActions.h:26,
> >                  from CMainWindow.cpp:672:
> > ../backend/Generate/CGenerateNoiseAction.h:56:26: warning: #warning this
> > should be defined by the selection, or give the user a choice
> > CMainWindow.cpp: In member function `long int
> >    CMainWindow::onShuttleChange(FXObject*, unsigned int, void*)':
> > CMainWindow.cpp:1337: error: call of overloaded `istring(float&, int,
> > int)' is
> >    ambiguous
> > ../../src/misc/istring:85: error: candidates are: std::istring::istring(T,
> > int,
> >    long int, bool) [with T = float]
> > ../../src/misc/istring:83: error:                 std::istring::istring(T,
> > int,
> >    bool) [with T = float]
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > -------------------------------------------------------
> > ReZound-users mailing list
> > ReZound-users@...
> > Subscribe/Unsubscribe and change options
> > https://lists.sourceforge.net/lists/listinfo/rezound-users
> > ReZound-users mailing list archive
> > http://sourceforge.net/mailarchive/forum.php?forum=rezound-users
>

On 4 Sep 2003, Davy Durham wrote:
> On Thu, 2003-09-04 at 05:21, guenter geiger wrote:
> > Hi Davy,
> >
>
> > big endian-ness is not a problem (I think big-endian alpha machines are
> > basically non-existant  .. yes, the alpha can be both big-endian and
> > little).
> >
> I thought Intel (and clones) was really the only manufacturer of little
> endian processors.. I thought alpha was NOT intel based. Is that a thing
> of the past?

:) You mean the alpha is a thing of the past ... that may well be :(
(Just joking ... I don't know, it seems that intel didn't have a patent on
little endianess)

<snip>
> > If I change the prototype in istring to: (note the "int precision")
> >
> > template<class T> explicit istring(const T val,const int min_width,const
> > int precision,const bool zero_pad=false)
> >
> > then it works, and I do not have to change anything else in the code.
> >
>
> Ah, ok.. that will be fine because I'm fairly confident that a range of
> -2^31 to 2^31-1 will be plenty for number formatting :)
>
> I'll make that change too in istring.

ok, great, this makes the next upgrade for  the Debian packaging a lot
easier.

>
> TPoolFile is the code that handles working files and the native .rez
> format.  I'm looking right now at what it will take to swap endian-ness
> of a .rez saved on the opposite endian platform.  I'm pretty sure that
> this is the only place that endian-ness will matter since libaudiofile
> (and the furture use of libsndfile) both support endian fixing.  I also
> assume that lame and libogg/vorbis will also return back native endian
> data.
>
> I chose in the beginning to save all configuration and presets data in
> text form, so that won't be a problem either.
>
> I *think* I can test things on sourceforge's big-endian compiler farm
> machines.  I just hope X11 gets forwarded properly.

Yeah, and if you can hear it :)

Greetings,

Guenter

On Thu, 2003-09-04 at 12:24, guenter geiger wrote:


> Yeah, and if you can hear it :)
> 

That won't be a problem.. I got GOOD ears. 

>^_^<

On Thu, 2003-09-04 at 05:21, guenter geiger wrote:
> Hi Davy,
> 

> big endian-ness is not a problem (I think big-endian alpha machines are
> basically non-existant  .. yes, the alpha can be both big-endian and
> little).
> 
I thought Intel (and clones) was really the only manufacturer of little
endian processors.. I thought alpha was NOT intel based. Is that a thing
of the past?

> I am compiling for PowerPC too, there we have to be careful. The problem
> is that I am only compiling for these architectures, but I do not have
> the possibilty to test yet.
> 
eek


> Further investigation revealed the problem:
> 
> template<class T> explicit istring(const T val,const int min_width,const
> streamsize precision,const bool zero_pad=false)
> 
> streamsize seems to be a "long int", which means the compiler can not find
> a perfect match on 64 bit architectures, because there,
> long int = 64 bit
> int = 32 bit
> ( ... the constructor gets called with an constant integer from different
> places in the code)
> 
> Because of this it gets confused and doesn't know which of the two
> constructors it should use.
> 
> If I change the prototype in istring to: (note the "int precision")
> 
> template<class T> explicit istring(const T val,const int min_width,const
> int precision,const bool zero_pad=false)
> 
> then it works, and I do not have to change anything else in the code.
> 

Ah, ok.. that will be fine because I'm fairly confident that a range of
-2^31 to 2^31-1 will be plenty for number formatting :)

I'll make that change too in istring.


TPoolFile is the code that handles working files and the native .rez
format.  I'm looking right now at what it will take to swap endian-ness
of a .rez saved on the opposite endian platform.  I'm pretty sure that
this is the only place that endian-ness will matter since libaudiofile
(and the furture use of libsndfile) both support endian fixing.  I also
assume that lame and libogg/vorbis will also return back native endian
data.

I chose in the beginning to save all configuration and presets data in
text form, so that won't be a problem either.

I *think* I can test things on sourceforge's big-endian compiler farm
machines.  I just hope X11 gets forwarded properly.


-- Davy