Re: [julia-users] Re: parse of string followed by number turned into @doc ?

gt;> (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" > > wrote: >> >>> If you want to disable the automatic

[julia-users] Re: ANN: Julia v0.4.0 released!

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 >

[julia-users] parse of string followed by number turned into @doc ?

Julia 0.4 rc4 I get the following unexpected (to me) behavior - julia> parse( "\"hello\"\n3.142" ) :(@doc "hello" 3.142) is this intentional ?

Re: [julia-users] Re: Get the inferred type of a function call given input argument types only

owever, my PR expunging 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 sho

Re: [julia-users] Re: Get the inferred type of a function call given input argument types only

ot documented, 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 UT

Re: [julia-users] Re: Get the inferred type of a function call given input argument types only

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 > wrote: > > function returns(f, types) > > rt = [] &g

[julia-users] Re: Get the inferred type of a function call given input argument types only

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

[julia-users] Equivalent of DL_LOAD_PATH in v0.4

Is there one ?

[julia-users] suppress deprecation warnings

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.

[julia-users] Re: method_exist inconsistent with dispatch ?

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 >

[julia-users] Re: method_exist inconsistent with dispatch ?

the other 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+

[julia-users] method_exist inconsistent with dispatch ?

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> method_exist

Re: [julia-users] Re: IDE for Julia

On Wednesday, 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 > > wrap

Re: [julia-users] Re: IDE for Julia

@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 10:0

Re: [julia-users] Re: IDE for Julia

>> * 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 without pain,

Re: [julia-users] Re: IDE for Julia

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 .

Re: [julia-users] Re: META: What are the chances of moving this forum?

I'd be inclined to agree. Which likely means using a hosted solution, for unlimited that would seem to run about 1k per month.

[julia-users] Re: META: What are the chances of moving this forum?

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 b

Re: [julia-users] Re: Type stability (or not) in core stats functions

t; 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 specific case its unfortunate tha

[julia-users] Re: [ANN] ForwardDiff.jl v0.1.0 Released

This is very impressive. Is there a description of the Julia mechanics at work here? The implementation looks very clean.

[julia-users] Re: Friendly error messages outside 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

[julia-users] Friendly error messages outside the REPL

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 ?

Re: [julia-users] Re: The new Dict syntax in 0.4 is very verbose

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) > @cap

[julia-users] Re: v0.4 - Pair does not behave like a Tuple

Pull request submitted https://github.com/JuliaLang/julia/pull/12931 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 convert(::Type{Pair{ > Sy

Re: [julia-users] Re: v0.4 - Pair does not behave like a Tuple

t;end > > Though be warned: naive 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

Re: [julia-users] Re: v0.4 - Pair does not behave like a Tuple

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

Re: [julia-users] Re: v0.4 - Pair does not behave like a Tuple

and valtype, 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

[julia-users] Re: v0.4 - Pair does not behave like a Tuple

