cppqed-support

[Cppqed-support] blitz-hg and flens-cvs in AUR for arch linux

[Raimar S. <rai...@ui...>]

Dear all,

the C++QED dependencies can now be obtained from AUR for arch linux.

Sebastian has updated the blitz-hg PKGBUILD and it works very well. To obtain 
the C++QED-patched version, just edit the PKGBUILD when it asks you and 
replace the URL with

hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz

Maybe we should upload a separate package for this version, Sebastian what do 
you think?

I have also overtaken the flens-cvs package and updated it, so that it now 
includes the same patches which are used in the Ubuntu package. This version 
is suitable for compiling C++QED, please test if it works for you :)

Best regards
Raimar

Re: [Cppqed-support] blitz-hg and flens-cvs in AUR for arch linux

[Andras V. <and...@ui...>]

Dear Raimar,
Thanks a lot!
It also occurs as an option that we distribute *only* our version of blitz
(although it does depend on Boost.Preprocessor, while the original does
not).
The FLENS dependency is going to be deprecated in the new release.
Currently, I’m working on replacing it with Eigen3 (cf.
http://eigen.tuxfamily.org), which is a header-only library also featured
in AUR.
Best regards,
András


Dr. Andras Vukics
Institute for Theoretical Physics
University of Innsbruck


On Thu, Nov 14, 2013 at 3:33 PM, Raimar Sandner
<rai...@ui...>wrote:

> Dear all,
>
> the C++QED dependencies can now be obtained from AUR for arch linux.
>
> Sebastian has updated the blitz-hg PKGBUILD and it works very well. To
> obtain
> the C++QED-patched version, just edit the PKGBUILD when it asks you and
> replace the URL with
>
> hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz
>
> Maybe we should upload a separate package for this version, Sebastian what
> do
> you think?
>
> I have also overtaken the flens-cvs package and updated it, so that it now
> includes the same patches which are used in the Ubuntu package. This
> version
> is suitable for compiling C++QED, please test if it works for you :)
>
> Best regards
> Raimar
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support
>

Re: [Cppqed-support] blitz-hg and flens-cvs in AUR for arch linux

[Andras V. <and...@ui...>]

Hi,
(I think Sebastian wanted to post the mail below on the list.)
I also don’t like the option of having to edit PKGBUILD.
The chances that our changes get back to the main repository are low
because I think they don’t want to get dependent on Boost.
I strongly suggest that we package only our version of Blitz.
By the way, I’m thinking a lot about deprecating Blitz as well, and
migrating to Boost.MultiArray as the basic data structure. Blitz has
several problems:
* It’s not well maintained.
* Its codebase is pretty outdated from the present C++ point of view.
* It has the major design problem that although it has reference-semantics,
it cannot represent all the four possibilites of const-ness for references.
Hence, with the use of Blitz, it is impossible to ensure const-correctness.
* It needs to be compiled, while Boost.MultiArray is header-only.
Best regards,
András


Dr. Andras Vukics
Institute for Theoretical Physics
University of Innsbruck


On Thu, Nov 14, 2013 at 6:05 PM, Sebastian Krämer <
seb...@ui...> wrote:

>  Hi all!
>
> What are the chances to get these changes back into the main blitz++
> branch? That would by far be the cleanest option. Otherwise, it's no
> problem to provide a separate AUR-package. However, it might be confusing
> and inconvenient for users if they have to decide between three different
> blitz packages. But I like the option to manually change the URL even less.
> It's just too easy to forget this step when installing it as dependency of
> c++qed.
>
> Sebastian
>
> On 11/14/2013 05:40 PM, Andras Vukics wrote:
>
>  Dear Raimar,
> Thanks a lot!
>  It also occurs as an option that we distribute *only* our version of
> blitz (although it does depend on Boost.Preprocessor, while the original
> does not).
>  The FLENS dependency is going to be deprecated in the new release.
> Currently, I’m working on replacing it with Eigen3 (cf.
> http://eigen.tuxfamily.org), which is a header-only library also featured
> in AUR.
> Best regards,
> András
>
>
> Dr. Andras Vukics
> Institute for Theoretical Physics
> University of Innsbruck
>
>
> On Thu, Nov 14, 2013 at 3:33 PM, Raimar Sandner <rai...@ui...
> > wrote:
>
>> Dear all,
>>
>> the C++QED dependencies can now be obtained from AUR for arch linux.
>>
>> Sebastian has updated the blitz-hg PKGBUILD and it works very well. To
>> obtain
>> the C++QED-patched version, just edit the PKGBUILD when it asks you and
>> replace the URL with
>>
>> hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz
>>
>> Maybe we should upload a separate package for this version, Sebastian
>> what do
>> you think?
>>
>> I have also overtaken the flens-cvs package and updated it, so that it now
>> includes the same patches which are used in the Ubuntu package. This
>> version
>> is suitable for compiling C++QED, please test if it works for you :)
>>
>> Best regards
>> Raimar
>>
>>
>> ------------------------------------------------------------------------------
>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> Free app hosting. Or install the open source package on any LAMP server.
>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Cppqed-support mailing list
>> Cpp...@li...
>> https://lists.sourceforge.net/lists/listinfo/cppqed-support
>>
>
>
>

Re: [Cppqed-support] blitz-hg and flens-cvs in AUR for arch linux

[Raimar S. <rai...@ui...>]

Editing the PKGBUILD was not thought to be a permanent solution :)

I also think it is best to only provide the patched version on AUR. Then we 
will have the official 0.10 release and our -hg version which adds the patches. 
But I don't know if it is polite to keep the name in this case. Maybe we 
should make it clear that this is essentially a fork?

By the way, the dependence on boost would only change from an optional one to 
a required one for the upstream project.

The switch to Boost.MultiArray would probably a lot of work, would it not? 
Even after re-implementing the traits, the blitz interface could be exposed to 
a lot of places via getArray.

Best regards
Raimar


On Thursday, November 14, 2013 06:34:52 PM Andras Vukics wrote:
> Hi,
> (I think Sebastian wanted to post the mail below on the list.)
> I also don’t like the option of having to edit PKGBUILD.
> The chances that our changes get back to the main repository are low
> because I think they don’t want to get dependent on Boost.
> I strongly suggest that we package only our version of Blitz.
> By the way, I’m thinking a lot about deprecating Blitz as well, and
> migrating to Boost.MultiArray as the basic data structure. Blitz has
> several problems:
> * It’s not well maintained.
> * Its codebase is pretty outdated from the present C++ point of view.
> * It has the major design problem that although it has reference-semantics,
> it cannot represent all the four possibilites of const-ness for references.
> Hence, with the use of Blitz, it is impossible to ensure const-correctness.
> * It needs to be compiled, while Boost.MultiArray is header-only.
> Best regards,
> András
> 
> 
> Dr. Andras Vukics
> Institute for Theoretical Physics
> University of Innsbruck
> 
> 
> On Thu, Nov 14, 2013 at 6:05 PM, Sebastian Krämer <
> 
> seb...@ui...> wrote:
> >  Hi all!
> > 
> > What are the chances to get these changes back into the main blitz++
> > branch? That would by far be the cleanest option. Otherwise, it's no
> > problem to provide a separate AUR-package. However, it might be confusing
> > and inconvenient for users if they have to decide between three different
> > blitz packages. But I like the option to manually change the URL even
> > less.
> > It's just too easy to forget this step when installing it as dependency of
> > c++qed.
> > 
> > Sebastian
> > 
> > On 11/14/2013 05:40 PM, Andras Vukics wrote:
> >  Dear Raimar,
> > 
> > Thanks a lot!
> > 
> >  It also occurs as an option that we distribute *only* our version of
> > 
> > blitz (although it does depend on Boost.Preprocessor, while the original
> > does not).
> > 
> >  The FLENS dependency is going to be deprecated in the new release.
> > 
> > Currently, I’m working on replacing it with Eigen3 (cf.
> > http://eigen.tuxfamily.org), which is a header-only library also featured
> > in AUR.
> > Best regards,
> > András
> > 
> > 
> > Dr. Andras Vukics
> > Institute for Theoretical Physics
> > University of Innsbruck
> > 
> > 
> > On Thu, Nov 14, 2013 at 3:33 PM, Raimar Sandner <rai...@ui...
> > 
> > > wrote:
> >> Dear all,
> >> 
> >> the C++QED dependencies can now be obtained from AUR for arch linux.
> >> 
> >> Sebastian has updated the blitz-hg PKGBUILD and it works very well. To
> >> obtain
> >> the C++QED-patched version, just edit the PKGBUILD when it asks you and
> >> replace the URL with
> >> 
> >> hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz
> >> 
> >> Maybe we should upload a separate package for this version, Sebastian
> >> what do
> >> you think?
> >> 
> >> I have also overtaken the flens-cvs package and updated it, so that it
> >> now
> >> includes the same patches which are used in the Ubuntu package. This
> >> version
> >> is suitable for compiling C++QED, please test if it works for you :)
> >> 
> >> Best regards
> >> Raimar
> >> 
> >> 
> >> -------------------------------------------------------------------------
> >> ----- DreamFactory - Open Source REST & JSON Services for HTML5 & Native
> >> Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API
> >> Access Free app hosting. Or install the open source package on any LAMP
> >> server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and
> >> Native!
> >> 
> >> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clkt
> >> rk
> >> _______________________________________________
> >> Cppqed-support mailing list
> >> Cpp...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cppqed-support

Re: [Cppqed-support] blitz-hg and flens-cvs in AUR for arch linux

[Andras V. <and...@ui...>]

>
> I also think it is best to only provide the patched version on AUR. Then we
> will have the official 0.10 release and our -hg version which adds the
> patches.
> But I don't know if it is polite to keep the name in this case. Maybe we
> should make it clear that this is essentially a fork?
>

I suggest that we call it cppqed-blitz.

By the way, the dependence on boost would only change from an optional one
> to
> a required one for the upstream project.
>

That’s right, because it optionally depends on Boost.Serialization – this I
forgot.

The switch to Boost.MultiArray would probably a lot of work, would it not?
> Even after re-implementing the traits, the blitz interface could be
> exposed to
> a lot of places via getArray.
>

Yes, the blitz-dependence goes rather deep, and that’s why I haven’t
started migrating yet :) . But it’s worth thinking about.

Re: [Cppqed-support] blitz-hg and flens-cvs in AUR for arch linux

[Andras V. <and...@ui...>]

The present version in the AUR doesn’t compile on my box. I think the
failure is in the compilation of the texinfo part. I think this part is
completely unnecessary since everyone will use the pdf documentation
anyway. So I think we should do only a
make lib


Dr. Andras Vukics
Institute for Theoretical Physics
University of Innsbruck


On Thu, Nov 14, 2013 at 11:08 PM, Andras Vukics <and...@ui...>wrote:

> I also think it is best to only provide the patched version on AUR. Then we
>> will have the official 0.10 release and our -hg version which adds the
>> patches.
>> But I don't know if it is polite to keep the name in this case. Maybe we
>> should make it clear that this is essentially a fork?
>>
>
> I suggest that we call it cppqed-blitz.
>
> By the way, the dependence on boost would only change from an optional one
>> to
>> a required one for the upstream project.
>>
>
> That’s right, because it optionally depends on Boost.Serialization – this
> I forgot.
>
> The switch to Boost.MultiArray would probably a lot of work, would it not?
>> Even after re-implementing the traits, the blitz interface could be
>> exposed to
>> a lot of places via getArray.
>>
>
> Yes, the blitz-dependence goes rather deep, and that’s why I haven’t
> started migrating yet :) . But it’s worth thinking about.
>
>