pending dataframe-1.2.0 release

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

pending dataframe-1.2.0 release

Olaf Till-2
Pascal,

there is still much to do:

- Please pull from the repository, I've updated the root level
  Makefile.

- NEWS:

-- There is much more to mention here than you did. There were a lot
   of enhancements since the last release.

-- Please use 3-digit version numbers in the NEWS headlines.

- INDEX doesn't by far contain all functions. (This will affect the
  html documentation and our function database at Octave Forge.)

- inst/@dataframe/private/strsplit.m contains 12 tests, 9 of them fail
  for me.

- License texts:

-- The license texts are wrong, in that they say 'This file is part of
   Octave.', which is not true, and 'Octave is free software;'. You
   should either write 'This program is free software' or 'This file
   is free software', or both 'This file is part of the dataframe
   package for Octave.' and 'The dataframe package for Octave is free
   software;'. Also, in 'You should have received a copy of the GNU
   General Public License along with Octave;', 'Octave' should be
   replaced by 'this file' or 'this program' or 'this package'.

-- Please replace the street address of the FSF with the web address
   (you'll find examples in Octave or other packages).

- Can the license be updated to GPL version 3 or later?

- The coding style deviates much from Octave, e.g. in the positioning
  of license text and help text, in the choice of comment signs, and
  in using unqualified 'end' (instead of e.g. 'endif'). The reason
  seems to be trying to be Matlab compatible. Why is that so? In a
  'community' package, I think we should try to adher to Octaves
  coding style.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

CdeMills
On Tue, 15 Aug 2017 13:00:06 +0200, Olaf Till wrote:
> Pascal,
>
> there is still much to do:
>
> - Please pull from the repository, I've updated the root level
>   Makefile.
>

Olaf,

Done -- working on solving the various issues.

Could you please use '[hidden email]' as current E-Mail address ?

Regards

Pascal

Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

CdeMills
CdeMills wrote
On Tue, 15 Aug 2017 13:00:06 +0200, Olaf Till wrote:
> Pascal,
>
> there is still much to do:
>
> - Please pull from the repository, I've updated the root level
>   Makefile.
>
Olaf,
the issues mentioned so far should have been solved in the last push I made on SF:
1) adapted the license texts as requested. Many files where touched by that.
2) there was a longstanding bug in strsplit() call. In case more than one separator are used (typically "\t" and ","), put them in a cellstr instead of concatenating them in a single string
3) one test failed as a matrix was accessed past its end. Corrected.

Could you please have a look ?

Pascal
Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

Olaf Till-2
On Sat, Aug 19, 2017 at 10:01:35AM -0700, CdeMills wrote:

> CdeMills wrote
> > On Tue, 15 Aug 2017 13:00:06 +0200, Olaf Till wrote:
> >> Pascal,
> >>
> >> there is still much to do:
> >>
> >> - Please pull from the repository, I've updated the root level
> >>   Makefile.
> >>
>
> Olaf,
> the issues mentioned so far should have been solved in the last push I made
> on SF:
> 1) adapted the license texts as requested. Many files where touched by that.
> 2) there was a longstanding bug in strsplit() call. In case more than one
> separator are used (typically "\t" and ","), put them in a cellstr instead
> of concatenating them in a single string
> 3) one test failed as a matrix was accessed past its end. Corrected.
>
> Could you please have a look ?
Extensive changes, thanks...

I've pushed a change to the root level Makefile, to call
dataframe_test in 'make check'.

dataframe_test.m seems non-trivial to me, so could you add a copyright
and license to it?

Calling dataframe_test, lines 191--193 (left division) didn't pass for
me without specifying a tolerance...


The rest is ok for the release (though we didn't as yet discuss the
'Matlab oriented coding style' issue further).

You probably don't need to upload a further tarball, it should be
enough if I generate it at my machine after you've done the last
polish to dataframe_test.m

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

Oliver Heimlich
On 15.08.2017 13:00, Olaf Till wrote:
> - The coding style deviates much from Octave, e.g. in the positioning
>   of license text and help text, in the choice of comment signs, and
>   in using unqualified 'end' (instead of e.g. 'endif'). The reason
>   seems to be trying to be Matlab compatible. Why is that so? In a
>   'community' package, I think we should try to adher to Octaves
>   coding style.

On 20.08.2017 17:15, Olaf Till wrote:
...
> The rest is ok for the release (though we didn't as yet discuss the
> 'Matlab oriented coding style' issue further).

IMO, a package should be allowed to maintain Matlab compatibility.  In
the end this can only be beneficial to the end user at a low cost.

If you wanted to have Matlab compatibility, but stick to Octave's syntax
/ coding style, that is quite an overhead during development.  For
example, look at the doctest package:  The doctest package uses Texinfo
documentation and has to convert all m-files to make a Matlab package.
If one additionally used Octave-only syntax, that would be quite an
effort to keep support for Matlab.

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

Olaf Till-2
On Sun, Aug 20, 2017 at 05:32:37PM +0200, Oliver Heimlich wrote:
> IMO, a package should be allowed to maintain Matlab compatibility.  In
> the end this can only be beneficial to the end user at a low cost.

It doesn't affect the current release.

But as for Matlab compatible coding: The point is the 'community'
package status, implying that potentially others may want to
contribute, among whom opinions on this matter may differ (e.g. some
might not want to code for Matlab). Another consideration is the
possibility of taking code over into Octave.

In the case of dataframe, however, the maintainers voice has the
largest weight, since, AFAICS, up to now it's more or less a one man
work.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

OF packages using Matlab-compatible code (was "pending dataframe-1.2.0 release")

Colin Macdonald-2
In reply to this post by Oliver Heimlich
On 2017-08-20 08:32 AM, Oliver Heimlich wrote:
> IMO, a package should be allowed to maintain Matlab compatibility.  In
> the end this can only be beneficial to the end user at a low cost.

I agree.  In addition to Doctest which was already mentioned, Symbolic
also tries to use Matlab-compatible syntax.

1.  Having people run it on Matlab has caught some bugs that I otherwise
might not have found.

2.  We might uncover and fix incompatibilities in core Octave.  This has
happened with Doctest (the implementation of "evalc" for example).

3.  Its not inconceivable that a Matlab user might choose an
Octave-Forge package and thus be drawn towards software freedom.

The situation is perhaps analogous to porting Free Software to
proprietary operating systems.  I think this is widely viewed as an
ethically-sound activity (I thought there was a better reference but for
now I found a list of [Free Software for Windows, hosted by
FSF](https://www.gnu.org/software/for-windows.en.html)).

Overall, I think this is a decision best left to package authors and
maintainers.

best,
Colin

Reply | Threaded
Open this post in threaded view
|

Re: OF packages using Matlab-compatible code (was "pending dataframe-1.2.0 release")

jbect
Le 21/08/2017 à 00:49, Colin Macdonald a écrit :

> On 2017-08-20 08:32 AM, Oliver Heimlich wrote:
>> IMO, a package should be allowed to maintain Matlab compatibility.  In
>> the end this can only be beneficial to the end user at a low cost.
>
> I agree.  In addition to Doctest which was already mentioned, Symbolic
> also tries to use Matlab-compatible syntax.
>
> 1.  Having people run it on Matlab has caught some bugs that I
> otherwise might not have found.
>
> 2.  We might uncover and fix incompatibilities in core Octave. This
> has happened with Doctest (the implementation of "evalc" for example).
>
> 3.  Its not inconceivable that a Matlab user might choose an
> Octave-Forge package and thus be drawn towards software freedom.
>
> The situation is perhaps analogous to porting Free Software to
> proprietary operating systems.  I think this is widely viewed as an
> ethically-sound activity (I thought there was a better reference but
> for now I found a list of [Free Software for Windows, hosted by
> FSF](https://www.gnu.org/software/for-windows.en.html)).
>
> Overall, I think this is a decision best left to package authors and
> maintainers.

I agree with Oliver and Colin's arguments.  The stk package is another
example of a Matlab-Octave compatible package.

Keeping this compatibility undoubtedly makes it useful to a much larger
group of potential users, including (as Colin observed) Matlab users
that are later brought to use Octave for this reason.

I can also testify that maintaining this compatibility (over a
wide-enough range of Octave and Matlab releases) lead me to report, and
sometimes fix, many compatiblity problems in core Octave.

One more observation: the fact that most Octave Forge packages, and in
particular "community" packages, are not MO-compatible, means that I can
not have any of them as a dependency for the stk package.  As an
example: I would probably use the OF statistics package as a dependency
for the stk package if it were MO-compatible.  IConversely, it it were
MO-compatible, and therefore usable as a dependency for the stk package,
I would most certainly contribute to it and also indirectly bring new
users to the statistics package.

Just my two cents.

Reply | Threaded
Open this post in threaded view
|

Re: OF packages using Matlab-compatible code (was "pending dataframe-1.2.0 release")

Juan Pablo Carbajal-2
Hi all,

On Mon, Aug 21, 2017 at 8:10 AM, Julien Bect
<[hidden email]> wrote:

> Le 21/08/2017 à 00:49, Colin Macdonald a écrit :
>>
>> On 2017-08-20 08:32 AM, Oliver Heimlich wrote:
>>>
>>> IMO, a package should be allowed to maintain Matlab compatibility.  In
>>> the end this can only be beneficial to the end user at a low cost.
>>
>>
>> I agree.  In addition to Doctest which was already mentioned, Symbolic
>> also tries to use Matlab-compatible syntax.
>>
>> 1.  Having people run it on Matlab has caught some bugs that I otherwise
>> might not have found.
>>
>> 2.  We might uncover and fix incompatibilities in core Octave. This has
>> happened with Doctest (the implementation of "evalc" for example).
>>
>> 3.  Its not inconceivable that a Matlab user might choose an Octave-Forge
>> package and thus be drawn towards software freedom.
>>

I agree with all the points but there is more considerations to throw in.
In particular, since this is a personal decision, having
M-compatibility or not in a package is up to the developers.
Also, if the package offers something that is not so easily found in
proprietary software, then it is worth considering (from the ethical
point of view) to force it t run only on free software by using
octave's pidgin.

>> The situation is perhaps analogous to porting Free Software to proprietary
>> operating systems.  I think this is widely viewed as an ethically-sound
>> activity (I thought there was a better reference but for now I found a list
>> of [Free Software for Windows, hosted by
>> FSF](https://www.gnu.org/software/for-windows.en.html)).
>>
>> Overall, I think this is a decision best left to package authors and
>> maintainers.
>
>
> I agree with Oliver and Colin's arguments.  The stk package is another
> example of a Matlab-Octave compatible package.
>
> Keeping this compatibility undoubtedly makes it useful to a much larger
> group of potential users, including (as Colin observed) Matlab users that
> are later brought to use Octave for this reason.
>
> I can also testify that maintaining this compatibility (over a wide-enough
> range of Octave and Matlab releases) lead me to report, and sometimes fix,
> many compatiblity problems in core Octave.
>
> One more observation: the fact that most Octave Forge packages, and in
> particular "community" packages, are not MO-compatible, means that I can not
> have any of them as a dependency for the stk package.  As an example: I
> would probably use the OF statistics package as a dependency for the stk
> package if it were MO-compatible.  IConversely, it it were MO-compatible,
> and therefore usable as a dependency for the stk package, I would most
> certainly contribute to it and also indirectly bring new users to the
> statistics package.
Well, I would suggest that you detect whether it is run on Matlab or
Octave and load the statistics package accordingly.
Again, if stk offers something beyond what's found in prop. software,
you better do this to seduce users to move to free software and get
the extra cool functionalities.

>
> Just my two cents.
>

Reply | Threaded
Open this post in threaded view
|

Re: OF packages using Matlab-compatible code (was "pending dataframe-1.2.0 release")

Oliver Heimlich
On 21.08.2017 10:20, Juan Pablo Carbajal wrote:

>>> I agree.  In addition to Doctest which was already mentioned, Symbolic
>>> also tries to use Matlab-compatible syntax.
>>>
>>> 1.  Having people run it on Matlab has caught some bugs that I otherwise
>>> might not have found.
>>>
>>> 2.  We might uncover and fix incompatibilities in core Octave. This has
>>> happened with Doctest (the implementation of "evalc" for example).
>>>
>>> 3.  Its not inconceivable that a Matlab user might choose an Octave-Forge
>>> package and thus be drawn towards software freedom.
>>>
> I agree with all the points but there is more considerations to throw in.
> In particular, since this is a personal decision, having
> M-compatibility or not in a package is up to the developers.

Yes, that should mainly be decided by those directly affected from the
extra work.

> Also, if the package offers something that is not so easily found in
> proprietary software, then it is worth considering (from the ethical
> point of view) to force it t run only on free software by using
> octave's pidgin.

Just to throw in another argument, I once got a request whether the
interval package could be run in Scilab, which is free software (GPL 2.0).

One reason why this would not have been an easy task is that the package
sticks to Octave's syntax which is not supported by Scilab.

I don't know of any examples, but in general it should be a good idea to
share packages between Octave and Scilab (at least better than sharing
with Matlab).  Again, this would only be reasonable in an m-file lingua
franca.

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

Olaf Till-2
In reply to this post by Olaf Till-2
On Sun, Aug 20, 2017 at 05:15:50PM +0200, Olaf Till wrote:

> On Sat, Aug 19, 2017 at 10:01:35AM -0700, CdeMills wrote:
> > CdeMills wrote
> > > On Tue, 15 Aug 2017 13:00:06 +0200, Olaf Till wrote:
> > >> Pascal,
> > >>
> > >> there is still much to do:
> > >>
> > >> - Please pull from the repository, I've updated the root level
> > >>   Makefile.
> > >>
> >
> > Olaf,
> > the issues mentioned so far should have been solved in the last push I made
> > on SF:
> > 1) adapted the license texts as requested. Many files where touched by that.
> > 2) there was a longstanding bug in strsplit() call. In case more than one
> > separator are used (typically "\t" and ","), put them in a cellstr instead
> > of concatenating them in a single string
> > 3) one test failed as a matrix was accessed past its end. Corrected.
> >
> > Could you please have a look ?
>
> Extensive changes, thanks...
>
> I've pushed a change to the root level Makefile, to call
> dataframe_test in 'make check'.
>
> dataframe_test.m seems non-trivial to me, so could you add a copyright
> and license to it?
>
> Calling dataframe_test, lines 191--193 (left division) didn't pass for
> me without specifying a tolerance...
>
>
> The rest is ok for the release (though we didn't as yet discuss the
> 'Matlab oriented coding style' issue further).
>
> You probably don't need to upload a further tarball, it should be
> enough if I generate it at my machine after you've done the last
> polish to dataframe_test.m
>
> Olaf
Ping...

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OF packages using Matlab-compatible code (was "pending dataframe-1.2.0 release")

Juan Pablo Carbajal-2
In reply to this post by Oliver Heimlich
> Just to throw in another argument, I once got a request whether the
> interval package could be run in Scilab, which is free software (GPL 2.0).
>
would have it worked if it was Matlab's syntax? Last time I checked
Scilab wasn't exactly matlab compatible.
I agree however that it would be nice to have a sharing point with Scilab.

Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

CdeMills
In reply to this post by Olaf Till-2
On Tue, 22 Aug 2017 15:10:22 +0200, Olaf Till wrote:

> On Sun, Aug 20, 2017 at 05:15:50PM +0200, Olaf Till wrote:
>> On Sat, Aug 19, 2017 at 10:01:35AM -0700, CdeMills wrote:
>> > CdeMills wrote
>> > > On Tue, 15 Aug 2017 13:00:06 +0200, Olaf Till wrote:
>> > >> Pascal,
>> > >>
>> > >> there is still much to do:
>> > >>
>> > >> - Please pull from the repository, I've updated the root level
>> > >>   Makefile.
>> > >>
>> >
>> > Olaf,
>> > the issues mentioned so far should have been solved in the last
>> push I made
>> > on SF:
>> > 1) adapted the license texts as requested. Many files where
>> touched by that.
>> > 2) there was a longstanding bug in strsplit() call. In case more
>> than one
>> > separator are used (typically "\t" and ","), put them in a cellstr
>> instead
>> > of concatenating them in a single string
>> > 3) one test failed as a matrix was accessed past its end.
>> Corrected.
>> >
>> > Could you please have a look ?
>>
>> Extensive changes, thanks...
>>
>> I've pushed a change to the root level Makefile, to call
>> dataframe_test in 'make check'.
>>
>> dataframe_test.m seems non-trivial to me, so could you add a
>> copyright
>> and license to it?
>>
>> Calling dataframe_test, lines 191--193 (left division) didn't pass
>> for
>> me without specifying a tolerance...
>>
>>
>> The rest is ok for the release (though we didn't as yet discuss the
>> 'Matlab oriented coding style' issue further).
>>
>> You probably don't need to upload a further tarball, it should be
>> enough if I generate it at my machine after you've done the last
>> polish to dataframe_test.m
>>
Olaf,

