[gentoo-science] gle-4.1.1

[gentoo-science] gle-4.1.1

[Andrey G. Grozin]

Hello *,

A long-awaited gle-4.1.0 appeared, to be quickly replaced by the 4.1.1 
bugfix release. It contains a much improved qt4 gui for gle (though I 
don't use this gui) plus a number of fixes and enhancements in the core 
gle. I've committed sci-visualization/gle-4.1.1.ebuild to the science 
overlay.

With the USE flag emacs, it installs the gle emacs mode. There is also vim 
support (in a separate file at sourceforge). It would be good to install 
it with USE=vim. However, I am not a vim user, and don't know how to 
install vim syntax files. Help is appreciated.

Best wishes,
Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

[gentoo-science] gle-4.1.1; extrema-4.3.4

[Andrey G. Grozin]

Hello *,

I added the USE flag vim-syntax to gle-4.1.1; with this flag, it installs 
vim support files.

I also bumped the version of extrema to 4.3.4. To make this less boring, I 
switched from wxGTK-2.6 to 2.8. Compiles and works fine. I really think 
that extrema should be in the main tree.

Best wishes,
Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

[gentoo-science] qtiplot-0.9.6 (and qwt-5.1.0)

[Andrey G. Grozin]

Hello *,

qtiplot-0.9.6 arreared recently. It requires qwt-5.1.0. I made these two 
ebuilds, and committed them to the science overlay.

I propose *not* to use an external liborigin in qtiplot. Am I right that 
liborigin is used only by qtiplot? Then it would be better to get rid of 
sci-libs/liborigin at all. It seems veru unlikely that anybody else 
(except qtiplot) will want it. And qtiplot always contains its own, 
newest and customized source of liborigin. If a uswer cares for Origin 
compatibility, he will be better off with this version.

Two defects in the current ebuild.

1. It does not install translations. I cannot understand why, it seems it 
should, but it does not.

2. In order to start working properly, for a given user, qtiplot needs 
some initial configuring. This is against the gentoo spirit - programs 
should work out of the box. qtiplot uses QSettings. From reading Qt4 
documentation, I concluded that a working configuration can be created by 
installing /etc/xdg/ProIndependent/QtiPlot.conf , with various path 
settings (to help, python files, etc.). No, this does not work, I cannot 
understand why. It seems that only ~/.config/ProIndependent/QtiPlot.conf 
is taken into account. This means that each user has to say where are 
help files etc. I added some elogs about this. Does anybody understand 
how QSettings work, and how to provide system-wide defaults?

Best wishes,
Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

Re: [gentoo-science] qtiplot-0.9.6 (and qwt-5.1.0)

[Sébastien Fabbro]

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

On Thu, 15 May 2008 18:24:35 +0700 (NOVST)
"Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> wrote:

 > I propose *not* to use an external liborigin in qtiplot. Am I right
> that liborigin is used only by qtiplot? Then it would be better to
> get rid of sci-libs/liborigin at all. It seems veru unlikely that
> anybody else (except qtiplot) will want it. And qtiplot always
> contains its own, newest and customized source of liborigin. If a
> uswer cares for Origin compatibility, he will be better off with this
> version.

At least sci-visualization/labplot uses liborigin, and someone could
want to use liborigin for its own use.
Internal copies are harmful and best avoided. The best solution is
ususally to work out with upstream to try to remove it. 

- --
Sébastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgut8MACgkQ1ycZbhPLE2CCDgCeKs2l0RMuSg8xlhni3hZatNGY
YikAmwSEitdIs7wcp/w2X4sfxTdTYX4B
=9Hrr
-----END PGP SIGNATURE-----

Re: [gentoo-science] qtiplot-0.9.6 (and qwt-5.1.0)

[Andrey G. Grozin]

On Sat, 17 May 2008, Sbastien Fabbro wrote:
> On Thu, 15 May 2008 18:24:35 +0700 (NOVST)
> "Andrey G. Grozin" <A.G.Grozin@inp.nsk.su> wrote:
>> I propose *not* to use an external liborigin in qtiplot. Am I right
>> that liborigin is used only by qtiplot? Then it would be better to
>> get rid of sci-libs/liborigin at all. It seems veru unlikely that
>> anybody else (except qtiplot) will want it. And qtiplot always
>> contains its own, newest and customized source of liborigin. If a
>> uswer cares for Origin compatibility, he will be better off with this
>> version.
> At least sci-visualization/labplot uses liborigin, and someone could
> want to use liborigin for its own use.
> Internal copies are harmful and best avoided. The best solution is
> ususally to work out with upstream to try to remove it.
OK, I'll fix the ebuild to use the external liborigin.

BTW, I've committed qwt-5.1.0 to the main tree.

Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

[gentoo-science] qtiplot-0.9.6, scidavis-0.1.3

[Andrey G. Grozin]

Hello *,

I've fixed the problem with translations (or rather their absense :-) in 
recent qtiplot version, and committed qtiplot-0.9.6 to the main tree. In 
the .pro file, the line which produced .qm files from .ts files was 
commented out.

There was also a bug #222527 asking for scidavis - a qtiplot fork. I've 
committed it to the overlay. Don't see much difference from qtiplot, 
though.

Andrey
-- 
gentoo-science@lists.gentoo.org mailing list

[gentoo-science] sympy-0.6.2

[Andrey G. Grozin]

Hello *,

I've just committed sympy-0.6.2.ebuild to the science overlay. It differs 
from the ebuild in sunrise: it builds and installs docs with USE=doc. I 
intended it to use external mpmath and pyglet, but so far I haven't done 
this - now (patched) versions of these packages are built with sympy. 
Using system mpmath and pyglet is, of course, desirable, but requrires 
patching many files - changing

import sympy.mpmath as mpmath

to

import mpmath

etc. I'll try to do this later and see if the result will be usable. There 
is also a problem with the external pyglet - currently, it depends on the 
binary package avbin-bin available only on x86 and amd64 (instructions for 
compiling avbin from sources are complicated and require checking out some 
specific cvs snapshot of ffmpeg; of course, it is possible to make a 
tarball of this snapshot and mirror it at Gentoo). Also, many things in 
pyglet don't work, at least for me. So, it is not a good idea to commit 
pyglet to the main tree now.

Please try sympy. It is a very interesting package.

Andrey

Re: [gentoo-science] sympy-0.6.2

[Matías Graña]

It seems that pyglet is pulled in by useflag X.
What would I be missing if I emerge sympy with USE=-X ?

Thanks for the ebuild!

Matías

On Thu, Aug 28, 2008 at 05:39:33PM +0700, Andrey G. Grozin wrote:
> Hello *,
>
> I've just committed sympy-0.6.2.ebuild to the science overlay. It differs 
> from the ebuild in sunrise: it builds and installs docs with USE=doc. I 
> intended it to use external mpmath and pyglet, but so far I haven't done 
> this - now (patched) versions of these packages are built with sympy. Using 
> system mpmath and pyglet is, of course, desirable, but requrires patching 
> many files - changing
>
> import sympy.mpmath as mpmath
>
> to
>
> import mpmath
>
> etc. I'll try to do this later and see if the result will be usable. There 
> is also a problem with the external pyglet - currently, it depends on the 
> binary package avbin-bin available only on x86 and amd64 (instructions for 
> compiling avbin from sources are complicated and require checking out some 
> specific cvs snapshot of ffmpeg; of course, it is possible to make a 
> tarball of this snapshot and mirror it at Gentoo). Also, many things in 
> pyglet don't work, at least for me. So, it is not a good idea to commit 
> pyglet to the main tree now.
>
> Please try sympy. It is a very interesting package.
>
> Andrey
>

Re: [gentoo-science] sympy-0.6.2

[Andrey G. Grozin]

On Thu, 28 Aug 2008, Mat?as Gra?a wrote:
> It seems that pyglet is pulled in by useflag X.
> What would I be missing if I emerge sympy with USE=-X ?
As things stand at the moment, nothing, because sympy will build its own 
subset of pyglet. It is used for 2d and 3d plots which appear in separate 
windows. I wanted to make sympy depending on external pyglet, but the 
simplest patch did not work, so, I postponed this. Sorry, I should have 
removed the dependence on pyglet for now.

Andrey