julialang / compat.jl Goto Github PK

Compatibility across Julia versions

License: Other

Julia 100.00%

compat.jl's Introduction

Compat Package for Julia

The Compat package is designed to ease interoperability between older and newer versions of the Julia language. In particular, in cases where it is impossible to write code that works with both the latest Julia master branch and older Julia versions, or impossible to write code that doesn't generate a deprecation warning in some Julia version, the Compat package provides a macro that lets you use the latest syntax in a backwards-compatible way.

This is primarily intended for use by other Julia packages, where it is important to maintain cross-version compatibility.

Usage

To use Compat in your Julia package, add it as a dependency of your package using the package manager

pkg> add Compat

and add a version specifier line such as Compat = "3.22, 4" in the [compat]section of the Project.toml file in your package directory. The version in the latter should be the minimum version that supports all needed features (see list below). Note that Compat v4 requires Julia v1.6, but some features may have been backported to Compat v3 (see the feature list of the release-3 branch). If you require any of those backported features, be sure to specify the correct compatibility in your Project.toml. E.g. if the feature from Compat v4.x has been backported to v3.y, use Compat = 3.y, 4.x. If you use a feature that had originally been added in Compat v3 (e.g. in 3.x), don't forget to also declare compatibility with v4 with Compat = 3.x, 4 (unless you use one the very few things that got removed between Compat v3 and v4, which you most probably don't).

To minimize dependency conflicts between packages it is recommended that packages allow for both appropriate v4 and v3 versions of Compat.jl in their Project.toml (except for rare cases of packages that support only v4 or v3 version of Compat.jl).

Then, in your package, shortly after the module statement include a line like this:

using Compat

and then as needed add

@compat ...compat syntax...

wherever you want to use syntax that differs in the latest Julia master (the development version of Julia). The compat syntax is usually the syntax on Julia master. However, in a few cases where this is not possible, a slightly different syntax might be used. Please check the list below for the specific syntax you need.

Compatibility

Features in the development versions of julia may be added and released in Compat.jl. However, such features are considered experimental until the relevant julia version is released. These features can be changed or removed without incrementing the major version of Compat.jl if necessary to match changes in julia.

Supported features

allequal(f, itr) and allunique(f, itr) methods. (#47679) (since Compat 4.13.0)
logrange(lo, hi; length) is like range but with a constant ratio, not difference. (#39071) (since Compat 4.14.0) Note that on Julia 1.8 and earlier, the version from Compat has slightly lower floating-point accuracy than the one in Base (Julia 1.11 and later).
Iterators.cycle(itr, n) is the lazy version of repeat(vector, n). (#47354) (since Compat 4.13.0)
@compat public foo, bar marks foo and bar as public in Julia 1.11+ and is a no-op in Julia 1.10 and earlier. (#50105) (since Compat 3.47.0, 4.10.0)
redirect_stdio, for simple stream redirection. (#37978) (since Compat 4.8.0)
trunc, floor, ceil, and round to Bool. (#25085) (since Compat 4.7.0)
splat(f) which is equivalent to args -> f(args...). (#42717, #48038) (since Compat 4.6.0) (Note: for historical reasons, Compat on Julia before v1.9 also exports Splat; its usage is discouraged, however.)
Compat.@assume_effects setting... ex overrides the compiler's effect modeling for the method definition ex on Julia versions that support this feature. Julia version without support just pass back ex. (#43852) (since Compat 4.4.0)
div, lcm, gcd, /, rem, and mod will promote heterogenous Dates.Periods (@bdf9ead9). (since Compat 4.3.0)
stack combines a collection of slices into one array (#43334). (since Compat 3.46.0, 4.2.0)
keepat! removes the items at all the indices which are not given and returns the modified source (#36229, #42351). (since Compat 3.44.0, 4.1.0)
@compat (; a, b) = (; c=1, b=2, a=3) supports property descturing assignment syntax (#39285).
allequal, the opposite of allunique (#43354). (since Compat 3.42.0)
eachsplit for iteratively performing split(str). (#39245). (since Compat 3.41.0)
ismutabletype(t::Type) check whether a type is mutable (the field mutable of DataType was removed. #39037) (since Compat 3.40)
convert(::Type{<:Period}, ::CompoundPeriod) can convert CompoundPeriods into the specified Period type (#40803) (since Compat 3.38.0)
Compat.@inline and Compat.@noinline can be used at function callsites to encourage the compiler to (not) inline the function calls on Julia versions that support these features, and otherwise do not have any effects (#41312) (since Compat 3.37)
Compat.@inline and Compat.@noinline can be used within function body to hint to the compiler the inlineability of the defined function (#41312) (since Compat 3.37)
Compat.@constprop :aggressive ex and Compat.@constprop :none ex allow control over constant-propagation during inference on Julia versions that support this feature, and otherwise just pass back ex. (#42125) (since Compat 3.36)
Returns(value) returns value for any arguments (#39794) (since Compat 3.35)
The function current_exceptions() has been added to get the current exception stack. Julia-1.0 lacks runtime support for full execption stacks, so we return only the most recent exception in that case. (#29901) (since Compat 3.34)
Two argument methods findmax(f, domain), argmax(f, domain) and the corresponding min versions (#35316, #41076) (since Compat 3.31.1)
isunordered(x) returns true if x is value that is normally unordered, such as NaN or missing (#35316) (since Compat 3.31.1)
get accepts tuples and numbers (#41007, #41032) (since Compat 3.31)
@something and @coalesce as short-circuiting versions of something and coalesce (#40729) (since Compat 3.29)
pkgversion(m::Module) returns the version of the package that loaded a given module (#45607) (since Compat 4.11)
VersionNumber(::VersionNumber) defined as a no-op constructor (#45052) (since Compat 4.12)

Developer tips

One of the most important rules for Compat.jl is to avoid breaking user code whenever possible, especially on a released version.

Although the syntax used in the most recent Julia version is the preferred compat syntax, there are cases where this shouldn't be used. Examples include when the new syntax already has a different meaning on previous versions of Julia, or when functions are removed from Base Julia and the alternative cannot be easily implemented on previous versions. In such cases, possible solutions are forcing the new feature to be used with qualified name in Compat.jl (e.g. use Compat.<name>) or reimplementing the old features on a later Julia version.

If you're adding additional compatibility code to this package, the contrib/commit-name.sh script in the base Julia repository is useful for extracting the version number from a git commit SHA. For example, from the git repository of julia, run something like this:

bash $ contrib/commit-name.sh a378b60fe483130d0d30206deb8ba662e93944da
0.5.0-dev+2023

This prints a version number corresponding to the specified commit of the form X.Y.Z-aaa+NNNN, and you can then test whether Julia is at least this version by VERSION >= v"X.Y.Z-aaa+NNNN".

Tagging the correct minimum version of Compat

Note that you should specify the correct minimum version for Compat in the [compat] section of your Project.toml, as given in above list.

compat.jl's People

Contributors

Stargazers

Watchers

Forkers

garborg jfsantos simondanisch jakebolewski tanmaykm simonbyrne shashi vchuravy tomasaschan mweastwood mbauman garrison lbenet wildart antimon2 scottpjones hayd zhmz90 joehuchette lostanlen davidavdav keno emoszkowski jgoldfar samoconnor dpsanders pkofod martinholters bicycle1885 stefankarpinski kleopatra999 jkroso dancasimiro fairbrot c42f ranjanan cstjean r9y9 sglyon tkelman ararslan pabloferz ssfrr davidagold habemus-papadum vimalaad jeffbezanson invenia traktofon pfitzseb chrisrackauckas jobjob mauro3 mschauer rofinn mortenpi petr-hlavenka chakravala rdeits ericforgy jdjohnston jmkuhn kristofferc rened appleparan grandtiger ksmcreynolds jekbradbury galenlynch anowacki darwindarak zhangfuhan jhardenberg tkf dalavancloud anu710 davidanthoff jiegillet mcabbott musm oxinabox ssikdar1 mtsch goretkin emmt fchorney anilkunwar simeonschaub stjordanis jmert mdmahbubarrahman global-localhost global19 global19-atlassian-net cscherrer standardgalactic playfloor longemen3000 00mjk mkitti

compat.jl's Issues

LoadError using Compat

The following problem occured with the current master version of Julia, as well as with a 6 days old version. I am on the master version on Compat.

julia> using Compat
Warning: Method definition call(Type{IPv4}, AbstractString) in module Base at socket.jl:35 overwritten in module Compat at /home/mi/asik/.julia/v0.4/Compat/src/Compat.jl:41.
Warning: Method definition call(Type{IPv6}, AbstractString) in module Base at socket.jl:78 overwritten in module Compat at /home/mi/asik/.julia/v0.4/Compat/src/Compat.jl:42.
Warning: Method definition isless(T<:Base.IPAddr, T<:Base.IPAddr) in module Base at socket.jl:6 overwritten in module Compat at /home/mi/asik/.julia/v0.4/Compat/src/Compat.jl:47.
Warning: Method definition call(Type{Dict{K,V}}, Any) in module Base at dict.jl:406 overwritten in module Compat at /home/mi/asik/.julia/v0.4/Compat/src/Compat.jl:59.
ERROR: LoadError: TypeError: apply_type: in Type, expected Type{T}, got Tuple{TypeVar,TypeVar}
 in include at ./boot.jl:252
 in include_from_node1 at ./loading.jl:134
 in reload_path at ./loading.jl:158
 in _require at ./loading.jl:70
 in require at ./loading.jl:53
while loading /home/mi/asik/.julia/v0.4/Compat/src/Compat.jl, in expression starting on line 60

I actually think compat.jl:59 shouldn't get executed as it is inside the if VERSION < v"0.4.0-dev+980" block and I am on the newest version. But somehow I also get:

julia> VERSION
v"0.4.0-dev+330"

Maybe this is a Julia versioning bug?

A typed dict macro?

Don't we need something that translates
Compat.@TypedDict( Symbol=>Any, :a=>1 ) into
Expr( :call, Expr( :curly, :Symbol, :Any ), pair...) in 0.4-dev
and
Expr( :typed_dict, Expr( :(=>), Symbol, Any ), pair...) in 0.3

@compat round error on Julia v0.3.6

Hi,

I am using Julia v0.3.6. Here are the error messages:

julia> using Compat

julia> @compat round(Integer, 5.3)
ERROR: `round` has no method matching round(::Type{Integer}, ::Float64)

julia> @compat round(Int, 5.3)
ERROR: `round` has no method matching round(::Type{Int64}, ::Float64)

Did I do something wrong?

Error with Dict compat

Repro.jl

module Repro

    using Compat

    macro fact(factex::Expr, args...)
        expr, assertion = factex.args
        msg = :nothing
        quote
            d = @compat Dict(:line => 5, :msg => $(esc(msg)))
        end
    end
end

Test

julia> using Repro

julia> @Repro.fact 1 => 2
ERROR: unsupported or misplaced expression =>

julia> @Repro.fact 1 + 2
ERROR: unsupported or misplaced expression =>

I'm not sure whats going on, probably something simple, but its lost on me!

split keep=true compat function?

I use this in IJulia:

# avoid deprecation warning for change in split API
if VERSION >= v"0.4-"
    splitkeep(str, splitter) = split(str, splitter, keep=true)
else
    splitkeep(str, splitter) = split(str, splitter, true)
end

test failure for Julia 0.2

With Julia 0.2.1, I get:

julia> include("/Users/stevenj/.julia/Compat/test/runtests.jl")
ERROR: test error during :((@compat Dict([(1,1)])==Dict([(1,1)])))
no method Dict{K,V}(Array{(Int64,Int64),1},)
 in anonymous at test.jl:53
 in do_test at test.jl:37
 in include at boot.jl:238
 in include_from_node1 at loading.jl:114
at /Users/stevenj/.julia/Compat/test/runtests.jl:33

In particular, the following syntax is not supported in Julia 0.2:

julia> Dict([(1,1)])
ERROR: no method Dict{K,V}(Array{(Int64,Int64),1},)

cc: @simonster

(I think we should aim for compatibility with at least Julia 0.2. I don't think it's necessary to support Julia 0.1 at this point.)

Macro for Base.parse(::BigFloat, s::AbstractString)

A recent change JuliaLang/julia/pull/10955 deprecates BigFloat("0.1") in favor of parse(BigFloat,"0.1").

Is the following useful?

if VERSION < v"0.4.0-dev+4539"
    Base.parse(::BigFloat, s::AbstractString) = BigFloat(s)
end

@compat for (e.g.) Vector{Int}()?

Hi,

Currently in 0.3.x

julia> q = Vector{Int}()
ERROR: type cannot be constructed

Any way to get this working in 0.3?

make `@doc` a no-op if Docile can't be loaded?

I've had some trouble getting Docile installed on some older versions of Julia. Since Docile provides no necessary functionality for most packages that "depend" on it, it would be nice to make this an optional dependency instead: if the Docile package cannot be loaded then just ignore @doc macros.

Dates compat?

Is it possible to do something like:

@compat using Dates

and have it expand to something like:

if VERSION < v"0.4"
    using Dates
else
    using Base.Dates
end

`Tuple{a...}` not translated correctly on 0.3

On 0.3

julia> Pkg.status()
3 required packages:
 - Compat                        0.4.2
 - LsqFit                        0.0.1
 - Optim                         0.4.1
7 additional packages:
 - ArrayViews                    0.6.2
 - Calculus                      0.1.7
 - Distributions                 0.7.1
 - DualNumbers                   0.1.3
 - NaNMath                       0.0.2
 - PDMats                        0.3.3
 - StatsBase                     0.6.15

julia> using Compat

julia> a = [Int, Int]
2-element Array{DataType,1}:                                                      
 Int64                                                                            
 Int64                                                                            

julia> @compat Tuple{a...}
ERROR: type: apply_type: in Vararg, expected Type{T<:Top}, got Array{DataType,1}

On 0.4-dev

julia> using Compat

julia> a = [Int, Int]
2-element Array{DataType,1}:
 Int64
 Int64

julia> @compat Tuple{a...}
Tuple{Int64,Int64}

@compat(BLAS.BlasInt(5))

This should be BLAS.blas_int(5) in 0.3.

Pair() for 0.3?

Is Pair a good candidate for inclusion into Compat, or is this a request better made to the 0.3 maintainers (to cherrypick it)?

lufact pivot argument

lufact since JuliaLang/julia@f9da849 has been type-stable, much like chol which has already been handled. Could an entry to Compat.jl be added for lufact too? I need this for CUSPARSE.jl tests.

Compat for deprecated lowercase conversions?

With JuliaLang/julia#10452 merged, we could use some Compat support for float64, int32, etc.

map(Int, array) works in 0.4, not in 0.3

a = [true false; false true]

v0.3:

julia> using Compat

julia> map(Int,a)
ERROR: type cannot be constructed
 in map at abstractarray.jl:1328

v0.4:

julia> map(Int,a)
2x2 Array{Int64,2}:
 1  0
 0  1

Tag 0.5.0 in METADATA.jl

Hi!

Just wanted to ask when 0.5.0 is going to be tagged in METADATA.jl?

Compat making tuples in function call (erronously?)

Is this desired behaviour?

julia> min(@compat Int32(-100), @compat Int32(100))
ERROR: MethodError: `min` has no method matching min(::(Int32,Int32))
Closest candidates are:
  min(::Any, ::Any)
  min(::Any, ::Any, ::Any)
  min(::Any, ::Any, ::Any, ::Any...)

If so, how can I do what I inteded (call min with two Int32s)

at-compat macro does not work with semi-colon in "split"

Note the ; in the second expression

macroexpand(:(@compat split("a?b?c?","?", limit=2, keep=false)))
:(split("a?b?c?","?",2,false))

macroexpand(:(@compat split("a?b?c?","?"; limit=2, keep=false)))
:(split("a?b?c?","?"; limit=2,keep=false))

Add sizehint! to the @compat collection

Can sizehint! be added so that

@compat sizehint!(tt,n)

becomes

sizehint(tt,n)

in version 0.3.x

Feature: macro for sharing same name btwn function and abstract type

Is it possible to allow for a common name shared by a function and an abstract type via a @compat macro? Julia v0.4 already allows this, but I am not sure how/if it is possible to emulate this behavior in Julia v0.3?

atsign_compat having trouble with Complex128

  | | |_| | | | (_| |  |  Version 0.3.7-pre+8 (2015-02-28 23:18 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 6205d5c* (18 days old release-0.3)
|__/                   |  x86_64-apple-darwin14.1.0

julia> using Compat

julia> complex128(1, NaN)
1.0 + NaN*im

julia> @compat(Complex128(1, NaN))
ERROR: `convert` has no method matching convert(::Type{Complex{Float64}}, ::Int64, ::Float64)

julia> @compat(Complex(1, NaN))
1.0 + NaN*im

Nullable with subtype

I am having a problem when I assign a value to a Nullable which it a sub-type of the type contained by the Nullable. This works in 0.4, but not with Compat.

Here is the problem:

julia> abstract Parent

julia> immutable Child <: Parent end

julia> type Container x::Nullable{Parent} end

julia> c = Container(Child())
ERROR: `convert` has no method matching convert(::Type{Nullable{Parent}}, ::Child)
 in Container at no file

However, I have no idea how you solve this because:

julia> convert{T,S<:T}(::Type{Nullable{T}}, s::S) = Nullable{T}(s)
ERROR: T not defined

@compat Tuple{...}

We need to support the new tuple-type syntax Tuple{T1,T2} for what used to be (T1,T2), and Tuple{T1,Vararg{T2}} for what used to be (T1,T2...), introduced in JuliaLang/julia#10380.

`@compat` for `[]`?

In julia 0.4, the {} syntax is deprecated:

julia> {}

WARNING: deprecated syntax "{}".
Use "[]" instead.
0-element Array{Any,1}

Changing {} to [] leads to the correct behavior on julia 0.4. However, on julia 0.3 it results in a different type, Array{None,1}:

julia> []
0-element Array{None,1}

I think one of two things should be done:

Make @compat [] transform to Any[] on julia 0.3; or,
Make the deprecation notice suggest using Any[] instead of [] in place of {}.

(If the second option makes more sense, this bug should really be filed against julia instead.)

Also, apologies if this has been discussed elsewhere; it's a fairly difficult issue to search for.

@compat for gc_enable(false)

gc_disable has been deprecated in favour of gc_enable(false)

Test failure on PkgEval?

>>> 'Pkg.test("Compat")' log
Julia Version 0.4.0-dev+5846
Commit 0503f2a (2015-07-08 02:04 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3
INFO: Testing Compat
ERROR: LoadError: UndefVarError: MS_SYNC not defined
 in anonymous at no file:209
 in include at ./boot.jl:254
 in include_from_node1 at loading.jl:133
 in process_options at ./client.jl:306
 in _start at ./client.jl:406
while loading /home/vagrant/.julia/v0.4/Compat/test/runtests.jl, in expression starting on line 208
===============================[ ERROR: Compat ]================================

failed process: Process(`/home/vagrant/julia/bin/julia --check-bounds=yes --code-coverage=none --color=no /home/vagrant/.julia/v0.4/Compat/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: No packages to install, update or remove
ERROR: Compat had test errors
 in error at ./error.jl:21
 in test at pkg/entry.jl:746
 in anonymous at pkg/dir.jl:31
 in cd at file.jl:22
 in cd at pkg/dir.jl:31
 in test at pkg.jl:71
 in process_options at ./client.jl:282
 in _start at ./client.jl:406

>>> End of log

I can't reproduce with my local OSX build though, weirdly.

Need a macro for Nothing/Void

... unless this confusing change is going to be unchanged?

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

I could not figure out a way to get rid of this warning in 0.4 without making the code break in 0.3. Could we put something in compat for this?

UInt aliases

In light of JuliaLang/julia#8905, it would be good to define aliases UInt for Uint etcetera in Julia < 0.4.

Add support for redesign of Triangular

As mentioned in JuliaLang/julia#9779, it would be nice if the redesign of Triangular would get support in Compat.jl

Inconsistency in IpAddr / IPAddr?

Perhaps a silly question:

IpAddr is in deprecated.jl in 0.4.x. It's both exported (export TcpSocket, UdpSocket, IpAddr) and reassigned (const IpAddr = IPAddr). If I understand it correctly, this produces an apparent inconsistency in which a deprecated object (IpAddr) is visible and returns IPAddr, but the non-deprecated object(IPAddr) is not exported. I'm not sure what the correct behavior is here, but it seems to me that either IPAddr should be exported, or NEITHER IPAddr nor IpAddr should.

in 0.3, IpAddr is not exported:

julia> IpAddr
ERROR: IpAddr not defined

julia> Base.IpAddr
IpAddr

julia> VERSION
v"0.3.4"

What is the proper behavior here?

Refs:

eachindex

Following the discussion at JuliaLang/julia#10858, I realized that eachindex is not implemented in Compat for julia 0.3. Might it make sense to implement it?

[PkgEval] Compat may have a testing issue on Julia 0.4 (2015-06-23)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

On 2015-06-22 the testing status was Tests pass.
On 2015-06-23 the testing status changed to Tests fail.

This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("Compat")' log
INFO: No packages to install, update or remove
INFO: Package database updated

>>> 'Pkg.test("Compat")' log
INFO: Testing Compat
ERROR: LoadError: syntax: local declaration in global scope
 in include at ./boot.jl:254
 in include_from_node1 at loading.jl:133
 in process_options at ./client.jl:304
 in _start at ./client.jl:404
while loading /home/vagrant/.julia/v0.4/Compat/test/runtests.jl, in expression starting on line 296

===============================[ ERROR: Compat ]================================

failed process: Process(`/home/vagrant/julia/bin/julia --check-bounds=yes --code-coverage=none --color=no /home/vagrant/.julia/v0.4/Compat/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: No packages to install, update or remove
ERROR: Compat had test errors
 in error at ./error.jl:21
 in test at pkg/entry.jl:746
 in anonymous at pkg/dir.jl:31
 in cd at file.jl:22
 in cd at pkg/dir.jl:31
 in test at pkg.jl:71
 in process_options at ./client.jl:280
 in _start at ./client.jl:404


>>> End of log

Capitalization of numeric type constructors

Running some libraries through Lint I see the following info:

INFO   In 0.4+, replace float64() with Float64()
INFO   In 0.4+, replace int64() with Int64()

Should these be aliased?

Related:
tonyhffong/Lint.jl#57

Julia 0.2 compatibility breakage

This was broken by 8759ca5

It would be nice to continue to support 0.2 at least until 0.4 is released, but it is a problem that no one is testing with Julia 0.2 anymore. Can we update Travis to test with 0.2?

Tuple and convert don't play well

I am using Julia 0.3.10 and Compat 0.4.9 and get this:

julia> using Compat

julia> @compat Tuple{Int8, Int8}  # basic syntax appears to work
(Int8,Int8)

julia> convert(@compat Tuple{Int8,Int8},(1,1))  # but I can't convert to this type
ERROR: `convert` has no method matching convert(::((DataType,DataType),(Int64,Int64)))

julia> convert((Int8, Int8), (1,1))  # even though conversion to the equivalent type works fine
(1,1)

Take care of the transition to AbstractFloat

Need to provide the facility to help package developers to deal with the FloatingPoint to AbstractFloat transition (JuliaLang/julia#12162).

Passing NULL pointers to ccall

Julia got stricter about passing a NULL pointer through ccall in v0.4. I think that it was this JuliaLang/julia@3387e77 to Julia, but I'm not sure. I had to update the WAV.jl package with this: dancasimiro/WAV.jl@7ed82cb to fix WAV.jl on

julia> versioninfo()
Julia Version 0.4.0-dev+3723
Commit b80f7db* (2015-03-08 05:30 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin14.1.0)
  CPU: Intel(R) Core(TM) i7-4960HQ CPU @ 2.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

The code works in v0.4, without printing any deprecation warnings. However, I get the following error on v0.3.6:

julia> WAV.wavplay(data, fs)
ERROR: type: AudioQueueEnqueueBuffer: in ccall argument 4, expected Ptr{None}, got Nothing
 in AudioQueueEnqueueBuffer at /Users/daniel.casimiro/.julia/v0.4/WAV/src/wavplay-audioqueue.jl:175
 in enqueueBuffer at /Users/daniel.casimiro/.julia/v0.4/WAV/src/wavplay-audioqueue.jl:192
 in wavplay at /Users/daniel.casimiro/.julia/v0.4/WAV/src/wavplay-audioqueue.jl:361

julia> versioninfo()
Julia Version 0.3.6
Commit 0c24dca* (2015-02-17 22:12 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4960HQ CPU @ 2.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

floor(Integer, array) generates wrong replacement call

floor(Integer, [5.5,6.9])
gives an error:

ERROR: `ifloor` has no method matching ifloor(::Type{Integer}, ::Array{Float64,1})
 in floor at C:\Users\s2maki\.julia\v0.3\Compat\src\Compat.jl:66

need @compat pipe

The |> etc operators were replaced by a new function, pipe, in JuliaLang/julia#10211, and we should have this in Compat.

compat erroneously creates 1-entry tuple

The following is in a very recent commit of Julia 0.4:

julia> c = Tuple{Int,Int}((4,3))
(4,3)

julia> c = (@compat Tuple{Int,Int})((4,3))
(4,3)

julia> typealias d Tuple{Int,Int}
Tuple{Int64,Int64}

julia> typealias e (@compat Tuple{Int,Int})
(Tuple{Int64,Int64},)

Shouldn't e also be defined as Tuple{Int,Int} rather than (Tuple{Int,Int},)?

Handle variables

Thinking of the code I've uglified already in the name of temporary compatibility, it would be useful if the tests looked like this:

v = 1

d = Dict{Int,Int}()
d[1] = 1
@test Compat.@Dict(1 => 1) == d
@test Compat.@Dict(1 => v) == d

ad = Dict{Any,Any}()
ad[1] = 1
@test Compat.@AnyDict(1 => 1) == ad
@test Compat.@AnyDict(1 => v) == ad

Currently:

ERROR: test error in expression: Compat.@AnyDict 1=>v == ad
v not defined

Cint not working in 0.3.7

julia> Pkg.checkout("Compat")
INFO: Checking out Compat master...
INFO: Pulling Compat latest master...
INFO: Upgrading Calculus: v0.1.6 => v0.1.8

julia> using Compat

julia> @compat(Cint(false))
ERROR: type cannot be constructed

julia> versioninfo()
Julia Version 0.3.7
Commit cb9bcae (2015-03-23 21:36 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

julia> Pkg.status()
2 required packages:
 - GLPlot                        0.0.5+             master
 - Jewel                         1.0.4
37 additional packages:
 - BinDeps                       0.3.12
 - Calculus                      0.1.8
 - Color                         0.4.5
 - Compat                        0.4.4              master
 - Compose                       0.3.12
 - DataStructures                0.3.9
 - Datetime                      0.1.7
 - Docile                        0.5.2
 - DualNumbers                   0.1.3
 - FactCheck                     0.2.7
 - FixedPointNumbers             0.0.7
 - GLAbstraction                 0.0.5+             master
 - GLFW                          1.0.0-alpha.6
 - GLText                        0.0.4
 - GLWindow                      0.0.5+             master
 - Graphics                      0.1.0
 - Homebrew                      0.1.14
 - Images                        0.4.36
 - ImmutableArrays               0.0.7
 - Iterators                     0.1.8
 - JSON                          0.4.3
 - JuliaParser                   0.6.2
 - LNR                           0.0.1
 - Lazy                          0.8.4
 - Lumberjack                    0.0.3
 - ModernGL                      0.0.5+             master
 - Mustache                      0.0.9
 - NaNMath                       0.0.2
 - Quaternions                   0.0.4
 - Reactive                      0.2.0
 - Requires                      0.1.2
 - SHA                           0.0.4
 - SIUnits                       0.0.3
 - TexExtensions                 0.0.2
 - URIParser                     0.0.5
 - UUID                          0.0.2
 - Zlib                          0.1.8

evaluate to call

Some packages, e.g. StatsBase, rely on the evaluation of functors.

In Julia 0.3, we used evaluate internally to invoke a functor, and in latest version of Julia 0.4, it now uses call.

I wish this can be supported by this package.

redefining @math_const at @irrational

A new change to Base over here:
JuliaLang/julia@5444813

means that @math_const is now obsolete and now much be replaced by @ irrational. Whoever's using Compat.jl to write other modules or code would get this error.

#110 doesn't rewrite properly

Consider:

julia> macroexpand(:(TarjanVisitor(n::Int) = TarjanVisitor(
                         @compat Vector{Int}(),
                         @compat Vector{Int}(),
                         zeros(Int, n),
                         @compat Vector{Vector{Int}}()
              )))
:(TarjanVisitor(n::Int) = begin  # none, line 1:
            TarjanVisitor((Vector{Int}(),(Vector{Int}(),zeros(Int,n),Vector{Vector{Int}}())))
        end)

julia> macroexpand(:(@compat TarjanVisitor(n::Int) = TarjanVisitor(
                         Vector{Int}(),
                         Vector{Int}(),
                         zeros(Int, n),
                         Vector{Vector{Int}}()
                     )))
:(TarjanVisitor(n::Int) = begin  # none, line 1:
            TarjanVisitor(Vector{Int}(),Vector{Int}(),zeros(Int,n),Vector{Vector{Int}}())
        end)

When @compat is placed BEFORE the beginning of the constructor, things are fine. When @compat is used WITHIN the constructor, things fail (see https://travis-ci.org/JuliaGraphs/LightGraphs.jl/builds/69349027 for an example).

size with multiple dim arguments

On Julia 0.4 I can do this:

a = rand(10, 10, 3)
size(a, 1, 3) == (10, 3)

However with 0.3.7 and using Compat I get a MethodError.

Is this something that Compat should support?

Dict(zip(keys, values)) not covered by Compat

As discussed in https://groups.google.com/d/msg/julia-users/Fobhly-DPNY/Nlwp4cWMSPwJ , in pre-0.4 the construct

keys = ["a", "b"]
values = [1:2]
Dict(keys, values)

warns that (Dict{K,V})(ks::AbstractArray{K},vs::AbstractArray{V}) is deprecated, use (Dict{K,V})(zip(ks,vs)) instead.

Using

@compat Dict(zip(keys,values))

works as advertised in pre-0.4, but not in release-0.3. My guess is that @compat should take care of this.

rem() for integer types

Compat.jl is missing support for 0.4-style integer truncations, e.g. 123 % Uint8.