eytype{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

[julia-users] Re: v0.4 - Pair does not behave like a Tuple

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

[julia-users] v0.4 - Pair does not behave like a Tuple

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:

Re: [julia-users] The new Dict syntax in 0.4 is very verbose

could be translated > 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 > wrote: > >> With the change to 0.4 happening soon I'm finding the the new Dict synta

Re: [julia-users] IDE for Julia

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

[julia-users] The new Dict syntax in 0.4 is very verbose

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 => [ {

[julia-users] Re: Julia 0.4 warnings and how to fix

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?

[julia-users] Re: Type stability (or not) in core stats functions

,Any[],Any[Int64],Any[:X,: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{

[julia-users] Re: Julia 0.4 warnings and how to fix

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

[julia-users] Julia 0.4 warnings and how to fix

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 ?

[julia-users] Re: Type stability (or not) in core stats functions

> 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 Fran

Re: [julia-users] Re: Dates and typemax error

Of course. Getting tired after too much JavaScript debugging.

Re: [julia-users] Type stability (or not) in core stats functions

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.

Re: [julia-users] Re: Dates and typemax error

he 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 yy is defin

[julia-users] Type stability (or not) in core stats functions

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]) :

Re: [julia-users] Re: Dates and typemax error

gt;> thoughts/input on this. >> >> I do think the Date/DateTime parsing/formatting code needs another once >> over to polish it up, so any ideas on allowing more >> flexibility/functionality would be appreciated. >> >> -Jacob >> >> >&

[julia-users] Dates and typemax error

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-3

[julia-users] Julia jobs in NYC

As way of an introduction I work for BlackRock 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

[julia-users] let and named args

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()

Re: [julia-users] Range{T} and FloatingPoint numbers

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.

Re: [julia-users] Range{T} and FloatingPoint numbers

> > julia> r[1801439850948200] > 0.40013 > > julia> r[1801439850948199] > 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 > wrote:

[julia-users] Range{T} and FloatingPoint numbers

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

[julia-users] Re: Microsoft and Julia (getting to 1.0)

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 > http://feedback.azure.com/forums/257792-machine-learning/suggestions/7668225-julia-support-in-azureml-s

Re: [julia-users] Semantic equivalent to Perl pack/unpack

t; fixed sized char arrays > > > On 0.3 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 F

Re: [julia-users] Re: verbs for immutable collections

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 thi

[julia-users] Re: Defining a function in different modules

@Scott, @Toivo In my mind this changing the meaning of existing code is happening all the time with the verbs in Base. Each time I use a module it can (and likely does) inject new behavior for verbs defined in Base ( or for verbs defined in any other module) These silently change the way other

[julia-users] Semantic equivalent to Perl pack/unpack

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 a

Re: [julia-users] Re: verbs for immutable collections

ates to reserve names for in Base >> even if there aren't any types in Base where that generic function makes >> sense. >> >> >> On Wednesday, May 13, 2015 at 5:08:19 PM UTC-7, Kevin Squire wrote: >>> >>> If you haven't yet, you should check ou

Re: [julia-users] Re: verbs for immutable collections

@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 im

[julia-users] Re: Defining a function in different modules

I ran into this issue yet again today with two packages where both defined the 'verb' "title". It cost me more time than I wanted to spend to figure out what the issue was. Both modules of code worked in isolation and both worked together in another package until I added a method call "title" (t

Re: [julia-users] Re: verbs for immutable 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 wo

Re: [julia-users] Re: verbs for immutable collections

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.

[julia-users] Re: verbs for immutable collections

fusion. > > Would you please elaborate on this? I'm not sure I understand (I'm > confident the issue is on my end). > > On Wednesday, May 13, 2015 at 3:03:11 PM UTC-4, Michael Francis wrote: >> >> A little bit of both, I have defined what I would consider c

[julia-users] Re: verbs for immutable collections

ndex and delete, thereby conflicting 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 i

[julia-users] verbs for immutable collections

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 to

[julia-users] [ANN] NamedTuples.jl: Named Tuples for Julia

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 Julia’

[julia-users] Re: merge functions from different modules

@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 > is

Re: [julia-users] Re: Defining a function in different modules

good thing. On Thursday, April 30, 2015 at 5:18:23 PM UTC-4, Stefan Karpinski wrote: > > On Thu, Apr 30, 2015 at 12:19 PM, Michael Francis > wrote: > >> My goal is not to remove namespaces, quite the opposite, for types a >> namespace is an elegant solution to resolvin

Re: [julia-users] Re: Defining a function in different modules

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 cit

Re: [julia-users] Re: Defining a function in different modules

to write `using > Distributions` and suddenly having all of the stats stuff you might want > available easily, you'd have to keep qualifying everything or explicitly > importing it. Both suck for interactive usage – and frankly even for > non-interactive usage, qualifyin

Re: [julia-users] Re: Defining a function in different modules

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 M

Re: [julia-users] Re: Defining a function in different modules

Lex, MA Laforge, It sounds like many of us agree, I'm not convinced by the it's hard argument though - I made the point at the outset that it isn't hard (or expensive) if the *exported *functions from a module *must reference types defined in that module*. Hence the suggestion that module de

Re: [julia-users] Re: Defining a function in different modules

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 ?

Re: [julia-users] Re: Defining a function in different modules

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 ge

Re: [julia-users] Re: Defining a function in different modules

Mauro, I like that idea that there is a central place. It is perhaps something akin to an interface. Being able to define and document an external interface for a module makes a lot of sense. I'd love to see interfaces in general, especially for things like iteration. If I implement a base in

Re: [julia-users] Re: Defining a function in different modules

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 don

Re: [julia-users] Re: Defining a function in different modules

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, ...) sud

Re: [julia-users] Re: Defining a function in different modules

exclude > that kind of use. > > Also, printing a warning is not the key part of #4345. The important > part is that you'd have to qualify names in that case, which is the > same thing that would happen if `export`ing the names were disallowed. > > > On Wed, Apr 22

Re: [julia-users] Re: Defining a function in different modules

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 ru

[julia-users] loading local resources in module

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 se

Re: [julia-users] Union types and contravariance, question

on. > > On Thursday, April 2, 2015 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: >>> >>>

Re: [julia-users] Union types and contravariance, question

> Vector{Float64}<:Vector{Union( Int64, Float64)} is false. Thus the no > method error. > > On Thu, 2015-04-02 at 21:32, Michael Francis > wrote: > > Is the following expected behavior for union types, I'm assuming yes ? > > > > v = Union( Int64,Float6

[julia-users] Union types and contravariance, question

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 f(::Array

[julia-users] HTML construction package

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 not

Re: [julia-users] Array construction types question

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

Re: [julia-users] Array construction types question

, Float64}) = Foo{Int} > > That rule basically gives higher 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

Re: [julia-users] Array construction types question

ow{Y, Z}() >> >> then the result would be Any. >> >> On Wed, Apr 1, 2015 at 11:45 AM, Stefan Karpinski > > wrote: >> > Arguably typejoin should do that. >> > >> > On Wed, Apr 1, 2015 at 11:35 AM, Michael Francis > > >> > wrote: >

Re: [julia-users] Array construction types question

riate 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 > wrote: > >> If I run the following,

[julia-users] Re: Array construction types question

is when asking 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 Fr

[julia-users] Array construction types question

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 typ

[julia-users] Re: Type system question

11, 2015 at 12:43:46 PM 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 (index<0) ? default : h.vals[index]::V > end > > and change my code to use this myget i

[julia-users] Re: Type system question

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) > >

[julia-users] Type system question

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 ?

Re: [julia-users] Re: request for feature: modify field in immutable object in a container

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 an

Re: [julia-users] Why do I get a no method exception for type parameters ?

> > > 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: [julia-users] Why do I get a no method exception for type parameters ?

> to the Foo object. It's a but confusing, I know. > > On Tue, Feb 10, 2015 at 12:38 PM, Michael Francis > 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 &

Re: [julia-users] Why do I get a no method exception for type parameters ?

ructor method, then you can call it. > > On Tue, Feb 10, 2015 at 12:15 PM, Michael Francis > 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 >>

[julia-users] Why do I get a no method exception for type parameters ?

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 ) )

Re: [julia-users] Re: request for feature: modify field in immutable object in a container

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

Re: [julia-users] Re: request for feature: modify field in immutable object in a container

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

Re: [julia-users] request for feature: modify field in immutable object in a container

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 fun

Re: [julia-users] Anon functions and closures, is this the expect behavior?

I suspect) you want. > > On Thu, 2015-02-05 at 16:26, Michael Francis > wrote: > > function test() > > x = 2 > > f = (()->x + 3) > > println( f() ) # Prints 5 Yeh! > > x = 4 > > println( f() ) # Prints 7 ??? > > g = ((

[julia-users] Anon functions and closures, is this the expect behavior?

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 t

  1   2   >