It was probably some version incompatibility issues then.
It is not easy to know how much info is required to solve a problem.
Sometimes you are lucky and it is a silly mistake that someone recognize
and just tell you how to fix the issue. Other times you are unlucky and
nobody understand what
Sorry for not providing enough information - new domain here for me so Im
not sure what's useful and what's not for debugging. My last issue was
debugged with a similar post so figured the same would be true here. Guess
not ;)
Anyways, I seem to have resolved the issue by just starting over f
Or just
versioninfo(true)
Which combines the two functions.
kl. 19:52:47 UTC+1 tirsdag 4. mars 2014 skrev Jacob Quinn følgende:
>
> Yeah, with how much DataFrames has been moving lately, we at least need to
> know which version you're running. Can you post the output of
>
> versioninfo()
> Pkg.
Yeah, with how much DataFrames has been moving lately, we at least need to
know which version you're running. Can you post the output of
versioninfo()
Pkg.status()
-Jacob
On Tue, Mar 4, 2014 at 1:48 PM, Ivar Nesje wrote:
> You might get much more response if you provide a (minmal?) executable
You might get much more response if you provide a (minmal?) executable
example. I can neither verify, nor help debug this issue, as I do not know
what the result variable is. If nobody else recognize the issue from their
own experience, and the rest of us do not have some code to run, we can not
Just checking one last time to see if anyone has any ideas. This has been
a showstopper for us Open to trying any suggestions :)
- - Dan
On Thursday, February 27, 2014 7:31:33 PM UTC-8, Dan B wrote:
>
> Friends,
>
> Any idea on how I can resolve this error that Im seeing while trying to
> sho
Okay so yeah - those lines don't exist anymore in show.jl, so I couldn't
use the workaround. Appreciate any advice.
Thanks in advance,
- - Dan
On Thursday, February 27, 2014 7:31:33 PM UTC-8, Dan B wrote:
>
> Friends,
>
> Any idea on how I can resolve this error that Im seeing while trying to
Correction... there is a workaround in there that I missed... will give it
a shot.
On Thursday, February 27, 2014 7:31:33 PM UTC-8, Dan B wrote:
>
> Friends,
>
> Any idea on how I can resolve this error that Im seeing while trying to
> show the contents of a DataFrame?
>
> julia> head(results)
>
Actually looks like it might be this
- https://groups.google.com/d/topic/julia-users/VmgmRnBCo9I/discussion
No workaround yet it seems.
On Thursday, February 27, 2014 7:31:33 PM UTC-8, Dan B wrote:
>
> Friends,
>
> Any idea on how I can resolve this error that Im seeing while trying to
> show t
Yeah, that seems totally reasonable to me. If we do this in a more formal way,
I’m now onboard.
Let’s add the idea of explicit restrictions on columns that can and can’t
contain NA’s to the spec: https://github.com/JuliaStats/DataFrames.jl/issues/502
— John
On Jan 23, 2014, at 8:21 PM, Sean G
My first thought was a Vector{Bool}.
On Thursday, January 23, 2014 10:05:25 PM UTC-6, John Myles White wrote:
>
> Ok. I’m coming around to this.
>
> How would you do I/O? If we make DataFrames expose a nullable property, we
> could plausibly produce vectors instead of data vectors when parsing CS
Ok. I’m coming around to this.
How would you do I/O? If we make DataFrames expose a nullable property, we
could plausibly produce vectors instead of data vectors when parsing CSV files.
— John
On Jan 23, 2014, at 7:38 PM, Sean Garborg wrote:
> I'd think of #3 as a feature, too.
>
> Just to
I'd think of #3 as a feature, too.
Just to throw another use case in the ring, if DataFrames with a mix of
Vectors and DataVectors (with NAs) were performant, my co-workers and I
would usually pull in data marking all columns as Vectors, these columns
would remain Vectors, and derived columns w
I would be a lot happier with that feature if we followed the lead of
traditional databases and constantly reminded users which columns are “NOT
NULL”. As it stands, the “types” of a DataFrame don’t tell you whether a column
could contain NA’s or not. If we exposed functionality through somethin
I think of item #3 as a feature, not a bug. I don't like the idea of
auto-conversion. If I choose Vectors, I should not expect them to
support missing values. R sometimes irritates me by adding NA's when I
don't expect it. I'd rather have the error than have NA's sneak in
there. Also, there may be
A couple of points that expand on Tom’s comments:
(1) We need to add Tom’s definition of countna(a::Array) = 0 to show() wide
DataFrame’s that contain any columns that are Vector’s. I never use DataFrame’s
like that, so I forgot that others might. It’s also impossible to produce such
a DataFram
That works, but columns will be Arrays instead of DataArrays. That's
the way it's always worked. If you want them to be DataArrays, then
convert to DataArrays right at the end.
To fix show to support columns that are arrays, we probably need (at
least) to define the following:
countna(da::Array)
Great investigative work. Is
DataFrames( array_of_arrays, Index(column_names_array) )
not the right way to hand construct DataFrames any more? I think I can
allocate DataArrays instead, but at every step of the way, I was trying to
hand-optimize the result fetching process, which resulted in not cr
To check Jacob's suggestion about versions mismatch I completely removed
the DataFrames and ODBC packages using Pkg.rm and physically deleted the
directories from disk. I then added them via Pkg.add and Pkg,update.
I am running the julia nightlies build.
julia> versioninfo()
Julia Version 0.3.
19 matches
Mail list logo
