FR, @comment #1:
The original author of csv2ell (& cell2csv and others) is Laurent Mazet. I did extend his work somewhat to cope with e.g., Excel-style ranges etc. and to keep it running in the io package.
csv2cell is a life-saver sometimes. At work with Matlab, reading large mixed-type csv files is extremely slow using importdata and textscan and often needs lots of postprocessing. csv2cell loads the same very large csv files in a jiffy and its output only needs minor polishing.

[OT]
I tend to agree with Tasos' musings about languages in general although I'm afraid Octave's niche is (very) slowly declining (or other languages simply grow faster). Too bad as especially during the last years the project has attracted several talented and active developers.
IMO a big plus of Octave (and Matlab) is that it offers a structured computing environment. E.g., for Python I found there's often a plethora of several incompatible packages for each job; not handy if at a late stage one gets stuck because at the start a less optimal choice was made.
As to R: does that support OOP? (It's used extensively at my work but I'm not very familiar with it).

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 :)

This bug is in reference to this stackoverflow post: https://stackoverflow.com/q/66389166/4183191

There is another bug in that question, which is already being dealt with by #56263, namely that the second column is inappropriately truncated if it only contains strings. Apparently this was fixed in the dev repo a few years back, but still not released. This report is not for this bug.

This report is for another bug resulting from the same csv data. I reproduce the offending data below:

"TIME","GEO","UNIT","S_ADJ","NA_ITEM","Value","Flag and Footnotes"
"1995Q1","Greece","Chain linked volumes, index 2010=100","Seasonally and calendar adjusted data","Gross domestic product at market prices","72.5",""
"1995Q2","Greece","Chain linked volumes, index 2010=100","Seasonally and calendar adjusted data","Gross domestic product at market prices","73.2",""

Suppose one attempts to load this file, e.g. as

D = dataframe( 'data.csv' );

As you can see, the above should result in a field UNIT with value: "Chain linked volumes, index 2010=100"
However dataframe incorrectly treats the comma here as a delimiter, and assigns the second part of this element to the S_ADJ field instead.

As a workaround, I note that the cell2csv function from the io package deals with this correctly instead.

Therefore:

dataframe( cell2csv( 'data.csv' ) );

works as expected (barring bug #56263, that is).