Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

textwidth is deprecated warning #1324

Closed
ExpandingMan opened this issue Dec 21, 2017 · 11 comments
Closed

textwidth is deprecated warning #1324

ExpandingMan opened this issue Dec 21, 2017 · 11 comments

Comments

@ExpandingMan
Copy link
Contributor

I get the following warning when displaying a DataFrame with strings

WARNING: textwidth is deprecated, use Compat.Unicode.textwidth instead.    
Stacktrace:                      
 [1] depwarn(::String, ::Symbol) at ./deprecated.jl:70 
 [2] textwidth(::String, ::Vararg{String,N} where N) at ./deprecated.jl:31
 [3] getmaxwidths(::DataFrames.DataFrame, ::UnitRange{Int64}, ::UnitRange{Int64}, ::Symbol) at /home/expandingman/.julia/v0.6/DataFrames/src/abstractdataframe/show.jl:96
 [4] show(::IOContext{Base.Terminals.TTYTerminal}, ::DataFrames.DataFrame, ::Bool, ::Symbol, ::Bool) at /home/expandingman/.julia/v0.6/DataFrames/src/abstractdataframe/show.jl:450
 [5] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::MIME{Symbol("text/plain")}, ::DataFrames.DataFrame) at ./REPL.jl:122
 [6] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::DataFrames.DataFrame) at ./REPL.jl:125
 [7] display(::DataFrames.DataFrame) at ./multimedia.jl:218               
 [8] eval(::Module, ::Any) at ./boot.jl:235                                                                                                                                                                           [9] print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, ::Bool, ::Void) at ./REPL.jl:144
 [10] print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, ::Bool) at ./REPL.jl:129                                                                                                                        [11] (::Base.REPL.#do_respond#16{Bool,Base.REPL.##26#36{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState, ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at ./REPL.jl:646                                                                                                                                             
 [12] eval(::Module, ::Any) at ./boot.jl:235                                                                                        
 [13] run_interface(::Base.Terminals.TTYTerminal, ::Base.LineEdit.ModalInterface) at ./LineEdit.jl:1583
 [14] run_frontend(::Base.REPL.LineEditREPL, ::Base.REPL.REPLBackendRef) at ./REPL.jl:945
 [15] run_repl(::Base.REPL.LineEditREPL, ::Base.##510#511) at ./REPL.jl:180
 [16] _start() at ./client.jl:413                                                                         
while loading no file, in expression starting on line 0       

on 11.2. This seems to come from here.

@nalimilan
Copy link
Member

Care yo make a PR?

@nalimilan
Copy link
Member

Though try on master first, as #1320 should have fixed this.

@ExpandingMan
Copy link
Contributor Author

ExpandingMan commented Dec 22, 2017

There's another error in master right now. In DataFrame(; kwargs...) the function Compat.pairs is returning elements of the form n::Int=>(s::Symbol, x::Any) when the constructor it's being provided to expects these to simply be (s::Symbol, x::Any). I assume this is for compatibility with 0.7 which passes keyword arguments as named tuples. This simplest fix of this would be to replace line 119 in dataframe.jl with

DataFrame((v.second[1]=>v.second[2] for v in A)...)

but I'm assuming this would break 0.7.

I'm not sure what the proper way of doing compat with named tuple arguments is...

@nalimilan
Copy link
Member

@bkamins has just noted the same thing at #1320. I guess any solution which works on both 0.6 and 0.7 will do, given that everything is broken right now.

@ExpandingMan
Copy link
Contributor Author

Ok... I'd really like to make a PR and actually be helpful, but I don't have 0.7 set up at all, so I'll have to leave it to someone else at least for now.

@ararslan
Copy link
Member

The definition of pairs in Compat may be incorrect. We should check that first.

@ExpandingMan
Copy link
Contributor Author

I suspect you are right. The current output of pairs doesn't make a whole lot of sense.

@bkamins
Copy link
Member

bkamins commented Dec 23, 2017

The problem with pairs and keyword arguments is that the API completely changed very much.

If in Compat we make pairs behave exactly like it behaves on 0.7 (it does not now) this will not fix the problem. Alo Compat currently does not define keys for Tuple and 0.7 does.

I do not know what best practice for such situations was in the past but I guess that we will have to have a custom code in DataFrames anyway (but agreed that we first should resolve Compat issue).

@nalimilan
Copy link
Member

See #1329 about keyword arguments.

The textwidth deprecation warning on Julia 0.6 is a weird result of JuliaLang/Compat.jl#432, I've commented there.

@nalimilan
Copy link
Member

JuliaLang/Compat.jl#437 fixes the textwidth warning on Julia 0.6.

@ExpandingMan
Copy link
Contributor Author

ExpandingMan commented Jan 2, 2018

Both the textwidth deprecation warning and the keyword argument issue seem to be fixed on the most recent tagged versions of DataFrames (0.11.3) and Compat (0.42.0).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants