Consts...
>>
>> (it also didn't seem to work properly for ints or floats when I tried --
>> the doc was added to meta, but help didn't seem to find it).
>> On Oct 10, 2015 11:50 AM, "Michael Hatherly" <michael...@gmail.com
>> > wrote:
>>
>&g
Congrats on the release.
On Friday, October 9, 2015 at 7:20:32 AM UTC-4, Tony Kelman wrote:
>
> At long last, we can announce the final release of Julia 0.4.0! See
> http://julialang.org/blog/2015/10/julia-0.4-release/ for more
> details. Binaries are available from the usual place
>
function returns(f, types)
rt = []
if( !isdefined(f, :code) )
for x in Base._methods(f,types,-1)
linfo = x[3].func.code
(tree, ty) = typeinf(linfo, x[1], x[2])
push!(rt, ty)
end
else
# It is a lambda, not a function, we also need the types of the bound
Is there one ?
Yes in the sense it hands anon functions
On Friday, September 18, 2015 at 8:41:16 AM UTC-4, Mauro wrote:
>
> Is that better than Base.return_types ?
>
> On Fri, 2015-09-18 at 14:36, Michael Francis <mdcfr...@gmail.com
> > wrote:
> > function
ted, though, so searching in the docs didn't turn anything
> up (and even though I guess it must have been used on this list, my search
> terms apparently weren't good enough to find it.
>
> Thanks!
>
> // T
>
> On Friday, September 18, 2015 at 2:42:47 PM UTC+2, Michael Francis
xpunging it (https://github.com/JuliaLang/julia/pull/12409)
>
> has not gotten any interest from those who objected, so I'm certain how
> serious they are ;-).
>
> --Tim
>
>
> On Friday, September 18, 2015 05:58:03 AM Michael Francis wrote:
> > I should probably submit
How can I suppress the printing of deprecation warnings in 0.4? I need to
temporarily suppress these so that I can see the wood for the trees.
@Tim - can you point me at the gap between Gtk and browser based, I'm
interested as I've spent a fair amount of time in d3/Escher recently and
with the correct
wrapping seems to do most of what I was looking for. We can take this to a
different thread.
On Wednesday, September 16, 2015 at
September 16, 2015 07:28:57 AM Michael Francis wrote:
> > @Tim - can you point me at the gap between Gtk and browser based, I'm
> > interested as I've spent a fair amount of time in d3/Escher recently and
> > with the correct
> > wrapping seems t
Ah yes so next( 1, 1 ) = ( 1,true )
On Wednesday, September 16, 2015 at 1:41:05 PM UTC-4, Michael Francis wrote:
>
> That's inconsistent with the documentation :(
>
> help?> method_exists
> search: method_exists
>
> .. method_exists(f, Tuple type) -> Bool
>
&
I was executing the following on 0.4
julia> next( Number, Any )
ERROR: MethodError: `next` has no method matching next(::Type{Number},
::Type{Any})
Closest candidates are:
next(::SimpleVector, ::Any)
next{T}(::StepRange{T,S}, ::Any)
next{T}(::UnitRange{T}, ::Any)
...
julia>
hands takes types as its arguments so your query
> should look like this:
> *method_exists( next, Tuple{DataType, DataType } )* or *method_exists(
> next, Tuple{ Type{Number}, Type{Any} } )*
> which correctly returns false.
>
> Am Mittwoch, 16. September 2015 19:16:50 UTC+2 schr
>> * code refactoring
>> * built-in documentation (in addition to Julia's own help system, I
>> suppose)
>> * built-in plots
>>
>> This doesn't look like a huge list. If this is what is needed for
>> non-programmers to work with Julia witho
I'd take the neutral ground here - for a language like Julia there is a
continuum of users ranging from people happy to live in vim/emacs, through
Developer IDEs to people looking for a 'Workbench'. This is dissimilar from
many of the languages being argued about in this thread (C, Java, Lisp
I'd be inclined to agree. Which likely means using a hosted solution, for
unlimited that would seem to run about 1k per month.
So the main (non-social) barriers would be hosting costs and having
somebody to run it unless you pay for the hosted solution?
On Wednesday, September 9, 2015 at 7:34:58 AM UTC-4, Nils Gudat wrote:
>
> Was just thinking about this as first I had to try opening a thread here a
> couple of times
t, although I'm in doubt if it is
>> really needed. The important thing is to have cov and cor type stable.
>>
>>
>> On Tuesday, September 1, 2015 at 1:29:59 PM UTC-4, Michael Francis wrote:
>>>
>>> Thanks, that is a good pointer.
>>>
>>> In
This is very impressive. Is there a description of the Julia mechanics at work
here? The implementation looks very clean.
try
x(1)
catch err
println( err )
end
returns
UndefVarError(:x)
The REPL defines
showerror(io::IO,e::UndefVarError) at replutil.jl:108
giving
ERROR: UndefVarError: x not defined
Should these more friendly messages be available outside of the REPL ?
or perhaps the fact that they are defined in repl is moot and I should just
use them.
On Friday, September 4, 2015 at 10:03:08 AM UTC-4, Michael Francis wrote:
>
> try
> x(1)
> catch err
> println( err )
> end
>
> returns
>
> UndefVarError(:x)
>
> Th
ive callers of this method might call it in a type
> unstable manner anyway by passing the index "n" from the value domain
> rather than the type domain.
>
> Best,
> Jarrett
>
> On Thursday, September 3, 2015 at 10:04:22 AM UTC-4, Michael Francis w
altype, but they are not exported. You
> could
> file a pull request that exports them (it would be a 2-line patch, though
> you
> might want to add a test to make sure they stay exported).
>
> --Tim
>
> On Thursday, September 03, 2015 06:37:02 AM Michael Francis wrote:
> &
For docs - are we performing in place updates to collections.rst ?
On Thursday, September 3, 2015 at 10:04:22 AM UTC-4, Michael Francis wrote:
>
> I will likely do so, it's quite a common action to take.
>
> Fortunately with typeof( ( 1,2 ) ) == Tuple{Int64,Int64} there is a
>
That's really quite nice and for the purpose of interfacing with JSON is
certainly clearer.
On Thursday, September 3, 2015 at 4:40:54 PM UTC-4, Mike Innes wrote:
>
> FWIW I mocked up a json syntax macro:
>
> using MacroTools, Lazy
>
> import MacroTools: prewalk
>
> function prockey(key)
>
ype{A,B}(::Type{Pair{A,B}}) = A
> valuetype{A,B}(::Type{Pair{A,B}}) = B
> pairtypes{A,B}(::Type{Pair{A,B}}) = (A,B)
>
> If you need this to work on 0.3, too, you can easily make these functions
> work for the old-style Tuples, too.
>
> On Thursday, September 3, 2015 at 9:06:30 AM UTC
julia> eltype( Dict( :x => 1, :y => 2 ) )[1]
ERROR: MethodError: `convert` has no method matching convert(::Type{Pair{
Symbol,Int64}}, ::Int64)
This may have arisen from a call to the constructor Pair{Symbol,Int64}(...),
since type constructors fall back to convert methods.
Closest candidates are:
Incidentally
eltype( Pair{String,Float64} )
gives Any, that seems slightly strange as well .
On Thursday, September 3, 2015 at 9:02:33 AM UTC-4, Michael Francis wrote:
>
> julia> eltype( Dict( :x => 1, :y => 2 ) )[1]
> ERROR: MethodError: `convert` has no method matching c
ated
> to unitary Dicts by JSON.
>
> (FWIW, it is not necessary to specify the argument types to Dict)
>
> On Wed, Sep 2, 2015 at 12:45 PM, Michael Francis <mdcfr...@gmail.com
> > wrote:
>
>> With the change to 0.4 happening soon I'm finding the the new Dict syntax
&
In case anybody runs into the same problem - Atom currently has issues with
mouse selection/dragging under a linux virtual machine. This is a known bug
with the version of chromium that they are using (more recent versions of
chromium do not have the issue.)
Otherwise it works very well, I do
With the change to 0.4 happening soon I'm finding the the new Dict syntax
in 0.4 (removal of {}, []) is extremely verbose.
I find myself interfacing with JSON APIs frequently, for example a
configuration dictionary :
data = {
:displayrows => 20,
:cols => [
{
Thanks
Does anybody have a pointer to why operators are not imported in 0.4 by
default?
On Tuesday, September 1, 2015 at 12:36:14 PM UTC-4, Tim Wheeler wrote:
>
> Thanks! I was trying to figure out how to do Base.== for a long time. It
> turns out the proper way to do it is as follows (found
:A,:B]],
>>
>> :(begin # none, line 1:*
>> *return
>> (top(typeassert))((top(kwcall))((top(getfield))(Main,:call)::F,2,:a,a::Int64,:b,b::Complex{Float64},Main.f,(top(ccall))(:jl_alloc_array_1d,(top(apply_type))(Base.Array,Any,1)::Type{Array{Any,1}},(top(svec))(Base.
iaLang/julia/issues/8113
> https://github.com/JuliaLang/julia/pull/12235
>
>
> On Tuesday, September 1, 2015 at 10:22:05 AM UTC-7, Michael Francis wrote:
>>
>> Thanks
>>
>> Does anybody have a pointer to why operators are not imported in 0.4 by
>> default?
ent).
> 2) The returned value depends only on `corzm`, and `corm`. If these two
> functions are type stable, then `cor` is type stable.
> 3) I'm not sure whether this is the "correct" way to write this function.
>
> On Monday, August 31, 2015 at 11:48:37 PM UTC+2, Michael Francis w
I get the following - WARNING: module should explicitly import ==
from Base
Unfortunately you can't simply do
Base.==( ... )
I can fix with
import Base: ==
what is the idiomatic way of doing this in 0.4
Also is there a guide for upgrading packages to 0.4 ?
The following is taken from statistics.jl line 428
function cor(x::AbstractVector, y::AbstractVector; mean=nothing)
mean == 0 ? corzm(x, y) :
mean == nothing ? corm(x, Base.mean(x), y, Base.mean(y)) :
isa(mean, (Number,Number)) ? corm(x, mean[1], y, mean[2]) :
is the utility of a date that predates the advent of time?
>
> On Friday, August 28, 2015 at 12:23:28 PM UTC-4, Michael Francis wrote:
>>
>> I agree except that people may expect yy-mm-dd to truncate, likely one of
>> the reasons for the ccyy-mm-dd strict form. Where
You are correct if I supply a mean then it is reasonable compilation.
Unfortunateky here the default is nothing for a fairly common use case and
hence the return type can not be safely inferred. The more I think about it -
I'm surprised that this is a named optional arg vs an overload.
It seems that there is an issue with typemax of dates and string
representation
julia using Dates
julia Dates.format(typemax( Date ),-mm-dd )
1149-12-31
julia typemax( Date )
252522163911149-12-31
julia Dates.format(typemax( Date ),yyy-mm-dd )
252522163911149-12-31
This
needs another once
over to polish it up, so any ideas on allowing more
flexibility/functionality would be appreciated.
-Jacob
On Friday, August 28, 2015 at 9:33:25 AM UTC-6, Michael Francis wrote:
It seems that there is an issue with typemax of dates and string
representation
julia
As way of an introduction I work for BlackRock http://www.blackrock.com and
we are actively looking for a couple of programmers who would be interested
in working with Julia in a financial setting.
Our interests include the core of the language, distributed computing, the
Julia UI framework
I was somewhat surprised to find that name args do not have an implicit let
and I don't seem to be able to embed the let syntax
bar() = Hello
wow( ; bar = bar() ) = string( bar, world)
wow()
: ERROR: bar not defined
Within a function I can do the following
function foo()
let bar = bar()
Thanks. I will take a deeper look at your package. The good news (for my
current problem ) is that I don't need all the numbers just the constraint that
a number exists in the interval. As such I can define the simple interval class
for now.
Given that
0:10
Defines the set of all integer values inclusive of 0 and 10
10 in 0:10 == true
With floating point numbers the range
0.0:10.0
turns out to *not *define the range of all numbers inclusive of 0.0 and
10.0 but the stepped range with step size 1.0
0.5 in 0.0:10.0 == false
]
0.3999
Discrete ranges are trickier and more subtle than one can imagine before
getting into it.
On Tue, May 26, 2015 at 4:17 PM, Michael Francis mdcfr...@gmail.com
javascript: wrote:
Given that
0:10
Defines the set of all integer values inclusive of 0 and 10
10 in 0:10 == true
Out of interest is there a definition of 1.0 ?
On Sunday, May 17, 2015 at 12:29:19 AM UTC-4, Tony Kelman wrote:
Julia might get Microsoft's attention at some point. You could go vote for
This is going off topic (which was my fault initially ) so lets take this
to the other thread
https://groups.google.com/forum/#!topic/julia-users/sk8Gxq7ws3w%5B101-125%5D
I agree that Haskell typeclasses may well be a long term interesting
solution, does anybody know if there is a plan for
you can simulate these with immutables. On 0.4, NTuple is now
inlined:
julia immutable foo2
x::Int
y::Int
z::NTuple{282,Int}
end
julia sizeof(foo2)
2272
On Fri, May 15, 2015 at 8:58 AM, Michael Francis mdcfr...@gmail.com
javascript: wrote
Is there a better way than a long list of
sid = reinterpret( Clong, bytes[16:20])
the data structure could in theory be represented by a structure but it has
embedded null bytes and fixed sized char arrays. The docs seem to indicate
that these are not well supported.
Ideally I'd like to be
@Tomas, thank you, I had briefly started down this path but thought perhaps
it was the wrong direction ( when I looked at what * or + should mean ).
Now you point it out again I'm thinking that following the notions that
these are sets might be the correct thing, so
# {} is not a syntax for
I added methods to NamedTuples.jl to support merge, set and delete. Since
NamedTuples are essentially immutable dictionaries it seems incorrect to
use the ! forms of setindex and delete. I now have an issue that these are
not defined in base. How best to solve this? This is indirectly related
with yours? Or just that they
should exist in Base?
On Wednesday, May 13, 2015 at 2:35:44 PM UTC-4, Michael Francis wrote:
I added methods to NamedTuples.jl to support merge, set and delete. Since
NamedTuples are essentially immutable dictionaries it seems incorrect to
use the ! forms
Here you have the same problem though. If I also defined assoc and deassoc
people could not include the two libraries without conflict. I'm also of the
mind that the verbs should be consistent with the more common mutable
collections.
Yes I've see reference to those. You can do this today though by defining the
following in Base.
setindex = nothing
delete = nothing
This would reserve the verbs, or we could do
setindex() = error(Not implemented)
I'm not sure what would be added beyond that?
Whilst in this instance I
@David: Thank you for this. It does appear to resolve a class of problems.
On Tuesday, May 5, 2015 at 11:43:34 AM UTC-4, David Gold wrote:
@Scott: Glad to hear it may be useful to you! If you encounter any bugs,
or if you think of a related feature you'd like to see, please do open an
issue
NamedTuples.jl provides an implementation of type safe named tuples for
Julia (cf named tuples in python). NamedTuples may be used anywhere that a
tuple is currently being used, for example in the definition of a method or
as the return value of a method. NamedTuples are implemented using
-4, Stefan Karpinski wrote:
On Thu, Apr 30, 2015 at 12:19 PM, Michael Francis mdcfr...@gmail.com
javascript: wrote:
My goal is not to remove namespaces, quite the opposite, for types a
namespace is an elegant solution to resolving the ambiguity between
different types of the same name
My goal is not to remove namespaces, quite the opposite, for types a
namespace is an elegant solution to resolving the ambiguity between
different types of the same name. What I do object to is that functions
(which are defined against user defined types) are relegated to being
second class
I would expect the user to explicitly import those method, I did not
preclude their existence. And it would be quite reasonable to support the
existing import all syntax hence
using MyModule
^ imports only those functions which explicitly reference user types
defined in the module
importall
or explicitly
importing it. Both suck for interactive usage – and frankly even for
non-interactive usage, qualifying or explicitly importing nearly every name
you use is a massive and unnecessary hassle.
On Wed, Apr 29, 2015 at 2:06 PM, Michael Francis mdcfr...@gmail.com
javascript: wrote
Quick question, is there a safe way to get the list of exported methods from a
module? I assume names(module) will retrieve all methods and types ?
I don't think Any in the same position is a conflict. This would be more of an
issue if Julia did not support strong typing, but it does and is a requirement
of dynamic dispatch. Consider
function foo( x::Any )
Will never be chosen over
Type Foo end
function foo( x::Foo )
As such I don't
Stefan, my takeaways from what you are saying are as follows.
1) dynamic dispatch doesn't work without the potential for surprising
ambiguities in a mixed namespace environment. The more modules included the
worse this gets.
2) A good practice would be to import no functions from modules I
the resolution of that issue seems odd - If I have two completely unrelated
libraries. Say DataFrames and one of my own. I export value( ::MyType) I'm
happily using it. Some time later I Pkg.update(), unbeknownst to me the
DataFrames dev team have added an export of value( ::DataFrame, ...)
I read through the issues / threads ( and some others )
https://github.com/JuliaLang/julia/issues/2327
https://github.com/JuliaLang/julia/issues/4345
I'm not sure that the either the SuperSecretBase or the warning are the
correct approach. I'd like to propose a counter which is a very simple
I'd like to load some local files from a module package directory. This is
akin to the way java has resources. If this were julia code I could just
include( 'foo.jl' ) and that will do mostly the right thing. Is there an
equivalent without having to perform string math on Pkg.dir() ...
I've
Is the following expected behavior for union types, I'm assuming yes ?
v = Union( Int64,Float64 )[]
push!( v, 1.2)
push!( v, 1) # works
f( v::Union(Int64,Float64)...) = v
f( [ 1.2 ]...) # Works
f( v::Vector{Union( Int64, Float64)}) = v
f( [ 1.2 ])# 'f' has not method matching
, Float64)} is false. Thus the no
method error.
On Thu, 2015-04-02 at 21:32, Michael Francis mdcfr...@gmail.com
javascript: wrote:
Is the following expected behavior for union types, I'm assuming yes ?
v = Union( Int64,Float64 )[]
push!( v, 1.2)
push!( v, 1) # works
f( v
at 3:28:34 PM UTC-5, Michael Francis wrote:
Thanks, that is what I suspected.
On Thursday, April 2, 2015 at 4:13:31 PM UTC-4, Mauro wrote:
Types in Julia are invariant:
If T1:T2 is true
then A1{T1}:A1{T2} is false (unless T1==T2).
Now setting T1=Float64 and T2=Union( Int64, Float64
As part of a project I've been working on I have put together a small
package for generating well-formed html documents from Julia.
Is there a similar package available? and if not is there any interest in
releasing this?
The below is a simple example (attached is a sample output, there is
have any fields, but you would do the appropriate conversions if there were
fields. If there's some appropriate way to pick a common type between Wow
and Foo objects, that can also have promote_rules.
On Wed, Apr 1, 2015 at 11:02 AM, Michael Francis mdcfr...@gmail.com
javascript: wrote
If I run the following, I get the results show to the right (in comments),
it appears array construction fails to raise to the common
parent type under certain conditions, is there a way round
this? Alternatively where is this code implemented ?
abstract Foo{K}
type Wow{K,V} : Foo{K} end
a
question like this--I'm not clear what isn't working as expected, here. As
far as I can tell all the inferred types are correct, though the second one
and the final one could be narrower.
On Wednesday, April 1, 2015 at 10:02:37 AM UTC-5, Michael Francis wrote:
If I run the following, I get
Karpinski ste...@karpinski.org
javascript: wrote:
Arguably typejoin should do that.
On Wed, Apr 1, 2015 at 11:35 AM, Michael Francis mdcfr...@gmail.com
javascript:
wrote:
In this instance I'm happy to have the abstract type as the promoted
type.
E.g. I would like to see this be Array
priority to the parameters, when I
would expect the type name to have higher priority. The best thing
would be to keep the join minimal and use Stefan's suggestion of
Wow{Int,_}.
On Wed, Apr 1, 2015 at 3:47 PM, Michael Francis mdcfr...@gmail.com
javascript: wrote:
@Jeff - I'd expect
nice,
so to confirm we agree that
[a,b]
2-element Array{Wow{K,V},1}:
Should be
Wow{Int64,_} or Foo{Int64} [ ideally the former ]
and
[a,b,c,d]
Should be
Foo{Int64}
and
Wow{Int64,_} : Foo{Int64) == true
?
If that is the case then there is a bug today in the typejoin code for the
After moving some code around I get the following error - I don't have a
small test case
ERROR: `get` has no method matching get(::Dict{WeakRef,CalcState},
::WeakRef, :: CalcState)
It looks like the type system is getting confused ? Any pointers in how to
resolve ?
?
On Wednesday, March 11, 2015 at 11:30:18 AM UTC-4, Michael Francis wrote:
After moving some code around I get the following error - I don't have a
small test case
ERROR: `get` has no method matching get(::Dict{WeakRef,CalcState},
::WeakRef, :: CalcState)
It looks like the type system is getting
UTC-4, Michael Francis wrote:
If I locally define
function myget{K,V}(h::Dict{K,V}, key, default)
index = Base.ht_keyindex(h, key)
return (index0) ? default : h.vals[index]::V
end
and change my code to use this myget it all works fine. So it looks like
the function resolution
A slightly simplified example, If I pin the type parameter I am unable to
create the new object. I'm sure I'm missing something obvious here but
given that Int 1 defaults to Int64 on my system I would expect both lines
to work ?
abstract Bar
type Foo{T} : Bar
t::T
Foo() = new( zero( T ) )
it.
On Tue, Feb 10, 2015 at 12:15 PM, Michael Francis mdcfr...@gmail.com
javascript: wrote:
A slightly simplified example, If I pin the type parameter I am unable to
create the new object. I'm sure I'm missing something obvious here but
given that Int 1 defaults to Int64 on my system I would
, I know.
On Tue, Feb 10, 2015 at 12:38 PM, Michael Francis mdcfr...@gmail.com
javascript: wrote:
But why is the outer constructor not called in this case ?
On Tuesday, February 10, 2015 at 12:35:44 PM UTC-5, Stefan Karpinski
wrote:
The inner constructor only has a zero-argument method
You can chain by calling the constructor again:
Thanks that helps clean the code up. So in essence we need both the inner
and out constructors and constructors are chain-able by name.
Re-reading the thread I believe what is being asked for is essentially a
copy on write semantic for replacing an immutable item in a collection with
a slightly modified original, not updating the immutable. So this isn't
mutation at all ?
In the case of an in-lined object it is safe to be
It does sound like immutable has been conflated with packed data structures.
That seems unfortunate. It would be nice if the properties of a type could be
selected at create time rather than with specific reserved words. Something
like the following.
type Buffer : Immutable,Packed
My 2c but is sounds like Julia needs a struct keyword which is C packed but
does not enforce immutability. Immutable should means just that and allows
the compiler more options for optimization.
On Monday, February 9, 2015 at 10:22:49 AM UTC-5, Kevin Squire wrote:
Hi Steve,
I have a
Totally agree packed has a strong meaning of fixed offsets et al. Probably a
bad choice of worlds.
Part of my thought for going to a more functional interface is that the
properties could be closed in the definitions. Hence we could have
Foo = Immutable( ... )
Which wraps the properties
function test()
x = 2
f = (()-x + 3)
println( f() ) # Prints 5 Yeh!
x = 4
println( f() ) # Prints 7 ???
g = (()-(x=4))
println( g() ) # Prints 4 Yeh, that should not be the same x
println( x ) # Oops seems it is the same X
println( f() ) # Yes seems
want.
On Thu, 2015-02-05 at 16:26, Michael Francis mdcfr...@gmail.com
javascript: wrote:
function test()
x = 2
f = (()-x + 3)
println( f() ) # Prints 5 Yeh!
x = 4
println( f() ) # Prints 7 ???
g = (()-(x=4))
println( g() ) # Prints 4 Yeh
90 matches
Mail list logo
