RE: [julia-users] Re: Hide and disable REPL

[David Anthoff]

I think most of them just have the code pasted into the REPL. That would work 
for us as well, but then we can’t do things like eval code in the context of a 
specific module.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of cdm
Sent: Monday, November 14, 2016 6:27 PM
To: julia-users 
Subject: Re: [julia-users] Re: Hide and disable REPL

 

 

do you know of there are analogs of your process flow

in other VS Code extensions, say the python extension

for VS Code ... ?

 

it seems that perhaps another VS Code implementation

would have had to also cross this bridge ... ?

 

~ cdm

 



On Monday, November 14, 2016 at 1:27:18 PM UTC-8, ant...@berkeley.edu 
  wrote: 

Bump, any help would really be appreciated. We are very, very close to 
releasing an amazing new version of the julia extension for VS Code, this is 
pretty much the only thing holding that release back right now. 

 

Thanks,

David

RE: [julia-users] Re: Hide and disable REPL

[David Anthoff]

That deletes everything, but really I just want to hide the current prompt. So 
say this is how the console looks:



julia> println(5)

5

julia>function foo(x)

   println(x)



So in this case the users is in the middle of entering something new into the 
REPL (i.e. the definition of foo). Assume that at this point my background task 
receives a message. I then want to be able to delete line 3+5, and position the 
cursor on column 1 line 3. Then I’ll execute the code that was sent to the 
server. Once that is finished, I want to print line 3+4, as it was before I hid 
the current prompt, again, starting at whatever the current cursor position is.

 

For example, say the background task received some code that printed “Foo” 
to the console, then I want the console to look like this, immediately after 
that code was executed:



julia> println(5)

5

Foo

julia>function foo(x)

   println(x)



I.e. the user could continue editing the stuff that he/she was working on 
before the background task briefly took over.

 

Thanks,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Steven G. Johnson
Sent: Tuesday, November 15, 2016 5:29 AM
To: julia-users 
Subject: Re: [julia-users] Re: Hide and disable REPL

 



On Friday, November 4, 2016 at 1:28:16 PM UTC-4, David Anthoff wrote: 

 

The complete setup is slightly more complicated, but you can imagine just the 
following: start a normal julia REPL. Then include a file that will start a 
server listening on some socket. This server is all async, so as soon as the 
server is started, the prompt appears again and one can use this REPL window in 
the normal way. Now some other process connects to the socket, and sends some 
code that this server will eval. Before the server evals this code, I would 
like it to switch off the prompt, then eval the code, then switch the prompt on 
again.

 

Base.Terminals.clear(Base.active_repl.t); sleep(10)

 

will clear the REPL window (including prompt) for 10 seconds.  Instead of 
sleep(10), you can do wait(c) where c is a Condition variable that gets 
notified by the server thread once it is ready.  See 
http://docs.julialang.org/en/latest/stdlib/parallel/?highlight=wait

RE: [julia-users] Re: Escaped $ in Strings has a strange behavior

[David Anthoff]

Ah, thanks for the answer, that does make sense. 

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Yichao Yu
> Sent: Monday, November 7, 2016 8:02 PM
> To: Julia Users 
> Subject: Re: [julia-users] Re: Escaped $ in Strings has a strange behavior
> 
> On Mon, Nov 7, 2016 at 10:55 PM, cdm  wrote:
> >
> >
> > On Monday, November 7, 2016 at 7:51:34 PM UTC-8, Yichao Yu wrote:
> >>
> >> Just to be clear. print/println does not "un-decorate" anything at
> >> all. It's `show`/`display`/`dump` "decorate" (escape/quote) it.
> >
> >
> > perhaps the help docs are not clear then ... ?
> >
> >   print(x)
> >
> >   Write (to the default output stream) a canonical (un-decorated) text
> > representation of a value if there is one, otherwise call show. The
> > representation used
> >   by print includes minimal formatting and tries to avoid
> > Julia-specific details.
> 
> The doc string says that the function prints the form that is `un-decorated`
> i.e. not decorated, different from show, which does `decorate` it.

[julia-users] Escaped $ in Strings has a strange behavior

[David Anthoff]

I get 

 

julia> x = "I have \$100 in my account"

"I have \$100 in my account"

 

Shouldn't the backlash not appear in the output? If then do

 

println(x)

 

the backlash doesn't show, but I would have expected that it also doesn't
show if I just eval the string.

 

Am I missing something basic here?

 

Thanks,

David

RE: [julia-users] Getting parameter names from Method

[David Anthoff]

Thanks!

 

I’ve now been using Base.arg_decl_parts, which also seems to work. Any word of 
wisdom which of these two approaches is “better”?

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Ralph Smith
Sent: Friday, November 4, 2016 8:23 PM
To: julia-users 
Subject: Re: [julia-users] Getting parameter names from Method

 

julia> mt=methods(randjump)

# 2 methods for generic function "randjump":

randjump(r::MersenneTwister, jumps::Integer) at random.jl:145

randjump(mt::MersenneTwister, jumps::Integer, jumppoly::AbstractString) at 
random.jl:137

 

julia> mt.ms[2].lambda_template.slotnames

8-element Array{Any,1}:

 Symbol("#self#")

 :mt 

 :jumps  

 :jumppoly   

 :mts

 Symbol("#temp#")

 :i  

 :cmt

 

julia> mt.ms[2].lambda_template.nargs

4

 




On Friday, November 4, 2016 at 7:00:56 PM UTC-4, David Anthoff wrote:

How do I get at this nargs field? On julia 0.5 Method doesn't seem to have a 
field with that name? 

> -Original Message- 
> From: julia...@googlegroups.com   [mailto:julia-   
> us...@googlegroups.com  ] On Behalf Of Yichao Yu 
> Sent: Friday, November 4, 2016 3:54 PM 
> To: Julia Users  > 
> Subject: Re: [julia-users] Getting parameter names from Method 
> 
> On Fri, Nov 4, 2016 at 6:31 PM, David Anthoff   > 
> wrote: 
> > Is there a way to get the names of the parameters of a method from a 
> > Method type instance on julia 0.5? 
> 
> Roughly: 
> 
> nargs tell you how many arguments the method accepts, the first one being 
> the object (function) being called. 
> The local variables names are available in the CodeInfo.slotnames and the 
> first nargs ones are the parameter names. 
> The CodeInfo can be found in the source field of the method for non- 
> generated functions and unspecialized.inferred for generated function. 
> 
> > 
> > 
> > 
> > Thanks, 
> > 
> > David 

RE: [julia-users] Getting parameter names from Method

[David Anthoff]

How do I get at this nargs field? On julia 0.5 Method doesn't seem to have a 
field with that name?

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Yichao Yu
> Sent: Friday, November 4, 2016 3:54 PM
> To: Julia Users 
> Subject: Re: [julia-users] Getting parameter names from Method
> 
> On Fri, Nov 4, 2016 at 6:31 PM, David Anthoff 
> wrote:
> > Is there a way to get the names of the parameters of a method from a
> > Method type instance on julia 0.5?
> 
> Roughly:
> 
> nargs tell you how many arguments the method accepts, the first one being
> the object (function) being called.
> The local variables names are available in the CodeInfo.slotnames and the
> first nargs ones are the parameter names.
> The CodeInfo can be found in the source field of the method for non-
> generated functions and unspecialized.inferred for generated function.
> 
> >
> >
> >
> > Thanks,
> >
> > David

[julia-users] Getting parameter names from Method

[David Anthoff]

Is there a way to get the names of the parameters of a method from a Method
type instance on julia 0.5?

 

Thanks,

David

RE: [julia-users] Re: Hide and disable REPL

[David Anthoff]

Ah, I should have been clearer. I just want to hide the prompt temporarily.

 

The complete setup is slightly more complicated, but you can imagine just the 
following: start a normal julia REPL. Then include a file that will start a 
server listening on some socket. This server is all async, so as soon as the 
server is started, the prompt appears again and one can use this REPL window in 
the normal way. Now some other process connects to the socket, and sends some 
code that this server will eval. Before the server evals this code, I would 
like it to switch off the prompt, then eval the code, then switch the prompt on 
again.

 

The setup is that VS Code starts a new julia process, and shows the normal 
julia REPL in a terminal emulation within VS Code. This instance is running the 
server I just described. The julia VS Code extension that will send code to 
this REPL window if a user hits Ctrl+Enter in any of the open editor windows.

 

Not sure this is much clearer, let me know if you need more info!

 

Best,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Isaiah Norton
Sent: Thursday, November 3, 2016 8:38 PM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Re: Hide and disable REPL

 

Can you explain the setup further -- Where is the REPL running? How are you 
interacting with it? If I take "I want to temporarily switch the REPL off, i.e. 
it should visually disappear" literally then it seems like a strange thing to 
do, so I may be missing something

 

If you *do* want to hide the terminal window (if any) the REPL is (may be) 
running in, that's going to be very hard to do generally and across platforms 
(on Windows under Console you can use GetActiveWindow or GetActiveConsole, but 
on real pty platforms the process doesn't necessarily know anything about the 
terminal it is connected to beyond termcap and i/o).

 

On Thu, Nov 3, 2016 at 7:41 PM, mailto:anth...@berkeley.edu> > wrote:

Bump, it would be great if someone could point me to some approach for this. We 
are getting an integrated terminal ready in VS Code, and this is the one piece 
missing right now.

 

Thanks,

David



On Thursday, June 23, 2016 at 5:00:22 PM UTC-7, David Anthoff wrote:

Hi,

 

is there a way to switch off the REPL and then on again, from a task?

 

Specifically, I want to start a julia instance and pass a script in with the –L 
parameter that will open a socket, listen for connections and the process 
messages from that socket. This server listening code is all wrapped in @async 
macro calls. So when I start things this way, julia shows the REPL and at the 
same time listens for incoming messages. I can use the REPL etc. This is 
exactly what I want.

 

But when I receive a message, I want to temporarily switch the REPL off, i.e. 
it should visually disappear while I process that message, and then I want to 
switch it back on once I’m done processing that message.

 

Can that be done somehow?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

 

RE: [julia-users] [ANN] DataStreams v0.1: Blog post + Package Release Notes

[David Anthoff]

Thanks, this is really super cool work!

 

Let me also point out that Query.jl works great with DataStream sources and 
sinks. For example, let’s say you want to load some code from a SQLite 
database, apply some filtering and transformations and write the result out as 
a CSV file, you can do that like this:

 

using Query, SQLite, CSV

sqlite_db = SQLite.DB(joinpath(Pkg.dir("SQLite"), "test", 
"Chinook_Sqlite.sqlite"))

q = @from i in SQLite.Source(sqlite_db, "SELECT * FROM Employee") begin

@where i.ReportsTo==2

@select {Name=i.LastName, Adr=i.Address}

@collect CSV.Sink("test-output.csv")

end

Data.close!(q)

 

Note that this will actually never materialize the data into a DataFrame or 
anything like that, instead everything is streamed throughout, from the 
DataStreams source to the think, including the whole query part in the middle.

 

Best,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Jacob Quinn
Sent: Thursday, October 27, 2016 11:33 PM
To: julia-users 
Subject: [julia-users] [ANN] DataStreams v0.1: Blog post + Package Release Notes

 

Hey everyone, 

 

Just wanted to put out the announcement of the release of DataStreams v0.1. (it 
was actually tagged a few weeks ago, but I've been letting a few last things 
shake out before announcing).

 

I've written up a blog post on the updates and release here: 
http://quinnj.github.io/datastreams-jl-v0-1/

 

The TL;DR is DataStreams.jl now defines concrete interfaces for Data.Sources 
and Data.Sinks, with each being completely decoupled from the other. This has 
also allowed some cool new features like appending to Data.Sinks and allowing 
simple transform functions to be applied to data "in-transit".

 

I included release notes of existing packages in the blog post, but I'll 
copy-paste here below for easier access:

 

Do note that the DataStreams.jl framework is now Julia 0.5-only.

 

 

·  CSV.jl

o  Docs

oSupports a wide variety of delimited file options such as delim, 
quotechar, escapechar, custom null strings; a header can be provided manually 
or on a specified row or range of rows; types can be provided manually, and 
results can be requested as nullable or not (nullable=true by default); and the 
# of rows can be provided manually (if known) for efficiency.

oCSV.parsefield(io::IO, ::Type{T}) can be called directly on any IOtype to 
tap into the delimited-parsing functionality manually

·  SQLite.jl

o  Docs

oQuery results will now use the declared table column type by default, 
which can help resultset column typing in some cases

oParameterized SQL statements are fully supported, with the ability to bind 
julia values to be sent to the DB

oFull serialization/deserialization of native and custom Julia types is 
supported; so Complex{Int128} can be stored in its own SQLite table column and 
retrieved without any issue

oPure Julia scalar and aggregation functions can be registered with an 
SQLite database and then called from within SQL statements: full docs  
 here

*   Feather.jl 

o  Docs

oFull support for feather release v0.3.0 to ensure compatibility

oFull support for returning "factor" or "category" type columns as native 
CategoricalArray and NullableCategoricalArray types in Julia, thanks to the new 
  CategoricalArrays.jl 
package

onullable::Bool=true keyword argument; if false, columns without null 
values will be returned as Vector{T} instead of NullableVector{T}

oFeather.Sink now supports appending, so multiple DataFrames or CSV.Source 
or any Data.Source can all be streamed to a single feather file

*   ODBC.jl 

o  Docs

oA new ODBC.DSN type that represents a valid, open connection to a 
database; used in all subsequent api calls; it can be constructed using a 
previously configured system/user dsn w/ username and password, or as a full 
custom connection string

oFull support for the DataStreams.jl framework through the ODBC.Sourceand 
ODBC.Sink types, along with their high-level convenience methods ODBC.query and 
ODBC.load

oA new ODBC.prepare(dsn, sql) => ODBC.Statement method which can send an 
sql statement to the database to be compiled and planned before executed 1 or 
more times. SQL statements can include parameters to be prepared that can have 
dynamic values bound before each execution.

RE: [julia-users] Re: VS code extension

[David Anthoff]

Yes, PRs to the main repo are welcome. It would be great if you could write up 
a short issue describing how this code goes about things. There are quite a 
number of strategies on how to achieve things in VS code (language server 
protocol vs everything in typescript vs mixed language solutions) and it would 
be good to sort out what is the right strategy for the extension, and how this 
new code fits in there.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Zac
Sent: Friday, October 28, 2016 8:40 AM
To: julia-users 
Subject: [julia-users] Re: VS code extension

 

Ok then, https://github.com/ZacLN/julia-vscode . I'll look into trying to make 
a pull request on the main repo. 

 

 

 

 

On Friday, October 28, 2016 at 3:29:17 PM UTC, Tony Kelman wrote:

The repo's MIT licensed, so unless this person changed the license of their 
additions, yes. Best to preserve git authorship attribution if you can. Pull 
requests to the JuliaEditorSupport repository are encouraged, I imagine.


On Friday, October 28, 2016 at 3:31:56 AM UTC-7, Zac wrote:

Hi, I'm using a fork of this that implements completions, function parameter 
hints, documentation hovers, linting and definitions. I pulled it from another 
fork that has subsequently disappeared (github.com/novatena 
 ). This 

 

Given that someone else did most of the work is it ok to share it here? 


On Tuesday, July 5, 2016 at 4:33:06 PM UTC, FANG Colin wrote:

Thank you.

 

I used to use https://github.com/Mike43110/julia.vscode which unfortunately 
doesn't provide the command for mark selection as comments. 

[julia-users] iterator trait

[David Anthoff]

Is there some way to find out whether a type can be iterated? I'm looking
for something like `isiterator(IterType)`, that would return `false` from a
default implementation and which any type that actually supports the
standard iterator interface would return `true`.

 

If we had that, we could actually define a SimpleTrait ``IsIterator`` and
use method dispatch to have methods that operate on iterators, which would
be really powerful.

 

Cheers,

David

RE: [julia-users] python-like generators?

[David Anthoff]

I don't think so. I think the python generator functions are modeled after
the C# yield keyword, which is a way to implement an iterator. I believe
tasks are quite a different beast. At least in C# tasks interact with the
async/await story really well. I think the julia tasks might be similar to
that, but I'm not sure.

In any case, having a yield keyword to implement standard iterators would be
fantastic. Simply a way to get the start, next and done methods implemented
automatically.

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Mauro
> Sent: Thursday, October 13, 2016 6:00 AM
> To: julia-users@googlegroups.com
> Subject: Re: [julia-users] python-like generators?
> 
> Isn't this the same as tasks in Julia?
> http://docs.julialang.org/en/release-0.5/stdlib/parallel/
> 
> Although, note that their performance is not on par with start-next-done
> iteration.
> 
> On Thu, 2016-10-13 at 14:46, Neal Becker  wrote:
> > julia-0.5 supports generator expressions, ala python, which is very
nice.
> >
> > Any thoughts on supporting the more general python generator
> > functions, as described e.g.: https://wiki.python.org/moin/Generators?
> > I haven't used them much myself (well, once), but they seem a really
cool
> idea.

RE: [julia-users] Filtering DataFrame with a function

[David Anthoff]

Yes, I think the general plan of the DataFrames maintainers is to largely rely 
on packages like Query and StructuredQueries for data manipulation.

 

There is another benefit of having this kind of query infrastructure in its own 
package: all the query operations that I showed that use Query also work 
against any other data source, i.e. you can use those with arrays, 
dictionaries, directly with a CSV source (and everything will be streamed, no 
allocations of intermediates!), TypedTables, IndexedTables and many more.

 

Cheers,

David

 

From: karbar...@gmail.com [mailto:karbar...@gmail.com] On Behalf Of Jacob Quinn
Sent: Wednesday, October 12, 2016 11:14 PM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Filtering DataFrame with a function

 

I think the Julia ecosystem is evolving tremendously in this respect. I think 
originally, there were a lot of these "mammoth" packages that tried to provide 
everything and the kitchen sink. Unfortunately, this has led to package bloat, 
package inefficiencies in terms of load times and installation, and 
unmaintainability. DataFrames and Gadfly are great examples.

 

The trend more recently has been a rededication to small, modular packages that 
interopt nicely with others. This means moving things **out** of packages that 
aren't totally essential: or in the case of DataFrames, that can include things 
like IO (CSV.jl), data manipulation (Query.jl and StructuredQuery.jl), and 
others.

 