the dataframe_test.m was a quick hack to locate one problem ... But
it's interesting anyway.
I will enclose things which are supposed to fail in a try/catch block,
to ensure a correct detection.
Release should occur within a few days.

Regards

Pascal




Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

Olaf Till-2
On Wed, Aug 23, 2017 at 09:35:04AM +0200, depuis wrote:
> Olaf,
>
> the dataframe_test.m was a quick hack to locate one problem ... But it's
> interesting anyway.
> I will enclose things which are supposed to fail in a try/catch block, to
> ensure a correct detection.
> Release should occur within a few days.

Don't forget the license for dataframe_test.m... that's the one
formality I can't do for others...

Regards, Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

CdeMills
In reply to this post by Olaf Till-2
On Tue, 22 Aug 2017 15:10:22 +0200, Olaf Till wrote:

> On Sun, Aug 20, 2017 at 05:15:50PM +0200, Olaf Till wrote:
>> On Sat, Aug 19, 2017 at 10:01:35AM -0700, CdeMills wrote:
>> > CdeMills wrote
>> > > On Tue, 15 Aug 2017 13:00:06 +0200, Olaf Till wrote:
>> > >> Pascal,
>> > >>
>> > >> there is still much to do:
>> > >>
>> > >> - Please pull from the repository, I've updated the root level
>> > >>   Makefile.
>> > >>
>> >
>> > Olaf,
>> > the issues mentioned so far should have been solved in the last
>> push I made
>> > on SF:
>> > 1) adapted the license texts as requested. Many files where
>> touched by that.
>> > 2) there was a longstanding bug in strsplit() call. In case more
>> than one
>> > separator are used (typically "\t" and ","), put them in a cellstr
>> instead
>> > of concatenating them in a single string
>> > 3) one test failed as a matrix was accessed past its end.
>> Corrected.
>> >
>> > Could you please have a look ?
>>
>> Extensive changes, thanks...
>>
>> I've pushed a change to the root level Makefile, to call
>> dataframe_test in 'make check'.
>>
>> dataframe_test.m seems non-trivial to me, so could you add a
>> copyright
>> and license to it?
Done

>> Calling dataframe_test, lines 191--193 (left division) didn't pass
>> for
>> me without specifying a tolerance...
Could you please tell me if the issue is still present ?

>> The rest is ok for the release (though we didn't as yet discuss the
>> 'Matlab oriented coding style' issue further).
This package would be useless to my students if they couldn't run it
under Matlab. They get it for free as students, why would
they care about Octave ? (paraphrasing their usual answer). I stopped
wasting time trying to explain about Free Software.


>> You probably don't need to upload a further tarball, it should be
>> enough if I generate it at my machine after you've done the last
>> polish to dataframe_test.m
>>
The 'make release' fails in a strange way:
1) it generate the main tarball
2) it fails with the error message 'generate_html not installed'
octave --no-gui --silent --no-history --norc --eval ' pkg
("local_list",
"/home/padupuis/Applications/Programmes/matlab-hg/octave-dataframe/target/.installation/.octave_packages");
' --eval ' pkg ("load", "dataframe"); '                    \
         --eval ' pkg load generate_html; ' \

The main issue seems to be that the usual package install path is
stripped down. I tried
'octave --no-gui --silent --no-history --norc --eval ' pkg -forge
-local install generate_html'
hoping that the package would be installed is some default path, bit
this failed too.

Regards

Pascal


Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

Olaf Till-2
On Wed, Aug 23, 2017 at 05:45:43PM +0200, depuis wrote:
> On Tue, 22 Aug 2017 15:10:22 +0200, Olaf Till wrote:
> >>Calling dataframe_test, lines 191--193 (left division) didn't pass for
> >>me without specifying a tolerance...
> Could you please tell me if the issue is still present ?

It seems so, with Octave-4.2.1:

FIXME -- should create a dataframe from the whole workspace
error: ASSERT errors for:  assert ((x \ y).array,x.array \ y)

  Location  |  Observed  |  Expected  |  Reason
   (1,1)       -1.7495      -1.7495      Abs err 4.4409e-16 exceeds tol 0
   (2,1)       0.25061      0.25061      Abs err 1.1102e-16 exceeds tol 0
   (3,1)       -2.1271      -2.1271      Abs err 4.4409e-16 exceeds tol 0
   (1,2)        2.1156       2.1156      Abs err 4.4409e-16 exceeds tol 0
   (2,2)       0.50236      0.50236      Abs err 3.3307e-16 exceeds tol 0
   (3,2)        2.8777       2.8777      Abs err 4.4409e-16 exceeds tol 0
   (2,3)       0.053649     0.053649     Abs err 6.9389e-18 exceeds tol 0
Makefile:221: recipe for target 'check' failed


with Octave-4.0.0 only this:

FIXME -- should create a dataframe from the whole workspace
error: ASSERT errors for:  assert ((x \ y).array,x.array \ y)

  Location  |  Observed  |  Expected  |  Reason
   (1,1)       0.16759      0.16759      Abs err 5.5511e-17 exceeds tol 0
   (2,1)       -1.2904      -1.2904      Abs err 4.4409e-16 exceeds tol 0
   (3,1)       0.27658      0.27658      Abs err 5.5511e-17 exceeds tol 0
Makefile:221: recipe for target 'check' failed

> >>You probably don't need to upload a further tarball, it should be
> >>enough if I generate it at my machine after you've done the last
> >>polish to dataframe_test.m
> >>
> The 'make release' fails in a strange way:
> 1) it generate the main tarball
> 2) it fails with the error message 'generate_html not installed'

The Makefile currently has the limitation that _locally_ installed
pre-requisite packages have to be installed _before_ 'make install'
and 'make release'.

To solve the problem, first install generate_html in the usual way,
the type 'make install' and then 'make release'. ('make release' alone
won't re-install the package, unless you delete target/ first).

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

CdeMills
On Wed, 23 Aug 2017 20:17:36 +0200, Olaf Till wrote:

> On Wed, Aug 23, 2017 at 05:45:43PM +0200, depuis wrote:
>> On Tue, 22 Aug 2017 15:10:22 +0200, Olaf Till wrote:
>> >>Calling dataframe_test, lines 191--193 (left division) didn't pass
>> for
>> >>me without specifying a tolerance...
>> Could you please tell me if the issue is still present ?
>
> It seems so, with Octave-4.2.1:
>
> FIXME -- should create a dataframe from the whole workspace
> error: ASSERT errors for:  assert ((x \ y).array,x.array \ y)
>
>   Location  |  Observed  |  Expected  |  Reason
>    (1,1)       -1.7495      -1.7495      Abs err 4.4409e-16 exceeds
> tol 0
>    (2,1)       0.25061      0.25061      Abs err 1.1102e-16 exceeds
> tol 0
>    (3,1)       -2.1271      -2.1271      Abs err 4.4409e-16 exceeds
> tol 0
>    (1,2)        2.1156       2.1156      Abs err 4.4409e-16 exceeds
> tol 0
>    (2,2)       0.50236      0.50236      Abs err 3.3307e-16 exceeds
> tol 0
>    (3,2)        2.8777       2.8777      Abs err 4.4409e-16 exceeds
> tol 0
>    (2,3)       0.053649     0.053649     Abs err 6.9389e-18 exceeds
> tol 0
> Makefile:221: recipe for target 'check' failed
>
>
> with Octave-4.0.0 only this:
>
> FIXME -- should create a dataframe from the whole workspace
> error: ASSERT errors for:  assert ((x \ y).array,x.array \ y)
>
>   Location  |  Observed  |  Expected  |  Reason
>    (1,1)       0.16759      0.16759      Abs err 5.5511e-17 exceeds
> tol 0
>    (2,1)       -1.2904      -1.2904      Abs err 4.4409e-16 exceeds
> tol 0
>    (3,1)       0.27658      0.27658      Abs err 5.5511e-17 exceeds
> tol 0
> Makefile:221: recipe for target 'check' failed
>

Pushed a fix for all tests implying left division

>> >>You probably don't need to upload a further tarball, it should be
>> >>enough if I generate it at my machine after you've done the last
>> >>polish to dataframe_test.m
>> >>
>> The 'make release' fails in a strange way:
>> 1) it generate the main tarball
>> 2) it fails with the error message 'generate_html not installed'
>
> The Makefile currently has the limitation that _locally_ installed
> pre-requisite packages have to be installed _before_ 'make install'
> and 'make release'.
>
> To solve the problem, first install generate_html in the usual way,
> the type 'make install' and then 'make release'. ('make release'
> alone
> won't re-install the package, unless you delete target/ first).
>
Tried so, still doesn't work. Could you generate and release the
package ?

Regards

Pascal


Reply | Threaded
Open this post in threaded view
|

Re: pending dataframe-1.2.0 release

Olaf Till-2
On Thu, Aug 24, 2017 at 08:30:05AM +0200, depuis wrote:
> Pushed a fix for all tests implying left division

Works for me, too, now.

> Tried so, still doesn't work. Could you generate and release the package ?

Done, thank you for the release. Please don't forget to announce it.

Regards, Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment