juliadata / namedtuples.jl Goto Github PK

Julia 1.0 and windows 10
I installed Makie (which is only very recently compatible with 1.0)
I then get a problem with NamedTuples.
I ran rm NamedTuples then tried to add that package again

v1.0) pkg> add NamedTuples
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package NamedTuples [73a701b4]:
NamedTuples [73a701b4] log:
├─possible versions are: [0.0.1-0.0.3, 0.1.0, 1.0.0, 2.0.0, 2.1.0, 3.0.0-3.0.3, 4.0.0-4.0.2] or uninstalled
├─restricted to versions 4.0.2 by an explicit requirement, leaving only versions 4.0.2
└─restricted by julia compatibility requirements to versions: uninstalled — no versions left

Looks like one of my other packages has a strict requirement for a version of NamedTuples which cannot be satisfied. How do I debug which one please?

Hello,

A NamedTuple can be created using

julia> @NT(x,y)(1,2)
(x = 1, y = 2)

but I wonder if there is a way to create a NamedTuple using a tuple of symbols and a tuple of values.
Something like:

julia> @NT(:x, :y)(1,2)

Any idea?

@mdcfrancis I have a whole bunch of suggestions for changes that would help Query.jl enormously. Query.jl depends heavily on NamedTuples (heck, it wouldn't exist without NamedTuples). I'll post each suggestion as a separate issue. I'm mainly looking for feedback whether you would consider these changes, I could probably implement them as PRs myself if you agree.

The first suggestion is to change the construction syntax from:

@NT( a => 1, b => "hello")

to

@NT( a = 1, b = "hello")

The main benefit would be less typing... People will construct very, very many NamedTuples in Query.jl, and anything that makes constructing NamedTuples simpler would help.

It would also make things cleaner in combination with another recommendation I have, I'll point that out once the other issue is open.

I'm not sure how concerned you are about backwards compat, but if such a breaking change is a problem, it should be fairly simply to phase this in over two release cycles, i.e. have one release where the old syntax throws a deprecation warning, but both new and old syntax are supported, and then the old syntax goes away in the next release.

At the moment merge can merge only two named tuples at a time. It would be good to extend this to allow for collections of named tuples.

It would be great if the folllowing syntax would work for merging NamedTuples:

nt1 = @NT( a=>1, b=>2, c=>3 )
nt2 = @NT( d=>4, e=>5)
@NT(nt1..., f=>"something else",nt2...)

would construct a NamedTuple (a=>1,b=>2,c=>3,f=>"something else",d=>4,e=>5).

The following will cause an infinite error message and crash julia or flood the RAM

a = zeros(2)
a .= @NT( a1=1, a2=2 )

On 0.6.2

On master, I'm seeing

WARNING: names(v) is deprecated, use fieldnames(v) instead.

When creating a simple package and trying to pre-compile:

__precompile__()
module MyPackage
using NamedTuples

const a_named_tuple = @NT(a = 1, b = 2)
end

I get the following error:

julia> using MyPackage
INFO: Recompiling stale cache file XXX/julia/lib/v0.5/MyPackage.ji for module MyPackage.
WARNING: eval from module NamedTuples to MyPackage:
Expr(:type, false, Expr(:<:, Expr(:curly, :_NT_a_b, :T1, :T2)::Any, :NamedTuple)::Any, Expr(:block, Expr(:::, :a, :T1)::Any, Expr(
:::, :b, :T2)::Any)::Any)::Any
  ** incremental compilation may be broken for this module **


signal (11): Segmentation fault: 11
while loading no file, in expression starting on line 0
jl_deserialize_value_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:1743
jl_deserialize_datatype at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:1238 [inlined]
jl_deserialize_value_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:1736
jl_deserialize_value_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:1733
jl_deserialize_value_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:1668
jl_deserialize_value_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:1485
_jl_restore_incremental at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:2532
jl_restore_incremental at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/dump.c:2580
_include_from_serialized at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
_require_from_serialized at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
require at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jlcall_require_22363 at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jl_call_method_internal at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 [inlined]
jl_apply_generic at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.h:1392 [inlined]
eval_import_path_ at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:402
eval_import_path at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:429 [inlined]
jl_toplevel_eval_flex at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/toplevel.c:480
jl_toplevel_eval_in_warn at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/builtins.c:590
eval at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jlcall_eval_19762 at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jl_call_method_internal at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 [inlined]
jl_apply_generic at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942
eval_user_input at ./REPL.jl:64
unknown function (ip: 0x322bfc0e6)
jl_call_method_internal at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 [inlined]
jl_apply_generic at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942
macro expansion at ./REPL.jl:95 [inlined]
#3 at ./event.jl:68
unknown function (ip: 0x322bf2fdf)
jl_call_method_internal at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia_internal.h:189 [inlined]
jl_apply_generic at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gf.c:1942
jl_apply at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/./julia.h:1392 [inlined]
start_task at /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/task.c:253
Allocations: 1878057 (Pool: 1877182; Big: 875); GC: 1
zsh: segmentation fault  julia

Any call to @NT seem to have the same effect.
I'm using julia v0.5 on OS/X, installed from homebrew.

Hi - I'm new to Julia. I'm not able to load NamedTuples.

[julia> using NamedTuples
[ Info: Precompiling NamedTuples [73a701b4-84e1-5df0-88ff-1968ee2ee8dc]
ERROR: LoadError: UndefVarError: start not defined
Stacktrace:
 [1] getproperty(::Module, ::Symbol) at ./sysimg.jl:13
 [2] top-level scope at none:0
 [3] include at ./boot.jl:317 [inlined]
 [4] include_relative(::Module, ::String) at ./loading.jl:1038
 [5] include(::Module, ::String) at ./sysimg.jl:29
 [6] top-level scope at none:2
 [7] eval at ./boot.jl:319 [inlined]
 [8] eval(::Expr) at ./client.jl:389
 [9] top-level scope at ./none:3
in expression starting at /Users/sidravinutala/.julia/packages/NamedTuples/MIrnh/src/NamedTuples.jl:16
ERROR: Failed to precompile NamedTuples [73a701b4-84e1-5df0-88ff-1968ee2ee8dc] to /Users/sidravinutala/.julia/compiled/v1.0/NamedTuples/SN1pr.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] macro expansion at ./logging.jl:313 [inlined]
 [3] compilecache(::Base.PkgId, ::String) at ./loading.jl:1184
 [4] _require(::Base.PkgId) at ./logging.jl:311
 [5] require(::Base.PkgId) at ./loading.jl:852
 [6] macro expansion at ./logging.jl:311 [inlined]
 [7] require(::Module, ::Symbol) at ./loading.jl:834

I installed NamedTuples using Pkg. Here's my environment

(v1.0) pkg> status
    Status `~/.julia/environments/v1.0/Project.toml`
  [c52e3926] Atom v0.7.3
  [336ed68f] CSV v0.3.1
  [a93c6f00] DataFrames v0.13.1
  [38e38edf] GLM v0.11.0
  [28b8d3ca] GR v0.32.3
  [7073ff75] IJulia v1.9.3
  [699e389a] IntroToJulia v0.0.0 [`~/.julia/dev/IntroToJulia`]
  [42fd0dbc] IterativeSolvers v0.7.1
  [e5e0dc1b] Juno v0.5.2
  [6f286f6a] MultivariateStats v0.5.0
  [73a701b4] NamedTuples v4.0.2
  [58dd65bb] Plotly v0.1.1
  [f0f68f2c] PlotlyJS v0.10.2
  [91a5bcdd] Plots v0.19.3
  [1a8c2f83] Query v0.9.3
  [189a3867] Reexport v0.2.0
  [1986cc42] Unitful v0.11.0
  [0f1e0344] WebIO v0.3.0

Any help would be greatly appreciated! Thank you.

This work:

key = @NT(a="aaa")
key = merge(key, @NT(b=1))

But this doesn't:

key = @NT(a)
key = merge(key, @NT(b))

or

key = @NT()
key = merge(key, @NT(a))

Could someone make me a co-maintainer of this package? I'd like to help out. In reality I have done that over the last two years in any case (if you look at the contribution page), and secondly my suite of packages is probably one of the larger users of this package, so I'd like to help make sure we don't break things.

Not sure whom to ping, so I'll just try the usual suspects: @quinnj, @nalimilan, @ararslan.

I am trying to use NamedTuples in my package, but couldn't find out how we are supposed to loop over key/value pairs, my attempt below failed:

nt = @NT(a=1, b=2.0)
for (k,v) in nt
  println(k, " = ", v)
end

I was spent some time getting more familiar with the NamedTuples code and I think the best way to have this package be both Julia 0.6 and 0.7 compatible would be to:

1. Remove some of the NamedTuples.jl features that aren't supported in 0.7 (e.g. getindex(::NamedTuple, ::AbstractVector) -> NamedTuple)
2. Make abstract type NamedTuple end in 0.6 be abstract type NamedTuple{K, V<:Tuple} end to be more consistent with 0.7. With this change we should also be able to deprecate the @NT(a::Int64, b::Float64) and @NT( a, b )( 1, "hello") syntax.

The following

foo() = @NT(a=1)

is no longer type-stable, if I try @code_warntype foo(). Previous versions were type-stable for this.

@JeffBezanson I think this must have been caused by one of your recent commits? Any chance you could look at this? Query completely breaks if that is not type-stable.

I think that nfield(x::DataType) returns a wrong result on the current master version with Julia 0.6.

using NamedTuples
x = @NT(a = 0.0, b = 0.0, c = 0.0)
nfields(NamedTuples._NT_a_b_c)
# returns 2 while I expected 3

The registered version on Metadata with Julia 0.5 returns 3, which is the answer I expected

Description

When trying to use the Query package, the following error is generated:

julia> using Query
[ Info: Precompiling Query [1a8c2f83-1ff3-5112-b086-8aa67b057ba1]
ERROR: LoadError: UndefVarError: start not defined
Stacktrace:
 [1] getproperty(::Module, ::Symbol) at .\sysimg.jl:13
 [2] top-level scope at none:0
 [3] include at .\boot.jl:317 [inlined]
 [4] include_relative(::Module, ::String) at .\loading.jl:1038
 [5] include(::Module, ::String) at .\sysimg.jl:29
 [6] top-level scope at none:2
 [7] eval at .\boot.jl:319 [inlined]
 [8] eval(::Expr) at .\client.jl:389
 [9] top-level scope at .\none:3
in expression starting at C:\Users\bas\.julia\packages\NamedTuples\MIrnh\src\NamedTuples.jl:16
ERROR: LoadError: Failed to precompile NamedTuples [73a701b4-84e1-5df0-88ff-1968ee2ee8dc] to C:\Users\bas\.julia\compiled\v1.0\NamedTuples\SN1pr.ji.
Stacktrace:
 [1] error(::String) at .\error.jl:33
 [2] macro expansion at .\logging.jl:313 [inlined]
 [3] compilecache(::Base.PkgId, ::String) at .\loading.jl:1184
 [4] _require(::Base.PkgId) at .\logging.jl:311
 [5] require(::Base.PkgId) at .\loading.jl:852
 [6] macro expansion at .\logging.jl:311 [inlined]
 [7] require(::Module, ::Symbol) at .\loading.jl:834
 [8] include at .\boot.jl:317 [inlined]
 [9] include_relative(::Module, ::String) at .\loading.jl:1038
 [10] include(::Module, ::String) at .\sysimg.jl:29
 [11] top-level scope at none:2
 [12] eval at .\boot.jl:319 [inlined]
 [13] eval(::Expr) at .\client.jl:389
 [14] top-level scope at .\none:3
in expression starting at C:\Users\bas\.julia\packages\Query\VIFkY\src\Query.jl:4
ERROR: Failed to precompile Query [1a8c2f83-1ff3-5112-b086-8aa67b057ba1] to C:\Users\bas\.julia\compiled\v1.0\Query\wGX7b.ji.
Stacktrace:
 [1] error(::String) at .\error.jl:33
 [2] macro expansion at .\logging.jl:313 [inlined]
 [3] compilecache(::Base.PkgId, ::String) at .\loading.jl:1184
 [4] macro expansion at .\logging.jl:311 [inlined]
 [5] _require(::Base.PkgId) at .\loading.jl:941
 [6] require(::Base.PkgId) at .\loading.jl:852
 [7] macro expansion at .\logging.jl:311 [inlined]
 [8] require(::Module, ::Symbol) at .\loading.jl:834

Environment:

• NamedTuples v4.0.2, [73a701b4]
• Julia 1.0
• OS Name : Microsoft Windows 10 Pro N
• OS Version : 10.0.17134 N/A Build 17134
• System Type : x64-based PC
• System Locale : en-us;English (United States)
• Hotfix(s) : 5 Hotfix(s) Installed.,[01]: KB4287903,[02]: KB4338832,[03]: KB4343669,[04]: KB4343902,[05]: KB4343909

I got a compile error below.

This error occurs because Julia's iteration interface is changed since v0.7.
iterators-in-julia-0.7

julia> using Query
[ Info: Precompiling Query [1a8c2f83-1ff3-5112-b086-8aa67b057ba1]
ERROR: LoadError: UndefVarError: start not defined
Stacktrace:
[1] getproperty(::Module, ::Symbol) at .\sysimg.jl:13
[2] top-level scope at none:0
[3] include at .\boot.jl:317 [inlined]
[4] include_relative(::Module, ::String) at .\loading.jl:1038
[5] include(::Module, ::String) at .\sysimg.jl:29
[6] top-level scope at none:2
[7] eval at .\boot.jl:319 [inlined]
[8] eval(::Expr) at .\client.jl:389
[9] top-level scope at .\none:3
in expression starting at D:\sys\sbin\Julia-1.0.0\juliapath\packages\NamedTuples\MIrnh\src\NamedTuples.jl:16
ERROR: LoadError: Failed to precompile NamedTuples [73a701b4-84e1-5df0-88ff-1968ee2ee8dc] to D:\sys\sbin\Julia-1.0.0\juliapath\compiled\v1.0\NamedTuples\SN1pr.ji.
Stacktrace:
[1] error(::String) at .\error.jl:33
[2] macro expansion at .\logging.jl:313 [inlined]
[3] compilecache(::Base.PkgId, ::String) at .\loading.jl:1184
[4] _require(::Base.PkgId) at .\logging.jl:311
[5] require(::Base.PkgId) at .\loading.jl:852
[6] macro expansion at .\logging.jl:311 [inlined]
[7] require(::Module, ::Symbol) at .\loading.jl:834
[8] include at .\boot.jl:317 [inlined]
[9] include_relative(::Module, ::String) at .\loading.jl:1038
[10] include(::Module, ::String) at .\sysimg.jl:29
[11] top-level scope at none:2
[12] eval at .\boot.jl:319 [inlined]
[13] eval(::Expr) at .\client.jl:389
[14] top-level scope at .\none:3
in expression starting at D:\sys\sbin\Julia-1.0.0\juliapath\packages\Query\VIFkY\src\Query.jl:4
ERROR: Failed to precompile Query [1a8c2f83-1ff3-5112-b086-8aa67b057ba1] to D:\sys\sbin\Julia-1.0.0\juliapath\compiled\v1.0\Query\wGX7b.ji.
Stacktrace:
[1] error(::String) at .\error.jl:33
[2] macro expansion at .\logging.jl:313 [inlined]
[3] compilecache(::Base.PkgId, ::String) at .\loading.jl:1184
[4] macro expansion at .\logging.jl:311 [inlined]
[5] _require(::Base.PkgId) at .\loading.jl:941
[6] require(::Base.PkgId) at .\loading.jl:852
[7] macro expansion at .\logging.jl:311 [inlined]
[8] require(::Module, ::Symbol) at .\loading.jl:834
[9] eval at .\boot.jl:319 [inlined]
[10] #9 at D:\sys\sbin\Julia-1.0.0\juliapath\packages\Atom\jodeb\src\repl.jl:129 [inlined]
[11] with_logstate(::getfield(Main, Symbol("##9#11")), ::Base.CoreLogging.LogState) at .\logging.jl:397
[12] with_logger(::Function, ::Atom.Progress.JunoProgressLogger) at .\logging.jl:493
[13] top-level scope at D:\sys\sbin\Julia-1.0.0\juliapath\packages\Atom\jodeb\src\repl.jl:128

Hello,

You are probably aware of JuliaLang/julia#22194
I wonder what will be roadmap for this package as NamedTuples have been merged recently in Julia master branch

Kind regards

I just tried to install NamedTuples in Julia 1.0, and I got the following error message:

julia> using NamedTuples
[ Info: Precompiling NamedTuples [73a701b4-84e1-5df0-88ff-1968ee2ee8dc]
ERROR: LoadError: UndefVarError: start not defined
Stacktrace:
 [1] getproperty(::Module, ::Symbol) at ./sysimg.jl:13
 [2] top-level scope at none:0
 [3] include at ./boot.jl:317 [inlined]
 [4] include_relative(::Module, ::String) at ./loading.jl:1038
 [5] include(::Module, ::String) at ./sysimg.jl:29
 [6] top-level scope at none:2
 [7] eval at ./boot.jl:319 [inlined]
 [8] eval(::Expr) at ./client.jl:389
 [9] top-level scope at ./none:3
in expression starting at /Users/martink/.julia/packages/NamedTuples/MIrnh/src/NamedTuples.jl:16
ERROR: Failed to precompile NamedTuples [73a701b4-84e1-5df0-88ff-1968ee2ee8dc] to /Users/martink/.julia/compiled/v1.0/NamedTuples/SN1pr.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] macro expansion at ./logging.jl:313 [inlined]
 [3] compilecache(::Base.PkgId, ::String) at ./loading.jl:1184
 [4] _require(::Base.PkgId) at ./logging.jl:311
 [5] require(::Base.PkgId) at ./loading.jl:852
 [6] macro expansion at ./logging.jl:311 [inlined]
 [7] require(::Module, ::Symbol) at ./loading.jl:834

The problem seems to be that NamedTuples is trying to overload Base.start in NamedTuples.jl, which no longer exists in Julia 1.0.

I'm not familiar enough with the code base to fix this issue myself, any help would be greatly appreciated.

It should be noted that this issue also means that installing IndexedTables and JuliaDB currently throws an error message in 1.0...

Installing NAmedTuples on v 1.0.0 on Windows 10 it is a required packaged for Queryverse

Somehow I think I have got something configured wrong.

(v1.0) pkg> test NamedTuples
Testing NamedTuples
Status C:\Users\hearn\AppData\Local\Temp\jl_67BB.tmp\Manifest.toml
[73a701b4] NamedTuples v4.0.2
ERROR: LoadError: UndefVarError: start not defined
Stacktrace:
[1] getproperty(::Module, ::Symbol) at .\sysimg.jl:13
[2] top-level scope at none:0
[3] include at .\boot.jl:317 [inlined]
[4] include_relative(::Module, ::String) at .\loading.jl:1038
[5] include(::Module, ::String) at .\sysimg.jl:29
[6] top-level scope at none:2
[7] eval at .\boot.jl:319 [inlined]
[8] eval(::Expr) at .\client.jl:389
[9] top-level scope at .\none:3
in expression starting at C:\Users\hearn.julia\packages\NamedTuples\MIrnh\src\NamedTuples.jl:16
ERROR: LoadError: Failed to precompile NamedTuples [73a701b4-84e1-5df0-88ff-1968ee2ee8dc] to C:\Users\hearn.julia\compiled\v1.0\NamedTuples\SN1pr.ji.
Stacktrace:
[1] error(::String) at .\error.jl:33
[2] macro expansion at .\logging.jl:313 [inlined]
[3] compilecache(::Base.PkgId, ::String) at .\loading.jl:1184
[4] _require(::Base.PkgId) at .\logging.jl:311
[5] require(::Base.PkgId) at .\loading.jl:852
[6] macro expansion at .\logging.jl:311 [inlined]
[7] require(::Module, ::Symbol) at .\loading.jl:834
[8] include at .\boot.jl:317 [inlined]
[9] include_relative(::Module, ::String) at .\loading.jl:1038
[10] include(::Module, ::String) at .\sysimg.jl:29
[11] include(::String) at .\client.jl:388
[12] top-level scope at none:0
in expression starting at C:\Users\hearn.julia\packages\NamedTuples\MIrnh\test\runtests.jl:1
ERROR: Package NamedTuples errored during testing

#9

@davidanthoff wrote - One thing that this PR changes and that broke my stuff is that make_tuples now returns an expression that can't just be evaluated in the current module because the named tuple is now always defined in the NamedTuples module. It might be nice if the expression returned by make_tuples actually included the fully qualified name of the type, i.e. including the module name NamedTuples. But from my side you can merge right now.

julia> using NamedTuples

julia> NamedTuples.setindex(@NT(a=1, b=2), :b, "cde")
(a = 1, b = 2)

I would have thought the result would be (a = 1, b = "cde")

Would it be possible to have a function NT? Or would it be less performant than the macro @NT?

# either this syntax
NT(a = 1, b = 2)
# or this syntax
NT(:a => 1, :b => 2)
# would return the same thing as @NT(a = 1, b = 2)

It would be great if the following syntax

a = 3
b = "something"
x = @NT(a,b)

would be equivalent to

x = @NT(a=>a,b=>b)

Ideally this would also work with immutables in the following way:

a = @NT(somename => 34)
x = @NT(a.somename)

and then x would have one member with name somename. In cases where no name can be inferred it could assign automatic names:

x = @NT(x^2)

would assign an automatic name to its one member.

This syntax would obviously break the current syntax for defining NamedTuples... But maybe that could just get its own macro, e.g. @DNT or something like that?

I expected the following works but it doesn't:

julia> using NamedTuples

julia> convert(@NT(foo::Int,bar::String), (42, "bar"))
ERROR: MethodError: Cannot `convert` an object of type Tuple{Int64,String} to an object of type NamedTuples._NT_foo_bar{Int64,String}
This may have arisen from a call to the constructor NamedTuples._NT_foo_bar{Int64,String}(...),
since type constructors fall back to convert methods.

Is there any reason not to support conversion from tuples?

I'm trying to create a somewhat large NamedTuple, and I get an error

ERROR: type too large
 in create_tuple(::Array{Symbol,1}) at C:\Users\anthoff\.julia\v0.5\NamedTuples\src\NamedTuples.jl:124
 in make_tuple(::Array{Expr,1}) at C:\Users\anthoff\.julia\v0.5\NamedTuples\src\NamedTuples.jl:165
 in getiterator(::DataFrames.DataFrame) at C:\Users\anthoff\.julia\v0.5\IterableTables\src\integrations\dataframes.jl:28

on julia 0.5.1.

The type I'm trying to create is this:

immutable _NT_API_FileNo_OriginalOperator_OriginalWellName_CurrentOperator_CurrentWellName_FieldName_CountyName_Township_Range_Section_QQ_Footages_Hole__Type_LATITUDE_LONGITUDE_FirstSpudDate_MeasuredTD_KBElev_DFElev_GRElev_GLElev_TY__BCHR_TY__BCHN_K__P_K__PJRS_K__PES_K__NB_K__GH_K__M_K__N_K__IK_J__S_J__R_T__S_PM__MK_PM__OP_PM__EBA_PM__BC_PN__T_M__EBS_M__BS_M__KL_M__MDUN_M__MD_M__MDR_M__MDLS_M__MDFA_M__MDFY_M__MDSA_M__MDTI_M__MDLP_MD__B_D__DV_D__TF_D__BB_D__DP_D__SR_D__DB_D__PE_D__W_S__I_S__CL_O__G_O__ST_O__RR_O__WR_O__WI_O__BI_CO__D_PC_LogsOnFile{T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18,T19,T20,T21,T22,T23,T24,T25,T26,T27,T28,T29,T30,T31,T32,T33,T34,T35,T36,T37,T38,T39,T40,T41,T42,T43,T44,T45,T46,T47,T48,T49,T50,T51,T52,T53,T54,T55,T56,T57,T58,T59,T60,T61,T62,T63,T64,T65,T66,T67,T68,T69,T70,T71,T72} <: NamedTuple
    API::T1
    FileNo::T2
    OriginalOperator::T3
    OriginalWellName::T4
    CurrentOperator::T5
    CurrentWellName::T6
    FieldName::T7
    CountyName::T8
    Township::T9
    Range::T10
    Section::T11
    QQ::T12
    Footages::T13
    Hole_Type::T14
    LATITUDE::T15
    LONGITUDE::T16
    FirstSpudDate::T17
    MeasuredTD::T18
    KBElev::T19
    DFElev::T20
    GRElev::T21
    GLElev::T22
    TY_BCHR::T23
    TY_BCHN::T24
    K_P::T25
    K_PJRS::T26
    K_PES::T27
    K_NB::T28
    K_GH::T29
    K_M::T30
    K_N::T31
    K_IK::T32
    J_S::T33
    J_R::T34
    T_S::T35
    PM_MK::T36
    PM_OP::T37
    PM_EBA::T38
    PM_BC::T39
    PN_T::T40
    M_EBS::T41
    M_BS::T42
    M_KL::T43
    M_MDUN::T44
    M_MD::T45
    M_MDR::T46
    M_MDLS::T47
    M_MDFA::T48
    M_MDFY::T49
    M_MDSA::T50
    M_MDTI::T51
    M_MDLP::T52
    MD_B::T53
    D_DV::T54
    D_TF::T55
    D_BB::T56
    D_DP::T57
    D_SR::T58
    D_DB::T59
    D_PE::T60
    D_W::T61
    S_I::T62
    S_CL::T63
    O_G::T64
    O_ST::T65
    O_RR::T66
    O_WR::T67
    O_WI::T68
    O_BI::T69
    CO_D::T70
    PC::T71
    LogsOnFile::T72
end

The crash occurs in this line.

@JeffBezanson any thoughts? This is a bit of an issue for my whole IterableTables and Query project, because I represent the row of any tabular data as a NamedTuple, and obviously I need to be able to represent more or less arbitrary number of columns, and certainly more than 72 :)

Ref: https://discourse.julialang.org/t/package-compatibility-caps/15301