Ultimately, with the help of core languages features like 
(https://github.com/JuliaLang/julia/issues/15705), I think we'll continue to 
see packages slim down. This, of course, opens up more possibilities in the 
future for so-called "meta" packages that could bundle several packages 
together. These "meta" packages are then essentially tasked with tracking 
versions, dependencies, and so forth while individual packages can focus on 
simple, solid code.

 

-Jacob

 

 

On Wed, Oct 12, 2016 at 11:20 PM, Júlio Hoffimann mailto:julio.hoffim...@gmail.com> > wrote:

Thank you very Much David, these queries you showed are really nice. I meant 
that ideally I wouldn't need to install another package for a simple filter 
operation on the rows.

 

-Júlio

 

2016-10-12 22:14 GMT-07:00 mailto:anth...@berkeley.edu> 
>:

Were you worried about Query being not lightweight enough in terms of overhead, 
or in terms of syntax?

 

I just added a more lightweight syntax for this scenario to Query. You can now 
do the following two things:

 

q = @where(df, i->i.price > 30.)

 

that will return a filtered iterator. You can materialize that into a DataFrame 
with collect(q, DataFrame).

 

I also added a counting option. Turns out that is actually a LINQ query 
operator, and the goal is to implement all of those in Query. The syntax is 
simple:

 

@count(df, i->i.price > 30.)

 

returns the number of rows for which the filter condition is true.

 

Under the hood both of these new syntax options use the normal Query machinery, 
this just provides a simpler syntax relative to the more elaborate things I've 
posted earlier. In terms of LINQ, this corresponds to the method invocation API 
that LINQ has. I'm still figuring out how to surface something like @count in 
the query expression syntax, but for now one can use it via this macro.

 

All of this is on master right now, so you would have to do 
Pkg.checkout("Query") to get these macros.

 

Best,

David


On Wednesday, October 12, 2016 at 6:47:15 PM UTC-7, Júlio Hoffimann wrote:

Hi David,

 

Thank you for your elaborated answer and for writing a package for general 
queries, that is great! I will keep the package in mind if I need something 
more complex.

 

I am currently looking for a lightweight solution within DataFrames, filtering 
is a very common operation. Right now, I am considering converting the 
DataFrame to an array and looping over the rows. I wonder if there is a 
syntactic sugar for this loop.

 

-Júlio

 

2016-10-12 17:48 GMT-07:00 David Anthoff < <mailto:ant...@berkeley.edu> 
ant...@berkeley.edu>:

Hi Julio,

 

you can use the Query package for the first part. To filter a DataFrame using 
some arbitrary julia expression, use something like this:

 

using DataFrames, Query, NamedTuples

 

q = @from i in df begin

@where 

@select i

end

 

You can use any julia code in . Say your DataFrame has a 
column called price, then you could filter like this:

 

@where i.price > 30.

 

The i will be a NamedTuple type, so you can access the columns either by their 
name, or also by their index, e.g.

 

@where i[1] > 30.

 

if you want to filter by the first column. You can also just call some function 
that you have defined somewhere else:

 

@where foo(i)

 

As long as the  returns a Bool, you should be good.

 

If you run a query like this, q will be a standard julia iterator. 

RE: [julia-users] Filtering DataFrame with a function

[David Anthoff]

Hi Julio,

 

you can use the Query package for the first part. To filter a DataFrame using 
some arbitrary julia expression, use something like this:

 

using DataFrames, Query, NamedTuples

 

q = @from i in df begin

@where 

@select i

end

 

You can use any julia code in . Say your DataFrame has a 
column called price, then you could filter like this:

 

@where i.price > 30.

 

The i will be a NamedTuple type, so you can access the columns either by their 
name, or also by their index, e.g.

 

@where i[1] > 30.

 

if you want to filter by the first column. You can also just call some function 
that you have defined somewhere else:

 

@where foo(i)

 

As long as the  returns a Bool, you should be good.

 

If you run a query like this, q will be a standard julia iterator. Right now 
you can’t just say length(q), although that is something I should probably 
enable at some point (I’m also looking into the VB LINQ syntax that supports 
things like counting in the query expression itself).

 

But you could materialize the query as an array and then look at the length of 
that:

 

q = @from i in df begin

@where 

@select i

@collect

end

count = length(q)

 

The @collect statement means that the query will return an array of a 
NamedTuple type (you can also materialize it into a whole bunch of other data 
structures, take a look at the documentation).

 

Let me know if this works, or if you have any other feedback on Query.jl, I’m 
much in need of some user feedback for the package at this point. Best way for 
that is to open issues here https://github.com/davidanthoff/Query.jl.

 

Best,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Júlio Hoffimann
Sent: Wednesday, October 12, 2016 5:20 PM
To: julia-users 
Subject: [julia-users] Filtering DataFrame with a function

 

Hi,

 

I have a DataFrame for which I want to filter rows that match a given criteria. 
I don't have the number of columns beforehand, so I cannot explicitly list the 
criteria with the :symbol syntax or write down a fixed number of indices.

 

Is there any way to filter with a lambda expression? Or even better, is there 
any efficient way to count the number of occurrences of a specific row of 
observations?

 

-Júlio

RE: [julia-users] Julia and the Tower of Babel

[David Anthoff]

I don’t have a solution, but I completely agree with the problem description.

 

I guess one small step would be that package authors should follow the patterns 
in base, if there are any. 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Gabriel Gellner
Sent: Friday, October 7, 2016 8:36 AM
To: julia-users 
Subject: [julia-users] Julia and the Tower of Babel

 

Something that I have been noticing, as I convert more of my research code over 
to Julia, is how the super easy to use package manager (which I love), coupled 
with the talent base of the Julia community seems to have a detrimental effect 
on the API consistency of the many “micro” packages that cover what I would 
consider the de-facto standard library.

What I mean is that whereas a commercial package like Matlab/Mathematica etc., 
being written under one large umbrella, will largely (clearly not always) 
choose consistent names for similar API keyword arguments, and have similar 
calling conventions for master function like tools (`optimize` versus `lbfgs`, 
etc), which I am starting to realize is one of the great selling points of 
these packages as an end user. I can usually guess what a keyword will be in 
Mathematica, whereas even after a year of using Julia almost exclusively I find 
I have to look at the documentation (or the source code depending on the 
documentation ...) to figure out the keyword names in many common packages.

Similarly, in my experience with open source tools, due to the complexity of 
the package management, we get large “batteries included” distributions that 
cover a lot of the standard stuff for doing science, like python’s numpy + 
scipy combination. Whereas in Julia the equivalent of scipy is split over many, 
separately developed packages (Base, Optim.jl, NLopt.jl, Roots.jl, NLsolve.jl, 
ODE.jl/DifferentialEquations.jl). Many of these packages are stupid awesome, 
but they can have dramatically different naming conventions and calling 
behavior, for essential equivalent behavior. Recently I noticed that 
tolerances, for example, are named as `atol/rtol` versus `abstol/reltol` versus 
`abs_tol/rel_tol`, which means is extremely easy to have a piece of scientific 
code that will need to use all three conventions across different calls to 
seemingly similar libraries. 

Having brought this up I find that the community is largely sympathetic and, in 
general, would support a common convention, the issue I have slowly realized is 
that it is rarely that straightforward. In the above example the abstol/reltol 
versus abs_tol/rel_tol seems like an easy example of what can be tidied up, but 
the latter underscored name is consistent with similar naming conventions from 
Optim.jl for other tolerances, so that community is reluctant to change the 
convention. Similarly, I think there would be little interest in changing 
abstol/reltol to the underscored version in packages like Base, ODE.jl etc as 
this feels consistent with each of these code bases. Hence I have started to 
think that the problem is the micro-packaging. It is much easier to look for 
consistency within a package then across similar packages, and since Julia 
seems to distribute so many of the essential tools in very narrow boundaries of 
functionality I am not sure that this kind of naming convention will ever be 
able to reach something like a Scipy, or the even higher standard of commercial 
packages like Matlab/Mathematica. (I am sure there are many more examples like 
using maxiter, versus iterations for describing stopping criteria in iterative 
solvers ...)

Even further I have noticed that even when packages try to find consistency 
across packages, for example Optim.jl <-> Roots.jl <-> NLsolve.jl, when one 
package changes how they do things (Optim.jl moving to delegation on types for 
method choice) then again the consistency fractures quickly, where we now have 
a common divide of using either Typed dispatch keywords versus :method symbol 
names across the previous packages (not to mention the whole inplace versus 
not-inplace for function arguments …)

Do people, with more experience in scientific packages ecosystems, feel this is 
solvable? Or do micro distributions just lead to many, many varying degrees of 
API conventions that need to be learned by end users? Is this common in 
communities that use C++ etc? I ask as I wonder how much this kind of thing can 
be worried about when making small packages is so easy.

RE: [julia-users] Is there a way to use values in a DataFrame directly in computation?

[David Anthoff]

Query.jl does not aim to make working with Nullables easier. The package 
provides querying capabilities, and is specifically designed to simply pick up 
whatever support for Nullables there is in julia base. Right now, as a 
temporary measure, Query.jl defines lots of methods for functions like 
arithmetic operators (``+`` etc.) for Nullables. Without those definitions the 
package would be close to unusable (in the same way that DataFrames right now 
is close to unusable). But I really hope to move these methods out of Query.jl, 
they don’t belong in that package, instead those methods should be in base (the 
approach here is what David Gold called the “method extension lifting 
approach”).

 

I feel strongly that “pushing” the problem of how to deal with Nullables into 
querying packages is not the right strategy. Instead I would much prefer to see 
better support for Nullables generally, and then packages like Query.jl can 
pick that support up. There are too many situations where using a query package 
is overkill, but where you will still encounter Nullables (especially now that 
DataFrames is based on NullableArrays). If we ask folks to use query packages 
in all of these cases we will have created a conceptually clean but completely 
impractical system, IMHO. For example, I think the examples from the original 
email simply need to work before the new DataFrames is tagged. Those kinds of 
operations are sooo common, I would find it completely impractical to ask folks 
to use something like Query.jl in such a situation.

 

I think the path to this is pretty simple: all we have to do is add methods for 
the common arithmetic operators that work on Nullable types. That is the 
approach that C# took, and it works really well. Maybe add some methods for 
Strings. I think once that is covered, most of the common use cases are dealt 
with and the system would work well in practice. Those new methods could be 
added to the julia master branch now, and then be backported to julia 0.5. Once 
that is done DataFrames could be merged.

 

Best,

David

 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of John Myles White
Sent: Monday, October 3, 2016 5:05 PM
To: julia-users 
Subject: Re: [julia-users] Is there a way to use values in a DataFrame directly 
in computation?

 

I think the core problem is that the current API + Nullable's is very 
cumbersome, but the switch to Nullable's will hopefully occur nearly 
simultaneously with the introduction of new API's that can make Nullable's much 
easier to deal with. David Gold spent the summer working on one approach that 
is, I think, much better than the current API; David Anthoff also has another 
approach that is substantially more powerful than the current API. The time 
between 0.5 and 0.6 may be a little chaotic in this regard, but I think the 
eventual results will be unequivocally worth the wait.


 -- John


On Monday, October 3, 2016 at 3:45:42 PM UTC-7, Min-Woong Sohn wrote:

Thank you. I fear that Nullables will make the DataFrame very difficult to use 
and turn many people away from Julia. 

 



On Monday, October 3, 2016 at 12:20:32 PM UTC-4, Milan Bouchet-Valat wrote:

Le lundi 03 octobre 2016 à 08:21 -0700, Min-Woong Sohn a écrit : 
> 
> I am using DataFrames from master branch (with NullableArrays as the 
> default) and was wondering how the following should be done: 
> 
> df = DataFrame() 
> df[:A] = NullableArray([1,2,3]) 
> 
> The following are not allowed or return wrong values: 
> 
> df[1,:A] == 1   # false 
> df[1,:A] > 1 # MethodError: no method matching isless(::Int64, 
> ::Nullable{Int64}) 
> df[3,:A] + 1 # MethodError: no method matching 
> +(::Nullable{Int64}, ::Int64) 
> 
> How should I get around these issues? Does anybody know if there is a 
> plan to support these kinds of computations directly? 
These operations currently work (after loading NullableArrays) if you 
rewrite 1 as Nullable(1), eg. df[1, :A] == Nullable(1). But the two 
first return a Nullable{Bool}, so you need to call get() on the result 
if you want to use them e.g. with an if. As an alternative, you can use 
isequal(). 

There are discussions as regards whether mixing Nullable and scalars 
should be allowed, as well as whether these operations should be moved 
into Julia Base. See in particular 
https://github.com/JuliaStats/NullableArrays.jl/pull/85 
https://github.com/JuliaLang/julia/pull/16988 

Anyway, the best approach to work with data frames is probably to use 
frameworks like AbstractQuery.jl and Query.jl, which are not yet 
completely ready to handle Nullable, but should make this easier. 


Regards 

[julia-users] ANN: Query.jl

[David Anthoff]

Hi all,


I just tagged Query.jl v0.1.0, and with that my little summer project should be 
ready for wider consumption.


Query.jl hopes to be the equivalent of LINQ or dplyr for julia, eventually. It 
provides a unified way to query many different data sources, the most prominent 
being DataFrames.


You can find more information and documentation at 
https://github.com/davidanthoff/Query.jl.


You should consider the package in beta at the moment: it is more or less 
feature complete and functional for a first release, but it hasn't been tested 
widely. Please do take it for a spin and report any bugs, usability issues etc. 
back.


I'm also keenly interested in collaborators. This is an ambitious project, and 
any help would be greatly appreciated. PRs are welcome!


