Skip to content
This repository has been archived by the owner on Feb 7, 2019. It is now read-only.

Major overhaul of methods checking in @traitsdef #10

Merged
merged 24 commits into from
Apr 14, 2015
Merged

Conversation

mauro3
Copy link
Owner

@mauro3 mauro3 commented Apr 13, 2015

This implements a hand-coded comparison between the methods in @traitdef and the methods of the generic function. This resolves many outstanding issues, including #2 and #8.

@mauro3 mauro3 mentioned this pull request Apr 13, 2015
Of course, the tests after manual-traitdef.jl are failing
which are marked in test/traitdef.jl with:
varag_not_supported_bug = true
constructors_not_supported_bug = true
These two bugs do not matter anymore as the new tests do not rely on method_exists:
method_exists_bug1 = false # see JuliaLang/julia#8959
method_exists_bug2 = false # see JuliaLang/julia#9043 and #2
at least for 990 out of 1000 cases.
On Version 0.4.0-dev+4133 running julia -L runtests.jl results in:

Could not instantiate instance for type encoding the trait Traits.Collection{Dict{Int64,V}}.
This usually indicates that something is amiss with the @traitdef
or that one of the generic functions is not defined.
The error was: ArgumentError("invalid type for argument #s73 in method definition for __eltype at null:0")
ERROR: LoadError: LoadError: test failed: istrait(Assoc{c},verbose=true)
 in expression: istrait(Assoc{c},verbose=true)
 in error at error.jl:19
 in default_handler at test.jl:27
 in do_test at test.jl:50
 in anonymous at no file:102
 in include at ./boot.jl:250
 in include_from_node1 at ./loading.jl:129
 in include at ./boot.jl:250
 in include_from_node1 at ./loading.jl:129
 in reload_path at ./loading.jl:153
 in _require at ./loading.jl:68
 in require at ./loading.jl:51
 in process_options at ./client.jl:260
 in _start at ./client.jl:401
while loading .julia/v0.4/Traits/test/traitdef.jl, in expression starting on line 101
while loading .julia/v0.4/Traits/test/runtests.jl, in expression starting on line 39

However, it goes away with a @show somewhere in isfitting.  Super
strange bug.
It looks like it is a problem with one of my julia builds.  Anotherone
on the same commit 09ca2e17c4f04b96973338f4b5cf22f8bca344bc did not
crash in many tries...

The bug is gone after a completely fresh julia rebuild.  At least on
version 21df2db4dca8463f6ca6f14ec435324f135f6440
Now with the fresh julia build.  As a work-around I added a never
executing block with a `@show` statement.  I'll look into it in branch
m3/heisenbug
Was a non-issue, just removed the error-throwing check...
Unnecessarily, I made some machinery to create traits with dummy types.
Dig them up in this commit if ever needed.
Checking Traits.Collection{Dict{Int64,V}}: Could not instantiate instance for type encoding the trait Traits.Collection{Dict{Int64,V}}.
This usually indicates that something is amiss with the @traitdef
or that one of the generic functions is not defined.
The error was: ArgumentError("invalid type for argument #s75 in method definition for __eltype at null:0")
The Heisenbug still is showing up, but only with running the tests in
the REPL with include("runtests.jl")
Also reenabled tests due to issue 9135 as it does not apply anymore.
Definitly getting the the area of dimishing returns...
@mauro3 mauro3 force-pushed the m3/para-methods branch 3 times, most recently from 93c7e09 to e12331c Compare April 14, 2015 17:31
mauro3 added a commit that referenced this pull request Apr 14, 2015
Major overhaul of methods checking in `@traitsdef`

Fixes #2, #8
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant