[Octave-bug-tracker] [bug #60138] [octave forge] (dataframe) `dataframe` incorrectly parses csv entries containing commas inside quotes

[Tasos Papastylianou]

Follow-up Comment #2, bug #60138 (project octave):

Hi Pascal!

First let me say that I do not mean to disparage your efforts. Clearly the
dataframe package is a gargantuan effort over many years, and it's clear from
the dev logs that you've invested quite a lot of time and love on it.

The reason I mention csv2cell here is not to point out that "someone else has
done it correctly". It is because I imagined that a fix calling csv2cell under
the hood is likely to be much less painful than trying to replicate that
functionality within dataframes, hence I pointed it out hoping it might be a
helpful suggestion. (and also, until this bug is patched, if any users come
across this thread, it might also help them by suggesting "dataframe(
csv2cell(" as a temporary workaround).

As for the other bug, as I mentioned in bug #56263, perhaps you could consider
creating a release? That bug has been fixed ages ago, it's a shame that the
existing release does not contain it.

Regarding the "switch to R" comment, or any other language for that matter, I
don't think that's the appropriate response - and definitely not simply just
to obtain a dataframe container. In fact, dataframes in R are nothing more
than a list with vector elements of consistent size as its fields - meaning,
in theory, one could replicate their full functionality using structs with
similar vectors as fields. But of course, simply having such a construct isn't
enough; one needs a nice collection of functions specialised for such a
container. Which is exactly the benefit of your package (though I'm assuming
your implementation does not necessarily rely on structs as mentioned here).

As someone who is well versed in octave, matlab, R, python and julia among
others, I see great things in all these languages, and I most certainly do not
consider octave the 'weaker player' in that list (even if the community of
package contributors is smaller - and as Kai has pointed out elsewhere, I
guess there are historical reasons for that, that may be worth addressing
going forward, to help the community become more active and more
project-independent when it comes to creating packages). Therefore I'm
slightly saddened at your suggestion here (and on stackoverflow) that one
should simply 'switch to R' for more serious computing...

Also, keep in mind, at least from what I see on stackoverflow, Octave has
risen in popularity quite a bit in recent years -- a major driving force, I
think, has been its promotion by Andrew Ng's original Machine Learning course
on Coursera, which promotes Octave as the de-facto language for his course.
This has been huge. But with increased exposure, there will be more users
drawn to it, and therefore more users encountering bugs. This is natural, and
something we, as a community, should be embracing, and nothing to shy away
from, let alone admit defeat and redirect to other languages!

I'm happy to have a look and create a merge request on sourceforge if I can
help. But in the meantime, please, keep up the good work, and do seek help
from octave's brilliant community if you're overwhelmed for time and manpower.
Don't just push them away to another language (as great as that other language
might also be). Let's help make octave a tiny bit better instead, one step at
a time :)

In the meantime, I think if you are happy to create a release that simply
includes the existing fix for bug #56263, I know for a fact that there's at
least one user of your package on stackoverflow  who's struggling with a
deadline, that you'd be making very happy :)

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60138>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/