Finally, the package builds on a lot of previous work. I just want to highlight 
some: C# LINQ (the basis for the whole package design), the NamedTuples package 
(couldn't have built Query without it) and the DataStreams ecosystem that 
enabled rapid integration of a large number of sources and sinks. And of course 
julia itself. It is quite amazing how simple it was to take a really complex 
design like LINQ and port it to julia. Not only did I never bump into any 
language limitation in the process, but julia actually enabled a couple of 
really neat features in Query.jl that would not have been possible in C#.


Here are some other highlights of the package:

- Query.jl is an almost complete implementation of the query expression section 
of the C# specification, with some additional julia specific features added in.
- The package supports a large number of data sources: DataFrames, TypedTables, 
normal arrays, any DataStream source (this includes CSV, Feather, SQLite), 
NDSparseData structures and any type that can be iterated.
- The results of a query can be materialized into a range of different data 
structures: iterators, DataFrames, arrays or any DataStream sink (this includes 
CSV and Feather files).
- One can mix and match almost all sources and sinks within one query. For 
example, one can easily perform a join of a DataFrame with a CSV file and write 
the results into a Feather file, all within one query.
- The type instability problems that one can run into with DataFrames do not 
affect Query.jl, i.e. queries against DataFrames are completely type stable.
- There are three different APIs that package authors can use to make their 
data sources queryable with this package. The most simple API only requires a 
data source to provide an iterator. Another API provides a data source with a 
complete graph representation of the query and the data source can then e.g. 
rewrite that query graph as a SQL statement to execute the query. The final API 
allows a data source to provide its own data structures that can represent a 
query graph.
- The package is completely documented.

Have fun and please report back any issues you run into.

Best,
David

[julia-users] RE: [julia-news] ANN: Julia v0.5.0 released!

[David Anthoff]

Great news, thanks to everyone who contributed to this great release! I’ve been 
using the release candidates for a couple of weeks, and 0.5 is a fantastic 
release.

 

Best,

David

 

From: julia-n...@googlegroups.com [mailto:julia-n...@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Tuesday, September 20, 2016 2:09 AM
To: julia-news 
Cc: Julia Users 
Subject: [julia-news] ANN: Julia v0.5.0 released!

 

At long last, we can announce the final release of Julia 0.5.0! See the release 
notes at https://github.com/JuliaLang/julia/blob/release-0.5/NEWS.md for more 
details, and expect a blog post with some highlights within the next few days. 
Binaries are available from the usual place  , 
and please report all issues to either the issue tracker 
  or email the julia-users list. 
Don't CC julia-news, which is intended to be low-volume, if you reply to this 
message.

 

Many thanks to all the contributors, package authors, users and reporters of 
issues who helped us get here. We'll be releasing regular monthly bugfix 
backports from the 0.5.x line, while major feature work is ongoing on master 
for 0.6-dev. Enjoy!


We haven't made the change just yet, but to package authors: please be aware 
that `release` on Travis CI for `language: julia` will change meaning to 0.5 
shortly. So if you want to continue supporting Julia 0.4 in your package, 
please update your .travis.yml file to have an "- 0.4" entry under `julia:` 
versions. When you want to drop support for Julia 0.4, update your REQUIRE file 
to list `julia 0.5` as a lower bound, and the next time you tag the package be 
sure to increment the minor or major version number via `PkgDev.tag(pkgname, 
:minor)`.

-- 
You received this message because you are subscribed to the Google Groups 
"julia-news" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to julia-news+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/julia-news/387852e5-6a73-4dd0-84b5-9914f2d5c35a%40googlegroups.com
 

 .
For more options, visit https://groups.google.com/d/optout.

RE: [julia-users] Re: Julia Users and First Customers

[David Anthoff]

I find this characterization of julia as “not released” and “alpha” really not 
helpful. To the casual reader these terms signal low quality and lots of bugs, 
and in my experience (after 2.5 years of heavy use) those are the last two 
things that come to mind with respect to julia. On the contrary, I think the 
quality of the julia builds at this point can easily compete with things like 
Python or R (in terms of bugs).

 

I think the correct characterization of the pre-1.0 builds is that julia hasn’t 
reached a stable API, i.e. you need to be willing to live with breaking changes 
coming your way. That is a VERY different thing than a buggy alpha release!

 

There is a large group of julia users out there that use julia for “real world” 
work. It is really not helpful for us if julia gets an undeserved reputation of 
being a pre-release, buggy thing that shouldn’t be used for “real work”. Such a 
reputation would question the validity of our results, whereas a reputation as 
“hasn’t reached a stable API” is completely harmless.

 

Also, keep in mind that there is julia computing out there, which is feeding 
the core dev group. They have customers that pay them (I hope) for supported 
versions of julia, so it seems highly misleading to characterize julia as not 
released and not ready for production. Heck, you can buy a support contract for 
the current released version, so in my mind that seems very much released!

 

I think it would be a good idea if the core julia group would actually put a 
definitive statement out on the website for this topic. There are a couple of 
devs that at least from the outside seem close to the core group that have made 
statements like the one below, that to any sloppy reader will just sound like 
“stay away from julia if you don’t want a bug riddled system”, and I think that 
really doesn’t square with the message that e.g. julia computing needs to put 
out there or with the state of the language. I think a good official position 
would be: “Current julia releases are of high quality and are ready to be used 
for ‘real world’ work. Pre-1.0 releases will introduce breaking API changes 
between 0.x versions, which might require extra work on the users part when 
updating to new julia versions.” Or something like that.

 

Cheers,

David

 

--

David Anthoff

University of California, Berkeley

 

 <http://www.david-anthoff.com> http://www.david-anthoff.com

 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Chris Rackauckas
Sent: Tuesday, September 13, 2016 9:05 AM
To: julia-users 
Subject: [julia-users] Re: Julia Users and First Customers

 

1. Jeff Bezanson and Stefan Karpinski. I kid (though that's true). It's the 
group of MIT students who made it. You can track the early issues and kind of 
see who's involved. 
<https://github.com/JuliaLang/julia/issues?page=348&q=is%3Aissue+is%3Aclosed>  
Very early on that's probably a good indicator of who's joining in when, but 
that only makes sense for very early Julia when using means also contributing 
to some extent.

 

2. Julia hasn't been released. Putting it in large scale production and 
treating it like it has been released is a bad idea.

 

3. The results advertise for itself. You go learn Julia and come back to your 
lab with faster code that was quicker to write than their MATLAB/Python/R code, 
and then everyone wants you to teach a workshop. Also packages seem to play a 
big role: a lot of people come to these forums for the first time to use things 
like JuMP.

 

4. Julia hasn't had its first release. 

 

Keep in mind Julia is still in its alpha. It doesn't even have a beta for v1.0 
yet. That doesn't mean it's not generally usable yet, quite the contrary: any 
hacker willing to play with it will find that you can get some extraordinary 
productivity and performance gains at this point. But just because Julia is 
doing well does not mean that it has suddenly been released. This misconception 
can lead to issues like this blog post 
<https://blog.staffjoy.com/retro-on-the-julia-programming-language-7655121ea341#.w1bggaw78>
 . Of course they had issues with Julia updating and breaking syntax: it's 
explicitly stated that Base syntax may change and many things may break because 
Julia is still in its alpha, and so there's no reason to slow down / stifle 
development for the few who jumped the gun and wanted a stable release 
yesterday. It always ends up like people complaining that the alpha/beta for a 
video game is buggy: of course it is, that's what you signed up for. Remember 
that?

 

Making sure people are aware of this fact is a good thing for Julia. If 
someone's not really a programmer and doesn't want to read Github issues / deal 
with changing documentation (a lot of mathematicians / scientists), there's 
still no reason to push Julia onto them becaus

RE: [julia-users] Re: Conda.jl needs a new maintainer

[David Anthoff]

I believe AppVeyor always is bound to a personal account, i.e. I don’t think 
you can have the second type of URL. 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Steven G. Johnson
Sent: Wednesday, September 7, 2016 1:49 PM
To: julia-users 
Subject: Re: [julia-users] Re: Conda.jl needs a new maintainer

 

I'm not completely sure of the right way to re-enable AppVeyor ... I did it for 
PyCall, but it shows up as 
https://ci.appveyor.com/project/StevenGJohnson/pycall-jl-nu3aa  how do I 
enable it as https://ci.appveyor.com/project/JuliaPy/pycall-jl?


On Wednesday, September 7, 2016 at 1:46:08 PM UTC-4, Tony Kelman wrote:

Please re enable all CI services for every repo that was moved into that 
prganization. Travis and AppVeyor don't always handle repo moves very well.

RE: [julia-users] Re: Pkg.update() does not pull latest version?

[David Anthoff]

Also see

https://github.com/JuliaLang/julia/issues/17799

https://github.com/JuliaLang/julia/issues/17571

 

No solutions yet, but some ideas.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tim Wheeler
Sent: Tuesday, September 6, 2016 9:36 AM
To: julia-users 
Subject: [julia-users] Re: Pkg.update() does not pull latest version?

 

Ok, will do!

On Tuesday, September 6, 2016 at 9:31:25 AM UTC-7, Tony Kelman wrote:

There's a bug somewhere with that error message, I've seen it points at the 
wrong package. If we can come up with a reproducible test case here it'll help 
for fixing the bug and making that message more useful.

It's almost certainly not Compat (I don't think anyone has ever added an upper 
bound to a Compat dependency). Perhaps loop over Pkg.installed() and display 
the contents of the REQUIRE file for the specific tags you have currently 
installed, see who is upper-bounding each other? We do need better tools for 
debugging this kind of thing to make it easier to figure out what the 
dependency resolver is doing, which bound constraints are active etc.


On Tuesday, September 6, 2016 at 9:25:53 AM UTC-7, Tim Wheeler wrote:

Okay - I removed GaussianMixtures and now it is complaining about Compat. 

 

ERROR: unsatisfiable package requirements detected: no feasible version could 
be found for package: Compat

 

I wrote a script to run through all package REQUIRE files and print out the 
Compat line, if any. None of these found anything specifying an upper-bound.

 

I would like to find the offending packages. Is there a good way to go about 
doing this?

 

Thank you.

 

ArgParse:  Compat 0.7.3

ArrayViews:Compat

AutomotiveDrivingModels:   Compat 0.8

AxisAlgorithms:Compat 0.8

BayesNets: Compat

BinDeps:   Compat 0.8.4

Blink: Compat 0.8.6

Blosc: Compat 0.8

BufferedStreams:   Compat 0.8.4

Cairo: Compat 0.8.0

Calculus:  Compat 0.4.0

Codecs:Compat 0.7.20

Colors:Compat 0.8.0

Compose:   Compat 0.8.0

Conda: Compat 0.8

ConjugatePriors:   Compat 0.4.0

Contour:   Compat 0.8.0

DataArrays:Compat 0.8.6

DataFrames:Compat 0.8

Debug: Compat

Discretizers:  Compat

Distances: Compat 0.8.4

Distributions: Compat 0.4.0

Docile:Compat 0.7.1

FastAnonymous: Compat

FileIO:Compat 0.7.19

FixedPointNumbers: Compat 0.7.14

FixedSizeArrays:   Compat 0.8.7

Formatting:Compat

ForwardDiff:   Compat 0.8.6

Gadfly:Compat 0.8.5

Glob:  Compat

Graphs:Compat 0.7.16

Gtk:   Compat 0.8.0

GtkUtilities:  Compat 0.7.16

GZip:  Compat 0.8.0

HDF5:  Compat 0.8.0

Hexagons:  Compat

Hiccup:Compat 0.8.2

HttpCommon:Compat 0.7.20

HttpParser:Compat 0.7.20

HttpServer:Compat 0.7.16

IJulia:Compat 0.7.20

ImageMagick:   Compat 0.7.7

Images:Compat 0.8.4

ImageView: Compat 0.4.6

IniFile:   Compat 0.7.4

Interact:  Compat 0.7

Interpolations:Compat 0.8.0

Ipopt: Compat 0.8.0

Iterators: Compat

JLD:   Compat 0.8.0

JSON:  Compat 0.8.4

JuMP:  Compat 0.8.6

KernelDensity: Compat

LaTeXStrings:  Compat 0.8.0

Lazy:  Compat 0.8.0

LegacyStrings: Compat 0.8.4

Libz:  Compat 0.8.0

LightXML:  Compat 0.8.3

Lint:  Compat 0.8.2

Loess: Compat 0.8.4

MacroTools:Compat

MathProgBase:  Compat 0.7.13

MbedTLS:   Compat 0.8.0

MLBase:Compat

MultivariateStats: Compat 0.8.4

Mustache:  Compat 0.7.18

NBInclude: Compat 0.7.9

Nettle:Compat 0.8.0

NLopt: Compat 0.8

Optim: Compat 0.8.4

ParserCombinator:  Compat 0.7.12

PDMats:Compat

PGFPlots:  Compat 0.8.0

PlotlyJS:  Compat 0.7.

RE: [julia-users] Re: Rescuing abandoned package

[David Anthoff]

Also, your PR is 10 days old. People go on vacation longer than that, so I 
would just give it a little more time before you fork. It looks as if the 
author was forking things 11 days ago, so I think it is premature to conclude 
that he/she disappeared.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Chris Rackauckas
Sent: Friday, September 2, 2016 3:48 PM
To: julia-users 
Subject: [julia-users] Re: Rescuing abandoned package

 

You can fork, update it, and then put a PR in to METADATA which changes the url 
for the package. Someone like @tkelman will probably try to contact the author 
to make sure he/she's really disappeared. Open an issue on METADATA and see if 
the author shows up.

On Friday, September 2, 2016 at 3:34:42 PM UTC-7, Evan Fields wrote:

I use the package GreatCircle   for 
great circle distance calculations. On 0.4.x it generates depwarns, and it's 
incompatible with 0.5. I've opened a pull request with the tiny changes needed 
to use the package on 0.5, but there's been no response and from the author's 
Github profile it looks like he/she is no longer generally active. Is there a 
way to rescue the package in this situation? (Besides perhaps forking and 
renaming, which leads to cluttered package names...)

RE: [julia-users] Re: ANN: Documenter.jl 0.3

[David Anthoff]

Yes, this is really cool, much appreciated!!

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Christoph Ortner
Sent: Saturday, August 20, 2016 6:56 PM
To: julia-users 
Subject: [julia-users] Re: ANN: Documenter.jl 0.3

 

this is really nice; thank you for putting this package together.

On Saturday, 20 August 2016 12:36:21 UTC+1, Morten Piibeleht wrote:

On Saturday, August 20, 2016 at 2:18:37 AM UTC+3, Christoph Ortner wrote:

I want to give this a try but I can't find the example of HTML output, which is 
supposed to be in test/html? 

 

Thank you. 

 

I apologize, the linked docs are a bit outdated and will be updated shortly. As 
was already mentioned, since Documenter uses the HTML output for its own docs, 
`docs/make.jl` is the best example.

 

`mkdocs.yml` has been dropped indeed. Instead the site's structure and title 
have to be defined in `make.jl`, via the (currently undocumented) `sitename` 
and `pages` options.

 

The HTML site gets built into `build/` directly, where we normally have 
outputted the processed Markdown files (with the filenames being translated as 
`path/file.md  ` -> `path/file.html`).

 

On Saturday, August 20, 2016 at 2:53:23 AM UTC+3, Stefan Karpinski wrote:

On Fri, Aug 19, 2016 at 5:07 PM, Morten Piibeleht mailto:morten.p...@gmail.com> > wrote:

[*] Developed as part of Morten’s  

 Google Summer of Code project.

Since I think that page is private, here's the description of the project:

 

Yes, the correct link should have been 
https://summerofcode.withgoogle.com/projects/#5046486001778688 (but it 
basically only contains the description Stefan already posted).

RE: [julia-users] Method definition overwritten

[David Anthoff]

I opened an issue for this: https://github.com/JuliaLang/julia/issues/18071

 

You can use anonymous functions as a workaround if you are julia 0.5 only (on 
julia 0.4 they would be slow).

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Andre Manoel
Sent: Tuesday, August 16, 2016 1:38 PM
To: julia-users 
Subject: [julia-users] Method definition overwritten

 


Hello! I've been trying out Julia 0.5-rc1, and noticed one aspect in which it 
behaves differently from 0.4. If I do

function f(x)
if x > 0
g(x) = x
else
g(x) = -x
end
 
return g(x)
end

​

I get the following warning

WARNING: Method definition in module Main at REPL[1]:3 overwritten at REPL[1]:5.

​

and in fact, g(x) ends up being always -x, that is, a single function g is 
defined in compile time following the last definition inside f. Is that 
behavior expected? I remember doing the same in Julia 0.4 and getting different 
g's depending on the value of x. What's the best way of dealing with this?

Thanks!
Andre

[julia-users] JuliaIO

[David Anthoff]

Who is maintaining JuliaIO packages? It would be great if someone with push
rights could follow up on https://github.com/JuliaIO/GZip.jl/issues/57. 

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[David Anthoff]

> There's a setting on both travis and appveyor where you can mark certain
> entries in the build matrix as allowed failures. So they will run and you can
> look at the logs, but failing won't cause a red status. This is good for 
> nightlies
> or when a package doesn't entirely support 32 bit, etc.

But I can't change those settings, these are not my packages.

> You should be changing the appveyor files in the same PR to add testing
> against 0.5 anyway. Same on Travis, "release" is going to change meaning so
> it's better to split entries for 0.4 and 0.5.

Yep, been doing that.

> What I'll do right now is replace the 0.5-latest downloads on s3 with rc1+1.
> That way Travis and Appveyor can have this bug fixed, but we're not making
> a new tag until more things are backported.

That is perfect, that will completely solve this problem, thanks!

RE: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[David Anthoff]

You mean I could just ignore the appveyor failures? I don’t want to do that, I 
don’t know these packages and who knows what new bugs I might introduce.

 

Or you mean I could update their appveyor files? Then I need two cycles of PRs 
per package merged, first my update to appveyor, then once that is done I can 
submit the PR with the julia 0.5 compat stuff, and then I should really follow 
up with each of these packages to change the appveyor file back to the right 
stuff once RC2 is out. Quite frankly, that is too cumbersome for me, I’ll just 
wait for RC2 for now…

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Friday, August 5, 2016 3:25 PM
To: julia-users 
Subject: Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

> I’m not going to change their appveyor to nightly builds

Why not? You can make it an allowed failure for now.


On Friday, August 5, 2016 at 3:17:29 PM UTC-7, David Anthoff wrote:

Well, I was hopping around opening PRs in packages that I don’t maintain and 
fixing 0.5 compat things in those packages. I’m not going to change their 
appveyor to nightly builds, so I’ll just stop fixing other packages until RC2 
is out.

 

From:   julia...@googlegroups.com [mailto:  
julia...@googlegroups.com] On Behalf Of Tony Kelman
Sent: Friday, August 5, 2016 2:56 PM
To: julia-users <  julia...@googlegroups.com>
Subject: Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

Use nightly for now, or change your appveyor script to temporarily download 
these rc1+1 binaries. There are a lot of things pending for backporting to the 
release-0.5 branch, and I'd like to test them properly before making another 
tag.

On Friday, August 5, 2016 at 2:26:47 PM UTC-7, David Anthoff wrote:

Any chance you could just tag RC2 really soon, before the normal weekly 
schedule? This  
<https://github.com/JuliaLang/julia/pull/17774#issuecomment-237552549> 
https://github.com/JuliaLang/julia/pull/17774#issuecomment-237552549 being on 
RC1 essentially breaks all appveyor builds on julia 0.5 right now, and that 
makes cleaning up packages really difficult.

 

Manual links to RC1+1 binaries don’t end up on the appveyor builds, so that is 
not really a practical option. My sense is that people would have to put 
package cleanup on hold until appveyor builds are back in business, which seems 
really not good. After all the whole point of releasing these RCs that are not 
candidates for a release is presumably so that package maintainers can get 
their packages to work on 0.5.

 

Cheers,

David

 

 

From:  <mailto:julia...@googlegroups.com> julia...@googlegroups.com [ 
<mailto:julia...@googlegroups.com> mailto:julia...@googlegroups.com] On Behalf 
Of Tony Kelman
Sent: Friday, August 5, 2016 10:49 AM
To: julia-users < <mailto:julia...@googlegroups.com> julia...@googlegroups.com>
Subject: Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

rc1+1 on the release-0.5 branch has the bug fixed, and may be more useful to 
test against:

https://s3.amazonaws.com/julianightlies/bin/linux/arm/0.5/julia-0.5.0-acfd04c18b-linuxarm.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x64/0.5/julia-0.5.0-acfd04c18b-linux64.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x86/0.5/julia-0.5.0-acfd04c18b-linux32.tar.gz
https://s3.amazonaws.com/julianightlies/bin/osx/x64/0.5/julia-0.5.0-acfd04c18b-osx.dmg
https://s3.amazonaws.com/julianightlies/bin/winnt/x64/0.5/julia-0.5.0-acfd04c18b-win64.exe
https://s3.amazonaws.com/julianightlies/bin/winnt/x86/0.5/julia-0.5.0-acfd04c18b-win32.exe

(these links will stop working in about a month since julianightlies doesn't 
keep files around forever, but consider this an early preview between rc1 and 
rc2)


On Thursday, August 4, 2016 at 10:51:09 AM UTC-7, Tony Kelman wrote:

> always the latest RC, and then the final version?

Yes.

We don't currently do automated nightly builds from release branches. Any sha 
from a branch within JuliaLang/julia can easily be built on demand though.


On Thursday, August 4, 2016 at 10:02:54 AM UTC-7, David Anthoff wrote:

Excellent!

 

Going forward, what will I get from

 

 
<http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe>
 http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe

 

I assume not nightly builds from the release-0.5 branch, but always the latest 
RC, and then the final version?

 

Is there a stable link that would get me the nightly builds from release-0.5 on 
windows?

 

From:  <mailto:julia...@googlegroups.com> julia...@googlegroups.com [ 
<mailto:julia...@googlegroups.com> mailto:julia...@googlegroups.com] On Behalf 
Of Tony Kelman
Sent: Thursday, August 4, 2016 6:53 AM
To: julia-users < <mailto:julia...@googlegroups.com> julia...@googlegroups.com>
Subject: [julia-users] Re: Announc

RE: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[David Anthoff]

Well, I was hopping around opening PRs in packages that I don’t maintain and 
fixing 0.5 compat things in those packages. I’m not going to change their 
appveyor to nightly builds, so I’ll just stop fixing other packages until RC2 
is out.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Friday, August 5, 2016 2:56 PM
To: julia-users 
Subject: Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

Use nightly for now, or change your appveyor script to temporarily download 
these rc1+1 binaries. There are a lot of things pending for backporting to the 
release-0.5 branch, and I'd like to test them properly before making another 
tag.

On Friday, August 5, 2016 at 2:26:47 PM UTC-7, David Anthoff wrote:

Any chance you could just tag RC2 really soon, before the normal weekly 
schedule? This  
<https://github.com/JuliaLang/julia/pull/17774#issuecomment-237552549> 
https://github.com/JuliaLang/julia/pull/17774#issuecomment-237552549 being on 
RC1 essentially breaks all appveyor builds on julia 0.5 right now, and that 
makes cleaning up packages really difficult.

 

Manual links to RC1+1 binaries don’t end up on the appveyor builds, so that is 
not really a practical option. My sense is that people would have to put 
package cleanup on hold until appveyor builds are back in business, which seems 
really not good. After all the whole point of releasing these RCs that are not 
candidates for a release is presumably so that package maintainers can get 
their packages to work on 0.5.

 

Cheers,

David

 

 

From:   julia...@googlegroups.com [mailto:  
julia...@googlegroups.com] On Behalf Of Tony Kelman
Sent: Friday, August 5, 2016 10:49 AM
To: julia-users <  julia...@googlegroups.com>
Subject: Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

rc1+1 on the release-0.5 branch has the bug fixed, and may be more useful to 
test against:

https://s3.amazonaws.com/julianightlies/bin/linux/arm/0.5/julia-0.5.0-acfd04c18b-linuxarm.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x64/0.5/julia-0.5.0-acfd04c18b-linux64.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x86/0.5/julia-0.5.0-acfd04c18b-linux32.tar.gz
https://s3.amazonaws.com/julianightlies/bin/osx/x64/0.5/julia-0.5.0-acfd04c18b-osx.dmg
https://s3.amazonaws.com/julianightlies/bin/winnt/x64/0.5/julia-0.5.0-acfd04c18b-win64.exe
https://s3.amazonaws.com/julianightlies/bin/winnt/x86/0.5/julia-0.5.0-acfd04c18b-win32.exe

(these links will stop working in about a month since julianightlies doesn't 
keep files around forever, but consider this an early preview between rc1 and 
rc2)


On Thursday, August 4, 2016 at 10:51:09 AM UTC-7, Tony Kelman wrote:

> always the latest RC, and then the final version?

Yes.

We don't currently do automated nightly builds from release branches. Any sha 
from a branch within JuliaLang/julia can easily be built on demand though.


On Thursday, August 4, 2016 at 10:02:54 AM UTC-7, David Anthoff wrote:

Excellent!

 

Going forward, what will I get from

 

 
<http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe>
 http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe

 

I assume not nightly builds from the release-0.5 branch, but always the latest 
RC, and then the final version?

 

Is there a stable link that would get me the nightly builds from release-0.5 on 
windows?

 

From:  <mailto:julia...@googlegroups.com> julia...@googlegroups.com [ 
<mailto:julia...@googlegroups.com> mailto:julia...@googlegroups.com] On Behalf 
Of Tony Kelman
Sent: Thursday, August 4, 2016 6:53 AM
To: julia-users < <mailto:julia...@googlegroups.com> julia...@googlegroups.com>
Subject: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

0.5.0-rc1 has been tagged and binaries are now available.

 
<https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz>
 
https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
 
<https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz>
 
https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
 
<https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz>
 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
 
<https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg>
 https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
 
<https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe>
 https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
 
<https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe>
 https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/jul

RE: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[David Anthoff]

Any chance you could just tag RC2 really soon, before the normal weekly 
schedule? This 
https://github.com/JuliaLang/julia/pull/17774#issuecomment-237552549 being on 
RC1 essentially breaks all appveyor builds on julia 0.5 right now, and that 
makes cleaning up packages really difficult.

 

Manual links to RC1+1 binaries don’t end up on the appveyor builds, so that is 
not really a practical option. My sense is that people would have to put 
package cleanup on hold until appveyor builds are back in business, which seems 
really not good. After all the whole point of releasing these RCs that are not 
candidates for a release is presumably so that package maintainers can get 
their packages to work on 0.5.

 

Cheers,

David

 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Friday, August 5, 2016 10:49 AM
To: julia-users 
Subject: Re: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

rc1+1 on the release-0.5 branch has the bug fixed, and may be more useful to 
test against:

https://s3.amazonaws.com/julianightlies/bin/linux/arm/0.5/julia-0.5.0-acfd04c18b-linuxarm.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x64/0.5/julia-0.5.0-acfd04c18b-linux64.tar.gz
https://s3.amazonaws.com/julianightlies/bin/linux/x86/0.5/julia-0.5.0-acfd04c18b-linux32.tar.gz
https://s3.amazonaws.com/julianightlies/bin/osx/x64/0.5/julia-0.5.0-acfd04c18b-osx.dmg
https://s3.amazonaws.com/julianightlies/bin/winnt/x64/0.5/julia-0.5.0-acfd04c18b-win64.exe
https://s3.amazonaws.com/julianightlies/bin/winnt/x86/0.5/julia-0.5.0-acfd04c18b-win32.exe

(these links will stop working in about a month since julianightlies doesn't 
keep files around forever, but consider this an early preview between rc1 and 
rc2)


On Thursday, August 4, 2016 at 10:51:09 AM UTC-7, Tony Kelman wrote:

> always the latest RC, and then the final version?

Yes.

We don't currently do automated nightly builds from release branches. Any sha 
from a branch within JuliaLang/julia can easily be built on demand though.


On Thursday, August 4, 2016 at 10:02:54 AM UTC-7, David Anthoff wrote:

Excellent!

 

Going forward, what will I get from

 

http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe

 

I assume not nightly builds from the release-0.5 branch, but always the latest 
RC, and then the final version?

 

Is there a stable link that would get me the nightly builds from release-0.5 on 
windows?

 

From: julia...@googlegroups.com <mailto:julia...@googlegroups.com>  
[mailto:julia...@googlegroups.com] On Behalf Of Tony Kelman
Sent: Thursday, August 4, 2016 6:53 AM
To: julia-users mailto:julia...@googlegroups.com> >
Subject: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

0.5.0-rc1 has been tagged and binaries are now available.

 
<https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz>
 
https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
 
<https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz>
 
https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
 
<https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz>
 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
 
<https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg>
 https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
 
<https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe>
 https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
 
<https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe>
 https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
 <https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256> 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256
 <https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5> 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5

(append .asc to the linux .tar.gz links for gpg signatures)


There will be a RC2 next week. An especially nasty bug was introduced on master 
right before we branched for release-0.5 and I unfortunately missed it in my 
testing. I had a PkgEval run going but tagged before it was finished, in order 
to get binaries building. I won't be repeating that mistake next time.


On Sunday, July 31, 2016 at 3:27:29 PM UTC-7, Viral Shah wrote:

Hello everyone,

 

You may have noticed 0.5.0-rc0 being tagged last week. The binaries are now all 
ready and available for testing. This is a good point for package developers to 
make their packages ready for 0.5, and for users to test their codes on the new 
release.

 

 
<https://s3.amazona

RE: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

[David Anthoff]

Excellent!

 

Going forward, what will I get from

 

http://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5-latest-win64.exe

 

I assume not nightly builds from the release-0.5 branch, but always the latest 
RC, and then the final version?

 

Is there a stable link that would get me the nightly builds from release-0.5 on 
windows?

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Thursday, August 4, 2016 6:53 AM
To: julia-users 
Subject: [julia-users] Re: Announcing 0.5.0-rc0 and binaries available

 

0.5.0-rc1 has been tagged and binaries are now available.

 

 
https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc1-linux-arm.tar.gz
 

 
https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc1-linux-x86_64.tar.gz
 

 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc1-linux-i686.tar.gz
 

 https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc1-osx10.7+.dmg
 

 https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc1-win64.exe
 

 https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc1-win32.exe
  
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.sha256
  
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc1.md5

(append .asc to the linux .tar.gz links for gpg signatures)


There will be a RC2 next week. An especially nasty bug was introduced on master 
right before we branched for release-0.5 and I unfortunately missed it in my 
testing. I had a PkgEval run going but tagged before it was finished, in order 
to get binaries building. I won't be repeating that mistake next time.


On Sunday, July 31, 2016 at 3:27:29 PM UTC-7, Viral Shah wrote:

Hello everyone,

 

You may have noticed 0.5.0-rc0 being tagged last week. The binaries are now all 
ready and available for testing. This is a good point for package developers to 
make their packages ready for 0.5, and for users to test their codes on the new 
release.

 

 

 
https://s3.amazonaws.com/julialang/bin/linux/arm/0.5/julia-0.5.0-rc0-linux-arm.tar.gz
 

 
https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc0-linux-x86_64.tar.gz
 

 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc0-linux-i686.tar.gz
 

 https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc0-osx10.7+.dmg
 

 https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc0-win64.exe
 

 https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc0-win32.exe
  
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.sha256
  
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc0.md5

 

We expect to have a new rc roughly every week until all the dust settles and 
0.5.0 is finally released. Follow the progress at:

 

https://github.com/JuliaLang/julia/issues/17418

 

-viral

 

[julia-users] CALL TO ACTION for package devs

[David Anthoff]

I started cleaning up my packages for julia 0.5 yesterday, both trying to
fix any errors there are and trying to get rid of deprecation warnings.

 

I very soon ran into lots of deprecation warnings in packages that my
package uses. I started tracking them down, and in about half the cases
things were actually already fixed on master in these packages, but no one
had tagged a version.

 

So, this is my call to action for package devs:

 

If you have fixed julia 0.5 things in your package, please tag a version. It
really helps the people that are going through the packages right now trying
to clean things up.

 

Thanks,

David

 

PS: Oh, and of course, also try to actually fix deprecation warnings, would
be great if we could have a smooth transition in the package ecosystem from
julia 0.4 to 0.5.

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: Tuples of Functions

[David Anthoff]

FunctionWrappers.jl is great, it just saved me! Any chance you might actually 
register it? It is super useful... And at least until something like that 
exists in Base, it would be great to be able to add it as a dependency.

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Yichao Yu
> Sent: Monday, August 1, 2016 1:30 AM
> To: Julia Users 
> Subject: Re: [julia-users] Re: Tuples of Functions
> 
> On Mon, Aug 1, 2016 at 4:15 PM, Kristoffer Carlsson
>  wrote:
> > The problem is not with the return value of the passed functions, it
> > is with inferring the type of `f`. Each function has it's own type and
> > that in turn makes `f` bind to different types (first f1 then f2) in
> > the loop i.e a type instability.
> 
> Ref https://github.com/JuliaLang/julia/issues/13984 and a proof of principle
> implementation at https://github.com/yuyichao/FunctionWrappers.jl that I
> wrote a few days ago. Note that the package is mainly an experiment to
> check what features are needed and I'm not planing to register it.
> 
> >
> >
> > On Monday, August 1, 2016 at 5:53:23 AM UTC+2, Christoph Ortner wrote:
> >>
> >> Consider the following code snippet which shows the following expect
> >> problem (on v0.5): if I form a tuple of functions, pass this tuple to
> >> another function, then julia cannot infer enough information about
> >> them and runs into a type instability.
> >>
> >> MY QUESTION is: is there a work-around?  I.e., can I form an array,
> >> tuple, etc of functions and call them without losing type stability?
> >>
> >> (declaring return-type did not help, which surprised me since I
> >> thought that would give the additional information about what the two
> >> functions f1,
> >> f2 in the tuple do)
> >>
> >>
> >> function test(N, ff)
> >> r = 0.234; s = 0.0
> >> for n = 1:N, f in ff
> >> s = s + f(r)::Float64
> >> end
> >> return s
> >> end
> >>
> >>
> >> function test2(N, f1, f2)
> >> r = 0.234; s = 0.0
> >> for n = 1:N
> >> s = s + f1(r) + f2(r)
> >> end
> >> return s
> >> end
> >>
> >>
> >> f1(r::Float64)::Float64 = r^3
> >> f2(r::Float64)::Float64 = r^5
> >>
> >>
> >> test(10, (f1,f2))
> >> test(10, (f1,f1))
> >> test2(10, f1,f2)
> >>
> >>
> >> @time test(1_000_000, (f1,f2))# 0.079190 seconds (4.00 M
> >> allocations...
> >> @time test2(1_000_000, f1, f2)# 0.002279 seconds (5 allocations: 176
> >> bytes)
> >> @time test(1_000_000, (f1,f1))# 0.002664 seconds (5 allocations: 176
> >> bytes)
> >>
> >>
> >>
> >

RE: [julia-users] Re: Which package downgrades other packages?

[David Anthoff]

The deeper problem though is: what if I want to use all the currently installed 
packages at the same time, but don’t want the downgraded versions of them? Say 
I want to use package A and B, and both have a dependency on C, but A requires 
some older version of C, and that prevents me from getting the latest version 
of B.

 

In some way the situation is a little like DDL hell on Windows in the early 
90s: we can only ever have one version of a dependency installed and loaded at 
the same time in julia right now. I guess one way to “solve” this would be to 
start adding new versions of packages whenever there is a breaking change, i.e. 
when C introduced a breaking change it could have registered a new version C2. 
Terrible, of course, but that is what happened on Windows for things like the 
MS C runtime…

 

Are there any thoughts around this, how this could be solved for julia? My 
guess is that these situations will only happen more often as the package 
eco-systems grows…

 

From: stefan.karpin...@gmail.com [mailto:stefan.karpin...@gmail.com] On Behalf 
Of Stefan Karpinski
Sent: Saturday, July 23, 2016 11:06 AM
To: Julia Users 
Subject: Re: [julia-users] Re: Which package downgrades other packages?

 

The way to do this would be to compute which packages' removal would allow 
another package to be upgraded.

 

On Sat, Jul 23, 2016 at 1:59 PM, Tony Kelman mailto:t...@kelman.net> > wrote:

Part of the issue here is dependency resolution is a global feasibility 
problem, each package imposes a subset of constraints. So you can identify 
active / free constraints at a solution, but it can be hard to assign blame to 
a single package in general.




On Saturday, July 23, 2016 at 7:37:50 AM UTC-7, Chris Rackauckas wrote:

Another +1. When Optim.jl tagged v0.5, it took me too long find out it was 
responsible for rolling back a few of my packages, causing some tests to break 
(especially since I didn't have it master checked out for it, so I wasn't 
expecting it to really change! I only tracked it down because of the 
julia-users announcement). That's not Optim's fault, but an issue with the 
package system for not making it explicit why it was occurring (at least it 
didn't a month ago?). I think Pkg.update() tells you when a package is rolled 
back, but not why.

 

IIRC, I was really hoping that Pkg.status() would tell me whenever a package 
was not at its highest version due to another package, and tell me which 
package was doing that. For example,

 

-CoolPkg 0.1 (Rolled back due to AwesomeFoo)


Then it would be easy to see where I should checkout master, find how to make 
them work together, and submit a pull request! But I don't know if that would 
be difficult to implement.

On Friday, July 22, 2016 at 7:24:30 PM UTC-7, Tony Kelman wrote:

Maybe a useful function to write and submit to PkgDev would be go through all 
installed packages, check the METADATA requires file for all the installed 
versions and display a list of upper-bounded dependencies and which package is 
responsible for each. A little bit of code might go a long way in making this 
more discoverable.

 

RE: [julia-users] Re: Which package downgrades other packages?

[David Anthoff]

https://github.com/JuliaLang/julia/issues/17571

 

Not the full thing you recommend, but on the other hand probably much easier to 
implement.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Chris Rackauckas
Sent: Saturday, July 23, 2016 7:38 AM
To: julia-users 
Subject: [julia-users] Re: Which package downgrades other packages?

 

Another +1. When Optim.jl tagged v0.5, it took me too long find out it was 
responsible for rolling back a few of my packages, causing some tests to break 
(especially since I didn't have it master checked out for it, so I wasn't 
expecting it to really change! I only tracked it down because of the 
julia-users announcement). That's not Optim's fault, but an issue with the 
package system for not making it explicit why it was occurring (at least it 
didn't a month ago?). I think Pkg.update() tells you when a package is rolled 
back, but not why.

 

IIRC, I was really hoping that Pkg.status() would tell me whenever a package 
was not at its highest version due to another package, and tell me which 
package was doing that. For example,

 

-CoolPkg 0.1 (Rolled back due to AwesomeFoo)


Then it would be easy to see where I should checkout master, find how to make 
them work together, and submit a pull request! But I don't know if that would 
be difficult to implement.

On Friday, July 22, 2016 at 7:24:30 PM UTC-7, Tony Kelman wrote:

Maybe a useful function to write and submit to PkgDev would be go through all 
installed packages, check the METADATA requires file for all the installed 
versions and display a list of upper-bounded dependencies and which package is 
responsible for each. A little bit of code might go a long way in making this 
more discoverable.

[julia-users] Which package downgrades other packages?

[David Anthoff]

I have a lot packages installed, but none pinned by myself. A whole bunch of
packages are at versions that are not up-to-date (e.g. MathProgBase is at
0.4.3, way behind), even after Pkg.update().

 

I guess there must be some package that has an upper limit on one of its
requirements, and that probably blocks everything. Is there some easy way
for me to identify the package that is holding everything back? I did look
through all the direct dependencies of MathProgBase, but none of them
explains this.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] What does Base.box mean in code_warntype?

[David Anthoff]

Ah, ok, so I can just safely ignore it! Thanks, David

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Yichao Yu
> Sent: Thursday, July 21, 2016 2:40 PM
> To: Julia Users 
> Subject: Re: [julia-users] What does Base.box mean in code_warntype?
> 
> On Thu, Jul 21, 2016 at 5:33 PM, David Anthoff 
> wrote:
> > Thanks everyone for the answers!
> >
> > I guess Tim's email in particular means that the presence of box might
> > indicate a problem, or not ;)
> 
> Base.box in the ast doesn't indicate a problem. Any type instability should be
> highlighted independently.
> 
> >
> > I guess it would be nice if there was some (easy) way to figure out
> > whether things get boxed or not, apart from looking at the assembler/llvm
> code.
> >
> >> -Original Message-
> >> From: julia-users@googlegroups.com [mailto:julia-
> >> us...@googlegroups.com] On Behalf Of Tim Holy
> >> Sent: Tuesday, July 19, 2016 10:55 AM
> >> To: julia-users@googlegroups.com
> >> Subject: Re: [julia-users] What does Base.box mean in code_warntype?
> >>
> >> They can mean "real" boxing and consequent performance problems, but
> >> sometimes these get auto-removed during compilation. I see this all
> >> the
> > time
> >> when writing array code, for example this function which takes an
> >> input
> > tuple
> >> and adds 1 to each element:
> >>
> >> julia> @inline inc1(a) = _inc1(a...)
> >> inc1 (generic function with 1 method)
> >>
> >> julia> @inline _inc1(a1, a...) = (a1+1, _inc1(a...)...)
> >> _inc1 (generic function with 1 method)
> >>
> >> julia> _inc1() = ()
> >> _inc1 (generic function with 2 methods)
> >>
> >> julia> inc1((3,5,7))
> >> (4,6,8)
> >>
> >> # Let's try using inc1 in another function
> >> julia> foo() = (ret = inc1((3,5,7)); prod(ret))
> >> foo (generic function with 1 method)
> >>
> >> julia> foo()
> >> 192
> >>
> >> julia> @code_warntype inc1((3,5,7))
> >> Variables:
> >>   #self#::#inc1
> >>   a::Tuple{Int64,Int64,Int64}
> >>
> >> Body:
> >>   begin
> >>   SSAValue(1) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},2)::Int64
> >>   SSAValue(2) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},3)::Int64
> >>   return
> >> (Core.tuple)((Base.box)(Int64,(Base.add_int)((Core.getfield)
> >> (a::Tuple{Int64,Int64,Int64},1)::Int64,1)),(Base.box)(Int64,(Base.add
> >> _int) (SSAValue(1),1)),(Base.box)(Int64,(Base.add_int)(SSAValue(2),
> >> 1)))::Tuple{Int64,Int64,Int64}
> >>   end::Tuple{Int64,Int64,Int64}
> >>
> >> julia> @code_llvm inc1((3,5,7))
> >>
> >> define void @julia_inc1_67366([3 x i64]* noalias sret, [3 x i64]*) #0
> >> {
> >> top:
> >>   %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
> >>   %2 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 1
> >>   %3 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 2
> >>   %4 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 0
> >>   %5 = load i64, i64* %4, align 8
> >>   %6 = add i64 %5, 1
> >>   %7 = load i64, i64* %2, align 8
> >>   %8 = add i64 %7, 1
> >>   %9 = load i64, i64* %3, align 8
> >>   %10 = add i64 %9, 1
> >>   %11 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 0
> >>   store i64 %6, i64* %11, align 8
> >>   %12 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 1
> >>   store i64 %8, i64* %12, align 8
> >>   %13 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 2
> >>   store i64 %10, i64* %13, align 8
> >>   ret void
> >> }
> >>
> >> julia> @code_llvm foo()
> >>
> >> define i64 @julia_foo_67563() #0 {
> >> top:
> >>   %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
> >>   ret i64 192
> >> }
> >>
> >> I think you'd be hard-pressed to complain about inefficiencies in
> >> foo()
> > ;-).
> >>
> >> --Tim
> >>
> >> On Tuesday, July 19, 2016 1:42:46 PM CDT Isaiah Norton wrote:
> >> > On Fri, Jul 15, 2016 at 5:02 PM, David Anthoff
> >> > 
> >> wrote:
> >> > > What do these mean?
> >> >
> >> > http://stackoverflow.com/questions/13055/what-is-boxing-and-
> unboxin
> >> > g-
> >> a
> >> > nd-wha
> >> > t-are-the-trade-offs
> >> > > And should I be worried, i.e. is this an indication that
> >> > > something slow might be going on?
> >> >
> >> > Boxing requires allocation and can block optimizations, so it can
> >> > be a problem to have box/unbox at points where you might hope to be
> >> > working with contiguous primitive values (such as within a loop).
> >> > But there's really no hard-and-fast rule.
> >> >
> >> > > --
> >> > >
> >> > > David Anthoff
> >> > >
> >> > > University of California, Berkeley
> >> > >
> >> > >
> >> > >
> >> > > http://www.david-anthoff.com
> >>
> >

RE: [julia-users] What does Base.box mean in code_warntype?

[David Anthoff]

Thanks everyone for the answers!

I guess Tim's email in particular means that the presence of box might
indicate a problem, or not ;)

I guess it would be nice if there was some (easy) way to figure out whether
things get boxed or not, apart from looking at the assembler/llvm code.

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Tim Holy
> Sent: Tuesday, July 19, 2016 10:55 AM
> To: julia-users@googlegroups.com
> Subject: Re: [julia-users] What does Base.box mean in code_warntype?
> 
> They can mean "real" boxing and consequent performance problems, but
> sometimes these get auto-removed during compilation. I see this all the
time
> when writing array code, for example this function which takes an input
tuple
> and adds 1 to each element:
> 
> julia> @inline inc1(a) = _inc1(a...)
> inc1 (generic function with 1 method)
> 
> julia> @inline _inc1(a1, a...) = (a1+1, _inc1(a...)...)
> _inc1 (generic function with 1 method)
> 
> julia> _inc1() = ()
> _inc1 (generic function with 2 methods)
> 
> julia> inc1((3,5,7))
> (4,6,8)
> 
> # Let's try using inc1 in another function
> julia> foo() = (ret = inc1((3,5,7)); prod(ret))
> foo (generic function with 1 method)
> 
> julia> foo()
> 192
> 
> julia> @code_warntype inc1((3,5,7))
> Variables:
>   #self#::#inc1
>   a::Tuple{Int64,Int64,Int64}
> 
> Body:
>   begin
>   SSAValue(1) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},2)::Int64
>   SSAValue(2) = (Core.getfield)(a::Tuple{Int64,Int64,Int64},3)::Int64
>   return (Core.tuple)((Base.box)(Int64,(Base.add_int)((Core.getfield)
> (a::Tuple{Int64,Int64,Int64},1)::Int64,1)),(Base.box)(Int64,(Base.add_int)
> (SSAValue(1),1)),(Base.box)(Int64,(Base.add_int)(SSAValue(2),
> 1)))::Tuple{Int64,Int64,Int64}
>   end::Tuple{Int64,Int64,Int64}
> 
> julia> @code_llvm inc1((3,5,7))
> 
> define void @julia_inc1_67366([3 x i64]* noalias sret, [3 x i64]*) #0 {
> top:
>   %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
>   %2 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 1
>   %3 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 2
>   %4 = getelementptr inbounds [3 x i64], [3 x i64]* %1, i64 0, i64 0
>   %5 = load i64, i64* %4, align 8
>   %6 = add i64 %5, 1
>   %7 = load i64, i64* %2, align 8
>   %8 = add i64 %7, 1
>   %9 = load i64, i64* %3, align 8
>   %10 = add i64 %9, 1
>   %11 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 0
>   store i64 %6, i64* %11, align 8
>   %12 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 1
>   store i64 %8, i64* %12, align 8
>   %13 = getelementptr inbounds [3 x i64], [3 x i64]* %0, i64 0, i64 2
>   store i64 %10, i64* %13, align 8
>   ret void
> }
> 
> julia> @code_llvm foo()
> 
> define i64 @julia_foo_67563() #0 {
> top:
>   %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
>   ret i64 192
> }
> 
> I think you'd be hard-pressed to complain about inefficiencies in foo()
;-).
> 
> --Tim
> 
> On Tuesday, July 19, 2016 1:42:46 PM CDT Isaiah Norton wrote:
> > On Fri, Jul 15, 2016 at 5:02 PM, David Anthoff 
> wrote:
> > > What do these mean?
> >
> > http://stackoverflow.com/questions/13055/what-is-boxing-and-unboxing-
> a
> > nd-wha
> > t-are-the-trade-offs
> > > And should I be worried, i.e. is this an indication that something
> > > slow might be going on?
> >
> > Boxing requires allocation and can block optimizations, so it can be a
> > problem to have box/unbox at points where you might hope to be working
> > with contiguous primitive values (such as within a loop). But there's
> > really no hard-and-fast rule.
> >
> > > --
> > >
> > > David Anthoff
> > >
> > > University of California, Berkeley
> > >
> > >
> > >
> > > http://www.david-anthoff.com
> 

RE: [julia-users] What does Base.box mean in code_warntype?

[David Anthoff]

Bump, does anyone have some info about this? Thanks, David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On
Behalf Of David Anthoff
Sent: Friday, July 15, 2016 2:02 PM
To: julia-users@googlegroups.com
Subject: [julia-users] What does Base.box mean in code_warntype?

 

I'm looking for type instabilities in a function with code_warntype, and I'm
seeing lots of ``(Base.box)`` terms there.

 

What do these mean? And should I be worried, i.e. is this an indication that
something slow might be going on?

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] What does Base.box mean in code_warntype?

[David Anthoff]

I'm looking for type instabilities in a function with code_warntype, and I'm
seeing lots of ``(Base.box)`` terms there.

 

What do these mean? And should I be worried, i.e. is this an indication that
something slow might be going on?

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

[David Anthoff]

Yeah, I think this just comes down to different needs. I would prefer to see a 
more extended period between feature freeze and RC that is used to clean up 
performance problems and some of the things that are currently assigned to the 
0.5.x milestone or have the regressions label. Some of the issues that are 
currently not assigned to the 0.5.0 milestone (like #16047 and #15276) almost 
certainly mean that I won’t be able to use 0.5.0 and will have to wait until 
0.5.1 to make the switch (and if that happens I probably also won’t update my 
packages until 0.5.x is ready for my daily use). From my point of view, I would 
prefer a release strategy that doesn’t mimics Microsoft’s old habit where you 
always had to wait until the first service pack until you could actually use a 
new version ;) BUT, I can easily see that julia computing/other users have 
different needs and that the right call here is to do what you seem to plan 
currently. These are all performance regressions, and they can be a nuisance 
for some but blocking for others, and then it probably comes down to how many 
users there are in each category (or what e.g. the paying customers want). I 
would encourage other users to weigh in on this, might be helpful for the core 
team to get more perspectives from the wider user base on this question.

 

My other suggestion is purely procedural on how to handle issues. I think it 
would be great if there was one clear signal that the core team looked at an 
issue and decided it is not release-blocking for 0.5.0. I think the 0.5.x 
milestone is exactly that, right? But there are lots of issues that have 
neither the 0.5.0 nor the 0.5.x milestone attached, and from my point of view 
it is unclear whether they have been considered and whether a decision has been 
made. For example, at some point I asked in #15276 whether it should get a 0.5 
label. Jeff responded that every issue tagged “regression” will get attention 
before 0.5-final. It would simply be great if the core team somehow marked 
issue that then got that attention. As #15276 stands right now, I got a message 
saying “we will triage this”, but I never got a message what the triage 
decision was. The suggestion here is very simple: Try to find some way to 
communicate back to the larger user base that a triage decision has been made 
for a given issue. There should be some way to tell whether an issue is 
awaiting triage or triage has been made (in the negative). A really simple way 
to do this seems this: 1) issue has no milestone attached => triage decision 
has not been made, 2) issue is attached to a milestone => triage decision has 
been made.

 

From: stefan.karpin...@gmail.com [mailto:stefan.karpin...@gmail.com] On Behalf 
Of Stefan Karpinski
Sent: Friday, July 15, 2016 9:34 AM
To: Julia Users 
Subject: Re: [julia-users] ANN: steps towards 0.5.0 release [candidates]

 

https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate:

 

A release candidate (RC) is a beta version with potential to be a final 
product, which is ready to release unless significant bugs emerge. In this 
stage of product stabilization, all product features have been designed, coded 
and tested through one or more beta cycles with no known showstopper-class bugs.

 

This is exactly how we use the term: a release candidate is a version that 
could be the release as long as no major bugs show up in the following week; if 
such bugs do become evident, we fix them and make a new RC a week later, 
including those fixes. This repeats until there's an RC that doesn't have new 
bugs, at which point that RC becomes the release.

 

Objections here seem to stem from the fact that the release has a set of known, 
non-critical bugs, but that's a completely standard thing to do in real-world 
software releases. Every project has different criteria for what constitutes a 
release-blocking bug and what doesn't: the 0.5.x milestone 
<https://github.com/JuliaLang/julia/milestone/21>  is our list of non-critical 
known issues for the 0.5 release – each of them has been considered and deemed 
not to be a show stopper.

 

On Fri, Jul 15, 2016 at 5:36 AM, Sisyphuss mailto:zhengwend...@gmail.com> > wrote:

It seems to me that it is the same terminology (RC) as Battle for Wesnoth.



On Friday, July 15, 2016 at 10:37:19 AM UTC+2, Scott Jones wrote:

I agree, and it does seem there is a bit of a problem with the nomenclature 
that the Julia team is using, which doesn't match industry wide practice.

At least the first Julia release candidate is really just a beta release (i.e. 
after a feature freeze and branch off of current development), as it is known 
that it isn't really ready for release,

and that known bugs/regressions are still being worked on.

 

Subsequent RCs may actually meet the definition of a release candidate.


On Thursday, July 14, 2016 at 8:34:21 PM UTC+2, David Anthoff wrote:

So what you

RE: [julia-users] Re: How to install 0.4.5 on Ubuntu?

[David Anthoff]

In that case the reference to the PPA should probably be removed from 
http://julialang.org/downloads/platform.html and the bottom of the README.md.

On the other hand, the juliareleases under staticfloat seems to be up-to-date...

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Tony Kelman
> Sent: Friday, July 15, 2016 10:37 AM
> To: julia-users 
> Subject: Re: [julia-users] Re: How to install 0.4.5 on Ubuntu?
> 
> The PPA is deprecated and not actively maintianed. Use the generic Linux
> binaries. Download and extract the tarball, then run bin/julia.

RE: [julia-users] Re: How to install 0.4.5 on Ubuntu?

[David Anthoff]

I don’t think you need the julia-deps thing anymore, it seems all the 
dependencies are now part of juliareleases. At least last time I tried this I 
didn’t add julia-deps and things worked.

 

If that is correct, someone should probably update the README/installation 
instructions on julialang.org.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Uwe Fechner
Sent: Friday, July 15, 2016 7:39 AM
To: julia-users 
Subject: [julia-users] Re: How to install 0.4.5 on Ubuntu?

 

Did you try:

sudo add-apt-repository ppa:staticfloat/juliareleases

sudo add-apt-repository ppa:staticfloat/julia-deps

sudo apt-get update

sudo apt-get install julia

 

You need to have the correct ppa enabled!

 

Uwe



On Friday, July 15, 2016 at 3:49:04 PM UTC+2, Ahmed Mazari wrote:

How to install julia 0.4.6 in ubuntu ?

l tried  
sudo apt-get install julia=v0.4.6 but it's not working

On Sunday, May 22, 2016 at 12:27:37 PM UTC+2, Nils Gudat wrote:

Slightly stupid question from someone who is forced to use Linux on a server: 
how can I get the latest stable version as opposed ot the dev release? 
I followed the instructions from here 
(http://julialang.org/downloads/platform.html), but always end up with a 44-day 
old 0.5 master version installed...

RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

[David Anthoff]

So what you intend to call "release candidate" is a feature complete build, 
with a list of known bugs that the core team still intends to fix before a 
0.5.0 release? I.e. in fact the first "release candidate" will not be a 
candidate for a release, because of a known list of things that still need to 
be fixed? I don't understand why you wouldn't just call that a "beta", that 
seems the more common way to designate a build like that, seems to much better 
indicate what that build is. But if you do want to call it RC, then please make 
sure to communicate to the wider user group that this build is actually not one 
that you might declare finished. And then once you have a RC that is a true 
candidate for a release, please also let us know. For me as a user and package 
developer, I do want to know whether you think a given build is completely done 
or not.

I think the more important question though is, where are you tracking the 
bugs/regressions that need to be fixed before a 0.5.0 release (at whatever 
stage of the process)?

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Keno Fischer
> Sent: Thursday, July 14, 2016 11:18 AM
> To: julia-users@googlegroups.com
> Subject: Re: [julia-users] ANN: steps towards 0.5.0 release [candidates]
> 
> Anything that's not on the milestone right now will not be in the RC (other
> than the cleanup tasks).
> The RC is there so that people can start fixing packages against 0.5, without
> having to worry about having to do it again once the release is out. We'll of
> course continue cleaning up and working on performance regressions, but
> we do need to work towards a release, so we can't block the RC on those.
> 
> On Thu, Jul 14, 2016 at 2:14 PM, David Anthoff 
> wrote:
> > This is fun ;)
> >
> >
> >
> > 7 “needs-tests” issues that haven’t been assigned to any milestone. 7
> > “needs-docs” issue with no milestone assigned. 4 “heisebugs” with no
> > milestone attached, one with a “priority” label.
> >
> >
> >
> > Just by looking at any of these it is not clear whether they have been
> > triaged for 0.5.0, and if so, what the decision was. The main problem
> > will all of these seems to be that it is unclear whether a) no one has
> > decided about inclusion in 0.5.0 yet, or b) someone decided that this
> > would not go into 0.5.0. I think the milestone suggestion below would
> > allow a pretty easy management of that information.
> >
> >
> >
> > From: julia-users@googlegroups.com
> > [mailto:julia-users@googlegroups.com] On Behalf Of David Anthoff
> > Sent: Thursday, July 14, 2016 11:04 AM
> > To: julia-users@googlegroups.com
> > Subject: RE: [julia-users] ANN: steps towards 0.5.0 release
> > [candidates]
> >
> >
> >
> > There are also 82 bugs that have no milestone assigned. Have these all
> > been triaged for 0.5.0 inclusion and it was decided that none of those
> > need to be fixed for 0.5.0? If so, how is that recorded in the issue
> > tracker? Might make sense to have another milestone named “post 0.5.0”
> > that simply indicates that someone from the core team made sure an
> > issue doesn’t have to be fixed for 0.5.0, but no other scheduling
> > decision has been made about that issue.
> >
> >
> >
> > From: julia-users@googlegroups.com
> > [mailto:julia-users@googlegroups.com] On Behalf Of David Anthoff
> > Sent: Thursday, July 14, 2016 10:58 AM
> > To: julia-users@googlegroups.com
> > Subject: RE: [julia-users] ANN: steps towards 0.5.0 release
> > [candidates]
> >
> >
> >
> > +100 to having a release plan like this!
> >
> >
> >
> > There are 28 open regressions, I assume/hope those will be taken care
> > of before RC1? I.e. after feature freeze, but before RC, right?
> >
> >
> >
> > There are 22 open issues assigned to the 0.5.x milestone. The
> > description for that one says “Bugs to fix in the 0.5.0 or 0.5.x
> > timeframe”. Might be a good idea to make a call on each of these and
> > decide which of those have to be fixed for 0.5.0 (in which case they
> > should be fixed before RC1) and which will go into 0.5.1.
> >
> >
> >
> > Here is one idea on how to handle this in terms of logistics: rename
> > the
> > 0.5.0 milestone to “0.5.0-beta” (or “0.5.0-feature-freeze” or
> > something like that). These are the items that need to get done before the
> feature freeze.
> > Create a new milestone “0.5.0-RC1”, and assign those issues that need
> > to be fixed before RC to that mil

RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

[David Anthoff]

This is fun ;)

 

7 “needs-tests” issues that haven’t been assigned to any milestone. 7 
“needs-docs” issue with no milestone assigned. 4 “heisebugs” with no milestone 
attached, one with a “priority” label.

 

Just by looking at any of these it is not clear whether they have been triaged 
for 0.5.0, and if so, what the decision was. The main problem will all of these 
seems to be that it is unclear whether a) no one has decided about inclusion in 
0.5.0 yet, or b) someone decided that this would not go into 0.5.0. I think the 
milestone suggestion below would allow a pretty easy management of that 
information.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of David Anthoff
Sent: Thursday, July 14, 2016 11:04 AM
To: julia-users@googlegroups.com
Subject: RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

 

There are also 82 bugs that have no milestone assigned. Have these all been 
triaged for 0.5.0 inclusion and it was decided that none of those need to be 
fixed for 0.5.0? If so, how is that recorded in the issue tracker? Might make 
sense to have another milestone named “post 0.5.0” that simply indicates that 
someone from the core team made sure an issue doesn’t have to be fixed for 
0.5.0, but no other scheduling decision has been made about that issue.

 

From:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com [ 
<mailto:julia-users@googlegroups.com> mailto:julia-users@googlegroups.com] On 
Behalf Of David Anthoff
Sent: Thursday, July 14, 2016 10:58 AM
To:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com
Subject: RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

 

+100 to having a release plan like this!

 

There are 28 open regressions, I assume/hope those will be taken care of before 
RC1? I.e. after feature freeze, but before RC, right?

 

There are 22 open issues assigned to the 0.5.x milestone. The description for 
that one says “Bugs to fix in the 0.5.0 or 0.5.x timeframe”. Might be a good 
idea to make a call on each of these and decide which of those have to be fixed 
for 0.5.0 (in which case they should be fixed before RC1) and which will go 
into 0.5.1.

 

Here is one idea on how to handle this in terms of logistics: rename the 0.5.0 
milestone to “0.5.0-beta” (or “0.5.0-feature-freeze” or something like that). 
These are the items that need to get done before the feature freeze. Create a 
new milestone “0.5.0-RC1”, and assign those issues that need to be fixed before 
RC to that milestone. I guess that should be most issues with a “regression” 
label (but maybe not all, seems possible that you decide to fix some of the 
regressions later), and some subset of the issues with the 0.5.x label. If 
needed, create more RC milestones as things go on, i.e. “0.5.0-RC2” etc. Change 
the description of the 0.5.x milestone to say, “Things to do in a 0.5.x 
release”, and anything assigned to that milestone will definitely not be done 
for 0.5.0.

 

Very exciting to see 0.5 come to a close!!

 

Cheers,

David

 

From:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com [ 
<mailto:julia-users@googlegroups.com> mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Thursday, July 14, 2016 10:25 AM
To: julia-news < <mailto:julia-n...@googlegroups.com> 
julia-n...@googlegroups.com>
Cc: Julia Users < <mailto:julia-users@googlegroups.com> 
julia-users@googlegroups.com>
Subject: [julia-users] ANN: steps towards 0.5.0 release [candidates]

 

See https://github.com/JuliaLang/julia/issues/17418 for how this process is 
going to go. Please keep any discussion on that github issue focused so the 
noise level stays manageable. If you have any questions or comments, you can 
ask them here (don't cc julia-news if you do so though, that list is intended 
to be low-volume).

RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

[David Anthoff]

There are also 82 bugs that have no milestone assigned. Have these all been 
triaged for 0.5.0 inclusion and it was decided that none of those need to be 
fixed for 0.5.0? If so, how is that recorded in the issue tracker? Might make 
sense to have another milestone named “post 0.5.0” that simply indicates that 
someone from the core team made sure an issue doesn’t have to be fixed for 
0.5.0, but no other scheduling decision has been made about that issue.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of David Anthoff
Sent: Thursday, July 14, 2016 10:58 AM
To: julia-users@googlegroups.com
Subject: RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

 

+100 to having a release plan like this!

 

There are 28 open regressions, I assume/hope those will be taken care of before 
RC1? I.e. after feature freeze, but before RC, right?

 

There are 22 open issues assigned to the 0.5.x milestone. The description for 
that one says “Bugs to fix in the 0.5.0 or 0.5.x timeframe”. Might be a good 
idea to make a call on each of these and decide which of those have to be fixed 
for 0.5.0 (in which case they should be fixed before RC1) and which will go 
into 0.5.1.

 

Here is one idea on how to handle this in terms of logistics: rename the 0.5.0 
milestone to “0.5.0-beta” (or “0.5.0-feature-freeze” or something like that). 
These are the items that need to get done before the feature freeze. Create a 
new milestone “0.5.0-RC1”, and assign those issues that need to be fixed before 
RC to that milestone. I guess that should be most issues with a “regression” 
label (but maybe not all, seems possible that you decide to fix some of the 
regressions later), and some subset of the issues with the 0.5.x label. If 
needed, create more RC milestones as things go on, i.e. “0.5.0-RC2” etc. Change 
the description of the 0.5.x milestone to say, “Things to do in a 0.5.x 
release”, and anything assigned to that milestone will definitely not be done 
for 0.5.0.

 

Very exciting to see 0.5 come to a close!!

 

Cheers,

David

 

From:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com [ 
<mailto:julia-users@googlegroups.com> mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Thursday, July 14, 2016 10:25 AM
To: julia-news < <mailto:julia-n...@googlegroups.com> 
julia-n...@googlegroups.com>
Cc: Julia Users < <mailto:julia-users@googlegroups.com> 
julia-users@googlegroups.com>
Subject: [julia-users] ANN: steps towards 0.5.0 release [candidates]

 

See https://github.com/JuliaLang/julia/issues/17418 for how this process is 
going to go. Please keep any discussion on that github issue focused so the 
noise level stays manageable. If you have any questions or comments, you can 
ask them here (don't cc julia-news if you do so though, that list is intended 
to be low-volume).

RE: [julia-users] ANN: steps towards 0.5.0 release [candidates]

[David Anthoff]

+100 to having a release plan like this!

 

There are 28 open regressions, I assume/hope those will be taken care of before 
RC1? I.e. after feature freeze, but before RC, right?

 

There are 22 open issues assigned to the 0.5.x milestone. The description for 
that one says “Bugs to fix in the 0.5.0 or 0.5.x timeframe”. Might be a good 
idea to make a call on each of these and decide which of those have to be fixed 
for 0.5.0 (in which case they should be fixed before RC1) and which will go 
into 0.5.1.

 

Here is one idea on how to handle this in terms of logistics: rename the 0.5.0 
milestone to “0.5.0-beta” (or “0.5.0-feature-freeze” or something like that). 
These are the items that need to get done before the feature freeze. Create a 
new milestone “0.5.0-RC1”, and assign those issues that need to be fixed before 
RC to that milestone. I guess that should be most issues with a “regression” 
label (but maybe not all, seems possible that you decide to fix some of the 
regressions later), and some subset of the issues with the 0.5.x label. If 
needed, create more RC milestones as things go on, i.e. “0.5.0-RC2” etc. Change 
the description of the 0.5.x milestone to say, “Things to do in a 0.5.x 
release”, and anything assigned to that milestone will definitely not be done 
for 0.5.0.

 

Very exciting to see 0.5 come to a close!!

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Thursday, July 14, 2016 10:25 AM
To: julia-news 
Cc: Julia Users 
Subject: [julia-users] ANN: steps towards 0.5.0 release [candidates]

 

See https://github.com/JuliaLang/julia/issues/17418 for how this process is 
going to go. Please keep any discussion on that github issue focused so the 
noise level stays manageable. If you have any questions or comments, you can 
ask them here (don't cc julia-news if you do so though, that list is intended 
to be low-volume).

RE: [julia-users] Pkg "threadsafe" or interprocess mutex package

[David Anthoff]

Ah, interesting. I guess for my use case (global system wide lock) this doesn’t 
matter.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Isaiah Norton
Sent: Friday, July 8, 2016 8:23 PM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Pkg "threadsafe" or interprocess mutex package

 

Libuv mostly abstracts away the differences, but named pipes are released 
automatically when the last handle closes, whereas named sockets are associated 
with an inode and must be checked/cleaned-up manually.

 

On Thu, Jul 7, 2016 at 10:24 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Yes, seems to work.

 

You need to use a different naming scheme on Windows, namely ``  
 .\\pipe\\yourname``, but then one can just 
use the normal julia socket functions for it. In particular, if one process 
listens on such a named pipe, calling ``listen`` from another process with the 
same name will give an error.

 

Actually, are there really different semantics? I haven’t come across any when 
I use such a named pipe on Windows for inter-process communication via the 
julia socket API…

 

From:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com 
[mailto: <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com] On 
Behalf Of Isaiah Norton
Sent: Thursday, July 7, 2016 5:34 PM


To: julia-users@googlegroups.com <mailto:julia-users@googlegroups.com> 
Subject: Re: [julia-users] Pkg "threadsafe" or interprocess mutex package

 

Does that work on Windows? I briefly tried earlier and it didn't seem to work. 
IIUC Windows doesn't support Unix-style named sockets. (it does have named 
pipes, but the semantics are a bit different)

 

On Thu, Jul 7, 2016 at 1:07 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Ah, I had actually come up with the same solution that Amit suggested in #7176 
and am using a named socket as a lock, that seems to work for now.

 

I’m also running into another race condition with respect to precompile, I 
opened a new issue for that:

 <https://github.com/JuliaLang/julia/issues/17320> 
https://github.com/JuliaLang/julia/issues/17320

 

Cheers,

David

 

From:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com 
[mailto: <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com] On 
Behalf Of Isaiah Norton
Sent: Thursday, July 7, 2016 6:52 AM
To:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com
Subject: Re: [julia-users] Pkg "threadsafe" or interprocess mutex package

 

See

https://github.com/JuliaLang/julia/issues/5622 and

https://github.com/JuliaLang/julia/issues/7176

 

If you are on Windows, LockFileEx is reliable and you could ccall it yourself. 
Probably simpler to handle the problem at a higher level for now though (i.e. 
run one script that checks installation *before* launching your analysis jobs).

 

 

On Wed, Jul 6, 2016 at 5:09 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Hi,

 

I have a script that is using some packages. The script is set up such that if 
the package it is trying to use is not installed, it will do a ``Pkg.add`` to 
add the package before ``using`` it.

 

This script is triggered by a third process, and it might be triggered multiple 
times simultaneously, i.e. multiple instances of julia might run the same 
script at the same time. Therefore the second julia instance might issue the 
same ``Pkg.add`` command as the first instance, while the first instance is not 
done with the ``Pkg.add`` yet.

 

I assume the package manager per se is not set up to handle that situation 
gracefully?

 

If not, is there some package that allows me to have something like a 
mutex/lock between my julia processes, so that I can guard the code section 
that fiddles with packages and make sure only one julia instance at a time runs 
that code?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

 

 

 

RE: [julia-users] Pkg "threadsafe" or interprocess mutex package

[David Anthoff]

Yes, seems to work.

 

You need to use a different naming scheme on Windows, namely `` 
.\\pipe\\yourname``  , but then one can just 
use the normal julia socket functions for it. In particular, if one process 
listens on such a named pipe, calling ``listen`` from another process with the 
same name will give an error.

 

Actually, are there really different semantics? I haven’t come across any when 
I use such a named pipe on Windows for inter-process communication via the 
julia socket API…

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Isaiah Norton
Sent: Thursday, July 7, 2016 5:34 PM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Pkg "threadsafe" or interprocess mutex package

 

Does that work on Windows? I briefly tried earlier and it didn't seem to work. 
IIUC Windows doesn't support Unix-style named sockets. (it does have named 
pipes, but the semantics are a bit different)

 

On Thu, Jul 7, 2016 at 1:07 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Ah, I had actually come up with the same solution that Amit suggested in #7176 
and am using a named socket as a lock, that seems to work for now.

 

I’m also running into another race condition with respect to precompile, I 
opened a new issue for that:

https://github.com/JuliaLang/julia/issues/17320

 

Cheers,

David

 

From: julia-users@googlegroups.com <mailto:julia-users@googlegroups.com>  
[mailto:julia-users@googlegroups.com <mailto:julia-users@googlegroups.com> ] On 
Behalf Of Isaiah Norton
Sent: Thursday, July 7, 2016 6:52 AM
To: julia-users@googlegroups.com <mailto:julia-users@googlegroups.com> 
Subject: Re: [julia-users] Pkg "threadsafe" or interprocess mutex package

 

See

https://github.com/JuliaLang/julia/issues/5622 and

https://github.com/JuliaLang/julia/issues/7176

 

If you are on Windows, LockFileEx is reliable and you could ccall it yourself. 
Probably simpler to handle the problem at a higher level for now though (i.e. 
run one script that checks installation *before* launching your analysis jobs).

 

 

On Wed, Jul 6, 2016 at 5:09 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Hi,

 

I have a script that is using some packages. The script is set up such that if 
the package it is trying to use is not installed, it will do a ``Pkg.add`` to 
add the package before ``using`` it.

 

This script is triggered by a third process, and it might be triggered multiple 
times simultaneously, i.e. multiple instances of julia might run the same 
script at the same time. Therefore the second julia instance might issue the 
same ``Pkg.add`` command as the first instance, while the first instance is not 
done with the ``Pkg.add`` yet.

 

I assume the package manager per se is not set up to handle that situation 
gracefully?

 

If not, is there some package that allows me to have something like a 
mutex/lock between my julia processes, so that I can guard the code section 
that fiddles with packages and make sure only one julia instance at a time runs 
that code?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

 

 

[julia-users] Disable precompile flag

[David Anthoff]

Hi,

 

is there a command line option for julia 0.4.x to disable all precompile?
I.e. I want a julia instance that doesn't precompile any modules it is
using.

 

On julia 0.5.x, would ``--precompiled=no`` achieve this?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Language Server Protocol ...

[David Anthoff]

I am, with no firm plans to do anything about it.

 

I just added linting support to the julia VS Code extension. I thought about 
using the language server protocol, but in the end decided to just use the 
existing server mode in Lint.jl and communicate directly with that from the 
julia TypeScript extension. Mostly because it seemed less work to implement…

 

It would be cool to use that protocol fully, though! 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of cdm
Sent: Thursday, July 7, 2016 10:12 AM
To: julia-users 
Subject: [julia-users] Language Server Protocol ...

 

 

anyone following developments in this space ?

 

see:  https://code.visualstudio.com/blogs

 

 

curious.

[julia-users] VS Code linter - help wanted

[David Anthoff]

Hi all,

 

I've added linting support to the julia VS Code extension (using Lint.jl). I
don't have a Mac to test things, would be great if some folks here could try
the beta that I have prepared on their Macs (and any other OS as well) and
help me find any problems that are still remaining.

 

Instructions on how to help are here
https://github.com/JuliaEditorSupport/julia-vscode/issues/6. 

 

Best,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Pkg "threadsafe" or interprocess mutex package

[David Anthoff]

Ah, I had actually come up with the same solution that Amit suggested in #7176 
and am using a named socket as a lock, that seems to work for now.

 

I’m also running into another race condition with respect to precompile, I 
opened a new issue for that:

https://github.com/JuliaLang/julia/issues/17320

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Isaiah Norton
Sent: Thursday, July 7, 2016 6:52 AM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Pkg "threadsafe" or interprocess mutex package

 

See

https://github.com/JuliaLang/julia/issues/5622 and

https://github.com/JuliaLang/julia/issues/7176

 

If you are on Windows, LockFileEx is reliable and you could ccall it yourself. 
Probably simpler to handle the problem at a higher level for now though (i.e. 
run one script that checks installation *before* launching your analysis jobs).

 

 

On Wed, Jul 6, 2016 at 5:09 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Hi,

 

I have a script that is using some packages. The script is set up such that if 
the package it is trying to use is not installed, it will do a ``Pkg.add`` to 
add the package before ``using`` it.

 

This script is triggered by a third process, and it might be triggered multiple 
times simultaneously, i.e. multiple instances of julia might run the same 
script at the same time. Therefore the second julia instance might issue the 
same ``Pkg.add`` command as the first instance, while the first instance is not 
done with the ``Pkg.add`` yet.

 

I assume the package manager per se is not set up to handle that situation 
gracefully?

 

If not, is there some package that allows me to have something like a 
mutex/lock between my julia processes, so that I can guard the code section 
that fiddles with packages and make sure only one julia instance at a time runs 
that code?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

 

[julia-users] Pkg "threadsafe" or interprocess mutex package

[David Anthoff]

Hi,

 

I have a script that is using some packages. The script is set up such that
if the package it is trying to use is not installed, it will do a
``Pkg.add`` to add the package before ``using`` it.

 

This script is triggered by a third process, and it might be triggered
multiple times simultaneously, i.e. multiple instances of julia might run
the same script at the same time. Therefore the second julia instance might
issue the same ``Pkg.add`` command as the first instance, while the first
instance is not done with the ``Pkg.add`` yet.

 

I assume the package manager per se is not set up to handle that situation
gracefully?

 

If not, is there some package that allows me to have something like a
mutex/lock between my julia processes, so that I can guard the code section
that fiddles with packages and make sure only one julia instance at a time
runs that code?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] using in try catch block

[David Anthoff]

Perfect, that is exactly the kind of thing I was looking for! Thanks, David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Yichao Yu
Sent: Monday, June 27, 2016 9:49 AM
To: Julia Users 
Subject: Re: [julia-users] using in try catch block

 


On Jun 27, 2016 12:20 PM, "Tom Breloff" mailto:t...@breloff.com> > wrote:
>
> Here is what I use for this sort of logic:
>
> function is_installed(pkgstr::AbstractString)
> try
> Pkg.installed(pkgstr) === nothing ? false: true

Dont do this since this will miss package in load path. Just eval a using 
expression.

> catch
> false
> end
> end
>
>
> On Mon, Jun 27, 2016 at 12:12 PM, David Anthoff  <mailto:anth...@berkeley.edu> > wrote:
>>
>> I’m trying to use ``using`` in a try catch block, but that doesn’t seem to 
>> be supported.
>>
>>  
>>
>> Any other way around this? Essentially I want to load a package, and if the 
>> package is not installed, automatically do a ``Pkg.add``.
>>
>>  
>>
>> I could of course get a list of all the installed packages and see if the 
>> one I need is there, but given the slowness of the package manager, I would 
>> prefer to just try to load it first, and only if that fails attempt to 
>> ``Pkg.add``.
>>
>>  
>>
>> Thanks,
>>
>> David
>>
>>  
>>
>> --
>>
>> David Anthoff
>>
>> University of California, Berkeley
>>
>>  
>>
>> http://www.david-anthoff.com
>>
>>  
>
>

[julia-users] using in try catch block

[David Anthoff]

I'm trying to use ``using`` in a try catch block, but that doesn't seem to
be supported.

 

Any other way around this? Essentially I want to load a package, and if the
package is not installed, automatically do a ``Pkg.add``.

 

I could of course get a list of all the installed packages and see if the
one I need is there, but given the slowness of the package manager, I would
prefer to just try to load it first, and only if that fails attempt to
``Pkg.add``.

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: VS code extension

[David Anthoff]

I added a gitter room for the VS Code plugin, maybe best to move further 
discussion of the extension there: 
https://gitter.im/JuliaEditorSupport/julia-vscode.

 

