dar-libdar_api — discussion area for developpers that want to use the libdar API

Re: [Dar-libdar_api] Problem building current SVN kdar against dar 2.3.3

[Adam W. <awi...@ma...>]

On Mon, 2007-06-18 at 20:58 +0200, Denis Corbin wrote:

> the missing operand is LIBDAR_MODE's value which is defined to an empty
> string. LIBDAR_MODE must either not be defined or be set to 64 or 32,
> either from CXXFLAGS and LDFLAGS if not using make from the compiler
> command-line.
> 
> example:
> export CXXFLAGS=-DLIBDAR_MODE=64
> export LDFLAGS=-DLIBDAR_MODE=64
> make
> 
> or
> g++ -DLIBDAR_MODE=64 ...

Just for interest, here's where kdar's broken...

#set the mode definition
    STRING(REGEX MATCH "[0-9][0-9]\\.so$" DAR_MODE ${DAR_LIBRARIES})
    STRING(REGEX REPLACE "\\.so$" "" DAR_MODE ${DAR_MODE})
    set(DAR_DEFINITIONS "-DLIBDAR_MODE=${DAR_MODE}")
    SET(DAR_LIB "-ldar${DAR_MODE}")

so it'll only work if the library files are called lib64dar.so.* or
lib32dar.so.* , if I'm reading it right. If the files are called
libdar.so.* (which is likely), it'll set the value to nothing...

That's in cmake/FindDar.cmake in kdar SVN.
-- 
adamw

Re: [Dar-libdar_api] Problem building current SVN kdar against dar 2.3.3

[Adam W. <awi...@ma...>]

On Mon, 2007-06-18 at 20:58 +0200, Denis Corbin wrote:

> the missing operand is LIBDAR_MODE's value which is defined to an empty
> string. LIBDAR_MODE must either not be defined or be set to 64 or 32,
> either from CXXFLAGS and LDFLAGS if not using make from the compiler
> command-line.
> 
> example:
> export CXXFLAGS=-DLIBDAR_MODE=64
> export LDFLAGS=-DLIBDAR_MODE=64
> make
> 
> or
> g++ -DLIBDAR_MODE=64 ...

Great, thanks, Denis. I guess it's a bug in kdar that its build process
doesn't set this value, but I can easily do it in the spec file instead.
Thanks again.
-- 
adamw

Re: [Dar-libdar_api] Problem building current SVN kdar against dar 2.3.3

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Adam Williamson a écrit :
> Hi, all. I am trying to build current SVN kdar for Mandriva. I know it's
> not much use currently, but at the moment we have a package that's
> entirely useless since it's built against libdar3, so anything would be
> an improvement.
> 
> Anyway, the build fails because of an apparent problem in a libdar
> header file. Does anyone know what the issue is here? Thanks!
> 
> [ 11%] Building CXX object
> src/kdar_part/CMakeFiles/kdarpart.dir/kdar_part.o
> /usr/bin/c++   -Dkdarpart_EXPORTS -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fomit-frame-pointer -march=i586 -mtune=generic
> -fasynchronous-unwind-tables  -Wnon-virtual-dtor -Wno-long-long -ansi
> -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
> -Wformat-security -fno-exceptions -fno-check-new -fno-common
> -fvisibility=hidden -O2 -g -fPIC
> -I/home/adamw/rpm/BUILD/kdar/build/src/kdar_part
> -I/home/adamw/rpm/BUILD/kdar/src/kdar_part -I/usr/lib/qt4/include
> -I/usr/lib/qt4/include/Qt -I/usr/lib/qt4/mkspecs/default
> -I/usr/lib/qt4/include/QtCore -I/usr/lib/qt4/include/QtGui
> -I/usr/lib/qt4/include/Qt3Support -I/usr/lib/qt4/include/QtAssistant
> -I/usr/lib/qt4/include/QtDesigner -I/usr/lib/qt4/include/QtNetwork
> -I/usr/lib/qt4/include/QtOpenGL -I/usr/lib/qt4/include/QtSql
> -I/usr/lib/qt4/include/QtXml -I/usr/lib/qt4/include/QtSvg
> -I/usr/lib/qt4/include/QtScript -I/usr/lib/qt4/include/QtUiTools
> -I/usr/lib/qt4/include/QtTest -I/usr/lib/qt4/include/QtDBus
> -I/opt/kde4/include -I/opt/kde4/include/KDE -I/usr/local/include
> -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_GNU_SOURCE
> -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS
> -fexceptions -DLIBDAR_MODE= -DVERSION=3.0 -DGCC_HASCLASSVISIBILITY
> -fvisibility=default -o
> src/kdar_part/CMakeFiles/kdarpart.dir/kdar_part.o
> -c /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp
> In file included from /usr/include/dar/compressor.hpp:32,
>                  from /usr/include/dar/libdar.hpp:63,
> 
> from /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdarbrowser.h:44,
> 
> from /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:22:
> /usr/include/dar/infinint.hpp:32:17: error: operator '==' has no left
> operand
> /usr/include/dar/infinint.hpp:37:17: error: operator '==' has no left
> operand

the missing operand is LIBDAR_MODE's value which is defined to an empty
string. LIBDAR_MODE must either not be defined or be set to 64 or 32,
either from CXXFLAGS and LDFLAGS if not using make from the compiler
command-line.

example:
export CXXFLAGS=-DLIBDAR_MODE=64
export LDFLAGS=-DLIBDAR_MODE=64
make

or
g++ -DLIBDAR_MODE=64 ...

Regards,
Denis.


> /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:246:6: warning:
> #warning TODO how should we set the cursor state? Which widgets will
> show the hourglass?
> /usr/include/dar/storage.hpp:67: error: expected ',' or '...' before '&'
> token
> /usr/include/dar/storage.hpp:70: error: expected ',' or '...' before '&'
> token
> /usr/include/dar/storage.hpp:89: error: declaration of 'operator[]' as
> non-function
> /usr/include/dar/storage.hpp:89: error: expected ';' before '(' token
> /usr/include/dar/storage.hpp:90: error: expected ',' or '...' before '&'
> token
> /usr/include/dar/storage.hpp:91: error: 'infinint' does not name a type
> /usr/include/dar/storage.hpp:119: error: 'infinint' has not been
> declared
> /usr/include/dar/storage.hpp:120: error: 'infinint' does not name a type
> /usr/include/dar/storage.hpp:174: error: 'infinint' has not been
> declared
> /usr/include/dar/storage.hpp:193: error: 'infinint' has not been
> declared
> /usr/include/dar/real_infinint.hpp: In member function 'libdar::infinint
> libdar::infinint::get_storage_size() const':
> /usr/include/dar/real_infinint.hpp:121: error: 'class libdar::storage'
> has no member named 'size'
> /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp: At global scope:
> /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:566: warning:
> unused parameter 'archiveName'
> /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:574: warning:
> unused parameter 'archiveName'
> make[2]: *** [src/kdar_part/CMakeFiles/kdarpart.dir/kdar_part.o] Error 1
> make[2]: Leaving directory `/home/adamw/rpm/BUILD/kdar/build'
> make[1]: *** [src/kdar_part/CMakeFiles/kdarpart.dir/all] Error 2
> make[1]: Leaving directory `/home/adamw/rpm/BUILD/kdar/build'
> make: *** [all] Error 2
> error: Bad exit status from /home/adamw/rpm/tmp/rpm-tmp.88093 (%build)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGdtXZpC5CI8gYGlIRAqJGAKDHEJsSexITdNiuouejFoU5LTI8IQCfVR8Y
cE6i+UBqB7IywEpaZ00wmsc=
=OrSu
-----END PGP SIGNATURE-----

[Dar-libdar_api] Problem building current SVN kdar against dar 2.3.3

[Adam W. <awi...@ma...>]

Hi, all. I am trying to build current SVN kdar for Mandriva. I know it's
not much use currently, but at the moment we have a package that's
entirely useless since it's built against libdar3, so anything would be
an improvement.

Anyway, the build fails because of an apparent problem in a libdar
header file. Does anyone know what the issue is here? Thanks!

[ 11%] Building CXX object
src/kdar_part/CMakeFiles/kdarpart.dir/kdar_part.o
/usr/bin/c++   -Dkdarpart_EXPORTS -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fomit-frame-pointer -march=i586 -mtune=generic
-fasynchronous-unwind-tables  -Wnon-virtual-dtor -Wno-long-long -ansi
-Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
-Wformat-security -fno-exceptions -fno-check-new -fno-common
-fvisibility=hidden -O2 -g -fPIC
-I/home/adamw/rpm/BUILD/kdar/build/src/kdar_part
-I/home/adamw/rpm/BUILD/kdar/src/kdar_part -I/usr/lib/qt4/include
-I/usr/lib/qt4/include/Qt -I/usr/lib/qt4/mkspecs/default
-I/usr/lib/qt4/include/QtCore -I/usr/lib/qt4/include/QtGui
-I/usr/lib/qt4/include/Qt3Support -I/usr/lib/qt4/include/QtAssistant
-I/usr/lib/qt4/include/QtDesigner -I/usr/lib/qt4/include/QtNetwork
-I/usr/lib/qt4/include/QtOpenGL -I/usr/lib/qt4/include/QtSql
-I/usr/lib/qt4/include/QtXml -I/usr/lib/qt4/include/QtSvg
-I/usr/lib/qt4/include/QtScript -I/usr/lib/qt4/include/QtUiTools
-I/usr/lib/qt4/include/QtTest -I/usr/lib/qt4/include/QtDBus
-I/opt/kde4/include -I/opt/kde4/include/KDE -I/usr/local/include
-D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_GNU_SOURCE
-DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS
-fexceptions -DLIBDAR_MODE= -DVERSION=3.0 -DGCC_HASCLASSVISIBILITY
-fvisibility=default -o
src/kdar_part/CMakeFiles/kdarpart.dir/kdar_part.o
-c /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp
In file included from /usr/include/dar/compressor.hpp:32,
                 from /usr/include/dar/libdar.hpp:63,

from /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdarbrowser.h:44,

from /home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:22:
/usr/include/dar/infinint.hpp:32:17: error: operator '==' has no left
operand
/usr/include/dar/infinint.hpp:37:17: error: operator '==' has no left
operand
/home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:246:6: warning:
#warning TODO how should we set the cursor state? Which widgets will
show the hourglass?
/usr/include/dar/storage.hpp:67: error: expected ',' or '...' before '&'
token
/usr/include/dar/storage.hpp:70: error: expected ',' or '...' before '&'
token
/usr/include/dar/storage.hpp:89: error: declaration of 'operator[]' as
non-function
/usr/include/dar/storage.hpp:89: error: expected ';' before '(' token
/usr/include/dar/storage.hpp:90: error: expected ',' or '...' before '&'
token
/usr/include/dar/storage.hpp:91: error: 'infinint' does not name a type
/usr/include/dar/storage.hpp:119: error: 'infinint' has not been
declared
/usr/include/dar/storage.hpp:120: error: 'infinint' does not name a type
/usr/include/dar/storage.hpp:174: error: 'infinint' has not been
declared
/usr/include/dar/storage.hpp:193: error: 'infinint' has not been
declared
/usr/include/dar/real_infinint.hpp: In member function 'libdar::infinint
libdar::infinint::get_storage_size() const':
/usr/include/dar/real_infinint.hpp:121: error: 'class libdar::storage'
has no member named 'size'
/home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp: At global scope:
/home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:566: warning:
unused parameter 'archiveName'
/home/adamw/rpm/BUILD/kdar/src/kdar_part/kdar_part.cpp:574: warning:
unused parameter 'archiveName'
make[2]: *** [src/kdar_part/CMakeFiles/kdarpart.dir/kdar_part.o] Error 1
make[2]: Leaving directory `/home/adamw/rpm/BUILD/kdar/build'
make[1]: *** [src/kdar_part/CMakeFiles/kdarpart.dir/all] Error 2
make[1]: Leaving directory `/home/adamw/rpm/BUILD/kdar/build'
make: *** [all] Error 2
error: Bad exit status from /home/adamw/rpm/tmp/rpm-tmp.88093 (%build)
-- 
adamw

