ltilib-devel Mailing List for LTI-Lib (C++ Computer Vision Library) (Page 8)
Status: Beta
Brought to you by:
alvarado
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(8) |
Feb
(13) |
Mar
(7) |
Apr
(2) |
May
(12) |
Jun
(3) |
Jul
(3) |
Aug
(30) |
Sep
(58) |
Oct
(1) |
Nov
|
Dec
(1) |
2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
(9) |
Mar
(6) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: <fab...@gm...> - 2005-12-13 21:26:01
|
Hi, New compiler output, with _CRT_SECURE_NO_DEPRECATE flag. Now, I got some (58) warnings about ISO C++ compliant functions, like: c:\arquivos de programas\ltilib\src\imgproc\ltiorientationmap.cpp(426) : warning C4996: 'hypot' was declared deprecated c:\arquivos de programas\microsoft visual studio 8\vc\include\math.h(455) : see declaration of 'hypot' Message: 'The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _hypot. See online help for details.' The output is attached. Thanks for a VS-based full working LTI-LIB! F=E1bio |
From: <fab...@gm...> - 2005-12-13 00:47:15
|
Hi, Warning: long mail! =3D] There are a few things which I should say... to give more detail about the compiling process, after checking out from CVS. 1- The .sln file generated by the script is not 'VS 8 compliant': >Trying to build debug version of ltilib for WIN32... >Microsoft (R) Visual Studio Version 8.0.50727.42. >Copyright (C) Microsoft Corp 1984-2005. All rights reserved. >Solution file 'C:\Arquivos de programas\ltilib\win\buildLib_net\ltilib.sln' is f >rom a previous version of Visual Studio and must be converted in order to = build >in this version of Visual Studio. To convert the solution, open the soluti= on in >this version of Visual Studio. >Error while building WIN32 Debug version!!! >Done. 2- I opened VS and converted it manually. The log shows: >Conversion Issues - ltilib.vcproj: >Visual C++ now supports a secure version of the C Runtime Library. Use of this library >is turned on by default. You may see some warnings about deprecated functions when >you build your project. It is advised that you correct these warnings, in order to make >your code more secure. >The C/C++ compiler default settings have been modified to be more compliant with ISO >Standard C++. Included in those changes are enforcing Standard C++ for loop scoping >and supporting wchar_t as a native type. These changes may cause existing code to no >longer compile without changes to the code or the compiler options with which it is built. >Project upgraded successfully. >Due to the requirement that Visual C++ projects produce an embedded (by default) >Windows SxS manifest, manifest files in the project are automatically excluded from >building with the Manifest Tool. It is recommended that the dependency information >contained in any manifest files be converted to "#pragma comment(linker,"<insert >dependency here>")" in a header file that is included from your source code. If your >project already embeds a manifest in the RT_MANIFEST resource section through a >resource (.rc) file, the line will need to be commented out before the project will build >correctly. >Due to a conformance change in the C++ compiler, code change may be required >before your project will build without errors. Previous versions of the C++ compiler >allowed specification of member function pointers by member function name (e.g. >MemberFunctionName). The C++ standard requires a fully qualified name with the use >of the address-of operator (e.g. &ClassName::MemberFunctionName). If your project >contains forms or controls used in the Windows Forms Designer, you may have to >change code in InitializeComponent because the designer generated code used the >non-conformant syntax in delegate construction (used in event handlers). 3- So, in the ltilib's project properties, for all configurations, I added "/D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1" In the "command line" subsection of C/C++ section. By the way, the compiler output suggests: Message: 'This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.' 4-Then I started a batch build for Win32 debug/release versions. Some files are in mac format, which generates an error. I opened this files, the VS converted them to windows, and I compiled again. List of "problem" files: (all with "lti" in the beginning and both .h e .cpp extensions) convolution dilation erosion correlation convolutionhelper kerneltype convolution_template dilation_template erosion_template correlation_template 5- The build had 228 warnings and no error. I'll compile it with _CRT_SECURE_NO_DEPRECATE to ignore deprecated errors, then I'll send the output too. The 'actual' build logs are attached. Thanks, and sorry for too much writing... =3D]~ F=E1bio |
From: <fab...@gm...> - 2005-12-12 14:05:55
|
Hi Peter, You are right. I didn't check the versions. I saw the update in the web-based cvs and downloaded it. I'm checking out again now. By the way, I updated my VS to the professional version (not beta), however, there is no difference so far. I'll send the compiler output as soon as I get it. Thanks F=E1bio On 12/12/05, Peter Doerfler <doe...@te...> wrote: > Hi F=E1bio. > > It looks like the errors are the same as before. Anon CVS is not updated = as > fast as one might wish at SF. E.g. ltiURL.cpp should have version number > 1.23. Could you please check that and if you don't have that version try > updating and compile again? > > Did you put the > /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 > into the options with this compilation? > If yes it doesn't really help much and we should probably do some > ltiWinConfig.h magic to get rid of the warnings. > Are these _s functions going to be standardized or is this just a M$ idea= ? > > Thanks, Peter > > On Saturday 10 December 2005 08:00, F=E1bio Dias wrote: > > I've just checked out from CVS and compiled. > > > > Attached are the compiler output. > > > > Thanks > > F=E1bio > > > > On 12/9/05, F=E1bio Dias <fab...@gm...> wrote: > > > Peter, > > > I should do this with the cvs version or the 'original' 1.9.15? > > > > > > F=E1bio > > > > > > On 12/9/05, Peter Doerfler <doe...@te...> wrote: > > > > Could you please try setting that flag instead of ignoring the warn= ing? > > > > I'd like to know the outcome of that. It seems like a cleaner solut= ion > > > > than ignoring. > > > > > > > > Thanks, Peter > > > > > > > > On Friday 09 December 2005 16:29, F=E1bio Dias wrote: > > > > > These "deprecated warnings" happened to me too. I only ignored > > > > > warnings C4996, because I always use this 'deprecated' functions. > > > > > > > > > > I'll get the CVS tomorrow. > > > > > > > > > > Thanks a lot > > > > > > > > > > F=E1bio > > > > > > > > > > On 12/9/05, Peter Doerfler <doe...@te...> wro= te: > > > > > > Hi F=E1bio. > > > > > > > > > > > > I've just committed some changes that might do the trick. > > > > > > > > > > > > The const char* thing is there because they changed the return = type > > > > > > of functions such as strstr(). This didn't really matter in the > > > > > > places where it was used. > > > > > > > > > > > > They also now got the 'pointer to member' stuff right, which is= why > > > > > > our .NET workaround for the 2003 bug borks. > > > > > > > > > > > > The bug in loadImageList was for real AFAICT: Shouldn't initial= ize > > > > > > an iterator with 0. > > > > > > > > > > > > Another user send me an email with loads of warnings about spri= ntf > > > > > > etc. being unsafe and to use sprintf_s instead. I read up on th= is > > > > > > and it seems the thing to do is > > > > > > /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 > > > > > > Is that what you did? > > > > > > > > > > > > The patched version should be in CVS by tomorrow sometime. It w= ould > > > > > > be great if you could check it. > > > > > > > > > > > > > > > > > > Thanks, Peter > > > > > > > > > > > > On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I was trying to use lti on VS 2005 beta 2, and I got a few > > > > > > > errors, like "const char *" cannot be converted to "char *", = and > > > > > > > so. > > > > > > > > > > > > > > If anyone wants to make lti compatible with VS 2005, probably > > > > > > > will want to look the attached files, logs of Win32 release a= nd > > > > > > > debug versions. And I can test the changes, if needed. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > F=E1bio Dias > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep throug= h > > > > > log files for problems? Stop! Download the new AJAX search engi= ne > > > > > that makes searching your log files as easy as surfing the web. > > > > > DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op= =3DClick > > > > > _______________________________________________ > > > > > Ltilib-devel mailing list > > > > > Lti...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/ltilib-devel > > |
From: Peter D. <doe...@te...> - 2005-12-12 12:37:53
|
Hi F=E1bio. It looks like the errors are the same as before. Anon CVS is not updated as= =20 fast as one might wish at SF. E.g. ltiURL.cpp should have version number=20 1.23. Could you please check that and if you don't have that version try=20 updating and compile again? Did you put the=20 /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 into the options with this compilation? If yes it doesn't really help much and we should probably do some=20 ltiWinConfig.h magic to get rid of the warnings. Are these _s functions going to be standardized or is this just a M$ idea? Thanks, Peter On Saturday 10 December 2005 08:00, F=E1bio Dias wrote: > I've just checked out from CVS and compiled. > > Attached are the compiler output. > > Thanks > F=E1bio > > On 12/9/05, F=E1bio Dias <fab...@gm...> wrote: > > Peter, > > I should do this with the cvs version or the 'original' 1.9.15? > > > > F=E1bio > > > > On 12/9/05, Peter Doerfler <doe...@te...> wrote: > > > Could you please try setting that flag instead of ignoring the warnin= g? > > > I'd like to know the outcome of that. It seems like a cleaner solution > > > than ignoring. > > > > > > Thanks, Peter > > > > > > On Friday 09 December 2005 16:29, F=E1bio Dias wrote: > > > > These "deprecated warnings" happened to me too. I only ignored > > > > warnings C4996, because I always use this 'deprecated' functions. > > > > > > > > I'll get the CVS tomorrow. > > > > > > > > Thanks a lot > > > > > > > > F=E1bio > > > > > > > > On 12/9/05, Peter Doerfler <doe...@te...> wrote: > > > > > Hi F=E1bio. > > > > > > > > > > I've just committed some changes that might do the trick. > > > > > > > > > > The const char* thing is there because they changed the return ty= pe > > > > > of functions such as strstr(). This didn't really matter in the > > > > > places where it was used. > > > > > > > > > > They also now got the 'pointer to member' stuff right, which is w= hy > > > > > our .NET workaround for the 2003 bug borks. > > > > > > > > > > The bug in loadImageList was for real AFAICT: Shouldn't initialize > > > > > an iterator with 0. > > > > > > > > > > Another user send me an email with loads of warnings about sprintf > > > > > etc. being unsafe and to use sprintf_s instead. I read up on this > > > > > and it seems the thing to do is > > > > > /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 > > > > > Is that what you did? > > > > > > > > > > The patched version should be in CVS by tomorrow sometime. It wou= ld > > > > > be great if you could check it. > > > > > > > > > > > > > > > Thanks, Peter > > > > > > > > > > On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > > > > > > Hi, > > > > > > > > > > > > I was trying to use lti on VS 2005 beta 2, and I got a few > > > > > > errors, like "const char *" cannot be converted to "char *", and > > > > > > so. > > > > > > > > > > > > If anyone wants to make lti compatible with VS 2005, probably > > > > > > will want to look the attached files, logs of Win32 release and > > > > > > debug versions. And I can test the changes, if needed. > > > > > > > > > > > > Thanks > > > > > > > > > > > > F=E1bio Dias > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through > > > > log files for problems? Stop! Download the new AJAX search engine > > > > that makes searching your log files as easy as surfing the web.=20 > > > > DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3D= Click > > > > _______________________________________________ > > > > Ltilib-devel mailing list > > > > Lti...@li... > > > > https://lists.sourceforge.net/lists/listinfo/ltilib-devel |
From: <fab...@gm...> - 2005-12-10 07:00:10
|
I've just checked out from CVS and compiled. Attached are the compiler output. Thanks F=E1bio On 12/9/05, F=E1bio Dias <fab...@gm...> wrote: > Peter, > I should do this with the cvs version or the 'original' 1.9.15? > > F=E1bio > > On 12/9/05, Peter Doerfler <doe...@te...> wrote: > > Could you please try setting that flag instead of ignoring the warning? > > I'd like to know the outcome of that. It seems like a cleaner solution = than > > ignoring. > > > > Thanks, Peter > > > > On Friday 09 December 2005 16:29, F=E1bio Dias wrote: > > > These "deprecated warnings" happened to me too. I only ignored > > > warnings C4996, because I always use this 'deprecated' functions. > > > > > > I'll get the CVS tomorrow. > > > > > > Thanks a lot > > > > > > F=E1bio > > > > > > On 12/9/05, Peter Doerfler <doe...@te...> wrote: > > > > Hi F=E1bio. > > > > > > > > I've just committed some changes that might do the trick. > > > > > > > > The const char* thing is there because they changed the return type= of > > > > functions such as strstr(). This didn't really matter in the places= where > > > > it was used. > > > > > > > > They also now got the 'pointer to member' stuff right, which is why= our > > > > .NET workaround for the 2003 bug borks. > > > > > > > > The bug in loadImageList was for real AFAICT: Shouldn't initialize = an > > > > iterator with 0. > > > > > > > > Another user send me an email with loads of warnings about sprintf = etc. > > > > being unsafe and to use sprintf_s instead. I read up on this and it= seems > > > > the thing to do is > > > > /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 > > > > Is that what you did? > > > > > > > > The patched version should be in CVS by tomorrow sometime. It would= be > > > > great if you could check it. > > > > > > > > > > > > Thanks, Peter > > > > > > > > On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > > > > > Hi, > > > > > > > > > > I was trying to use lti on VS 2005 beta 2, and I got a few errors= , > > > > > like "const char *" cannot be converted to "char *", and so. > > > > > > > > > > If anyone wants to make lti compatible with VS 2005, probably wil= l > > > > > want to look the attached files, logs of Win32 release and debug > > > > > versions. And I can test the changes, if needed. > > > > > > > > > > Thanks > > > > > > > > > > F=E1bio Dias > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through lo= g > > > files for problems? Stop! Download the new AJAX search engine that = makes > > > searching your log files as easy as surfing the web. DOWNLOAD SPLUN= K! > > > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3DClick > > > _______________________________________________ > > > Ltilib-devel mailing list > > > Lti...@li... > > > https://lists.sourceforge.net/lists/listinfo/ltilib-devel > > > > > |
From: <fab...@gm...> - 2005-12-10 00:35:57
|
Peter, I should do this with the cvs version or the 'original' 1.9.15? F=E1bio On 12/9/05, Peter Doerfler <doe...@te...> wrote: > Could you please try setting that flag instead of ignoring the warning? > I'd like to know the outcome of that. It seems like a cleaner solution th= an > ignoring. > > Thanks, Peter > > On Friday 09 December 2005 16:29, F=E1bio Dias wrote: > > These "deprecated warnings" happened to me too. I only ignored > > warnings C4996, because I always use this 'deprecated' functions. > > > > I'll get the CVS tomorrow. > > > > Thanks a lot > > > > F=E1bio > > > > On 12/9/05, Peter Doerfler <doe...@te...> wrote: > > > Hi F=E1bio. > > > > > > I've just committed some changes that might do the trick. > > > > > > The const char* thing is there because they changed the return type o= f > > > functions such as strstr(). This didn't really matter in the places w= here > > > it was used. > > > > > > They also now got the 'pointer to member' stuff right, which is why o= ur > > > .NET workaround for the 2003 bug borks. > > > > > > The bug in loadImageList was for real AFAICT: Shouldn't initialize an > > > iterator with 0. > > > > > > Another user send me an email with loads of warnings about sprintf et= c. > > > being unsafe and to use sprintf_s instead. I read up on this and it s= eems > > > the thing to do is > > > /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 > > > Is that what you did? > > > > > > The patched version should be in CVS by tomorrow sometime. It would b= e > > > great if you could check it. > > > > > > > > > Thanks, Peter > > > > > > On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > > > > Hi, > > > > > > > > I was trying to use lti on VS 2005 beta 2, and I got a few errors, > > > > like "const char *" cannot be converted to "char *", and so. > > > > > > > > If anyone wants to make lti compatible with VS 2005, probably will > > > > want to look the attached files, logs of Win32 release and debug > > > > versions. And I can test the changes, if needed. > > > > > > > > Thanks > > > > > > > > F=E1bio Dias > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files for problems? Stop! Download the new AJAX search engine that ma= kes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3DClick > > _______________________________________________ > > Ltilib-devel mailing list > > Lti...@li... > > https://lists.sourceforge.net/lists/listinfo/ltilib-devel > > |
From: Peter D. <doe...@te...> - 2005-12-09 15:43:38
|
Could you please try setting that flag instead of ignoring the warning? I'd like to know the outcome of that. It seems like a cleaner solution than= =20 ignoring. Thanks, Peter On Friday 09 December 2005 16:29, F=E1bio Dias wrote: > These "deprecated warnings" happened to me too. I only ignored > warnings C4996, because I always use this 'deprecated' functions. > > I'll get the CVS tomorrow. > > Thanks a lot > > F=E1bio > > On 12/9/05, Peter Doerfler <doe...@te...> wrote: > > Hi F=E1bio. > > > > I've just committed some changes that might do the trick. > > > > The const char* thing is there because they changed the return type of > > functions such as strstr(). This didn't really matter in the places whe= re > > it was used. > > > > They also now got the 'pointer to member' stuff right, which is why our > > .NET workaround for the 2003 bug borks. > > > > The bug in loadImageList was for real AFAICT: Shouldn't initialize an > > iterator with 0. > > > > Another user send me an email with loads of warnings about sprintf etc. > > being unsafe and to use sprintf_s instead. I read up on this and it see= ms > > the thing to do is > > /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 > > Is that what you did? > > > > The patched version should be in CVS by tomorrow sometime. It would be > > great if you could check it. > > > > > > Thanks, Peter > > > > On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > > > Hi, > > > > > > I was trying to use lti on VS 2005 beta 2, and I got a few errors, > > > like "const char *" cannot be converted to "char *", and so. > > > > > > If anyone wants to make lti compatible with VS 2005, probably will > > > want to look the attached files, logs of Win32 release and debug > > > versions. And I can test the changes, if needed. > > > > > > Thanks > > > > > > F=E1bio Dias > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3DClick > _______________________________________________ > Ltilib-devel mailing list > Lti...@li... > https://lists.sourceforge.net/lists/listinfo/ltilib-devel |
From: <fab...@gm...> - 2005-12-09 15:29:49
|
These "deprecated warnings" happened to me too. I only ignored warnings C4996, because I always use this 'deprecated' functions. I'll get the CVS tomorrow. Thanks a lot F=E1bio On 12/9/05, Peter Doerfler <doe...@te...> wrote: > Hi F=E1bio. > > I've just committed some changes that might do the trick. > > The const char* thing is there because they changed the return type of > functions such as strstr(). This didn't really matter in the places where= it > was used. > > They also now got the 'pointer to member' stuff right, which is why our .= NET > workaround for the 2003 bug borks. > > The bug in loadImageList was for real AFAICT: Shouldn't initialize an ite= rator > with 0. > > Another user send me an email with loads of warnings about sprintf etc. b= eing > unsafe and to use sprintf_s instead. I read up on this and it seems the t= hing > to do is > /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 > Is that what you did? > > The patched version should be in CVS by tomorrow sometime. It would be gr= eat > if you could check it. > > > Thanks, Peter > > > > On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > > Hi, > > > > I was trying to use lti on VS 2005 beta 2, and I got a few errors, > > like "const char *" cannot be converted to "char *", and so. > > > > If anyone wants to make lti compatible with VS 2005, probably will > > want to look the attached files, logs of Win32 release and debug > > versions. And I can test the changes, if needed. > > > > Thanks > > > > F=E1bio Dias > > |
From: Peter D. <doe...@te...> - 2005-12-09 15:14:40
|
Hi F=E1bio. I've just committed some changes that might do the trick.=20 The const char* thing is there because they changed the return type of=20 functions such as strstr(). This didn't really matter in the places where i= t=20 was used. They also now got the 'pointer to member' stuff right, which is why our .NE= T=20 workaround for the 2003 bug borks. The bug in loadImageList was for real AFAICT: Shouldn't initialize an itera= tor=20 with 0. Another user send me an email with loads of warnings about sprintf etc. bei= ng=20 unsafe and to use sprintf_s instead. I read up on this and it seems the thi= ng=20 to do is /D _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES=3D1 Is that what you did? The patched version should be in CVS by tomorrow sometime. It would be grea= t=20 if you could check it. Thanks, Peter On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > Hi, > > I was trying to use lti on VS 2005 beta 2, and I got a few errors, > like "const char *" cannot be converted to "char *", and so. > > If anyone wants to make lti compatible with VS 2005, probably will > want to look the attached files, logs of Win32 release and debug > versions. And I can test the changes, if needed. > > Thanks > > F=E1bio Dias |
From: Peter D. <doe...@te...> - 2005-12-09 09:49:46
|
Thanks Fabio. I've opened a bug report so we don't forget. I'll try to take care of this= =20 shortly, if nobody beats me to it. I'll send you a note when this is done so you can test. Thanks again, Peter On Thursday 08 December 2005 16:56, F=E1bio Dias wrote: > Hi, > > I was trying to use lti on VS 2005 beta 2, and I got a few errors, > like "const char *" cannot be converted to "char *", and so. > > If anyone wants to make lti compatible with VS 2005, probably will > want to look the attached files, logs of Win32 release and debug > versions. And I can test the changes, if needed. > > Thanks > > F=E1bio Dias |
From: <fab...@gm...> - 2005-12-08 15:57:01
|
Hi, I was trying to use lti on VS 2005 beta 2, and I got a few errors, like "const char *" cannot be converted to "char *", and so. If anyone wants to make lti compatible with VS 2005, probably will want to look the attached files, logs of Win32 release and debug versions. And I can test the changes, if needed. Thanks F=E1bio Dias |
From: Pablo A. <pal...@ie...> - 2005-11-23 16:48:49
|
Hello, I've just checked something else. There is a method "restoreOwnership()",= =20 which is the one really created for this purposes. I think the (ab)use of= =20 resize for this purpose should be avoided, and semantically use it just for= =20 real resize tasks. The change of ownership by resizing matrices that do no= t=20 own their data is a side-effect of the fact that it is not possible to know= =20 how otherwise the change of size should be done. Regards,=20 Pablo On Wednesday 23 November 2005 10:11 am, Peter Doerfler wrote: > Hi. > > On Wednesday 23 November 2005 15:58, Pablo Alvarado wrote: > > Hello all, > > > > Well, I'm guilty of all charges. While implementing the matrices and t= he > > vectors an their relationships obviously I leave some inconsistencies > > between documentation and implementation lying around... > > Well, and I should have thought a bit more about it before 'fixing' the > bug. > > > The way it was, (before Peter changed it) was the best compromise I > > found, but I forgot to change the docu (terrible sinn, but I'm not the > > only one > > > > :-P ). > > (1) > We could still take ownership if > ownsData =3D=3D false && constRef =3D=3D false > independent of newSize=3D=3DoldSize > > That would be closer to the current docu, indicating that taking ownership > is a feature and should be done whenever possible. > > > The resizing of a matrix or vector, which do not own its data, changed > > the memory allocantion and ownership if and only if the new size was > > different than the previous one. A resize had absolutelly no effect if > > the there was no resize in the terms that the new desired dimensions we= re > > already there. So, to restore ownership some tricks had to be done: li= ke > > a detach, or a resize but changing the size. I have in mind that an > > explicit method to restore ownership was also done, but, I don't rememb= er > > if it was for the LTI-Lib 1 or 2. > > > > Other methods would cause that most of the library wouldn't work, becau= se > > too much time would be required making unnecessary resizes; some"strict" > > on-place methods would change the memory used, etc. (I think this shou= ld > > be a major topic in the LTI-Lib-2: all on-place methods have to be stri= ct > > on-place (at least if the size of the result is correct, avoiding even > > the memory changes of the result container class! However, I know this > > is too much work and no one has the time.) > > Yes, that would make interfacing to other libraries much easier since no > copying would be involved e.g. for filtering. > > I already did something like this for transpose() if the area of the matr= ix > doesn't change, I think. > > > I believe with a consistent documentation the problem is solved, leaving > > it as it was before. > > (2) > In this case the documentation should read like > > \b Note that when the new size is different from the old size the > [vector,matrix] always owns the data after calling resize(). If the > [vector,matrix] alread has the correct size no action (besides filling if > necessary) is taken. > > that means taking ownership is more a side effect than an actual feature = of > resize() > > You are suggesting to do (2). I'm fine with that. I just want to point out > that (1) is another possibility we have. However, it would lead to unwant= ed > side effects for useExternData() stuff as destination which might work so= me > day far from now. > > If I don't hear anything to the contrary until tomorrow morning Aachen > time. I'll commit option (2) as of this mail. > > > Regards, > > > > Pablo > > Thanks, > Peter > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Ltilib-devel mailing list > Lti...@li... > https://lists.sourceforge.net/lists/listinfo/ltilib-devel =2D-=20 Dr. Pablo Alvarado E-Mail: pal...@ie... Escuela de Electr=F3nica Tel.: (+506) 550 2106 Instituto Tecnol=F3gico de Costa Rica Apartado Postal 159-7050 Cartago Costa Rica |
From: Peter D. <doe...@te...> - 2005-11-23 16:11:44
|
Hi. On Wednesday 23 November 2005 15:58, Pablo Alvarado wrote: > Hello all, > > Well, I'm guilty of all charges. While implementing the matrices and the > vectors an their relationships obviously I leave some inconsistencies > between documentation and implementation lying around... > Well, and I should have thought a bit more about it before 'fixing' the bug. > The way it was, (before Peter changed it) was the best compromise I found, > but I forgot to change the docu (terrible sinn, but I'm not the only one > :-P ). (1) We could still take ownership if ownsData == false && constRef == false independent of newSize==oldSize That would be closer to the current docu, indicating that taking ownership is a feature and should be done whenever possible. > > The resizing of a matrix or vector, which do not own its data, changed the > memory allocantion and ownership if and only if the new size was different > than the previous one. A resize had absolutelly no effect if the there was > no resize in the terms that the new desired dimensions were already there. > So, to restore ownership some tricks had to be done: like a detach, or a > resize but changing the size. I have in mind that an explicit method to > restore ownership was also done, but, I don't remember if it was for the > LTI-Lib 1 or 2. > > Other methods would cause that most of the library wouldn't work, because > too much time would be required making unnecessary resizes; some"strict" > on-place methods would change the memory used, etc. (I think this should > be a major topic in the LTI-Lib-2: all on-place methods have to be strict > on-place (at least if the size of the result is correct, avoiding even the > memory changes of the result container class! However, I know this is too > much work and no one has the time.) > Yes, that would make interfacing to other libraries much easier since no copying would be involved e.g. for filtering. I already did something like this for transpose() if the area of the matrix doesn't change, I think. > I believe with a consistent documentation the problem is solved, leaving it > as it was before. > (2) In this case the documentation should read like \b Note that when the new size is different from the old size the [vector,matrix] always owns the data after calling resize(). If the [vector,matrix] alread has the correct size no action (besides filling if necessary) is taken. that means taking ownership is more a side effect than an actual feature of resize() You are suggesting to do (2). I'm fine with that. I just want to point out that (1) is another possibility we have. However, it would lead to unwanted side effects for useExternData() stuff as destination which might work some day far from now. If I don't hear anything to the contrary until tomorrow morning Aachen time. I'll commit option (2) as of this mail. > Regards, > > Pablo Thanks, Peter |
From: Pablo A. <pal...@ie...> - 2005-11-23 14:58:07
|
Hello all, Well, I'm guilty of all charges. While implementing the matrices and the=20 vectors an their relationships obviously I leave some inconsistencies betwe= en=20 documentation and implementation lying around... The way it was, (before Peter changed it) was the best compromise I found, = but=20 I forgot to change the docu (terrible sinn, but I'm not the only one :-P ).= =20 The resizing of a matrix or vector, which do not own its data, changed the= =20 memory allocantion and ownership if and only if the new size was different= =20 than the previous one. A resize had absolutelly no effect if the there was= =20 no resize in the terms that the new desired dimensions were already there. = =20 So, to restore ownership some tricks had to be done: like a detach, or a=20 resize but changing the size. I have in mind that an explicit method to=20 restore ownership was also done, but, I don't remember if it was for the=20 LTI-Lib 1 or 2.=20 Other methods would cause that most of the library wouldn't work, because t= oo=20 much time would be required making unnecessary resizes; some"strict" on-pla= ce=20 methods would change the memory used, etc. (I think this should be a major= =20 topic in the LTI-Lib-2: all on-place methods have to be strict on-place (at= =20 least if the size of the result is correct, avoiding even the memory change= s=20 of the result container class! However, I know this is too much work and n= o=20 one has the time.) I believe with a consistent documentation the problem is solved, leaving it= as=20 it was before. Regards, Pablo =2D-=20 Dr. Pablo Alvarado E-Mail: pal...@ie... Escuela de Electr=F3nica Tel.: (+506) 550 2106 Instituto Tecnol=F3gico de Costa Rica Apartado Postal 159-7050 Cartago Costa Rica |
From: Peter D. <doe...@te...> - 2005-11-22 12:14:22
|
Hi. On Tuesday 22 November 2005 11:40, Claudia Goenner wrote: > Hi Peter, > > A note on (1): The problem does not only occur for constRef's. Such an > exeption is hard to understand and remember. Thus I don't like (1). Actually, I think it does. Working with externData as destination is clearly not supported right now because of other issues like the implementation of some onCopy applies. > > A note on (3): Fixing all the functor would be an option. But from a > user's perspective it does not make sense. Many programmers will forget > it to test it. Thus I don't like (3). I agree. > > I can live with (2). But we didn't specify the implications / side > effects. Resize does not know, when it may savely resize extern data > (e.g. user intent) and when this causes side effects. In your (modified) > matrix vector example resizing would be fatal. I would expect an error. Extern data may never be resized in the sense of changing the memory pointed to. And of course constRef vectors may never be resized in that sense. > > > matrix src, dest; > > //dest.resize(src.size); > > > for (i in rows of src) { > > myFunc.apply(src.getRow(i), dest.getRow(i)); > > } Not resizing dest is *always* a bug in this case! > > What do you think about this? > (4) Resize does not restore ownership. If the data is extern, resize > returns true if (oldSize==newSize) and announces an error otherwise > (either exception or return false). As a rule of thumb, we would > prohibit resizing of extern data. It is up to the application programmer > to ensure correct size before calling an apply with extern data. Unfortunately, I think at least Pablo used resize() precisely to claim ownership of data. Also if we implemented 4) there wouldn't be a way to do what it does now. Also, from a user's point of view, how often do you really check the return value of a member function. If we returned false as in 4) the crash would only be delayed until access of the not available memory. An exception would be doable. I wish we could fail at compile time for this, but we can't. I am more and more convinced that we should go with 2) and just change the docu to say that resize() ensures ownership iff oldsize != newsize. This would be in line with our design guideline that code should recover from user errors as much as possible. Let's wait what Pablo has to say about this. We need a fix until Thursday and a new Release on Friday. I suggest 1.9.15 instead of a bugfix number like 1.9.14.1 since this release will be shipped with the book and it doesn't look nice to have the only bugfix release on the CD. --Peter > > >>Now we can do three things: > >> > >>1) Make an exception from the ownership rule when the vector is a > >> constRef > >> > >>2) Say resize doesn't guarantee ownership > >> > >>3) Wait for the bugs to trickle in and fix all the wrong uses of resize() > >> > >>I prefer 1) but 3) would be ok. 2) doesn't seems to be a bad thing to do. > >>The reason I don't like 3) is that we're publishing a book with a version > >>of the LTI-Lib and I'd like to have as few bugreports on that as > >> possible. > >> > >>Thoughts? > > > >I'm starting to think that 2) might be not such a bad choice after all. > >Wouldn't that enable us also to have matrices/vectors that useExternData() > > as dest of a functor? > > > >Why does resize guarantee ownership. Wouldn't it suffice to say it claims > >ownership if it has to actually change the size? That would lead back to > > the implementation as it was before my last change. > > The former implementation made sense. Also it is a bit ugly. See my > comment above. > > Regards, > Claudia |
From: Claudia G. <go...@te...> - 2005-11-22 10:43:44
|
Hi Peter, A note on (1): The problem does not only occur for constRef's. Such an=20 exeption is hard to understand and remember. Thus I don't like (1). A note on (3): Fixing all the functor would be an option. But from a=20 user's perspective it does not make sense. Many programmers will forget=20 it to test it. Thus I don't like (3). I can live with (2). But we didn't specify the implications / side=20 effects. Resize does not know, when it may savely resize extern data=20 (e.g. user intent) and when this causes side effects. In your (modified) = matrix vector example resizing would be fatal. I would expect an error. > matrix src, dest; //dest.resize(src.size); > for (i in rows of src) { > myFunc.apply(src.getRow(i), dest.getRow(i)); > } What do you think about this? (4) Resize does not restore ownership. If the data is extern, resize=20 returns true if (oldSize=3D=3DnewSize) and announces an error otherwise=20 (either exception or return false). As a rule of thumb, we would=20 prohibit resizing of extern data. It is up to the application programmer = to ensure correct size before calling an apply with extern data. >> >>Now we can do three things: >> >>1) Make an exception from the ownership rule when the vector is a const= Ref >> >>2) Say resize doesn't guarantee ownership >> >>3) Wait for the bugs to trickle in and fix all the wrong uses of resize= () >> >>I prefer 1) but 3) would be ok. 2) doesn't seems to be a bad thing to d= o. >>The reason I don't like 3) is that we're publishing a book with a versi= on >>of the LTI-Lib and I'd like to have as few bugreports on that as possib= le. >> >>Thoughts? >> =20 >> > >I'm starting to think that 2) might be not such a bad choice after all. = >Wouldn't that enable us also to have matrices/vectors that useExternData= () as=20 >dest of a functor? > >Why does resize guarantee ownership. Wouldn't it suffice to say it claim= s=20 >ownership if it has to actually change the size? That would lead back to= the=20 >implementation as it was before my last change. > =20 > The former implementation made sense. Also it is a bit ugly. See my=20 comment above. Regards, Claudia --=20 _______________________________________________________________________ Dipl.-Inform. Claudia G=F6nner mailto:go...@te...= =20 Chair of Technical Computer Science Phone: +49 241 80-23633=20 Aachen University of Technology (RWTH) Fax : +49 241 80-22308=20 Ahornstr.55, 52074 Aachen, Germany http://www.techinfo.rwth-aachen.de _______________________________________________________________________ |
From: Peter D. <doe...@te...> - 2005-11-22 10:00:41
|
Hi again. Gave it some more thought. See below. On Monday 21 November 2005 17:55, Peter Doerfler wrote: > Hi all. > > I think we have a problem with the resize member function of > (generic)vector/matrix. > > In the docu it says that after a resize the data is owned. That makes > sense. > > The implication is that whenever data is not owned new memory is allocated. > Now an often used code snippet in the LTI-Lib would be > > matrix src, dest; > dest.resize(src.size); > for (i in rows of src) { > myFunc.apply(src.getRow(i), dest.getRow(i)); > } > > Unfortunately, or I should say understandably the first thing myFunc::apply > does is resize dest which must fail. > > Something similar just stopped RBF networks from working. The have a > calling sequence like that for l2Distance. > > Now we can do three things: > > 1) Make an exception from the ownership rule when the vector is a constRef > > 2) Say resize doesn't guarantee ownership > > 3) Wait for the bugs to trickle in and fix all the wrong uses of resize() > > I prefer 1) but 3) would be ok. 2) doesn't seems to be a bad thing to do. > The reason I don't like 3) is that we're publishing a book with a version > of the LTI-Lib and I'd like to have as few bugreports on that as possible. > > Thoughts? I'm starting to think that 2) might be not such a bad choice after all. Wouldn't that enable us also to have matrices/vectors that useExternData() as dest of a functor? Why does resize guarantee ownership. Wouldn't it suffice to say it claims ownership if it has to actually change the size? That would lead back to the implementation as it was before my last change. > > Thanks, Peter > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Ltilib-devel mailing list > Lti...@li... > https://lists.sourceforge.net/lists/listinfo/ltilib-devel |
From: Peter D. <doe...@te...> - 2005-11-22 09:57:09
|
Hi Claudia. On Monday 21 November 2005 18:17, Claudia Goenner wrote: > Hi Peter, > > I don't quite understand the problem. How does resize behave, when the > size is correct? Does it invalidate the data or return doing nothing? I > would expect it, to do nothing. Then your code snipplet would work fine > for all functors with src.size() = dest.size(). That is the scenario I > am using heavily. And I expect it to work that way in the future! > > Regards, > Claudia > Taking a look at the docu there is a comment that after resize the vector/matrix owns the data which means if it doesn't own the data, new memory is allocated even if the size was correct before. The implementation of that feature was buggy and I fixed it recently. Now the problem is that matrix::getRow() returns a vector that obviously doesn't own its data and also obviously is a constRef (i.e. can't change the allocated memory). This is where the conflict is. According to the documentation (at least AFAIU) you then must not apply resize to a vector obtained by matrix::getRow(). However, this is probably often done in the LTI-Lib. We need a solution to this urgently. See my other email for more comments on the solution. Best, Peter > Peter Doerfler wrote: > >Hi all. > > > >I think we have a problem with the resize member function of > >(generic)vector/matrix. > > > >In the docu it says that after a resize the data is owned. That makes > > sense. > > > >The implication is that whenever data is not owned new memory is > > allocated. Now an often used code snippet in the LTI-Lib would be > > > >matrix src, dest; > >dest.resize(src.size); > >for (i in rows of src) { > > myFunc.apply(src.getRow(i), dest.getRow(i)); > >} > > > >Unfortunately, or I should say understandably the first thing > > myFunc::apply does is resize dest which must fail. > > > >Something similar just stopped RBF networks from working. The have a > > calling sequence like that for l2Distance. > > > >Now we can do three things: > > > >1) Make an exception from the ownership rule when the vector is a constRef > > > >2) Say resize doesn't guarantee ownership > > > >3) Wait for the bugs to trickle in and fix all the wrong uses of resize() > > > >I prefer 1) but 3) would be ok. 2) doesn't seems to be a bad thing to do. > > The reason I don't like 3) is that we're publishing a book with a version > > of the LTI-Lib and I'd like to have as few bugreports on that as > > possible. > > > >Thoughts? > > > >Thanks, Peter > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > >Register for a JBoss Training Course. Free Certification Exam > >for All Training Attendees Through End of 2005. For more info visit: > >http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > >_______________________________________________ > >Ltilib-devel mailing list > >Lti...@li... > >https://lists.sourceforge.net/lists/listinfo/ltilib-devel |
From: Claudia G. <go...@te...> - 2005-11-21 17:17:35
|
Hi Peter, I don't quite understand the problem. How does resize behave, when the=20 size is correct? Does it invalidate the data or return doing nothing? I=20 would expect it, to do nothing. Then your code snipplet would work fine=20 for all functors with src.size() =3D dest.size(). That is the scenario I = am using heavily. And I expect it to work that way in the future! Regards, Claudia Peter Doerfler wrote: >Hi all. > >I think we have a problem with the resize member function of=20 >(generic)vector/matrix. > >In the docu it says that after a resize the data is owned. That makes se= nse. > >The implication is that whenever data is not owned new memory is allocat= ed.=20 >Now an often used code snippet in the LTI-Lib would be > >matrix src, dest; >dest.resize(src.size); >for (i in rows of src) { > myFunc.apply(src.getRow(i), dest.getRow(i)); >} > >Unfortunately, or I should say understandably the first thing myFunc::ap= ply=20 >does is resize dest which must fail. > >Something similar just stopped RBF networks from working. The have a cal= ling=20 >sequence like that for l2Distance. > >Now we can do three things: > >1) Make an exception from the ownership rule when the vector is a constR= ef > >2) Say resize doesn't guarantee ownership > >3) Wait for the bugs to trickle in and fix all the wrong uses of resize(= ) > >I prefer 1) but 3) would be ok. 2) doesn't seems to be a bad thing to do= =2E The=20 >reason I don't like 3) is that we're publishing a book with a version of= the=20 >LTI-Lib and I'd like to have as few bugreports on that as possible. > >Thoughts? > >Thanks, Peter > > > >------------------------------------------------------- >This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >Register for a JBoss Training Course. Free Certification Exam >for All Training Attendees Through End of 2005. For more info visit: >http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick >_______________________________________________ >Ltilib-devel mailing list >Lti...@li... >https://lists.sourceforge.net/lists/listinfo/ltilib-devel > > > =20 > --=20 _______________________________________________________________________ Dipl.-Inform. Claudia G=F6nner mailto:go...@te...= =20 Chair of Technical Computer Science Phone: +49 241 80-23633=20 Aachen University of Technology (RWTH) Fax : +49 241 80-22308=20 Ahornstr.55, 52074 Aachen, Germany http://www.techinfo.rwth-aachen.de _______________________________________________________________________ |
From: Peter D. <doe...@te...> - 2005-11-21 16:55:41
|
Hi all. I think we have a problem with the resize member function of (generic)vector/matrix. In the docu it says that after a resize the data is owned. That makes sense. The implication is that whenever data is not owned new memory is allocated. Now an often used code snippet in the LTI-Lib would be matrix src, dest; dest.resize(src.size); for (i in rows of src) { myFunc.apply(src.getRow(i), dest.getRow(i)); } Unfortunately, or I should say understandably the first thing myFunc::apply does is resize dest which must fail. Something similar just stopped RBF networks from working. The have a calling sequence like that for l2Distance. Now we can do three things: 1) Make an exception from the ownership rule when the vector is a constRef 2) Say resize doesn't guarantee ownership 3) Wait for the bugs to trickle in and fix all the wrong uses of resize() I prefer 1) but 3) would be ok. 2) doesn't seems to be a bad thing to do. The reason I don't like 3) is that we're publishing a book with a version of the LTI-Lib and I'd like to have as few bugreports on that as possible. Thoughts? Thanks, Peter |