I have a prototype  up and running for sending selected or individual lines of 
code from the editor to a REPL via Ctrl+Enter. All very rough at this point and 
for a smooth story it will need some work on Microsoft’s part, but generally it 
is pretty straightforward to get something up and running. 
https://github.com/JuliaEditorSupport/julia-vscode/pull/2

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of David Anthoff
Sent: Thursday, June 23, 2016 12:07 PM
To: julia-users@googlegroups.com
Subject: RE: [julia-users] Re: VS code extension

 

Yes, VS Code does feel a lot snappier than Atom. I never had problem with 
installation or updating with Atom, though.

 

Right now the VS Code plugin is very bare and has hardly any features (syntax 
highlighting, latex completion, and one command to open a package in a new 
window). Right now I mostly feel that it is good to have some bare bones 
support for VS Code. I don’t know whether there is enough man power/interest to 
ever try to get it into a polished thing that supports more of the VS Code 
extension points for languages. While I’ll maintain the extension, I have no 
plans for major development.

 

PRs are welcome, though!

 

Cheers,

David

 

From: julia-users@googlegroups.com <mailto:julia-users@googlegroups.com>  
[mailto:julia-users@googlegroups.com] On Behalf Of Tony Kelman
Sent: Wednesday, June 22, 2016 8:11 PM
To: julia-users mailto:julia-users@googlegroups.com> >
Subject: [julia-users] Re: VS code extension

 

VS Code feels much snappier and higher performance to me than Atom, especially 
on larger files. If you're on Windows especially, the installation and updating 
experience is just a lot more polished and customizable. The downside is 
there's been a lot less work on Julia-specific addin integration so far.


On Wednesday, June 22, 2016 at 10:36:58 PM UTC-4, Gabriel Gellner wrote:

Are there benefits to using this over atom? Why are people moving over? Pros, 
Cons?

On Tuesday, June 21, 2016 at 3:26:52 PM UTC-7, David Anthoff wrote:

Hi all,

 

I’ve created a new github repo for a VS code extension 
https://github.com/davidanthoff/julia-vscode and it is published here 
https://marketplace.visualstudio.com/items?itemName=julialang.language-julia. 
Be5invis will delete the old julia extension from the marketplace because he is 
no longer maintaining it. At this point my extension has zero additional 
features over his old one, except that there is a public github repo where in 
theory people could contribute.

 

Two questions:

1) could we move the github repo under some official julia organization? I know 
most other editor plugins are under julialang, but I also remember talk about 
creating something like a juliaeditor org or something like that? In any case, 
I would like to move the repo to something more official. I’m happy to maintain 
it for the foreseeable future, so no fear on that front.

2) I used the julia logo. I hope that is ok from a copyright point of view? I 
took it from the repo for the julia homepage, and that whole repo seemed to be 
under an MIT license, but just wanted to be sure.

 

And if anyone wants to add stuff to the extension, PRs are welcome! Especially 
a debug adapter would of course be fantastic.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] Hide and disable REPL

[David Anthoff]

Hi,

 

is there a way to switch off the REPL and then on again, from a task?

 

Specifically, I want to start a julia instance and pass a script in with the
-L parameter that will open a socket, listen for connections and the process
messages from that socket. This server listening code is all wrapped in
@async macro calls. So when I start things this way, julia shows the REPL
and at the same time listens for incoming messages. I can use the REPL etc.
This is exactly what I want.

 

But when I receive a message, I want to temporarily switch the REPL off,
i.e. it should visually disappear while I process that message, and then I
want to switch it back on once I'm done processing that message.

 

Can that be done somehow?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: VS code extension

[David Anthoff]

Yes, VS Code does feel a lot snappier than Atom. I never had problem with 
installation or updating with Atom, though.

 

Right now the VS Code plugin is very bare and has hardly any features (syntax 
highlighting, latex completion, and one command to open a package in a new 
window). Right now I mostly feel that it is good to have some bare bones 
support for VS Code. I don’t know whether there is enough man power/interest to 
ever try to get it into a polished thing that supports more of the VS Code 
extension points for languages. While I’ll maintain the extension, I have no 
plans for major development.

 

PRs are welcome, though!

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Wednesday, June 22, 2016 8:11 PM
To: julia-users 
Subject: [julia-users] Re: VS code extension

 

VS Code feels much snappier and higher performance to me than Atom, especially 
on larger files. If you're on Windows especially, the installation and updating 
experience is just a lot more polished and customizable. The downside is 
there's been a lot less work on Julia-specific addin integration so far.


On Wednesday, June 22, 2016 at 10:36:58 PM UTC-4, Gabriel Gellner wrote:

Are there benefits to using this over atom? Why are people moving over? Pros, 
Cons?

On Tuesday, June 21, 2016 at 3:26:52 PM UTC-7, David Anthoff wrote:

Hi all,

 

I’ve created a new github repo for a VS code extension 
https://github.com/davidanthoff/julia-vscode and it is published here 
https://marketplace.visualstudio.com/items?itemName=julialang.language-julia. 
Be5invis will delete the old julia extension from the marketplace because he is 
no longer maintaining it. At this point my extension has zero additional 
features over his old one, except that there is a public github repo where in 
theory people could contribute.

 

Two questions:

1) could we move the github repo under some official julia organization? I know 
most other editor plugins are under julialang, but I also remember talk about 
creating something like a juliaeditor org or something like that? In any case, 
I would like to move the repo to something more official. I’m happy to maintain 
it for the foreseeable future, so no fear on that front.

2) I used the julia logo. I hope that is ok from a copyright point of view? I 
took it from the repo for the julia homepage, and that whole repo seemed to be 
under an MIT license, but just wanted to be sure.

 

And if anyone wants to add stuff to the extension, PRs are welcome! Especially 
a debug adapter would of course be fantastic.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: VS code extension

[David Anthoff]

I just used this

 

https://github.com/JuliaLang/Julia.tmbundle/blob/696f630736669251a3cb56cb27741b5b07a4c093/Syntaxes/Julia.tmLanguage

 

file.

 

I don’t know what format atom uses to define grammars…

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Eric Forgy
Sent: Wednesday, June 22, 2016 5:05 PM
To: julia-users 
Subject: Re: [julia-users] Re: VS code extension

 

Hi David,

 

This is awesome. Thanks for this. Out of curiosity, is this the same syntax 
highlighting used in Juno? It feels a little different and I've gotten used to 
Juno. 

 

I was able to get the same Julia.tmBundle to work in Visual Studio (not VS 
Code) and filed an issue here 
<https://github.com/JuliaLang/Julia.tmbundle/issues/10> .

Thanks.


Best regards,

Eric

On Thursday, June 23, 2016 at 12:18:28 AM UTC+8, David Anthoff wrote:

The VS code extension now lives here  
<https://github.com/JuliaEditorSupport/julia-vscode> 
https://github.com/JuliaEditorSupport/julia-vscode.

 

Cheers,

David

 

From:   julia...@googlegroups.com [mailto:  
julia...@googlegroups.com] On Behalf Of Lyndon White
Sent: Tuesday, June 21, 2016 7:53 PM
To: julia-users <  julia...@googlegroups.com>
Subject: [julia-users] Re: VS code extension

 

I would be happy to transfer https://github.com/oxinabox/julia-vim-completions 
to an Org.
Though probably worth waiting til it is wrapped up into a form people who are 
not me can use.





On Wednesday, 22 June 2016 06:26:52 UTC+8, David Anthoff wrote:

Hi all,

 

I’ve created a new github repo for a VS code extension 
https://github.com/davidanthoff/julia-vscode and it is published here 
https://marketplace.visualstudio.com/items?itemName=julialang.language-julia. 
Be5invis will delete the old julia extension from the marketplace because he is 
no longer maintaining it. At this point my extension has zero additional 
features over his old one, except that there is a public github repo where in 
theory people could contribute.

 

Two questions:

1) could we move the github repo under some official julia organization? I know 
most other editor plugins are under julialang, but I also remember talk about 
creating something like a juliaeditor org or something like that? In any case, 
I would like to move the repo to something more official. I’m happy to maintain 
it for the foreseeable future, so no fear on that front.

2) I used the julia logo. I hope that is ok from a copyright point of view? I 
took it from the repo for the julia homepage, and that whole repo seemed to be 
under an MIT license, but just wanted to be sure.

 

And if anyone wants to add stuff to the extension, PRs are welcome! Especially 
a debug adapter would of course be fantastic.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] GraphViz.jl alternative on windows

[David Anthoff]

Hi,

 

GraphViz.jl doesn't seem to work on Windows. Is there an alternative package
for this sort of thing? I know about NetworkViz.jl and TikzGraphs.jl, but
would appreciate pointers to any other package that I might have missed.

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: VS code extension

[David Anthoff]

The VS code extension now lives here 
https://github.com/JuliaEditorSupport/julia-vscode.

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Lyndon White
Sent: Tuesday, June 21, 2016 7:53 PM
To: julia-users 
Subject: [julia-users] Re: VS code extension

 

I would be happy to transfer https://github.com/oxinabox/julia-vim-completions 
to an Org.
Though probably worth waiting til it is wrapped up into a form people who are 
not me can use.





On Wednesday, 22 June 2016 06:26:52 UTC+8, David Anthoff wrote:

Hi all,

 

I’ve created a new github repo for a VS code extension 
https://github.com/davidanthoff/julia-vscode and it is published here 
https://marketplace.visualstudio.com/items?itemName=julialang.language-julia. 
Be5invis will delete the old julia extension from the marketplace because he is 
no longer maintaining it. At this point my extension has zero additional 
features over his old one, except that there is a public github repo where in 
theory people could contribute.

 

Two questions:

1) could we move the github repo under some official julia organization? I know 
most other editor plugins are under julialang, but I also remember talk about 
creating something like a juliaeditor org or something like that? In any case, 
I would like to move the repo to something more official. I’m happy to maintain 
it for the foreseeable future, so no fear on that front.

2) I used the julia logo. I hope that is ok from a copyright point of view? I 
took it from the repo for the julia homepage, and that whole repo seemed to be 
under an MIT license, but just wanted to be sure.

 

And if anyone wants to add stuff to the extension, PRs are welcome! Especially 
a debug adapter would of course be fantastic.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] VS code extension

[David Anthoff]

Hi all,

 

I've created a new github repo for a VS code extension
https://github.com/davidanthoff/julia-vscode and it is published here
https://marketplace.visualstudio.com/items?itemName=julialang.language-julia
. Be5invis will delete the old julia extension from the marketplace because
he is no longer maintaining it. At this point my extension has zero
additional features over his old one, except that there is a public github
repo where in theory people could contribute.

 

Two questions:

1) could we move the github repo under some official julia organization? I
know most other editor plugins are under julialang, but I also remember talk
about creating something like a juliaeditor org or something like that? In
any case, I would like to move the repo to something more official. I'm
happy to maintain it for the foreseeable future, so no fear on that front.

2) I used the julia logo. I hope that is ok from a copyright point of view?
I took it from the repo for the julia homepage, and that whole repo seemed
to be under an MIT license, but just wanted to be sure.

 

And if anyone wants to add stuff to the extension, PRs are welcome!
Especially a debug adapter would of course be fantastic.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: Julia 0.4.6 Windows 32bits not run

[David Anthoff]

I like to add a new-alias command to my Microsoft.PowerShell_profile.ps1 file 
that makes the “julia” command available in my powershell session.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Tuesday, June 21, 2016 12:46 PM
To: julia-users 
Subject: [julia-users] Re: Julia 0.4.6 Windows 32bits not run

 

I disagree, adding Julia's bin/ directory to the Windows PATH is generally a 
bad idea. Any library that depends on the same set of libraries that Julia 
does, but wants them in a different configuration, can easily hit compatibility 
problems if Julia's dll's are all added to the path, and Windows puts dll's and 
exe's in the same location. You can write a wrapper script or similar, or set 
up a terminal environment in a way that you temporarily add Julia's location to 
your path only when you need it.


On Tuesday, June 21, 2016 at 10:17:40 AM UTC-4, Андрей Логунов wrote:

I had similar difficulties when having upgraded from 0.4.5 to 0.4.6 under Win10 
x64. The REPL console did not run. But then i recalled that i'd added a value 
to the users's path variable, and it turned out to be the reason for the 
porblem in question for when i substituted 5 with 6 the problem vanished. It'd 
be much better if the path value was added/removed automatically during 
installation.


вторник, 21 июня 2016 г., 22:15:21 UTC+10 пользователь Tony Kelman написал:

Please provide more information. Exactly what error do you get? Can you try to 
run julia.exe from inside a command prompt if that provides more of an error 
message?


On Tuesday, June 21, 2016 at 6:03:58 AM UTC-4, alx wrote:



Hello,

Julia 0.4.6 Windows 32bits, is installed correctly but does not run, Wrong 
configuration

Windows XP

RE: [julia-users] Re: Git-maggedon

[David Anthoff]

Ah, I see. On one hand that makes sense. On the other hand, I’ve been under the 
impression for more than two years now that if I remove a package via Pkg.rm 
and it doesn’t show up in Pkg.status, it is no longer on my disc. Doesn’t seem 
an unreasonable expectation, so maybe that is something to clarify somewhere.

 

From: stefan.karpin...@gmail.com [mailto:stefan.karpin...@gmail.com] On Behalf 
Of Stefan Karpinski
Sent: Tuesday, June 21, 2016 11:29 AM
To: Julia Users 
Subject: Re: [julia-users] Re: Git-maggedon

 

Yes, that's right. The cache is also shared between different Julia versions.

 

On Tue, Jun 21, 2016 at 1:49 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

You mean when I completely uninstalled a package and then add it again?

 

It wouldn’t be needed if I just switch to a different version of an installed 
package, right?

 

From:  <mailto:stefan.karpin...@gmail.com> stefan.karpin...@gmail.com [mailto: 
<mailto:stefan.karpin...@gmail.com> stefan.karpin...@gmail.com] On Behalf Of 
Stefan Karpinski
Sent: Tuesday, June 21, 2016 10:45 AM
To: Julia Users < <mailto:julia-users@googlegroups.com> 
julia-users@googlegroups.com>
Subject: Re: [julia-users] Re: Git-maggedon

 

The cache folders are just bare git repositories for packages. Keeping these 
around prevents having to hit the network to reinstall a package version that 
you've already fetched and installed before.

 

On Tue, Jun 21, 2016 at 1:31 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

I’ve never understood the various .cache folders that hang around, but if you 
want to be sure to start from a clean .julia package folder you might want to 
make sure all the .cache folders are also removed. In particular I guess the 
.julia/.cache folder. And then retry the whole Pkg.init() procedure. 

 

From:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com 
[mailto: <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com] On 
Behalf Of Eric Forgy
Sent: Tuesday, June 21, 2016 10:24 AM
To: julia-users < <mailto:julia-users@googlegroups.com> 
julia-users@googlegroups.com>
Subject: [julia-users] Re: Git-maggedon

 

Update:

 

I went back and changed v0.4 -> v0.4_temp2 and did a Pkg.Init() and 
Pkg.add("JSON") using v0.4.5 just to see if it was related to upgrading. 

 

I see the exact same problem. I suspect my Git is corrupted somehow which is 
wreaking havoc with Pkg. That is just a guess.

 

Any ideas?


On Wednesday, June 22, 2016 at 12:37:50 AM UTC+8, Eric Forgy wrote:

I just upgraded to v0.4.6 on Windows, but I think this problem might predate 
the upgrade (I think the upgrade was partially in hopes of resolving this).

 

I don't know if this is a Julia issue or a Git issue, but if I add any package, 
e.g.

 

julia> Pkg.add("JSON")


The package gets added to my package directory, but no branch is checked out so 
I am on HEAD.

 

Worse, instead of my remotes being things like:

 

remotes/origin/master


I see things like

 

remotes/cached/heads/master

 

Any idea what's going on? I'm on a critical business trip and my development is 
completely paralyzed until I can resolve this so I really sincerely appreciate 
any help.

 

In an act of desperation, I moved v0.4 -> v0.4_temp, Pkg.init() and reinstalled 
every single package. I still have exactly the same problem, so I am unable to 
do anything with Julia until I fix this.

 

Thank you very much and best regards,

Eric

 

 

 

 

RE: [julia-users] Re: Git-maggedon

[David Anthoff]

You mean when I completely uninstalled a package and then add it again?

 

It wouldn’t be needed if I just switch to a different version of an installed 
package, right?

 

From: stefan.karpin...@gmail.com [mailto:stefan.karpin...@gmail.com] On Behalf 
Of Stefan Karpinski
Sent: Tuesday, June 21, 2016 10:45 AM
To: Julia Users 
Subject: Re: [julia-users] Re: Git-maggedon

 

The cache folders are just bare git repositories for packages. Keeping these 
around prevents having to hit the network to reinstall a package version that 
you've already fetched and installed before.

 

On Tue, Jun 21, 2016 at 1:31 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

I’ve never understood the various .cache folders that hang around, but if you 
want to be sure to start from a clean .julia package folder you might want to 
make sure all the .cache folders are also removed. In particular I guess the 
.julia/.cache folder. And then retry the whole Pkg.init() procedure. 

 

From:  <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com 
[mailto: <mailto:julia-users@googlegroups.com> julia-users@googlegroups.com] On 
Behalf Of Eric Forgy
Sent: Tuesday, June 21, 2016 10:24 AM
To: julia-users < <mailto:julia-users@googlegroups.com> 
julia-users@googlegroups.com>
Subject: [julia-users] Re: Git-maggedon

 

Update:

 

I went back and changed v0.4 -> v0.4_temp2 and did a Pkg.Init() and 
Pkg.add("JSON") using v0.4.5 just to see if it was related to upgrading. 

 

I see the exact same problem. I suspect my Git is corrupted somehow which is 
wreaking havoc with Pkg. That is just a guess.

 

Any ideas?


On Wednesday, June 22, 2016 at 12:37:50 AM UTC+8, Eric Forgy wrote:

I just upgraded to v0.4.6 on Windows, but I think this problem might predate 
the upgrade (I think the upgrade was partially in hopes of resolving this).

 

I don't know if this is a Julia issue or a Git issue, but if I add any package, 
e.g.

 

julia> Pkg.add("JSON")


The package gets added to my package directory, but no branch is checked out so 
I am on HEAD.

 

Worse, instead of my remotes being things like:

 

remotes/origin/master


I see things like

 

remotes/cached/heads/master

 

Any idea what's going on? I'm on a critical business trip and my development is 
completely paralyzed until I can resolve this so I really sincerely appreciate 
any help.

 

In an act of desperation, I moved v0.4 -> v0.4_temp, Pkg.init() and reinstalled 
every single package. I still have exactly the same problem, so I am unable to 
do anything with Julia until I fix this.

 

Thank you very much and best regards,

Eric

 

 

 

RE: [julia-users] Re: Git-maggedon

[David Anthoff]

I’ve never understood the various .cache folders that hang around, but if you 
want to be sure to start from a clean .julia package folder you might want to 
make sure all the .cache folders are also removed. In particular I guess the 
.julia/.cache folder. And then retry the whole Pkg.init() procedure. 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Eric Forgy
Sent: Tuesday, June 21, 2016 10:24 AM
To: julia-users 
Subject: [julia-users] Re: Git-maggedon

 

Update:

 

I went back and changed v0.4 -> v0.4_temp2 and did a Pkg.Init() and 
Pkg.add("JSON") using v0.4.5 just to see if it was related to upgrading. 

 

I see the exact same problem. I suspect my Git is corrupted somehow which is 
wreaking havoc with Pkg. That is just a guess.

 

Any ideas?


On Wednesday, June 22, 2016 at 12:37:50 AM UTC+8, Eric Forgy wrote:

I just upgraded to v0.4.6 on Windows, but I think this problem might predate 
the upgrade (I think the upgrade was partially in hopes of resolving this).

 

I don't know if this is a Julia issue or a Git issue, but if I add any package, 
e.g.

 

julia> Pkg.add("JSON")


The package gets added to my package directory, but no branch is checked out so 
I am on HEAD.

 

Worse, instead of my remotes being things like:

 

remotes/origin/master


I see things like

 

remotes/cached/heads/master

 

Any idea what's going on? I'm on a critical business trip and my development is 
completely paralyzed until I can resolve this so I really sincerely appreciate 
any help.

 

In an act of desperation, I moved v0.4 -> v0.4_temp, Pkg.init() and reinstalled 
every single package. I still have exactly the same problem, so I am unable to 
do anything with Julia until I fix this.

 

Thank you very much and best regards,

Eric

 

 

RE: [julia-users] Re: parse.(Int64, x)

[David Anthoff]

https://github.com/JuliaLang/julia/issues/16966

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Milan Bouchet-Valat
> Sent: Thursday, June 16, 2016 1:33 AM
> To: julia-users@googlegroups.com
> Subject: Re: [julia-users] Re: parse.(Int64, x)
> 
> Le mercredi 15 juin 2016 à 17:28 -0700, Tony Kelman a écrit :
> > Try parse.([Int64], x)
> > note that the output will be an Array{Any} because issue #4883 hasn't
> > been fixed yet. The issue here is that broadcast doesn't treat types
> > as "scalar-like."
> Is the latter a separate bug? Should we open an issue for that?
> 
> 
> > > map of course works, but it is quite verbose. I’ve been working a
> > > group of new julia users lately, many of them from other languages
> > > like R, Python etc., and they roll their eyes when something that
> > > simple takes
> > >
> > > df[:x] = map(q->parse(Int64,q), df[:x])
> > >
> > > It just is quite complicated for something pretty simple… Maybe
> > > there are other simple constructs for this?
> > >
> > > Thanks,
> > > David
> > >
> > > From: julia...@googlegroups.com [mailto:julia...@googlegroups.com]
> > > On Behalf Of John Myles White
> > > Sent: Wednesday, June 15, 2016 3:53 PM
> > > To: julia-users 
> > > Subject: [julia-users] Re: parse.(Int64, x)
> > >
> > > I would be careful combining element-wise function application with
> > > partial function application. Why not use map instead?
> > >
> > > On Wednesday, June 15, 2016 at 3:47:05 PM UTC-7, David Anthoff
> > > wrote:
> > > I just tried to use the new dot syntax for vectorising function
> > > calls in order to convert an array of strings into an array of
> > > Int64. For example, if this would work, it would be very, very
> > > handy:
> > >
> > > x = [“1”, “2”, “3”]
> > > parse.(Int64, x)
> > >
> > > Right now I get an error, but I wonder whether this could be enabled
> > > somehow in this new framework? If this would work for all sorts of
> > > parsing, type conversions etc. it would just be fantastic.
> > > Especially when working DataFrames and one is in the first phase of
> > > cleaning up data types of columns etc. this would make for a very
> > > nice and short notation.
> > >
> > > Thanks,
> > > David
> > >
> > > --
> > > David Anthoff
> > > University of California, Berkeley
> > >
> > > http://www.david-anthoff.com
> > >
> > >

RE: [julia-users] Re: parse.(Int64, x)

[David Anthoff]

map of course works, but it is quite verbose. I’ve been working a group of new 
julia users lately, many of them from other languages like R, Python etc., and 
they roll their eyes when something that simple takes

 

df[:x] = map(q->parse(Int64,q), df[:x])

 

It just is quite complicated for something pretty simple… Maybe there are other 
simple constructs for this?

 

Thanks,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of John Myles White
Sent: Wednesday, June 15, 2016 3:53 PM
To: julia-users 
Subject: [julia-users] Re: parse.(Int64, x)

 

I would be careful combining element-wise function application with partial 
function application. Why not use map instead?

On Wednesday, June 15, 2016 at 3:47:05 PM UTC-7, David Anthoff wrote:

I just tried to use the new dot syntax for vectorising function calls in order 
to convert an array of strings into an array of Int64. For example, if this 
would work, it would be very, very handy:

 

x = [“1”, “2”, “3”]

parse.(Int64, x)

 

Right now I get an error, but I wonder whether this could be enabled somehow in 
this new framework? If this would work for all sorts of parsing, type 
conversions etc. it would just be fantastic. Especially when working DataFrames 
and one is in the first phase of cleaning up data types of columns etc. this 
would make for a very nice and short notation.

 

Thanks,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] parse.(Int64, x)

[David Anthoff]

I just tried to use the new dot syntax for vectorising function calls in
order to convert an array of strings into an array of Int64. For example, if
this would work, it would be very, very handy:

 

x = ["1", "2", "3"]

parse.(Int64, x)

 

Right now I get an error, but I wonder whether this could be enabled somehow
in this new framework? If this would work for all sorts of parsing, type
conversions etc. it would just be fantastic. Especially when working
DataFrames and one is in the first phase of cleaning up data types of
columns etc. this would make for a very nice and short notation.

 

Thanks,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: ArrayFire.jl - GPU Programming in Julia

[David Anthoff]

https://github.com/JuliaComputing/ArrayFire.jl/issues/40

 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Gabriel Goh
Sent: Friday, June 10, 2016 3:00 PM
To: julia-users 
Subject: [julia-users] Re: ArrayFire.jl - GPU Programming in Julia

 

is there windows support? I have a pretty beefy gaming PC


On Thursday, June 9, 2016 at 10:08:42 PM UTC-7, ran...@juliacomputing.com 
  wrote:

Hello, 

 

We are pleased to announce ArrayFire.jl, a library for GPU and heterogeneous 
computing in Julia: (https://github.com/JuliaComputing/ArrayFire.jl). We look 
forward to your feedback and your contributions as well! 

 

For more information, check out Julia Computing's latest blog post: 
http://juliacomputing.com/blog/2016/06/09/julia-gpu.html

 

Thanks,

Ranjan

Julia Computing, Inc. 

[julia-users] paratext

[David Anthoff]

I know a bunch of people are working on more efficient csv file reading for
julia. I stumbled across this http://www.wise.io/tech/paratext. It sounds
impressive, and one could probably create a julia wrapper. I won't, but just
thought I'd flag it if anyone else is interested.

 

Cheers,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: Lack of an explicit return in Julia, heartache or happiness?

[David Anthoff]

+1. While I like it, I’m not sure it is worth the cost. If there is a decision 
to go ahead with it, it would be good to do so rather sooner than later, just 
to make that breakage a little less worse… 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Steven G. Johnson
Sent: Tuesday, May 24, 2016 4:13 PM
To: julia-users 
Subject: Re: [julia-users] Re: Lack of an explicit return in Julia, heartache 
or happiness?

 



On Tuesday, May 24, 2016 at 6:30:19 PM UTC-4, Stefan Karpinski wrote:

With the change I proposed, we can statically tell the difference between an 
accidental return and an intentional one.

 

Nice, now I see.  The biggest problem is that it seems like it would be a 
hugely breaking change.

RE: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Anthoff]

I think that is a way too complicated rule, no one will know anymore what is 
happening.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Jeffrey Sarnoff
Sent: Tuesday, May 24, 2016 12:58 PM
To: julia-users 
Subject: Re: [julia-users] Lack of an explicit return in Julia, heartache or 
happiness?

 

Rather than impose `return nothing` on all unshortly functions that do not 
provide an explicit return, 

perhaps limit postpending `return nothing` to functions that 

neither provide an explicit return anywhere within the function body 

nor have as the final line of the function (before end) either 

  (a) a single variable/value or

  (b) a tuple of variables/values or 

  (c) a conditional/branching that selects either (a) or (b) or throws an 
exception. 

 

On Tuesday, May 24, 2016 at 2:49:26 PM UTC-4, Tamas Papp wrote:

I wonder if a mandatory return would play well with macros. The neat 
thing about the Lisp-style syntax is that it is nestable, an expression 
does not need to care about where it is and whether a return statement 
makes sense in that context. 

On Tue, May 24 2016, David Anthoff wrote: 

> BUT, if this was to adopted, please do it soon :) These are the kind of 
> breaking code changes that should get fewer and fewer as 1.0 moves closer. 
> ​ 

Re: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Anthoff]

BUT, if this was to adopted, please do it soon :) These are the kind of
breaking code changes that should get fewer and fewer as 1.0 moves closer.
​

RE: [julia-users] Lack of an explicit return in Julia, heartache or happiness?

[David Anthoff]

I like that idea. I think the current behavior is not a huge problem, but I 
often run into a situation where I code up a method that modifies something and 
shouldn’t return anything, and then I forget to add a blank return statement at 
the end (*) and the function returns just something arbitrary, which can be 
confusing, especially in interactive sessions a la IJulia.

 

Cheers,

David

 

(*) ``return`` and ``return nothing`` and ``nothing`` on the last line are all 
equivalent, right? 

 

From: stefan.karpin...@gmail.com [mailto:stefan.karpin...@gmail.com] On Behalf 
Of Stefan Karpinski
Sent: Tuesday, May 24, 2016 10:28 AM
To: Julia Users 
Subject: Re: [julia-users] Lack of an explicit return in Julia, heartache or 
happiness?

 

The modification I've occasionally considered would be:

*   short-form functions implicitly return their expression value;
*   long-form functions implicitly return `nothing` unless an explicit 
value is returned.

This could be implemented by automatically inserting a `return nothing` at the 
end of every long-form function body. I agree that it doesn't help cases where 
an expression like `a[:] = 1` evaluates to something unexpected. What it does 
mitigate is accidentally returning some value that you didn't really mean to 
return. That's not a huge issue since people are free to call the function and 
ignore the return value, but there is a hazard of people relying on accidental 
return values which could then change in the future since they were 
unintentional in the first place.

 

On Tue, May 24, 2016 at 1:19 PM, Jeff Bezanson mailto:jeff.bezan...@gmail.com> > wrote:

We did it this way because it's useful in general for the value of a
block to be the value of its last expression (as in lisp `progn` and
scheme `begin`). For example, a macro might want to return some
statements that need to execute before finally computing its value.
The "implicit return" behavior falls out of this. We could maybe add a
check that says "you must write an explicit return", but I find this
to be kind of an arbitrary restriction. It also doesn't fit so well
with other features of the syntax. For example is

f(x) = 2

allowed, or do you have to write

f(x) = return 2

?

True, some constructs have non-obvious return values. For example in

function set1(a)
a[:] = 1
end

some might assume it returns `1`, and others might prefer it to return
`a`. If we gave a "must write a return" error, many would just
reflexively add

function set1(a)
return a[:] = 1
end

which doesn't clarify anything. It seems like a documentation problem
to me. If the meaning of a function's return value isn't clear,
requiring people to add redundant keywords doesn't seem like a real
fix to me.


On Tue, May 24, 2016 at 12:48 PM, David Parks mailto:davidpark...@gmail.com> > wrote:

> The last line of a function is its implicit return value in Julia.
>
> Can someone tell me why this is a great idea?
>
> I'm realizing a serious downside to it in reading someone else's code. It's
> not immediately clear to me if a use of a particular function is using the
> last statement as a return value or not.
>
> The lack of an explicit return is making the code ambiguous to read, and
> therefore I'm searching for uses of it to understand the original intent.
>
> Even if the original coder is being perfectly hygienic in their style, I
> can't make an assumption as such. I've always though explicit over implicit
> reigned king in code maintainability. Can someone convince me otherwise?
>
>
>

 

RE: [julia-users] Re: Julia large project example.

[David Anthoff]

Do a search for “encapsulation” in this google group and you’ll find quite a 
number of discussions on some of the design philosophies around this topic, 
many from the julia devs.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Ford Ox
Sent: Thursday, May 12, 2016 10:20 AM
To: julia-users 
Subject: [julia-users] Re: Julia large project example.

 

I am sorry for those words. The idea of that sentence should have been:

"Your approach looks like a big no no. 
Could julia devs share their idea of how should apple encapsulation achieved? 
Since they are the one, who invented this language, they had to consider 
encapsulation many times already, so they should be the very first person who 
gives advice on this particular topic (since nobody answered this topic well 
one comes to conclusion that they are also the only one who can answer it)."

Thank you for your time and patience devoting to my questions.

Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):

I am pretty sure the Julia developers can speak for themselves. A more humble 
approach would suit you well.

RE: [julia-users] Why does julia use END for block end?

[David Anthoff]

See also https://github.com/JuliaLang/julia/issues/6823 

 

From: stefan.karpin...@gmail.com [mailto:stefan.karpin...@gmail.com] On Behalf 
Of Stefan Karpinski
Sent: Friday, May 6, 2016 1:10 PM
To: Julia Users 
Subject: Re: [julia-users] Why does julia use END for block end?

 

I proposed this once upon a time: 
https://github.com/JuliaLang/julia/issues/1657; it wasn't popular. Please don't 
start commenting on that long-dead issue – keep the discussion here instead.

 

On Fri, May 6, 2016 at 4:08 PM, Tom Short mailto:tshort.rli...@gmail.com> > wrote:

You can make a quick macro for one-line if statements:

 

macro when(condition, expr)

esc(:( if $condition; $expr; end))

end

 

@when 4 > pi  x = 2

 

For even more compact syntax, you can replace `when` with `?`.

 

 

 

 

On Fri, May 6, 2016 at 3:12 PM, Adrian Salceanu mailto:adrian.salce...@gmail.com> > wrote:

The only place where I find the "end" requirement annoying is for one line IF 
statements. When you have a short one liner, the "end" part just does not feel 
right. It would be nice if the "end" could be left out for one liners. Even PHP 
allows one to skip the accolades in such cases. 

 

If there's some other way of achieving this I'd love to hear about it. I don't 
like the ternary operator in this situation cause it forces me to add the 3rd 
part as "nothing" or whatever. And doing "expr1 && expr2" only works when expr2 
is "return" for instance, otherwise the compiler complains about using a 
non-boolean in a boolean context. 



vineri, 6 mai 2016, 20:37:49 UTC+2, Stefan Karpinski a scris:

There is a long history of languages using this syntax, including Algol, 
Pascal, Ruby and Matlab.

 

On Fri, May 6, 2016 at 2:26 PM, Ford Ox mailto:ford...@gmail.com> > wrote:

Is there any reasoning behind it? It seems to me like a weird choice since you 
have to type three letters, which is the complete opposite of the goal of this 
language - being very productive (a lot work done with little code).
On top of that, brain has to read the word every time your eyes look at it so 
you spend more time also reading the code - tho this should be easy to omit, by 
highlighting this keyword by other color than other keywords (the current 
purple color in ATOM just drives me crazy, since it is one of the most violent 
colors, so my eyes always try to read that useless piece of information first, 
instead of the important code).

 

 

 

RE: [julia-users] Cloning private package with 0.5

[David Anthoff]

https://github.com/JuliaLang/julia/issues/16041

 

We can continue this discussion there. I think that issue should get a 0.5.0 
label, i.e. this should be treated as a regression that has to be fixed before 
0.5 can be released.

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of David Anthoff
Sent: Monday, April 25, 2016 11:16 AM
To: julia-users@googlegroups.com
Subject: RE: [julia-users] Cloning private package with 0.5

 

That doesn’t work for bitbucket repos, though…

 

From: karbar...@gmail.com <mailto:karbar...@gmail.com>  
[mailto:karbar...@gmail.com] On Behalf Of Jacob Quinn
Sent: Sunday, April 24, 2016 8:49 PM
To: julia-users@googlegroups.com <mailto:julia-users@googlegroups.com> 
Subject: Re: [julia-users] Cloning private package with 0.5

 

Note that it's currently possible to clone private GitHub repos using "personal 
access tokens" from Github. If you go to your profile/settings, you can 
generate private access tokens that allow access to private Github repos and 
then from Julia, you can clone with the following format:

 

Pkg.clone("https://username:to...@github.com/username/private_repo.jl";)

 

On Fri, Apr 22, 2016 at 5:57 PM, Eric Forgy mailto:eric.fo...@gmail.com> > wrote:

I have the same problem (on Windows) and really hoping this gets fixed before 
0.5 is released. I have a ton of private repos.

I'd prefer a solution that lets me keep my remotes at 
g...@github.com:EricForgy/MyPrivateRepo.jl 
<mailto:g...@github.com:EricForgy/MyPrivateRepo.jl> . It would be more than a 
little annoying if I have to change every one to https. Hopefully, Pkg can do 
some magic and make the changes for me if needed.

 

RE: [julia-users] Cloning private package with 0.5

[David Anthoff]

That doesn’t work for bitbucket repos, though…

 

From: karbar...@gmail.com [mailto:karbar...@gmail.com] On Behalf Of Jacob Quinn
Sent: Sunday, April 24, 2016 8:49 PM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Cloning private package with 0.5

 

Note that it's currently possible to clone private GitHub repos using "personal 
access tokens" from Github. If you go to your profile/settings, you can 
generate private access tokens that allow access to private Github repos and 
then from Julia, you can clone with the following format:

 

Pkg.clone("https://username:to...@github.com/username/private_repo.jl";)

 

On Fri, Apr 22, 2016 at 5:57 PM, Eric Forgy mailto:eric.fo...@gmail.com> > wrote:

I have the same problem (on Windows) and really hoping this gets fixed before 
0.5 is released. I have a ton of private repos.

I'd prefer a solution that lets me keep my remotes at 
g...@github.com:EricForgy/MyPrivateRepo.jl 
 . It would be more than a 
little annoying if I have to change every one to https. Hopefully, Pkg can do 
some magic and make the changes for me if needed.

 

RE: [julia-users] Cloning private package with 0.5

[David Anthoff]

None of the suggestions in [1,2] work. They are all based on command line git 
using a credential helper. I have a working credential helper for command line 
git on my system, but Pkg.clone doesn’t seem to know or use that credential 
helper at all. As far as I can tell, libgit2 is not using credential helpers in 
the first place, so that whole route probably doesn’t help.

 

About SSH, is the plan to make those changes to the makefile and include 
libssh2 in the windows binary distribution, so that one can just clone private 
repos via ssh? That would be great!

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Isaiah Norton
Sent: Saturday, April 23, 2016 12:56 PM
To: julia-users@googlegroups.com
Subject: Re: [julia-users] Cloning private package with 0.5

 

I would hope that this is a release blocker issue, given that private package 
repos have been supported forever. 

So right now there seems no way to use them on 0.5 from Windows...

 

https:// should be supported, although I haven't tried it on Windows. See [1,2] 
for configuration details and instructions to avoid password prompts.

 

Regarding ssh, see [3]:

 

building against libssh2 is explicitly disabled by our Makefile.

 

(this line [2])

 

Switching ssh on for windows would require Makefile rules to build and package 
libssh2 along with libgit2 and the rest of the libraries. Note that libssh2 can 
use native windows crypto functionality ("WinCNG" backend), so it should not 
impose any further requirements.

 

[1] 
https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-https-urls-recommended

[2] 
http://stackoverflow.com/questions/13800289/configure-git-clients-like-github-for-windows-to-not-ask-for-authentication/18607931#18607931

[3] https://groups.google.com/d/msg/julia-users/GEwX49wwmdo/CihXC62yCAAJ

[4]  
https://github.com/JuliaLang/julia/blob/c2042326cc5d68db01c0b2e0d12a15f48b03563a/deps/Makefile#L2094

 

 

On Fri, Apr 22, 2016 at 8:30 PM, David Anthoff mailto:anth...@berkeley.edu> > wrote:

Yes, I would hope that this is a release blocker issue, given that private 
package repos have been supported forever. I also have a very large number of 
private repos.

So right now there seems no way to use them on 0.5 from Windows...

I also would prefer to use SSH keys for authentication. If it does have to be 
https, I guess it would be ok if things are integrated with the git credential 
storage infrastructure. What would really be sort of a disaster is if I was 
asked for a username and password every time I do an Pkg.update() or something 
like that...


> -Original Message-
> From: julia-users@googlegroups.com <mailto:julia-users@googlegroups.com>  
> [mailto:julia- <mailto:julia-> 
> us...@googlegroups.com <mailto:us...@googlegroups.com> ] On Behalf Of Eric 
> Forgy
> Sent: Friday, April 22, 2016 4:58 PM
> To: julia-users  <mailto:julia-users@googlegroups.com> >
> Subject: RE: [julia-users] Cloning private package with 0.5
>
> I have the same problem (on Windows) and really hoping this gets fixed
> before 0.5 is released. I have a ton of private repos.
>
> I'd prefer a solution that lets me keep my remotes at
> g...@github.com:EricForgy/MyPrivateRepo.jl 
> <mailto:g...@github.com:EricForgy/MyPrivateRepo.jl> . It would be more than a 
> little
> annoying if I have to change every one to https. Hopefully, Pkg can do some
> magic and make the changes for me if needed.

 

RE: [julia-users] Cloning private package with 0.5

[David Anthoff]

Yes, I would hope that this is a release blocker issue, given that private 
package repos have been supported forever. I also have a very large number of 
private repos.

So right now there seems no way to use them on 0.5 from Windows...

I also would prefer to use SSH keys for authentication. If it does have to be 
https, I guess it would be ok if things are integrated with the git credential 
storage infrastructure. What would really be sort of a disaster is if I was 
asked for a username and password every time I do an Pkg.update() or something 
like that...

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Eric Forgy
> Sent: Friday, April 22, 2016 4:58 PM
> To: julia-users 
> Subject: RE: [julia-users] Cloning private package with 0.5
> 
> I have the same problem (on Windows) and really hoping this gets fixed
> before 0.5 is released. I have a ton of private repos.
> 
> I'd prefer a solution that lets me keep my remotes at
> g...@github.com:EricForgy/MyPrivateRepo.jl. It would be more than a little
> annoying if I have to change every one to https. Hopefully, Pkg can do some
> magic and make the changes for me if needed.

RE: [julia-users] Cloning private package with 0.5

[David Anthoff]

Oh, and I'm on Windows.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On
Behalf Of David Anthoff
Sent: Friday, April 22, 2016 3:35 PM
To: julia-users@googlegroups.com
Subject: [julia-users] Cloning private package with 0.5

 

I'm trying to clone a package that is hosted as a private package on
bitbucket. I'm calling Pkg.clone(url), and have tried both the https and the
ssh variant of the repo URL. Neither one works.

 

When I use the SSH link I get an error "Unsupported URL protocol", when I
use the https variant I get a prompt asking for the username, and once I've
entered that, I get this error:

 

ERROR: ccal: could not find function getpass

 

Is there currently any way to clone private repos with julia 0.5? On julia
0.4 I can use the SSH URL without problems (my SSH keys are all set up
properly).

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

 

[julia-users] Cloning private package with 0.5

[David Anthoff]

I'm trying to clone a package that is hosted as a private package on
bitbucket. I'm calling Pkg.clone(url), and have tried both the https and the
ssh variant of the repo URL. Neither one works.

 

When I use the SSH link I get an error "Unsupported URL protocol", when I
use the https variant I get a prompt asking for the username, and once I've
entered that, I get this error:

 

ERROR: ccal: could not find function getpass

 

Is there currently any way to clone private repos with julia 0.5? On julia
0.4 I can use the SSH URL without problems (my SSH keys are all set up
properly).

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

 

RE: [julia-users] JuliaCon 2016: Keynote speakers

[David Anthoff]

Wow, that is a FANTASTIC lineup, well done!! Cheers, David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Andreas Noack
Sent: Friday, April 8, 2016 6:43 PM
To: julia-users 
Subject: [julia-users] JuliaCon 2016: Keynote speakers

 

JuliaCon 2016
June 21 - 25, 2016
Massachusetts Institute of Technology, Cambridge, Massachusetts, USA.
http://juliacon.org/

On behalf of the JuliaCon 2016 committee, I am happy to announce the following 
keynote speakers:

Timothy E. Holy, Thomas J. Sargent, and Guy L. Steele Jr.

Timothy E. Holy is Associate Professor of Neuroscience at Washington University 
in St. Louis. In 2009 he received the NIH Director’s Pioneer award for 
innovations in optics and microscopy. His research interests include imaging of 
neuronal activity and his lab was probably one of the first to adopt Julia for 
scientific research. He is a long time Julia contributor and a lead developer 
of Julia’s multidimensional array capabilities as well as the author of far too 
many Julia packages.

Thomas J. Sargent is Professor of Economics at New York University and Senior 
Fellow at the Hoover Institution. In 2011 the Royal Swedish Academy of Sciences 
awarded him the Nobel Memorial Prize in Economic Sciences for his work on 
macroeconomics. Together with John Stachurski he founded quant-econ.net, a 
Julia and Python based learning platform for quantitative economics focusing on 
algorithms and numerical methods for studying economic problems as well as 
coding skills.

Guy L. Steele Jr. is a Software Architect for Oracle Labs and Principal 
Investigator of the Programming Language Research project. The Association for 
Computing Machinery awarded him the 1988 Grace Murray Hopper award. He has 
co-designed the programming language Scheme, which has greatly influenced the 
design of Julia, as well as languages such as Fortress and Java.

Andreas Noack
JuliaCon 2016 Local Chair
Postdoctoral Associate
Computer Science and Artificial Intelligence Laboratory
Massachusetts Institute of Technology

RE: [julia-users] Pkg.update() - Version of julia and JuliaParser do not match

[David Anthoff]

You can’t be on master for JuliaParser if you use julia 0.4.x, Keno just sent 
around a message on julia-dev that JuliaParser master is now julia 0.5 only.

 

But if you do Pkg.free(“JuliaParser”) things should just work, in that case the 
package manager should just give you the last version of JuliaParser that still 
works with julia 0.4.x.

 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Aswathi Radhakrishnan
Sent: Friday, April 1, 2016 6:15 AM
To: julia-users 
Subject: [julia-users] Pkg.update() - Version of julia and JuliaParser do not 
match

 

 

Hi,

 

When I do Pkg.update(), I am getting the following error. I am on OS X. I tried 
Pkg.resolve() and many other workaround but it didn't resolve the problem. Has 
anyone encountered this issue?

 

julia> Pkg.update()

INFO: Updating METADATA...

INFO: Updating JuliaParser...

INFO: Computing changes...

WARNING: julia is fixed at 0.4.3 conflicting with requirement for JuliaParser: 
[0.5.0-,∞)

ERROR: AbstractTrees can't be installed because it has no versions that support 
0.4.3 of julia. You may need to update METADATA by running `Pkg.update()`

 in error at error.jl:22

 in resolve at 
/Applications/Julia-0.4.3.app/Contents/Resources/julia/lib/julia/sys.dylib

 in update at 
/Applications/Julia-0.4.3.app/Contents/Resources/julia/lib/julia/sys.dylib

 in anonymous at pkg/dir.jl:31

 in cd at file.jl:22

 in cd at pkg/dir.jl:31

 in update at 
/Applications/Julia-0.4.3.app/Contents/Resources/julia/lib/julia/sys.dylib

RE: [julia-users] Announcing JuDE: autocomplete and jump to definition support for Atom

[David Anthoff]

+1 I’m also much more interested in a simple install story for an existing Atom 
installation than a standalone juno bundle.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tomas Lycken
Sent: Tuesday, March 29, 2016 2:39 PM
To: julia-users 
Subject: Re: [julia-users] Announcing JuDE: autocomplete and jump to definition 
support for Atom

 

It would be nice, though, if it were somewhere documented - or even better, a 
meta-package with dependencies on all the others - to allow turning an already 
existing Atom installation into a Julia IDE too. I'd be much more interested in 
improving an editor I'm already using for other thing, than in installing yet 
another atom-sublime-vscode-like (they all look the same nowadays...) editor 
just to get the Julia goodness.

 

This is, of course and as already noted, definitely not urgent, but I think it 
should be on the road map.

 

// T

On Monday, March 28, 2016 at 10:26:06 PM UTC+2, Jonathan Malmaud wrote:

Mike can step in, but I think it is indeed the plan to have a Julia IDE bundle, 
causing the exact packages required on the julia and atom side to be invisible 
implementation details from the user's POV.

On Monday, March 28, 2016 at 1:27:01 PM UTC-4, David Anthoff wrote:

I think the user experience for almost all people would be much easier if they 
install Atom, then add one package for julia support and everything works. 
Having multiple Atom packages (julia-language, ink, julia-client, 
latex-completion and Jude right now) makes things confusing for most people, 
installation a pain and most people probably won’t even discover all of these 
packages.

 

Maybe another solution to this would be to eventually have one “juno” package 
that automatically installs all the individual useful plugins for Atom that 
make it a good julia IDE. I also don’t think any of this is urgent, right now 
the whole Atom story is so experimental in any case that most likely only a 
small number of people is using it in the first place.

 

From:  <mailto:julia...@googlegroups.com> julia...@googlegroups.com [ 
<mailto:julia...@googlegroups.com> mailto:julia...@googlegroups.com] On Behalf 
Of James Dang
Sent: Sunday, March 27, 2016 4:57 AM
To: julia-users < <mailto:julia...@googlegroups.com> julia...@googlegroups.com>
Subject: Re: [julia-users] Announcing JuDE: autocomplete and jump to definition 
support for Atom

 

Hi David, I think Jude's functionality is pretty orthogonal to julia-client so 
they function pretty well as distinct, easier to manage packages. julia-client 
is focused on live code execution and results visualization while Jude is more 
about getting traditional IDE tools via static syntax analysis. Why do you 
think they should merge?

RE: [julia-users] Announcing JuDE: autocomplete and jump to definition support for Atom

[David Anthoff]

I think the user experience for almost all people would be much easier if they 
install Atom, then add one package for julia support and everything works. 
Having multiple Atom packages (julia-language, ink, julia-client, 
latex-completion and Jude right now) makes things confusing for most people, 
installation a pain and most people probably won’t even discover all of these 
packages.

 

Maybe another solution to this would be to eventually have one “juno” package 
that automatically installs all the individual useful plugins for Atom that 
make it a good julia IDE. I also don’t think any of this is urgent, right now 
the whole Atom story is so experimental in any case that most likely only a 
small number of people is using it in the first place.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of James Dang
Sent: Sunday, March 27, 2016 4:57 AM
To: julia-users 
Subject: Re: [julia-users] Announcing JuDE: autocomplete and jump to definition 
support for Atom

 

Hi David, I think Jude's functionality is pretty orthogonal to julia-client so 
they function pretty well as distinct, easier to manage packages. julia-client 
is focused on live code execution and results visualization while Jude is more 
about getting traditional IDE tools via static syntax analysis. Why do you 
think they should merge?

RE: [julia-users] Determine the module where a type is declared

[David Anthoff]

Perfect, thanks!

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Yichao Yu
> Sent: Friday, March 25, 2016 12:19 PM
> To: Julia Users 
> Subject: Re: [julia-users] Determine the module where a type is declared
> 
> On Fri, Mar 25, 2016 at 3:00 PM, David Anthoff 
> wrote:
> > Hi,
> >
> >
> >
> > I’m looking for a function that gives me back the module where a given
> > type is declared. For example, if I call something like
> >
> >
> >
> > type_module(Float64)
> 
> Not an official API but `Float64.name.module`
> 
> >
> >
> >
> > I’d like the function type_module to return the module where Float64
> > is defined. Essentially, I’m just looking for the equivalent of
> > function_module, but for types instead of functions.
> >
> >
> >
> > Does such a function exist?
> >
> >
> >
> > Thanks,
> >
> > David
> >
> >
> >
> > --
> >
> > David Anthoff
> >
> > University of California, Berkeley
> >
> >
> >
> > http://www.david-anthoff.com
> >
> >

[julia-users] Determine the module where a type is declared

[David Anthoff]

Hi,

 

I'm looking for a function that gives me back the module where a given type
is declared. For example, if I call something like

 

type_module(Float64)

 

I'd like the function type_module to return the module where Float64 is
defined. Essentially, I'm just looking for the equivalent of
function_module, but for types instead of functions.

 

Does such a function exist?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Announcing JuDE: autocomplete and jump to definition support for Atom

[David Anthoff]

Very nice!

 

Any chance that this could just become part of julia-client at some point?

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of James Dang
Sent: Sunday, March 20, 2016 11:58 AM
To: julia-users 
Subject: [julia-users] Announcing JuDE: autocomplete and jump to definition 
support for Atom

 

Hi All, Julia has been great for me, and I wanted to give back a little. 
LightTable and Atom are great editors, but I was really starting to miss good 
intellisense-like autocomplete and basic navigation features like 
jump-to-definition, especially on larger codebases. It's really quite a slog to 
remember exactly where in which file a function was defined, or what its exact 
arguments are. And maybe with better tooling, more people will be drawn to the 
community. So I put a bit of work into a new package for Atom that gives you 
that!

https://atom.io/packages/jude

  



This is a bit different from what you get out of julia-client and 
autocomplete-julia because it does a full syntax parsing and scope resolution 
of your codebase without executing it in a Julia process. It reparses very 
quickly on the fly without needing to save. And the matching is precise, not 
fuzzy, giving you exactly what names are available in the scope you are in 
currently. It's quite new and unpolished, but please try it out and let me know 
what you think!

Cheers,
James

RE: [julia-users] Re: What to read to understand finishing v0.5?

[David Anthoff]

At some point in the summer there was communication from the core team that 
v0.5 would be a short release cycle that was all about the arraypocalypse 
theme. My sense is that this original plan is off the table, and that (as John 
said) there is no new time plan to replace the original one, or at least none 
has been communicated from the core at this point. Take this info with a grain 
of salt, I’m largely reading tea-leaves here :)

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of John Myles White
Sent: Wednesday, March 9, 2016 10:17 AM
To: julia-users 
Subject: [julia-users] Re: What to read to understand finishing v0.5?

 

I think it's fair to say that the reason your questions aren't already answered 
by GitHub is because there's no one who's made an executive decision about the 
answers to those questions.

 

 -- John

On Wednesday, March 9, 2016 at 4:44:28 AM UTC-8, Andreas Lobinger wrote:

Hello colleagues,

i need a bigger picture of the status of v0.5, dates, timelines, missing 
features, missing testing, expected closing. Just go to github and select the 
v0.5 milestone gives me a diverse picture.

Wishing ahappy day,
Andreas

RE: [julia-users] load a Julia dataframe from Microsoft SQL Server table

[David Anthoff]

https://msdn.microsoft.com/en-us/library/ms716246%28v=vs.85%29.aspx?f=255 

 &MSPPError=-2147217396

 

suggests that if you call the version without the A or W suffix you get the 
ANSI version. 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Scott Jones
Sent: Thursday, February 4, 2016 1:55 PM
To: julia-users 
Subject: Re: [julia-users] load a Julia dataframe from Microsoft SQL Server 
table

 



On Thursday, February 4, 2016 at 4:29:46 PM UTC-5, Stefan Karpinski wrote:

On Thu, Feb 4, 2016 at 1:50 PM, Scott Jones  > wrote:

 

This still doesn't explain why some drivers are accepting UCS-2/UTF-16 when 
called with the non-Unicode API.

 

When you do so, are you actually calling the functions with the A, or just the 
macro without either A or W?

The macro will compile to either the A or the W form, depending on how your 
application is built.

 

This is a better page in MSDN: 
https://msdn.microsoft.com/en-us/library/ms712612(v=vs.85).aspx describing what 
is going on.

 

The ODBC package calls the functions without A or W. What it's calling can't be 
a macro since macros aren't callable via ccall. But changing ODBC to call the W 
version of everything may be the fix here.

 

That very well may be the solution: looking for example at libiodbc on the Mac, 
it has 3 different versions of all those functions, and I'm not sure just what 
behavior you get when using the form without the A or W.  I've always used ODBC 
with the C headers, unlike the direct linking that Julia is doing, so that it 
always gets the W version since I compile as a Unicode build. 

[julia-users] method to determine return type of a method

[David Anthoff]

Hi,

 

is there a method that I can pass a function f and a type signature to and
it returns the return type I can expect from calling f with the given types?
I.e. something like

 

code_returntype(f, (Int64, Float64))

 

and then it would return the type that f would return if called with an
Int64 and Float64. The return type could of course be a union of many types
if the function is not typestable.

 

Thanks,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Juno IDE

[David Anthoff]

Ha, excellent, I had completely missed that plotting support for Gadfly is 
there already!

 

I really appreciate how nicely the whole Juno thing is coming along, thanks to 
all the contributors of that fantastic effort!

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Mike Innes
Sent: Tuesday, February 2, 2016 10:22 AM
To: julia-users 
Subject: Re: [julia-users] Juno IDE

 

Currently we do support Gadfly, it's not too hard to add others (although right 
now I'm focused on getting the foundations really right rather than display of 
specific types). Are you using Images.jl?

 

On Tue, 2 Feb 2016 at 18:19 Sisyphuss mailto:zhengwend...@gmail.com> > wrote:

The multimedia support, specifically, the image support is the only remaining 
issue that hold me back from Atom.

 

4) We want to support different workflows as well as we can. The Atom work 
includes a repl which is going to get a lot nicer over the next couple weeks. 
If there are any other obvious missing features, you're welcome to mention them.

 

RE: [julia-users] Re: Julia Benchmarks Feedback

[David Anthoff]

+1

 

These benchmarks seem to test the performance of specific algorithms, 
implemented in different languages. Including start up or compile time doesn’t 
make any sense to me in that case.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Stefan Karpinski
Sent: Wednesday, January 27, 2016 2:39 PM
To: Julia Users 
Subject: Re: [julia-users] Re: Julia Benchmarks Feedback

 

It's true. However interpreters don't take much time to start up – an 
interpreter is the lowest latency way to get from source code to running 
program (compared to AOT or JIT compilation). There's an argument to be made 
for including all of the things that take time when benchmarking. However, we 
don't time benchmarks because we're interested in how fast language 
implementations can run the benchmarks – we're trying to get some sense of how 
fast they'll run real programs. And if you care about speed, you probably have 
a program that's going to take a non-trivial amount of time to run – which 
means that runtime startup and JIT are going to become negligible. But we don't 
really want benchmarks that run for minutes. So instead we eliminate fixed 
overheads like runtime startup and JIT time when measuring benchmarks – not 
because they doesn't happen, but because they're a fixed cost that ends up 
being insignificant for real life programs. The only scenario where I can 
imagine really caring about runtime startup and JIT is if you were evaluation 
how good a language implementation is for running short-lived command-line 
programs. Then it would absolutely make sense to measure runtime startup and 
JIT. But I don't think that's what these benchmarks are trying to measure.

 

On Wed, Jan 27, 2016 at 4:48 PM, Ismael Venegas Castelló 
mailto:ismael.vc1...@gmail.com> > wrote:

but then again the benchmarks are flawed because other implementations are also 
timing the interpreters startup time.



El martes, 26 de enero de 2016, 22:07:54 (UTC-6), George escribió:

I was surprised to se the results on the following benchmarks:

  https://github.com/kostya/benchmarks

 


Some benchmarks of different languages


Brainfuck


  Brainfuck


bench.b


Language

Time,s

Memory, Mb


Nim Clang

3.21

0.7


Felix

4.07

1.3


Nim Gcc

4.52

0.6


Java

4.94

147.6


C++

5.08

1.1


Rust

5.46

4.9


Scala

5.90

116.3


D

6.57

1.0


D Ldc

6.61

0.9


Crystal

6.97

1.3


Go

7.29

1.3


Javascript Node

8.74

15.0


D Gdc

8.87

1.0


Julia

9.25

59.0


Javascript V8

9.41

8.1


Go Gcc

13.60

10.0


Python Pypy

13.94

55.4


Javascript Jx

17.14

11.0


C# Mono

18.08

15.4


OOC

48.86

1.3


Ruby JRuby

87.05

124.1


Ruby Topaz

112.91

36.0


Ruby JRuby9K

160.15

297.2


Ruby

226.86

8.0


Tcl

262.20

2.7


Python

452.44

4.9


Ruby Rbx

472.08

45.0


Python3

480.78

5.5


mandel.b


  Mandel 
in Brainfuck


Language

Time,s

Memory, Mb


Nim Clang

28.96

1.0


Felix

40.06

3.7


D Ldc

43.30

0.9


D

45.29

1.2


Rust

46.34

4.9


Crystal

48.62

1.3


Nim Gcc

50.45

0.9


Go

52.56

7.6


Java

55.14

69.9


Cpp

56.63

1.1


Scala

64.37

126.4


D Gdc

70.12

1.5


Go Gcc

85.67

10.7


Javascript Node

92.65

15.8


Julia

94.33

56.9



...

 

[julia-users] RTVS

[David Anthoff]

Microsoft is going to release an open source plug-in for Visual Studio that
turns it into an R environment:

 

https://www.youtube.com/watch?v=Y1_0XN-p3Hs

 

This is in addition to their existing (excellent) python plugin for VS.
Would be great if we could somehow convince them to add julia support as
well!

 

Cheers,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Moore foundation grant.

[David Anthoff]

You mean Julia Computing is working on an Eclipse solution? How does that match 
with the efforts around Atom to create an IDE that are also ongoing? It would 
be nice to see efforts and resources concentrated on a single IDE solution, in 
the hope of getting something that is really polished some day... 

> -Original Message-
> From: julia-users@googlegroups.com [mailto:julia-
> us...@googlegroups.com] On Behalf Of Viral Shah
> Sent: Wednesday, December 30, 2015 11:00 PM
> To: julia-users@googlegroups.com
> Subject: Re: [julia-users] Moore foundation grant.
> 
> 
> The Eclipse Foundation doesn’t have funding, it turns out. However, we at
> Julia Computing just started on an effort recently, and hope to have
> something to show as soon as we have something minimal working.
> 
> -viral
> 
> 
> > On 31-Dec-2015, at 6:37 AM, Oleg Mikulchenko 
> wrote:
> >
> > 1. Congratulations!
> > 2. Having a good Eclipse plugin for Julia is the dream for many potential
> users, just like me. Looking forward to hear some good news on that !
> >
> > On Wednesday, November 11, 2015 at 11:12:16 PM UTC-8, Viral Shah
> wrote:
> >
> > Independently, we are also discussing with the Eclipse Foundation to see
> how we can work with their scientific community and have a good Eclipse
> plugin for Julia.
> >

RE: [julia-users] Re: DataFrame melt question

[David Anthoff]

Thanks!

 

That works, but it seems a bit hacky, and the case I’m describing seems common 
enough to me that it should be possible to do in some easy way.

 

I opened an issue over at DataFrames, not really with an idea on how to solve 
this, but maybe someone else has a good idea how this could be made easier in 
the standard DataFrame implementation.

 

https://github.com/JuliaStats/DataFrames.jl/issues/899

 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Dan
Sent: Wednesday, December 16, 2015 12:42 AM
To: julia-users 
Subject: [julia-users] Re: DataFrame melt question

 

the following re-reads the header and generates a dictionary which assigns the 
original column name to the converted one, in a one-liner-ish:

 

df = readtable("/the/file.csv")

 

h = Dict(zip(keys(df.colindex.lookup),split(open("/tmp/file.csv") do f 
chomp(readline(f)) ; end,",")[collect(values(df.colindex.lookup))]))

 

now aside from using `h` in other ways, you can do:

 

melteddf[:Region] = [h[r] for r in melteddf[:Region]]

 

to fix the `melteddf`.

On Wednesday, December 16, 2015 at 2:39:57 AM UTC+2, David Anthoff wrote:

Hi,

 

I have a csv file that roughly looks like this:

 

 

Year,Name of country 1, Name of country 2

1950, 5., 6.

1951, 6., 8.

 

The real file has more columns and rows.

 

I want to bring this into tidy format, so that I have a DataFrame that looks 
like this:

 

Year, Region, Value

1950, Name of country 1, 5.

1950, Name of country 2, 6.

1951, Name of country 1, 6.

1951, Name of country 2, 8.

 

Right now I read the file with readtable into a DataFrame and then use

 

melt(df, :Year)

 

This gives me the right structure, but now all the country names are messed up, 
e.g. they look like “Name_of_country_1” instead of “Name of country 1”.

 

I understand why that is the case, i.e. readtable converts strings into symbols 
and has to insert these underscores, but I’m wondering whether the original 
string value is preserved somewhere, and could be used in the melt operation in 
some way?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] DataFrame melt question

[David Anthoff]

Hi,

 

I have a csv file that roughly looks like this:

 

 

Year,Name of country 1, Name of country 2

1950, 5., 6.

1951, 6., 8.

 

The real file has more columns and rows.

 

I want to bring this into tidy format, so that I have a DataFrame that looks
like this:

 

Year, Region, Value

1950, Name of country 1, 5.

1950, Name of country 2, 6.

1951, Name of country 1, 6.

1951, Name of country 2, 8.

 

Right now I read the file with readtable into a DataFrame and then use

 

melt(df, :Year)

 

This gives me the right structure, but now all the country names are messed
up, e.g. they look like "Name_of_country_1" instead of "Name of country 1".

 

I understand why that is the case, i.e. readtable converts strings into
symbols and has to insert these underscores, but I'm wondering whether the
original string value is preserved somewhere, and could be used in the melt
operation in some way?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

RE: [julia-users] Re: ANN: DSGE.jl

[David Anthoff]

I don’t think that the package should be registered as DSGE, though. DSGE is a 
type of model, and there are lots and lots of those around. The repo from the 
NY Fed is their specific DSGE model, it is one example of a DSGE model. I think 
a package that in general provided methods to solve DSGE models, or define them 
etc. might be registered as DSGE, but not this specific model. But even for 
such a general package, I’m not sure it should be named DSGE: there are lots of 
different solution methods for DSGE models, and I think different packages 
might try different implementations (the situation might be a little bit like 
the various MCMC packages floating around). In those cases it is not clear to 
me that one of these packages should be allowed to “own” the official name… 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Thursday, December 3, 2015 6:17 PM
To: julia-users 
Subject: [julia-users] Re: ANN: DSGE.jl

 

DSGE is against the usual naming guidelines of trying to avoid acronyms, but at 
least this one is unambiguously googlable with one dominant result. I'd never 
heard of it as a non-economist, but given this is a big project from a major 
institution we can perhaps make an exception to the usual guidelines.



On Thursday, December 3, 2015 at 1:20:51 PM UTC-8, Patrick Kofod Mogensen wrote:

Fellow economist here, great stuff! I'm curious to see what choices were made, 
and how it compares to other DSGE toolboxes and tools out there.

Is it going to be registered in METADATA? If so, would a name like DSGE be 
"allowed"?

On Thursday, December 3, 2015 at 3:05:57 PM UTC+1, Spencer Lyon wrote:

The Federal Reserve bank of New York has finished moving their fairly large 
DSGE model from Matlab to Julia. This model is used inside the Fed for 
forecasting and policy analysis. 

 

As part of the move to Julia, the code base has been open sourced.

 

A blog post announcing the release is here: 
http://libertystreeteconomics.newyorkfed.org/2015/12/the-frbny-dsge-model-meets-julia.html

 

And the repository can be found here: https://github.com/FRBNY-DSGE/DSGE.jl