Re: [Dar-libdar_api] Empty option for testing archives

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote:
> Hi Denis,

Hello Johnathan,

> 
>> the archive pointed to by 'a' is passed to both threads thus the same
>> variable is modified by both threads at the same time. Morevoer, the
>> archive::op_test method() is not a constant method, but OK, I am not
>> sure that all const methods of the API can be used without mutex by
>> different threads on the same object at the same time. I will double
>> check this right now.
>>
>> To solve your problem I would create two archive objects (yes, memory
>> will suffer) or avoid using concurrent thread here.
> 
> Is it possible to get a copy constructor for archive::archive?

it should be possible, however it will duplicate the catalogue inside
the archive, this double the memory requirements. However, as the
archive contains references to the slicing/compression/encryption layers
on disk theses could not be copied without raising concurrent I/O access
to the archive layout on disk.

> Better still, 
> would it be possible to have an "archive archive::isolate()" function to 
> obtain a copy of an isolated archive without writing it to disk?

Here the problem is that an archive object holds references to the file
layout (slicing/compression/encryption...) which exist even withing
isolated catalogue. Well, I must double check but it should be possible
to have this operation on a pure memory object (file layout pointing to
a 'null' generic_file object, class that already exist).

> That would 
> give an opportunity to run empty methods on a small copy of the archive in a 
> concurrent thread.

the fact that the archive is isolated will not make the copy smaller:
The archive object is all tha in memory part of an archive. There is no
significative difference of size between an archive object and its
isolated archive object counterpart.

Maybe it would be interesting to start from the need to see if there is
some other ways (simpler or more intersting --- from the libdar inside
point of view) to address this need.

> 
>> Regards,
>> Denis.
> 
> Cheers,
> JB
> 

Regards,
Denis.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGWbcEpC5CI8gYGlIRAmolAJ44xloLXxDiajVDumcyI/kaE17w9QCeNgjW
fDJM/XtMGaYd9lxDxWHG0w8=
=HhgY
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] Empty option for testing archives

[Johnathan B. <jk...@ro...>]

Hi Denis,

>
> the archive pointed to by 'a' is passed to both threads thus the same
> variable is modified by both threads at the same time. Morevoer, the
> archive::op_test method() is not a constant method, but OK, I am not
> sure that all const methods of the API can be used without mutex by
> different threads on the same object at the same time. I will double
> check this right now.
>
> To solve your problem I would create two archive objects (yes, memory
> will suffer) or avoid using concurrent thread here.

Is it possible to get a copy constructor for archive::archive? Better still, 
would it be possible to have an "archive archive::isolate()" function to 
obtain a copy of an isolated archive without writing it to disk? That would 
give an opportunity to run empty methods on a small copy of the archive in a 
concurrent thread.

> Regards,
> Denis.

Cheers,
JB

Re: [Dar-libdar_api] more stability on libdar API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Jacob a wrote
> Quite a lot of new lines of code there ;-)

yep, a lot of new lines, a bit painful, but necessary. :-)

> 
> But I see that you "only" modified the external interfacing
> layer of the libdar/* stuff, which is probably enough
> to limit upgrading hassles for code that links against libdar,
> but people that want to hack the code (i.e. me ;-) still have
> a lot of option passing to do when they want to do
> things in the depth of dar... So: any plans to propagate
> those changes further?

It will depend on the feasability. For example some internal routing
like archive::op_create_in_sub are used by archive creation, isolation
and merging. Theses three operations do not have exactly the same set of
options, thus the extension to the options classes deeper in libdar's
code may raise some problem, problem that will be addresses on a case by
case basis.

The first an main objective was to let external aplication live their
lives while new features get added. This is now achieved for all that
concern dar's features. For dar_manager, this will be done later if new
feature have to be added.

I guess that when new features will get added, I will extend the class
options more deeply inside libdar (like filter.cpp and archive class sub
routines), because I also find fastidious to modify that many headers
when adding just a single new argument...

> 
> To illustrate, in order to add a new option that basically extends
> dar by "remote-control-by-pipe-over-stdin/stderr"-mechanism, I had
> to change 24 hpp/cpp files (+4 new ones), with maybe 6 where anything "functional"
> happens and 11 of where I just added a new
> parameter to member functions that hand this parameter down
> to another layer (I can mail you a patch agains 2.3.3 if you are interested
> in more details).

I guess you rather can let this patch available publicly in the patch
tracker on sourceforge(
https://sourceforge.net/tracker/?group_id=65612&atid=511614 ). It may
also be interesting for other people than just me.

I guess that when new features will get added, I will extend the class
options more deeply inside libdar (like filter.cpp and archive class sub
routines), because I also find fastidious to modify that many headers
when adding just a single new argument...



> 
> If you had just one option class instance, that you could hand
> down all over the place (for instance making it a parameter
> in any class constructor of notice), one would
> just have to change the option parsing in dar_suite/* and
> the precise code that does something "real" in libdar/* to add new
> features.

Well, I thought about having a more hierarchically set of classes to
handle options, but I also considered the user point of view. Providing
a single class let the API user easily get the set of options available
for a given operation without having to look for parent classes, or
checking whether an options from a single global class is available for
a particular operation.

This also bring independency between the different operations when
adding new feature.

> 
> Of course, this might all a bit much to ask to implement, since
> that would mean changing even larger parts of the libdar code... hmm... just
> a random thought really...-

Last point is that I know dar's implementation is not that perfect (even
if it is far from being the last of my concerns), there is still some
point that can be made better in regard to readability, efficiency,
state of the art, 'beauty' of the ideas. When dar will get stable (i.e.:
when nobody will request new features) I think I will consider this
aspect more globally in this application ;-)
In the meanwhile, I have plenty of interesting features to add! Note
that I try as much as possible to keep the source 'open', by 'open' I
mean that I spend the necessary effort when implementing a new feature
to keep other potential future features still be possible to implement
nicely and efficiency.

> 
>      Regards,
>            Thomas
> 
>

Thanks for feedback!

Regards,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGVs4HpC5CI8gYGlIRAjzsAKCt6YeHTePlrLG2KyWwDxZyv+y5JQCgjugA
XV2UsZuI1AWyT7LYy+gkSSQ=
=GKsg
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] more stability on libdar API

[Thomas J. <ja...@in...>]

Quite a lot of new lines of code there ;-)

But I see that you "only" modified the external interfacing
layer of the libdar/* stuff, which is probably enough
to limit upgrading hassles for code that links against libdar,
but people that want to hack the code (i.e. me ;-) still have
a lot of option passing to do when they want to do
things in the depth of dar... So: any plans to propagate
those changes further?

To illustrate, in order to add a new option that basically extends
dar by "remote-control-by-pipe-over-stdin/stderr"-mechanism, I had
to change 24 hpp/cpp files (+4 new ones), with maybe 6 where anything "func=
tional"
happens and 11 of where I just added a new
parameter to member functions that hand this parameter down
to another layer (I can mail you a patch agains 2.3.3 if you are interested
in more details).

If you had just one option class instance, that you could hand
down all over the place (for instance making it a parameter
in any class constructor of notice), one would
just have to change the option parsing in dar_suite/* and
the precise code that does something "real" in libdar/* to add new
features.

Of course, this might all a bit much to ask to implement, since
that would mean changing even larger parts of the libdar code... hmm... just
a random thought really...-

     Regards,
           Thomas


On Thu, May 24, 2007 at 09:48:48PM +0200, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hello,
>=20
> CVS is up to date with new API. Tutorial has also been updated.
>=20
> Regards,
> Denis.
>=20
>=20
> Denis Corbin wrote:
> > Hello Johnathan, Hello Thomas,
> >=20
> > Thanks for your feedback. I have thus started moving archive's options
> > in several classes. It is not yet in CVS as it is not yet completed, but
> > seen the impact on the command-line tools, as Thomas said, it already
> > greatly improved readability!
> >=20
> > Kind Regards,
> > Denis.
> >=20
> > Denis Corbin wrote:
> >> Hi,
> >=20
> >> For almost each added feature, I have to add new parameter(s) to the
> >> archive class's constructors or methods. This is annoying for all
> >> software that rely on libdar (dar command line programs, kdar, etc.).
> >=20
> >> This break ascendant compatibility at each major release, which implies
> >> some work for each libdar dependent software.
> >=20
> >> I would like you to get your feedback about the following idea to solve
> >> this problem:
> >=20
> >> The idea is very simple, replace the plethora of *optional* arguments
> >> found in constructor and archive::op_* methods by a single one which t=
ype
> >> is a class, class which name would be isolate_option, create_option,
> >> extract_option, and so on.
> >=20
> >> All theses class would have a default constructor (with no argument),
> >> along with a list of methods to set the different options (slicing,
> >> encryption, compression, etc.). then, as new feature get added, a new
> >> method of in theses option classes would be added. Not using this new
> >> method would only let libdar behaves with default value for this new o=
ption.
> >=20
> >> Old software would continue to work with new libdar API and less work
> >> would have to be done for libdar dependent software. Using a new featu=
re
> >> by libdar dependent programs could be done asynchronously from libdar's
> >> release, this brings more freedom for anyone around libdar's API.
> >=20
> >> Thanks in advance for feedback,
> >=20
> >> Regards,
> >> Denis.
> >=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>=20
> iD8DBQFGVewgpC5CI8gYGlIRAlLCAJ93UxgnSbyDngS4aZAtYgp6ou6rkwCfaJcp
> 8WmzYJNu6c0r9yXp+ubLjpk=3D
> =3D5jP9
> -----END PGP SIGNATURE-----
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

Re: [Dar-libdar_api] more stability on libdar API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

CVS is up to date with new API. Tutorial has also been updated.

Regards,
Denis.


Denis Corbin wrote:
> Hello Johnathan, Hello Thomas,
> 
> Thanks for your feedback. I have thus started moving archive's options
> in several classes. It is not yet in CVS as it is not yet completed, but
> seen the impact on the command-line tools, as Thomas said, it already
> greatly improved readability!
> 
> Kind Regards,
> Denis.
> 
> Denis Corbin wrote:
>> Hi,
> 
>> For almost each added feature, I have to add new parameter(s) to the
>> archive class's constructors or methods. This is annoying for all
>> software that rely on libdar (dar command line programs, kdar, etc.).
> 
>> This break ascendant compatibility at each major release, which implies
>> some work for each libdar dependent software.
> 
>> I would like you to get your feedback about the following idea to solve
>> this problem:
> 
>> The idea is very simple, replace the plethora of *optional* arguments
>> found in constructor and archive::op_* methods by a single one which type
>> is a class, class which name would be isolate_option, create_option,
>> extract_option, and so on.
> 
>> All theses class would have a default constructor (with no argument),
>> along with a list of methods to set the different options (slicing,
>> encryption, compression, etc.). then, as new feature get added, a new
>> method of in theses option classes would be added. Not using this new
>> method would only let libdar behaves with default value for this new option.
> 
>> Old software would continue to work with new libdar API and less work
>> would have to be done for libdar dependent software. Using a new feature
>> by libdar dependent programs could be done asynchronously from libdar's
>> release, this brings more freedom for anyone around libdar's API.
> 
>> Thanks in advance for feedback,
> 
>> Regards,
>> Denis.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGVewgpC5CI8gYGlIRAlLCAJ93UxgnSbyDngS4aZAtYgp6ou6rkwCfaJcp
8WmzYJNu6c0r9yXp+ubLjpk=
=5jP9
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] more stability on libdar API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Johnathan, Hello Thomas,

Thanks for your feedback. I have thus started moving archive's options
in several classes. It is not yet in CVS as it is not yet completed, but
seen the impact on the command-line tools, as Thomas said, it already
greatly improved readability!

Kind Regards,
Denis.

Denis Corbin wrote:
> Hi,
> 
> For almost each added feature, I have to add new parameter(s) to the
> archive class's constructors or methods. This is annoying for all
> software that rely on libdar (dar command line programs, kdar, etc.).
> 
> This break ascendant compatibility at each major release, which implies
> some work for each libdar dependent software.
> 
> I would like you to get your feedback about the following idea to solve
> this problem:
> 
> The idea is very simple, replace the plethora of *optional* arguments
> found in constructor and archive::op_* methods by a single one which type
> is a class, class which name would be isolate_option, create_option,
> extract_option, and so on.
> 
> All theses class would have a default constructor (with no argument),
> along with a list of methods to set the different options (slicing,
> encryption, compression, etc.). then, as new feature get added, a new
> method of in theses option classes would be added. Not using this new
> method would only let libdar behaves with default value for this new option.
> 
> Old software would continue to work with new libdar API and less work
> would have to be done for libdar dependent software. Using a new feature
> by libdar dependent programs could be done asynchronously from libdar's
> release, this brings more freedom for anyone around libdar's API.
> 
> Thanks in advance for feedback,
> 
> Regards,
> Denis.

- -------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Dar-libdar_api mailing list
Dar...@li...
https://lists.sourceforge.net/lists/listinfo/dar-libdar_api



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUdlapC5CI8gYGlIRAlaYAJ4z8vXV6AsxG8eKFjDAqO4Bkh9lkACfaeO5
GzBRXvrlMlhjHmrCFCqbcow=
=cWbM
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] more stability on libdar API

[Johnathan B. <jk...@ro...>]

Hi Denis,

On Friday 18 May 2007 6:24 am, Denis Corbin wrote:
> Hi,
>
> For almost each added feature, I have to add new parameter(s) to the
> archive class's constructors or methods. This is annoying for all
> software that rely on libdar (dar command line programs, kdar, etc.).
>
> This break ascendant compatibility at each major release, which implies
> some work for each libdar dependent software.
>
> I would like you to get your feedback about the following idea to solve
> this problem:
>
> The idea is very simple, replace the plethora of *optional* arguments
> found in constructor and archive::op_* methods by a single one which type
> is a class, class which name would be isolate_option, create_option,
> extract_option, and so on.
>
> All theses class would have a default constructor (with no argument),
> along with a list of methods to set the different options (slicing,
> encryption, compression, etc.). then, as new feature get added, a new
> method of in theses option classes would be added. Not using this new
> method would only let libdar behaves with default value for this new
> option.
>
> Old software would continue to work with new libdar API and less work
> would have to be done for libdar dependent software. Using a new feature
> by libdar dependent programs could be done asynchronously from libdar's
> release, this brings more freedom for anyone around libdar's API.

This is a great idea! I'm looking forward to it.

>
> Thanks in advance for feedback,
>
> Regards,
> Denis.

Cheers,
JB

Re: [Dar-libdar_api] more stability on libdar API

[Thomas J. <ja...@in...>]

I've been thinking a similiar thing for
a while now, as I've been hacking dar quite
a bit for my own purposes and the most annoying
thing really is having to hand down options over
many different layers, otherwise the code
is very easy to work with.

Something along the lines you suggest would
make things much easier for me at least, also
the interface definitions would be more readable.

Contributing code that requires new options would
be made more simple, you would just have to
add an option handler, and then use that option
exactly where you need it.

But why use different classes for the various
parts of dar? As long as your options names are unique,
just use one class, so you don't need to duplicate
options that are needed in more than one part of the code.

Also, are you sure that you can still dynamically link against
a new version of the library, if a class has extra
methods, without recompiling? Don't know much about
C++ and shared libraries myself...

On Fri, May 18, 2007 at 12:24:36PM +0200, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hi,
>=20
> For almost each added feature, I have to add new parameter(s) to the
> archive class's constructors or methods. This is annoying for all
> software that rely on libdar (dar command line programs, kdar, etc.).
>=20
> This break ascendant compatibility at each major release, which implies
> some work for each libdar dependent software.
>=20
> I would like you to get your feedback about the following idea to solve
> this problem:
>=20
> The idea is very simple, replace the plethora of *optional* arguments
> found in constructor and archive::op_* methods by a single one which type
> is a class, class which name would be isolate_option, create_option,
> extract_option, and so on.
>=20
> All theses class would have a default constructor (with no argument),
> along with a list of methods to set the different options (slicing,
> encryption, compression, etc.). then, as new feature get added, a new
> method of in theses option classes would be added. Not using this new
> method would only let libdar behaves with default value for this new opti=
on.
>=20
> Old software would continue to work with new libdar API and less work
> would have to be done for libdar dependent software. Using a new feature
> by libdar dependent programs could be done asynchronously from libdar's
> release, this brings more freedom for anyone around libdar's API.
>=20
> Thanks in advance for feedback,
>=20
> Regards,
> Denis.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>=20
> iD8DBQFGTX7jpC5CI8gYGlIRAp8sAKCizFlPFYnkZVjO65J152jdrERunQCfWauK
> sJQEgxRbL0fPK+OIRhV8Bqc=3D
> =3DRbTW
> -----END PGP SIGNATURE-----
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

[Dar-libdar_api] more stability on libdar API

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

For almost each added feature, I have to add new parameter(s) to the
archive class's constructors or methods. This is annoying for all
software that rely on libdar (dar command line programs, kdar, etc.).

This break ascendant compatibility at each major release, which implies
some work for each libdar dependent software.

I would like you to get your feedback about the following idea to solve
this problem:

The idea is very simple, replace the plethora of *optional* arguments
found in constructor and archive::op_* methods by a single one which type
is a class, class which name would be isolate_option, create_option,
extract_option, and so on.

All theses class would have a default constructor (with no argument),
along with a list of methods to set the different options (slicing,
encryption, compression, etc.). then, as new feature get added, a new
method of in theses option classes would be added. Not using this new
method would only let libdar behaves with default value for this new option.

Old software would continue to work with new libdar API and less work
would have to be done for libdar dependent software. Using a new feature
by libdar dependent programs could be done asynchronously from libdar's
release, this brings more freedom for anyone around libdar's API.

Thanks in advance for feedback,

Regards,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGTX7jpC5CI8gYGlIRAp8sAKCizFlPFYnkZVjO65J152jdrERunQCfWauK
sJQEgxRbL0fPK+OIRhV8Bqc=
=RbTW
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] Empty option for testing archives

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill a écrit :
> Hi Denis,

Hello Johnathan,

> 
> On Wednesday 02 May 2007 2:31 pm, Denis Corbin wrote:
>> This now in CVS Trunk.
>>
>> Regards,
>> Denis.
> 
> I've tried the empty option to op_test, and it works okay when running the 
> test in a single thread.

OK,

> 
> But sometimes, not all of the time, I get a SRC_BUG thrown at line 44 of 
> defile.cpp when testing the archive in two threads at once, one real test and 
> one empty test.

This is normal if you use the same object in two different treads (see
the explanation I have just written for further reference
http://dar.linux.free.fr/doc/FAQ.html#threadsafe ).

But this is not normal if you use two different objects in two different
threads or use the same object portected by a Posix Mutex for example.

> 
> Here is a test program that should reproduce the behaviour. You'll need to 
> edit the archive path to open an archive on your system. I compiled it with:
> 
> g++ -DLIBDAR_MODE=64 -fexceptions -L/usr/local/lib -lpthread -lattr -lcrypto -ldar64 -lz -lbz2 
> twothreadtest.cpp -o twothreadtest
> 
> Running "twothreadtest" from the command line several times in a row usually 
> shows the bug.

the archive pointed to by 'a' is passed to both threads thus the same
variable is modified by both threads at the same time. Morevoer, the
archive::op_test method() is not a constant method, but OK, I am not
sure that all const methods of the API can be used without mutex by
different threads on the same object at the same time. I will double
check this right now.

To solve your problem I would create two archive objects (yes, memory
will suffer) or avoid using concurrent thread here.

The problem is that archive::op_test() needs to read the contents of the
archive (this is the libdar::catalogue object stored inside the archive
object). This is done by several call to catalogue::read() method each
returning an inode object to be tested. Thus the libdar::catalogue
object is changed by each call to catalogue::read() for it provides the
next entry at each catalogue::read() call. The defile object stores the
complete path of the object and get confuses by the second thread that
let the catalogue object reach the end of catalogue too soon (the defile
object has several subdirectories to pop, thus expects at least some eod
from the catalogue).

I am just surprised that the problem does not arise every time!

> 
> Any ideas what the problem is?
> 
> Thanks,
> JB
> 

Regards,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGQGRCpC5CI8gYGlIRArmiAJ9+K04bPlfz0ScIXOYrytGQNqwM/ACfQktx
VWS8eRB8vZO6NQmYt/LzgTw=
=uWpt
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] Empty option for testing archives

[Johnathan B. <jk...@ro...>]

Hi Denis,

On Wednesday 02 May 2007 2:31 pm, Denis Corbin wrote:
> This now in CVS Trunk.
>
> Regards,
> Denis.

I've tried the empty option to op_test, and it works okay when running the 
test in a single thread.

But sometimes, not all of the time, I get a SRC_BUG thrown at line 44 of 
defile.cpp when testing the archive in two threads at once, one real test and 
one empty test.

Here is a test program that should reproduce the behaviour. You'll need to 
edit the archive path to open an archive on your system. I compiled it with:

g++ -DLIBDAR_MODE=64 -fexceptions -L/usr/local/lib -lpthread -lattr -lcrypto -ldar64 -lz -lbz2 
twothreadtest.cpp -o twothreadtest

Running "twothreadtest" from the command line several times in a row usually 
shows the bug.

Any ideas what the problem is?

Thanks,
JB

Re: [Dar-libdar_api] Empty option for testing archives

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This now in CVS Trunk.

Regards,
Denis.


Denis Corbin wrote :
> Johnathan Burchill wrote :
>> Hi Denis,
> 
> Hello Johnathan,
> 
>> Is it possible to have the "empty" boolean option added to the 
>> libdar::archive->op_test() api? 
> 
> Well, I see no objections.
> 
>> My plan is to use the "dummy run" option to quickly determine the number of 
>> files considered by an operation's selection and subtree filters, and at the 
>> same time in a different thread run the actual operation. Once the dummy 
>> operation is finished, and it returns the number of files considered, I can 
>> start to update my progress dialog based on the current stats of the running 
>> operation. The other operations have this empty option, but not the op_test.
> 
>> Presumably op_test() with empty=true would traverse the archive according to 
>> the masks, and not perform the CRC checks.
> 
> Yep, thus if no CRC is done, no file reading is necessary, this will
> make the thing even faster as no decompression/decryption will be necessary.
> 
>> Cheers,
>> JB
> 
> 
> Regards,
> Denis.
> 

- -------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Dar-libdar_api mailing list
Dar...@li...
https://lists.sourceforge.net/lists/listinfo/dar-libdar_api



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGONkSpC5CI8gYGlIRAnMgAKCblN06uE9VZwxaEdWbE0lmZ9AGbACfbGbd
Qrn96GR+a6KFbygr7+i5UQ4=
=/dCN
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] Typos in compressor.cpp

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote :
> Hi Denis,

hello again,

> 
> The ERange source argument in "char compression2char(compression c)", around 
> line 431 in compressor.cpp should be "compression2char", instead 
> of "char2compression". Similar problem in "string 
> compression2string(compession c)".

You are right. This is fixed in CVS branch_2_3_x and will be merged back
 to Trunk at next release on this branch.

> 
> Cheers,
> JB
> 

Regards,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGL7XtpC5CI8gYGlIRApgnAJ4oN3SAxytUcDEFL1J1trqAHKXTuwCffyOg
deJUkIv/lGV3eR2N4FMKT9A=
=QgVD
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] Empty option for testing archives

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote :
> Hi Denis,

Hello Johnathan,

> 
> Is it possible to have the "empty" boolean option added to the 
> libdar::archive->op_test() api? 

Well, I see no objections.

> 
> My plan is to use the "dummy run" option to quickly determine the number of 
> files considered by an operation's selection and subtree filters, and at the 
> same time in a different thread run the actual operation. Once the dummy 
> operation is finished, and it returns the number of files considered, I can 
> start to update my progress dialog based on the current stats of the running 
> operation. The other operations have this empty option, but not the op_test.
> 
> Presumably op_test() with empty=true would traverse the archive according to 
> the masks, and not perform the CRC checks.

Yep, thus if no CRC is done, no file reading is necessary, this will
make the thing even faster as no decompression/decryption will be necessary.

> 
> Cheers,
> JB
> 

Regards,
Denis.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGL7N1pC5CI8gYGlIRAqV8AKDHEQ1Srae4XyKkaxq35F/jUMrWuQCfWD6j
T3e0V1W+Gp1hicXnhgPw7BY=
=N1Zk
-----END PGP SIGNATURE-----

Re: [Dar-libdar_api] Typos in compressor.cpp

[Johnathan B. <jk...@ro...>]

On Saturday 21 April 2007 2:11 pm, Johnathan Burchill wrote:
> Hi Denis,
>
> The ERange source argument in "char compression2char(compression c)",
> around line 431 in compressor.cpp should be "compression2char", instead
> of "char2compression". Similar problem in "string
> compression2string(compession c)".

Using dar-2.3.3, and cvs browse shows it in HEAD as well.

>
> Cheers,
> JB
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

[Dar-libdar_api] Typos in compressor.cpp

[Johnathan B. <jk...@ro...>]

Hi Denis,

The ERange source argument in "char compression2char(compression c)", around 
line 431 in compressor.cpp should be "compression2char", instead 
of "char2compression". Similar problem in "string 
compression2string(compession c)".

Cheers,
JB

[Dar-libdar_api] Empty option for testing archives

[Johnathan B. <jk...@ro...>]

Hi Denis,

Is it possible to have the "empty" boolean option added to the 
libdar::archive->op_test() api? 

My plan is to use the "dummy run" option to quickly determine the number of 
files considered by an operation's selection and subtree filters, and at the 
same time in a different thread run the actual operation. Once the dummy 
operation is finished, and it returns the number of files considered, I can 
start to update my progress dialog based on the current stats of the running 
operation. The other operations have this empty option, but not the op_test.

Presumably op_test() with empty=true would traverse the archive according to 
the masks, and not perform the CRC checks.

Cheers,
JB

Re: [Dar-libdar_api] =?utf-8?q?updating_kdar_to_work_with___libdar_4_?= =?utf-8?b?KGRhciAyLjMuMSk=?=

[nelg <ne...@li...>]

Hi Johnathan,



I was planning on working with kdar on kde 3.5.x.  However, as yet, have not made any progress, as soon after deciding to start working on it, got really busy with work.  However, do keep in contact, and I'll checkout your changes in svn.  I am still wanting to work on it, and should get a chance to keep working with it over the next month, since I have finished painting the bathroom now... :)



Regards

Glen Ogilvie







On Fri, 6 Apr 2007 16:05:34 -0400, Johnathan Burchill <jk...@ro...> wrote:

> Glen Ogilvie wrote:

> 

>> Hi,

> 

> Hi Glen,

> 

>>

>> I would like to help with getting kdar working with the newer dar

>> libraries.  I am a beginner C++  programmer, so will need help, but am

>> prepared to spend  time learning and will put in some effort if anyone

>> still reads this list.

>>

>> I've been digging around in the source, but not finding it easy to

>> figure out all the new stuff needed to be passed when using new

>> libdar::archive in createArchiveThread.cpp.

>>

>> Also,

>>

>> Denis Corbin wrote:

>>>   By the way, I have quite finished implementing the features I wanted

> to

>>>   include in next major release that have impact on the API. There is

> one

>>>   more feature (the "dar_merge") I have to make room for (a new

>>>   constructor for the archive class) then I will freeze the API for new

>>>   features. So you will be very welcome to integrate the new features

>>>   brought by the next libdar if you like in kdar, eventually give your

>>>   feedback for I add the necessary calls I could have not thought about

>>>   for it works as you wish. Of course I will first have to give you a

>>>   summary of what have changed since previous API and how to use it.

>>>

>>>   On the path to the release, few other feature are to be implemented

>>>   that should not have impact on the API and documentation of the API

>>>   should have to be updated, as well as I hope a review of the overall

>>>   documentation structure.

>>>

>> Dennis, have you managed to put togeather a summary of the API

>> changes?  It would help in updating kdar to use them.

>>

>> Regards

>> Glen Ogilvie

>> New Zealand

> 

> That's great! I've let KDar lapse behind the times. I've recently moved

> back

> to Canada from the US and have gotten settled enough to make progress on

> KDar. I haven't been subscribed to this list for awhile, so I only just

> saw

> your email now.

> 

> I've got KDar adapted to KDE4 and libdar 4.0 in svn. Please check it out

> and

> let me know if you need help. I've only got the open and test functions

> implemented, so anything that you have done will certainly be appreciated.

> 

> Are you using KDE 3 or 4(development)? With KDE3, your changes could be

> made

> into an svn branch to continue to make KDar available to current KDE'ers.

> 

> Best regards,

> Johnathan (JB)

> 

> -------------------------------------------------------------------------

> Take Surveys. Earn Cash. Influence the Future of IT

> Join SourceForge.net's Techsay panel and you'll get the chance to share

> your

> opinions on IT & business topics through brief surveys-and earn cash

> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

> _______________________________________________

> Dar-libdar_api mailing list

> Dar...@li...

> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

Re: [Dar-libdar_api] updating kdar to work with libdar 4 (dar 2.3.1)

[Johnathan B. <jk...@ro...>]

Glen Ogilvie wrote:

> Hi,

Hi Glen,

> 
> I would like to help with getting kdar working with the newer dar
> libraries.  I am a beginner C++  programmer, so will need help, but am
> prepared to spend  time learning and will put in some effort if anyone
> still reads this list.
> 
> I've been digging around in the source, but not finding it easy to
> figure out all the new stuff needed to be passed when using new
> libdar::archive in createArchiveThread.cpp.
> 
> Also,
> 
> Denis Corbin wrote:
>>   By the way, I have quite finished implementing the features I wanted to
>>   include in next major release that have impact on the API. There is one
>>   more feature (the "dar_merge") I have to make room for (a new
>>   constructor for the archive class) then I will freeze the API for new
>>   features. So you will be very welcome to integrate the new features
>>   brought by the next libdar if you like in kdar, eventually give your
>>   feedback for I add the necessary calls I could have not thought about
>>   for it works as you wish. Of course I will first have to give you a
>>   summary of what have changed since previous API and how to use it.
>>
>>   On the path to the release, few other feature are to be implemented
>>   that should not have impact on the API and documentation of the API
>>   should have to be updated, as well as I hope a review of the overall
>>   documentation structure.
>>
> Dennis, have you managed to put togeather a summary of the API
> changes?  It would help in updating kdar to use them.
> 
> Regards
> Glen Ogilvie
> New Zealand

That's great! I've let KDar lapse behind the times. I've recently moved back
to Canada from the US and have gotten settled enough to make progress on
KDar. I haven't been subscribed to this list for awhile, so I only just saw
your email now.

I've got KDar adapted to KDE4 and libdar 4.0 in svn. Please check it out and
let me know if you need help. I've only got the open and test functions
implemented, so anything that you have done will certainly be appreciated.

Are you using KDE 3 or 4(development)? With KDE3, your changes could be made
into an svn branch to continue to make KDar available to current KDE'ers.

Best regards,
Johnathan (JB)

Re: [Dar-libdar_api] entree_stats access

[Denis C. <dar...@fr...>]

This is now in CVS branch_2_3_x.

Regards,
Denis.

Denis Corbin wrote:
> Johnathan Burchill wrote:
> 
>>Hi Denis,
> 
> 
> Hello Johnathan!
> 
> Happy to hear about you again. This is my turn this next few month to be
> out of time, but the patch you propose is OK.
> 
> However, I think it would better to have it available from 2.3.x branch,
> as it may take some time for the 2.4.x (current CVS trunk) to mature and
> become a release.
> 
> Current libdar is 4.1.0 it could become 4.2.0 with the addition of this
> small patch (plus other potential bug fixes) for you can get the
> entree_stats you need. Having a new release (2.3.4 is the next one) from
> branch_2_3_x does not imply a lot of effort (and testing), thus I can
> afford it currently.
> 
> New version of kdar relying on this new little enhancement would just
> have to test that they are linked with libdar version 4.x.y where x >= 2.
> 
> Regards,
> Denis.
> 
> 
>>It's been a long time, but I've finally put some spare time into 
>>adapting KDar to KDE4 and libdar-4.0.
>>
>>I'd like to be able to get information about existing archives, 
>>basically the info that is stored in the catalogue and which is 
>>accessible by 
>>
>>entree_stats   catalogue::get_stats () const.
>>
>>Since you don't want the user to call the 
>>
>>const catalogue &   archive::get_catalogue () const 
>>
>>function directly, could we have a passthrough for the entree_stats?
>>This patch for cvs HEAD is what I have in mind.
>>
>>Index: archive.hpp
>>===================================================================
>>RCS file: /cvsroot/dar/dar/src/libdar/archive.hpp,v
>>retrieving revision 1.35
>>diff -u -r1.35 archive.hpp
>>--- archive.hpp 14 Jan 2007 21:16:07 -0000      1.35
>>+++ archive.hpp 4 Apr 2007 13:24:46 -0000
>>@@ -494,6 +494,9 @@
>>            /// not part of the API but must remain a public method 
>>for been usable by the database class
>>        const catalogue & get_catalogue() const { if(cat == NULL) 
>>throw SRC_BUG; return *cat; };
>>
>>+            /// gives access to archive statistics. Obtained from the 
>>archive's catalogue.
>>+       const entree_stats get_stats() const { if(cat == NULL) throw  
>>SRC_BUG; return cat->get_stats(); };
>>+
>>     private:
>>        enum operation { oper_create, oper_isolate, oper_merge };
>>
>>
>>
>>Cheers,
>>JB
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys-and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>Dar-libdar_api mailing list
>>Dar...@li...
>>https://lists.sourceforge.net/lists/listinfo/dar-libdar_api
>>
>>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys-and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Dar-libdar_api mailing list
>>Dar...@li...
>>https://lists.sourceforge.net/lists/listinfo/dar-libdar_api

Re: [Dar-libdar_api] entree_stats access

[Denis C. <dar...@fr...>]

Johnathan Burchill wrote:
> Hi Denis,

Hello Johnathan!

Happy to hear about you again. This is my turn this next few month to be
out of time, but the patch you propose is OK.

However, I think it would better to have it available from 2.3.x branch,
as it may take some time for the 2.4.x (current CVS trunk) to mature and
become a release.

Current libdar is 4.1.0 it could become 4.2.0 with the addition of this
small patch (plus other potential bug fixes) for you can get the
entree_stats you need. Having a new release (2.3.4 is the next one) from
branch_2_3_x does not imply a lot of effort (and testing), thus I can
afford it currently.

New version of kdar relying on this new little enhancement would just
have to test that they are linked with libdar version 4.x.y where x >= 2.

Regards,
Denis.

> 
> It's been a long time, but I've finally put some spare time into 
> adapting KDar to KDE4 and libdar-4.0.
> 
> I'd like to be able to get information about existing archives, 
> basically the info that is stored in the catalogue and which is 
> accessible by 
> 
> entree_stats   catalogue::get_stats () const.
> 
> Since you don't want the user to call the 
> 
> const catalogue &   archive::get_catalogue () const 
> 
> function directly, could we have a passthrough for the entree_stats?
> This patch for cvs HEAD is what I have in mind.
> 
> Index: archive.hpp
> ===================================================================
> RCS file: /cvsroot/dar/dar/src/libdar/archive.hpp,v
> retrieving revision 1.35
> diff -u -r1.35 archive.hpp
> --- archive.hpp 14 Jan 2007 21:16:07 -0000      1.35
> +++ archive.hpp 4 Apr 2007 13:24:46 -0000
> @@ -494,6 +494,9 @@
>             /// not part of the API but must remain a public method 
> for been usable by the database class
>         const catalogue & get_catalogue() const { if(cat == NULL) 
> throw SRC_BUG; return *cat; };
> 
> +            /// gives access to archive statistics. Obtained from the 
> archive's catalogue.
> +       const entree_stats get_stats() const { if(cat == NULL) throw  
> SRC_BUG; return cat->get_stats(); };
> +
>      private:
>         enum operation { oper_create, oper_isolate, oper_merge };
> 
> 
> 
> Cheers,
> JB
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Dar-libdar_api mailing list
> Dar...@li...
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api
> 
> 
>