Re: [julia-users] what is "type piracy"?

[Mike Innes]

Another way to look at this is, redefining a module shouldn't result in 
method redefinition warnings.

On Thursday, 3 November 2016 17:24:28 UTC, Spencer Russell wrote:
>
> As far as I know "type piracy" is not a widespread term in CS, but has 
> popped up in the Julia community. 
>
> Basically it refers to violations of the Julia guideline that a package 
> shouldn't define methods of functions it doesn't own on types it doesn't 
> own. 
>
> For example, if package A exports a function `foo`, and package B 
> defines a type `Bar`, package C shouldn't define `foo(x::Bar)`. It's in 
> some ways stealing functionality that other packages should be 
> responsible for, and from a user's perspective it can be confusing if 
> `using C` changes behavior that's associated with completely different 
> packages. 
>
> -s 
>
> On Thu, Nov 3, 2016, at 11:44 AM, Tamas Papp wrote: 
> > What does the term "type piracy" mean? 
> > 
> > The term shows up in julia-related discussions, mostly on 
> > Github. Googling for it leads back these discussions, and a lot of 
> > unrelated stuff about copyright and/or typefaces. 
> > 
> > (Apologies if the term is well-known, I am an economist, not a computer 
> > scientist). 
>

Re: [julia-users] Gadfly plots no longer showing in Juno

[Mike Innes]

Try Pkg.checkout("Gadfly"). We recently moved the integration code from
Atom to Gadfly, but I guess Gadfly hasn't been tagged yet.

On Tue, 4 Oct 2016 at 19:14 James Noeckel  wrote:

> With the latest update, it seems that display(::Gadfly.Plot) no longer
> opens a plot tab in the Atom editor. Instead, it prints the contents of the
> plot object in the console. Gadfly is Juno's preferred plotting
> environment, but I don't know if this is an issue with Gadfly.jl or
> Atom.jl. Can anybody figure out a workaround?
>

Re: [julia-users] Debuging with Juno

[Mike Innes]

We have some patches for recent changes to Gallium.jl which are very soon
to be tagged, so this will all work very soon.

On Fri, 16 Sep 2016, 13:29 Tsur Herman,  wrote:

> did any one managed to get that working?
>
> I am getting an error Base.active_repl not defined .
> However debugging somewhat works in julia shell .
>
> I personally think that the ability to comfortably step into functions,
> including what is considered system packages is crucial
> for the language to take off.
>
> So does anyone have any clue as to why is this happening?
>
>

Re: [julia-users] Re: Please Help.. Unable to get Input in Juno IDE

[Mike Innes]

Ah great, that explains it then. Glad to help, at feel free to let us know
if you have any other questions on the forum!

On Tue, 16 Aug 2016 at 14:13 Rishabh Raghunath 
wrote:

> Ok.. Got it !! .. Thanks a lot Mike !!. I used to use input() and that
> explains why It worked before. 👍
>
> On Tue, Aug 16, 2016 at 6:36 PM, Mike Innes 
> wrote:
>
>> Also, just for future reference, people with Juno knowledge tend to be
>> more active over here: http://discuss.junolab.org/
>>
>> I recommend posting there for faster / more reliable responses.
>>
>>
>> On Tuesday, 16 August 2016 14:02:33 UTC+1, Mike Innes wrote:
>>>
>>> I don't think this ever worked in Juno in the form you're showing. You
>>> can send input to Julia via STDIN but you have to do so explicitly; select
>>> some text in an editor and run the `Julia Client: Send to Stdin` command.
>>>
>>> A smarter way to do this is
>>>
>>> ```
>>> using Atom
>>> foo = input()
>>> ```
>>>
>>> This will show an input cell in the console and return the result when
>>> the user presses enter; in other words you can use it to replace `readline`.
>>>
>>> On Tuesday, 16 August 2016 06:52:37 UTC+1, Rishabh Raghunath wrote:
>>>>
>>>> I'm Sorry .. But I don't quite understand what you are saying.. My
>>>> problem is that I am unable to type in an input in the Juno console like I
>>>> could before.. It simply does not give me a place to write in my input to
>>>> the julia program via the console.. This is a new problem I am experiencing
>>>> and was not there before..
>>>>
>>>> On Monday, August 15, 2016 at 11:26:13 AM UTC+5:30, Rishabh Raghunath
>>>> wrote:
>>>>>
>>>>> Hello Julia Users..
>>>>> I have been experiencing a new problem with juno ide..
>>>>> I am not able to get input in Juno with readline(STDIN).. It never
>>>>> accepts any input.. just remains stuck..
>>>>> All the print statements work just fine.. But the inputs arent
>>>>> working..
>>>>> Input using the same code used to work in Juno.. But suddenly .. Juno
>>>>> is not getting inputs..
>>>>> The code works perfectly fine while I try to run it in the terminal.
>>>>> Please guide me how to fix this problem..
>>>>> I have attached a Screenshot below.. you can see my print
>>>>> statements(which work perfectly fine as shown in the screenshot.. But the
>>>>> readline(STDIN) does not get input in Juno.. It keeps loading..
>>>>> Thanks.
>>>>>
>>>>
>

[julia-users] Re: Please Help.. Unable to get Input in Juno IDE

[Mike Innes]

Also, just for future reference, people with Juno knowledge tend to be more 
active over here: http://discuss.junolab.org/

I recommend posting there for faster / more reliable responses.

On Tuesday, 16 August 2016 14:02:33 UTC+1, Mike Innes wrote:
>
> I don't think this ever worked in Juno in the form you're showing. You can 
> send input to Julia via STDIN but you have to do so explicitly; select some 
> text in an editor and run the `Julia Client: Send to Stdin` command.
>
> A smarter way to do this is
>
> ```
> using Atom
> foo = input()
> ```
>
> This will show an input cell in the console and return the result when the 
> user presses enter; in other words you can use it to replace `readline`.
>
> On Tuesday, 16 August 2016 06:52:37 UTC+1, Rishabh Raghunath wrote:
>>
>> I'm Sorry .. But I don't quite understand what you are saying.. My 
>> problem is that I am unable to type in an input in the Juno console like I 
>> could before.. It simply does not give me a place to write in my input to 
>> the julia program via the console.. This is a new problem I am experiencing 
>> and was not there before.. 
>>
>> On Monday, August 15, 2016 at 11:26:13 AM UTC+5:30, Rishabh Raghunath 
>> wrote:
>>>
>>> Hello Julia Users..
>>> I have been experiencing a new problem with juno ide..
>>> I am not able to get input in Juno with readline(STDIN).. It never 
>>> accepts any input.. just remains stuck..
>>> All the print statements work just fine.. But the inputs arent working..
>>> Input using the same code used to work in Juno.. But suddenly .. Juno is 
>>> not getting inputs..
>>> The code works perfectly fine while I try to run it in the terminal.
>>> Please guide me how to fix this problem..
>>> I have attached a Screenshot below.. you can see my print 
>>> statements(which work perfectly fine as shown in the screenshot.. But the 
>>> readline(STDIN) does not get input in Juno.. It keeps loading.. 
>>> Thanks.
>>>
>>

[julia-users] Re: Please Help.. Unable to get Input in Juno IDE

[Mike Innes]

I don't think this ever worked in Juno in the form you're showing. You can 
send input to Julia via STDIN but you have to do so explicitly; select some 
text in an editor and run the `Julia Client: Send to Stdin` command.

A smarter way to do this is

```
using Atom
foo = input()
```

This will show an input cell in the console and return the result when the 
user presses enter; in other words you can use it to replace `readline`.

On Tuesday, 16 August 2016 06:52:37 UTC+1, Rishabh Raghunath wrote:
>
> I'm Sorry .. But I don't quite understand what you are saying.. My problem 
> is that I am unable to type in an input in the Juno console like I could 
> before.. It simply does not give me a place to write in my input to the 
> julia program via the console.. This is a new problem I am experiencing and 
> was not there before.. 
>
> On Monday, August 15, 2016 at 11:26:13 AM UTC+5:30, Rishabh Raghunath 
> wrote:
>>
>> Hello Julia Users..
>> I have been experiencing a new problem with juno ide..
>> I am not able to get input in Juno with readline(STDIN).. It never 
>> accepts any input.. just remains stuck..
>> All the print statements work just fine.. But the inputs arent working..
>> Input using the same code used to work in Juno.. But suddenly .. Juno is 
>> not getting inputs..
>> The code works perfectly fine while I try to run it in the terminal.
>> Please guide me how to fix this problem..
>> I have attached a Screenshot below.. you can see my print 
>> statements(which work perfectly fine as shown in the screenshot.. But the 
>> readline(STDIN) does not get input in Juno.. It keeps loading.. 
>> Thanks.
>>
>

Re: [julia-users] ERROR: Gallium can't be installed because it has no versions that support 0.4.6 of julia.

[Mike Innes]

Can you show me your Pkg.status()?

On Wed, 29 Jun 2016 at 15:40 Lior Horesh  wrote:

> Dear Mike,
>
> No, this is a fresh installation on a new machine.
>
> L
>
>
> On Wednesday, June 29, 2016 at 2:45:03 PM UTC-4, Stefan Karpinski wrote:
>
>> Did you previously install Gallium? Mike, does Atom depend on Gallium
>> these days?
>>
>
>> On Wed, Jun 29, 2016 at 2:29 PM, Lior Horesh  wrote:
>>
>>> hi friends,
>>>
>>> I have tried to add the Atom package in Julia 'Pkg.add("Atom")', but
>>> faced the following error message.
>>>
>>> '
>>> julia> Pkg.add("Atom")
>>> ERROR: Gallium can't be installed because it has no versions that
>>> support 0.4.6 of julia. You may need to update METADATA by running
>>> `Pkg.update()`
>>>  in error at error.jl:22
>>>  in sync_end at task.jl:413
>>>  [inlined code] from task.jl:422
>>>  in add at pkg/entry.jl:64
>>>  in add at pkg/entry.jl:73
>>>  in anonymous at pkg/dir.jl:31
>>>  in cd at file.jl:32
>>>  in cd at pkg/dir.jl:31
>>>  in add at pkg.jl:23
>>>
>>> julia> Pkg.update()
>>> INFO: Updating METADATA...
>>> INFO: Updating Atom...
>>> INFO: Computing changes...
>>> ERROR: Gallium can't be installed because it has no versions that
>>> support 0.4.6 of julia. You may need to update METADATA by running
>>> `Pkg.update()`
>>>  in error at error.jl:22
>>> '
>>>
>>> Any suggestions ?
>>>
>>> L
>>>
>>
>>

Re: [julia-users] ERROR: Gallium can't be installed because it has no versions that support 0.4.6 of julia.

[Mike Innes]

The master branch of Atom does depend on Gallium, which is 0.5-only. On 0.4
you should run `Pkg.free("Atom")` to go back to the latest 0.4-compatible
version.

On Wed, 29 Jun 2016 at 14:44 Stefan Karpinski  wrote:

> Did you previously install Gallium? Mike, does Atom depend on Gallium
> these days?
>
> On Wed, Jun 29, 2016 at 2:29 PM, Lior Horesh 
> wrote:
>
>> hi friends,
>>
>> I have tried to add the Atom package in Julia 'Pkg.add("Atom")', but
>> faced the following error message.
>>
>> '
>> julia> Pkg.add("Atom")
>> ERROR: Gallium can't be installed because it has no versions that support
>> 0.4.6 of julia. You may need to update METADATA by running `Pkg.update()`
>>  in error at error.jl:22
>>  in sync_end at task.jl:413
>>  [inlined code] from task.jl:422
>>  in add at pkg/entry.jl:64
>>  in add at pkg/entry.jl:73
>>  in anonymous at pkg/dir.jl:31
>>  in cd at file.jl:32
>>  in cd at pkg/dir.jl:31
>>  in add at pkg.jl:23
>>
>> julia> Pkg.update()
>> INFO: Updating METADATA...
>> INFO: Updating Atom...
>> INFO: Computing changes...
>> ERROR: Gallium can't be installed because it has no versions that support
>> 0.4.6 of julia. You may need to update METADATA by running `Pkg.update()`
>>  in error at error.jl:22
>> '
>>
>> Any suggestions ?
>>
>> L
>>
>
>

Re: [julia-users] Regarding GSoC 2017

[Mike Innes]

Most likely the set of possible projects will be very similar next year –
at most only a few will be completed by students this year, although there
could be some additions as well. What sort of areas are you interested in?
Preparing early is a great idea and it'd be good to get you contributing to
relevant packages.

On Tue, 29 Mar 2016 at 21:48 Ayush Pandey  wrote:

> Hi Vishesh,
> It would be best for you to start contributing to one of the many packages
> that are available in Julia (List ). Make
> yourself comfortable with the syntax, try to understand the source code and
> contribute patches if possible.
>
> You can always have a look at this year GSoc projects here
> . You can propose your own GSoc
> project idea next year if you have any in your mind.
>
> *Yours Sincerely,*
> *Ayush Pandey* * *
> *LinkedIn Profile *
> *GitHub *
>
> On Tue, Mar 29, 2016 at 7:54 PM,  wrote:
>
>> Hello,
>> I am a first year student pursuing computer science at IIT Jodhpur and I
>> am really looking forward to apply in GSoC 2017. For this, I would
>> appreciate if any mentor could inform me about the projects that I should
>> expect the next year so that I can start preparing for them from now.
>>
>> Thank You.
>>
>
>

[julia-users] GSoC Application Deadline Approaching

[Mike Innes]

Hey All,

The GSoC application deadline is approaching and submissions will close in
just over 24 hours. Thanks to all who have submitted draft proposals so far
– I highly recommend getting a "final" PDF proposal in as soon as possible
and well before the deadline. Before the deadline you can also re-submit
the PDF as many times as you like, but you *must* submit one by tomorrow at
19:00 UTC or we won't be able to consider your project.

As always, let us know at julia...@googlegroups.com if you have questions.
I'll try my best to look over the proposals, drafts and emails that we have
and give feedback tomorrow morning, but it's best not to rely on that at
this stage. Don't be too worried about the specific details of projects,
which can always be finalised or tweaked later – above all, we'd like to
see that thought and effort has gone in, and if you've done that then it'll
show.

Good Luck!
Mike

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

[Mike Innes]

This is very cool! RE the path, perhaps it could make sense for Jude to
check for the `julia-client.juliaPath` before defaulting to `julia`? I'm
also hoping that julia-client can expose some kind of API eventually so
that people can build whatever custom interactions they want.

Autocomplete in the console is definitely an issue, but there's actually a
set of PRs to Atom and autocomplete-plus that will help us fix this. In
future, there's no reason not to expect both julia-client and Jude
autocompletions to be available there.

On Tue, 22 Mar 2016 at 05:17 James Dang  wrote:

> Hi Evan, no, the console is controlled by Juno (or "julia-client" in
> Atom), and Jude can't hook into that. Besides, Jude is complementary and
> distinct from what Juno provides. Jude does auto-complete within scopes, so
> you can get autocomplete in the middle of a function body you are editing,
> which might be nested deep in a module which is imported into your main
> script. Juno does auto-complete just on your main script, ie at global
> scope, just like a Julia REPL. It's probably possible for Juno to
> eventually hook its own auto-completes into the console. It's just not as
> easy because then it can't use Atom's Autocomplete+ package.
>
> Instead, you could type your code directly into your source file,
> leveraging Jude's autocomplete there. Then once you're done typing the
> line, you could type Ctrl-Enter to execute it via Juno. When I use Juno, I
> rarely have to type directly into the console. I usually just edit a script
> file and run the lines individually.
>
>
>

Re: [julia-users] Wrong description of a GSoC project on idea page.

[Mike Innes]

Yup, it will be exactly the same process, just at the website repo
<https://github.com/JuliaLang/julialang.github.com> – I think you can even
make the change through Github directly.

On Sat, 19 Mar 2016 at 19:24 Sarvjeet singh ghotra 
wrote:

> Thanks Mike.
>
> Not first PR, I have made some PRs before while fixing JuliaLang issues.
> Is PR process for this error same, like make a PR on Julia Github page?
>
> Cheers.
>
> On Sun, Mar 20, 2016 at 12:11 AM, Mike Innes 
> wrote:
>
>> You're right that there's a typo in the Mux project, but perhaps this is
>> a good opportunity to submit your first PR? Happy to give tips on the
>> process if you want.
>>
>> It's good to see that there's some work on cookie and session handling,
>> although as far as I know this isn't at all integrated with Mux.jl – so you
>> can't, for example, put in a middlewhere that takes cookies out into a
>> dictionary or something – that would be nice to have. As I've mentioned, a
>> great project plan would be getting everything integrated with Mux and
>> polished so that setting up a simple website is very easy.
>>
>> Other than that, I think I would follow Jock's advice and check out what
>> features web frameworks in Go, Clojure, Ruby or Python have that we don't.
>> Putting together a small web app yourself would probably be the quickest
>> way to find out what's missing.
>>
>> On Sat, 19 Mar 2016 at 10:19 Sarvjeet singh ghotra <
>> sssarvjee...@gmail.com> wrote:
>>
>>> In the description of GSoC project Middlewares for common web
>>> application chores in Mux.jl
>>> <http://julialang.org/soc/ideas-page#middlewares-for-common-web-application-chores-in-muxjl>
>>>  project the subsection Expected Result is wrong. Someone please
>>> correct that.
>>>
>>> One more thing, while discussing this project with Jock Lawire I came to
>>> know that most of the routines that are expected to be implemented like
>>> routing, cookie/session handling, authentication in Mux.jl are either
>>> already done or half finished. So I want to know what other features are
>>> required.
>>>
>>> Of the mid-level features mentioned in the project description, routing
>>>> is done (Mux.jl), cookie/session handling is partly done
>>>> (SecureSessions.jl), and authentication is partly done (SecureSessions.jl).
>>>> Load balancing is not done. Whether this is a priority depends if users
>>>> want to write heavy-traffic apps that are insecure, or moderate-traffic
>>>> apps that are secure.
>>>
>>>
>>>  -Jock
>>>
>>> Question to JuliaWeb Members: Are you following any other framework for
>>> reference while working on Middleware related features? So that I can also
>>> look at the same framework for consistency purpose.
>>>
>>>
>

Re: [julia-users] ANN: NetworkViz.jl - Julia module for graph visualization

[Mike Innes]

This looks promising so far. With things like plotting, wrapping web-based
libraries has turned out to work very nicely; what's your take on wrapping
something like Cytoscape instead of starting from scratch, in terms of pros
and cons?

On Thu, 17 Mar 2016 at 13:17 Abhijith Anilkumar 
wrote:

> Hi,
>
> I'm happy to announce the first registered version of NetworkViz.jl
> , a julia interface
> to visualize graphs using ThreeJS.jl
>  and Escher.jl
> . The package is tightly coupled
> with LightGraphs.jl . It
> uses Escher.jl to interactively modify the visualization. The following
> examples demonstrate what NetworkViz is capable of :
>
>
>- WheelGraph Visualization
>
>- Code-Mirror example 
>
>
> I've planned to implement the following features in the future releases :
>
>- Implement different Graph Plotting algorithms
>- Better Text Support
>- Blink Integration
>- Generalize the package (to work with packages other than LightGraphs)
>
>
> I would like to take this up as a GSoC project and continue working on the
> package. I would therefore like to ask if there is someone who would like
> to be a mentor for this project?
>
> Please give your suggestions so that I can use it to improve the package
> and make it useful for the community.
>
> Regards,
> Abhijith
>

Re: [julia-users] Wrong description of a GSoC project on idea page.

[Mike Innes]

You're right that there's a typo in the Mux project, but perhaps this is a
good opportunity to submit your first PR? Happy to give tips on the process
if you want.

It's good to see that there's some work on cookie and session handling,
although as far as I know this isn't at all integrated with Mux.jl – so you
can't, for example, put in a middlewhere that takes cookies out into a
dictionary or something – that would be nice to have. As I've mentioned, a
great project plan would be getting everything integrated with Mux and
polished so that setting up a simple website is very easy.

Other than that, I think I would follow Jock's advice and check out what
features web frameworks in Go, Clojure, Ruby or Python have that we don't.
Putting together a small web app yourself would probably be the quickest
way to find out what's missing.

On Sat, 19 Mar 2016 at 10:19 Sarvjeet singh ghotra 
wrote:

> In the description of GSoC project Middlewares for common web application
> chores in Mux.jl
> 
>  project the subsection Expected Result is wrong. Someone please correct
> that.
>
> One more thing, while discussing this project with Jock Lawire I came to
> know that most of the routines that are expected to be implemented like
> routing, cookie/session handling, authentication in Mux.jl are either
> already done or half finished. So I want to know what other features are
> required.
>
> Of the mid-level features mentioned in the project description, routing is
>> done (Mux.jl), cookie/session handling is partly done (SecureSessions.jl),
>> and authentication is partly done (SecureSessions.jl). Load balancing is
>> not done. Whether this is a priority depends if users want to write
>> heavy-traffic apps that are insecure, or moderate-traffic apps that are
>> secure.
>
>
>  -Jock
>
> Question to JuliaWeb Members: Are you following any other framework for
> reference while working on Middleware related features? So that I can also
> look at the same framework for consistency purpose.
>
>

Re: [julia-users] Call for GSoC mentors for proposed projects under the JuliaQuantum org

[Mike Innes]

In general, it'd be great if anyone interested in mentoring could email us
at julia...@googlegroups.com, mentioning your area of interest. There isn't
much to be done on the mentor side at this stage but it will help us to
match up proposals and mentors later on. Most likely we'll also want some
help reviewing projects and deciding which are the most promising.

On Thu, 17 Mar 2016 at 16:18 Xiaodong Qi  wrote:

> Dear Julia users and developers,
>
> You may not have noticed that JuliaQuantum--an umbrella organization under
> JuliaLang--have received some ideas and proposals
>  on
> this year's GSoC projects. However, the current members in the org seem
> pretty busy for the summer, and hence I am writing on behalf of the org to
> ask if anyone here is available to be a mentor for the current proposed and
> potential GSoC projects.
>
> JuliaQuantum is a pretty small Julia org, but we have successfully
> supported a GSoC project last year and have most of the fundamental
> framework of the Julia libraries for quantum science set up in our current
> scope. Hopefully see your participations in our current J/GSoC issue thread
> at https://github.com/JuliaQuantum/JuliaQuantum.github.io/issues/32 and
> contributions for the community in a long run. More information about the
> org can be found in our website at http://juliaquantum.github.io.
>
> Thanking you,
> Qi
>

Re: [julia-users] Re: GSoC 2016 - Simple persistent distributed storage Project

[Mike Innes]

For something ComputeFramework related, it's likely that Shashi Gowda would
be interested in mentoring. You could try opening issues for queries as
well. We're flexible about mentoring if you have someone in mind, but in
general we'll try to match proposals with people who are known to the
community.

On Fri, 18 Mar 2016 at 12:47 Soujanya Ponnpalli <
soujanya.ponnapa...@gmail.com> wrote:

> Hello!
>
> I've started taking a look at the package ComputeFramework.jl. I have a
> few queries and would want some information regarding them.
>
> Could you tell me how I could get in touch with potential mentors for this
> project? Is it the case that there are a few fixed mentors amongst which
> one shall get convinced to mentor me, or is it that anyone with domain
> specific knowledge and experience in Julia can mentor me on this project?
>
> Looking forward to hear from you,
> Soujanya Ponnapalli.
>
> On Sun, Mar 13, 2016 at 11:06 PM, Mike Innes 
> wrote:
>
>> Hey Soujanya,
>>
>> Glad to have your interest! I don't know a lot about this project
>> personally, but you might be interested to take a look at the recent work
>> on ComputeFramework.jl <https://github.com/shashi/ComputeFramework.jl>,
>> which is in a similar area. Getting stuck in over there would be a great
>> way to meet potential mentors and get a hard start on the project.
>>
>> Cheers,
>> Mike
>>
>> On Friday, 11 March 2016 14:35:06 UTC, Soujanya Ponnpalli wrote:
>>>
>>> Hello!
>>>
>>> I am Soujanya Ponnapalli, a junior at International Institute of
>>> Information Technology, Hyderabad (IIIT-H), majoring in Computer Science
>>> and Engineering (CSE). I got introduced to Julia at International
>>> Parallel and Distributed Processing Symposium - IPDPS 2015 and was
>>> taken aback by the features of Julia like performance efficiency, parallel
>>> and distributed computation support.
>>>
>>> I would rate my competency level in C++, Java and Python as intermediate
>>> and getting my hands on Julia. I would like to contribute to the project "
>>> Simple persistent distributed storage" as I'm interested in Distributed
>>> Systems. My experience in this field includes, implementing a file
>>> system similar to HDFS in java.
>>>
>>> I would be thankful if I could get some information regarding,
>>> 1. What is expected from your side, in context to this project?
>>> 2. How do I contact the mentors and get involved in the project
>>> discussions?
>>>
>>> Regards,
>>> Soujanya Ponnapalli.
>>>
>>>
>

Re: [julia-users] Google SoC '16: Native Julia solvers for ordinary differential equations, Julia|Quantum>, and Native Julia implementation of Holonomic Functions

[Mike Innes]

Hey Joseph,

Glad to see your interest, I think your best bet at the moment is just to
get going with the ideas you have – perhaps try a few things in parallel
and see what picks up momentum.

As for the Holonomic functions project, it sounds pretty interesting, but
it's obviously difficult to judge ideas like this. There are plenty of
people on this list who would have relevant expertise, but if nothing else
I might have a look over the idea myself over the next couple days.

Sorry I can't be more helpful than that right now.

Cheers,
Mike

On Tue, 15 Mar 2016 at 18:10 Joseph Obiajulu  wrote:

> Hello All,
>
> My name is Joseph Obiajulu and I'm a junior studying mathematics and
> computer science at Princeton University. I was looking through the project
> ideas for potential GSoC projects on the Sage page, and I came across a
> project idea concerning "Native Julia solvers for ordinary differential
> equations." I have experience with differential equations from my math
> training, as well as exposure to different numerical computing methods and
> am starting to get my feet wet with coding in Julia, and so thought that I
> might be able to contribute to the project. I wanted to ask on this mailing
> list, especially to those who will mentor this project, where the best
> place to start would be (I have a few ideas, but I wanted to ask those who
> have put more thought into this question for advice). Also, I was wondering
> if this is a high-priority project, or if there is another project that the
> Julia community would rather have someone work on for the summer.
>
> With that said, I also am thinking of proposing two of my own project
> ideas (of course, I would only end up pursuing one over the summer, but I
> figured it doesn't hurt to propose additional ideas). The first is working
> to expand Julia|Quantum>. I have a particular interest in quantum mechanics
> and especially quantum computing, and I thought a cool project would be to
> work on implementing some of the long term JuliaQuantum project goals (see 
> these
> goals here
> ), as
> well as maybe implementing simple quantum computing algorithms, such as
> Shor's and Groover's. This idea is still very much in its infancy, so I'm
> curious to hear what people think of it.
>
> The second is a native julia implementation of holonomic functions
> . Holonomic functions
> draw their strength from their closure properties, and often can simplify
> some calculations (or at least that's what I've read, I'm still looking
> into it). The following dissertation
> 
> would be something I would work through as I try to implement standard
> operations of holonomic functions (addition, multiplication, integration,
> derivatives, etc). This is more of a 'Blue Sky' project, but I find it
> particularly interesting, because it is probably the most "mathematically
> heavy" one of the three I've proposed, and I that's something that get's me
> excited, especially that it deals with analysis, which is my mathematical
> focus.
>
> I'm eagerly awaiting to hear from the Julia community!
>
> Thanks for the help,
> Joseph
>

Re: [julia-users] Documentation effort for GSoC

[Mike Innes]

Hey Morten,

This looks like an interesting idea. Is (a) doable in three months? It
might be tricky, especially with the current state of Julia's web tooling.

I recommend taking a look over the Docile and Lexicon packages – Michael
Hatherly has made really great progress with some of these ideas, and you
might be able to get involved over there and figure out some more detailed
ideas.

Cheers,
Mike

On Tue, 15 Mar 2016 at 18:10 Morten Piibeleht 
wrote:

> I would like to put together a GSoC proposal targeting the
> documentation. Some thoughts have been on floating in my head as I
> have been using Julia for the past year and would be fun for me to work on.
>
> Specifically, the following could be specific enough the be a GSoC project:
>
> (a) A system for user notes/feedback on the docs.
>
> The idea is to have a system where the users could comment on every
> section of the documentation, probably also with a moderation system
> in place. Basically inspired by the PHP documentation, where every
> page (e.g. function) has notes attached.
>
> It would effectively make the docs update and improve more rapidly, by
> people sharing their thoughts and examples on particular functions,
> types etc, and on the other hand make it easy for others to find.
> These entries would complement the documentation, or function as a
> temporary placeholder documentation, if the documentation is lacking
> something. It would also offer a library of use cases etc. for people
> who would at some point hopefully edit the official documentation,
> helping to write better documentation in general.
>
> For the implementation, it depends what’s out there of course. Perhaps
> something existing could be tweaked for to fit Julia, Read the Docs
> extended or something written from scratch.
>
>
> (b) Automation tools & guidelines for the docs
>
> This one is a bit more vague, but would involve making the docs even
> more friendly to automatic parsing and then making use of that. For
> example, creating useful, thorough reference manuals for packages
> (like the Base has, but I haven't seen for packages). Moreover, even
> the Base could benefit from having more thorough information (e.g.
> exact function signature, automatically extracted from the code).
>
> Part of it would be figuring out and defining a good way to write
> documentation for packages, so that it could be used be automatic
> tools for displaying etc, and also how to display it in a useful
> manner. What I have in mind is something like doxygen or javadoc for
> Julia. I think it could also tie into the only documentation-related
> idea on the ideas page regarding having docs in the IDEs (under Juno).
>
>
> Would love to hear whether people think that these could be a useful
> and one of them make a reasonable GSoC project (and if so, whether
> there’s anyone willing to mentor it). Also, just to hopefully start a
> useful discussion, what other thoughts have people had to make the
> docs even better?
>
> Best,
> Morten
>

Re: [julia-users] Google Summer of Code 2016

[Mike Innes]

Got it, thanks!

On Tue, 15 Mar 2016 at 18:15 Jorge  wrote:

> Many thanks Mike! I've already sent an email to the new address you gave me
>
> On Tuesday, March 15, 2016 at 9:51:19 AM UTC-6, Mike Innes wrote:
> > Ok, we're replacing this old / broken email with:
> >
> >
> > julia...@googlegroups.com
> >
> >
> > so give that a go, let me know if it's still not working.
> >
> >
> >
> > On Tue, 15 Mar 2016 at 14:42 Mike Innes <> wrote:
> >
> > I don't think you've done anything wrong, there seems to be a
> permissions issue with the group. Feel free to email me directly in the
> mean time, and we'll try to sort something out.
> >
> >
> >
> >
> > On Tue, 15 Mar 2016 at 07:10 Jorge  wrote:
> >
> > Many thanks for your reply, Mike! Actually now I do have some questions
> about GSoC and tried to email you guys at the address you gave me
> julia-g...@googlegroups.com, but wasn't able to get it sent. The server
> replied:
> >
> >
> > "We're writing to let you know that the group you tried to contact
> (julia-gsoc-2014) may not exist, or you may not have permission to post
> messages to the group."
> >
> >
> > :(
> >
> >
> > Is there anything I'm doing wrong?
> >
> > On Thursday, March 10, 2016 at 5:07:56 AM UTC-6, Mike Innes wrote:
> > Sure thing, well if it's a question about admin or organisation you can
> go ahead and email julia-g...@googlegroups.com. For more technical
> questions, or feedback on ideas and plans, you're always welcome to post on
> this julia-users as well.
> >
> >
> >
> >
> > On Thu, 10 Mar 2016 at 04:39 Jorge <> wrote:
> >
> > Thanks Mike! I'm preparing my proposal to apply as a student this year,
> so, just wanted to know who could I contact if I ever have a question for
> you guys!
> >
> >
> >
> >
> > -J
> >
> >
> > On Wednesday, March 9, 2016 at 4:28:51 PM UTC-6, Mike Innes wrote:
> >
> >
> > Hey Jorge, me and Shashi Gowda are organising GSoC this year and there
> are a few others with admin access – why do you ask?
> >
> >
> >
> >
> > On Wed, 9 Mar 2016 at 22:17 Jorge  wrote:
> > Hi Mike,
> >
> >
> >
> > Do you know who are Julia's GSoC 2016 org admins?
> >
> >
> >
> > Best,
> >
> > Jorge
>
>

Re: [julia-users] Google Summer of Code 2016

[Mike Innes]

Ok, we're replacing this old / broken email with:

julia...@googlegroups.com

so give that a go, let me know if it's still not working.

On Tue, 15 Mar 2016 at 14:42 Mike Innes  wrote:

> I don't think you've done anything wrong, there seems to be a permissions
> issue with the group. Feel free to email me directly in the mean time, and
> we'll try to sort something out.
>
>
> On Tue, 15 Mar 2016 at 07:10 Jorge  wrote:
>
>> Many thanks for your reply, Mike! Actually now I do have some questions
>> about GSoC and tried to email you guys at the address you gave me
>> julia-g...@googlegroups.com , but
>> wasn't able to get it sent. The server replied:
>>
>> "We're writing to let you know that the group you tried to contact
>> (julia-gsoc-2014) may not exist, or you may not have permission to post
>> messages to the group."
>>
>> :(
>>
>> Is there anything I'm doing wrong?
>>
>> On Thursday, March 10, 2016 at 5:07:56 AM UTC-6, Mike Innes wrote:
>>>
>>> Sure thing, well if it's a question about admin or organisation you can
>>> go ahead and email julia-g...@googlegroups.com
>>> . For more technical questions, or
>>> feedback on ideas and plans, you're always welcome to post on this
>>> julia-users as well.
>>>
>>
>>> On Thu, 10 Mar 2016 at 04:39 Jorge <> wrote:
>>>
>>>> Thanks Mike! I'm preparing my proposal to apply as a student this year,
>>>> so, just wanted to know who could I contact if I ever have a question for
>>>> you guys!
>>>>
>>>>
>>>> -J
>>>>
>>>> On Wednesday, March 9, 2016 at 4:28:51 PM UTC-6, Mike Innes wrote:
>>>>
>>>>> Hey Jorge, me and Shashi Gowda are organising GSoC this year and there
>>>>> are a few others with admin access – why do you ask?
>>>>>
>>>>> On Wed, 9 Mar 2016 at 22:17 Jorge  wrote:
>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> Do you know who are Julia's GSoC 2016 org admins?
>>>>>>
>>>>>> Best,
>>>>>> Jorge
>>>>>
>>>>>

Re: [julia-users] Signal Processing related project for GSOC 2016

[Mike Innes]

Hey Rishabh,

You should check out the JuliaAudio  org and
AudioIO.jl . I have no idea what would
make a reasonable project in this area, but if you browse over the
currently available functionality and issues, maybe contribute a patch or
two, you're likely to get an idea of what's doable in 3 months. I'm sure
there's a lot of interesting functionality that you could add in that time.

Cheers,
Mike

On Tue, 15 Mar 2016 at 14:07 Rishabh Gupta 
wrote:

> Hello all,
>
> I am a final year Electrical and Electronics undergraduate from BITS
> Pilani Goa Campus, India. I have prior programming experience in C,C++ and
> MATLAB.I am interested in audio and signal processing and I would like to
> contribute to the julia's signal processing toolbox but I cannot see any
> related project on the GSOC webpage. I request you to guide me as to what
> could be a suitable project and how I can start contributing for the same.
>
> Thanks and Regards,
>
> Rishabh
>

Re: [julia-users] Re: Google Summer of Code 2016

[Mike Innes]

Hi Hyun,

What's your idea / area of interest? You can open a discussion on this list
or look for relevant packages and get involved with issues, features and
roadmaps – package maintainers will be involved in the discussion and many
will be willing to mentor as well.

If you're working fairly independently and have a solid proposal, a mentor
isn't a strict requirement – you can apply without one. But especially for
projects outside of our range of expertise, it's a big help for us to see
someone endorse your idea.

Cheers,
Mike

On Tue, 15 Mar 2016 at 14:07 Hyun  wrote:

> Hi, Mike,
>
> This is Hyun, I'm a student in Korea, and I have a plan to apply this
> Julia GSoC program.
>
> May I ask you a question?
>
> You mentioned "Finding a good mentor for your project will be a big help
> for most applications, and showing mentors your enthusiasm is a great way
> to get them on board.",
>
> Can you tell me how to find a mentor for my project?
>
> Sincerely,
> Hyun.
>
>
> 2016년 3월 9일 수요일 오후 10시 53분 41초 UTC+9, Mike Innes 님의 말:
>>
>> Hey All,
>>
>> As you may have heard by now, the Julia language is proud to be part of 
>> Google
>> Summer of Code
>> <https://summerofcode.withgoogle.com/organizations/6453977159827456/>
>> 2016! We’re inviting students to get paid to work on a Julia-related
>> project of their choice during their summer break. I’ll explain more about
>> how everyone can get involved below, and any questions can be directed to
>> this group or to the aptly-named julia-s...@googlegroups.com.
>>
>
>>
>> *Students*: Start by thinking about the kind of projects you’d like to
>> work on! As a starting point, there are a bunch of interesting projects on
>> our ideas page <http://julialang.org/soc/ideas-page>. At this stage,
>> it’s also a good idea to start getting involved with the community around
>> your area of interest by opening issues, sending PRs and speaking to
>> developers. Finding a good mentor for your project will be a big help for
>> most applications, and showing mentors your enthusiasm is a great way to
>> get them on board. Feel free to start discussions on this group, although
>> note that it’s easier for us to answer broad questions about the process
>> than to give specific technical feedback.
>>
>> *Everyone else*: If you happen to know any students, please let them
>> know! We’d also like to encourage people to step up as mentors, so if
>> you’re interested then please contact us at the above julia-soc group and
>> let us know what areas you’d like to help with. Please also feel free to
>> give technical feedback on proposals that come up on this list.
>>
>> Cheers,
>> Mike
>>
>

Re: [julia-users] Google Summer of Code 2016

[Mike Innes]

I don't think you've done anything wrong, there seems to be a permissions
issue with the group. Feel free to email me directly in the mean time, and
we'll try to sort something out.

On Tue, 15 Mar 2016 at 07:10 Jorge  wrote:

> Many thanks for your reply, Mike! Actually now I do have some questions
> about GSoC and tried to email you guys at the address you gave me
> julia-g...@googlegroups.com , but
> wasn't able to get it sent. The server replied:
>
> "We're writing to let you know that the group you tried to contact
> (julia-gsoc-2014) may not exist, or you may not have permission to post
> messages to the group."
>
> :(
>
> Is there anything I'm doing wrong?
>
> On Thursday, March 10, 2016 at 5:07:56 AM UTC-6, Mike Innes wrote:
>>
>> Sure thing, well if it's a question about admin or organisation you can
>> go ahead and email julia-g...@googlegroups.com
>> . For more technical questions, or
>> feedback on ideas and plans, you're always welcome to post on this
>> julia-users as well.
>>
>
>> On Thu, 10 Mar 2016 at 04:39 Jorge <> wrote:
>>
>>> Thanks Mike! I'm preparing my proposal to apply as a student this year,
>>> so, just wanted to know who could I contact if I ever have a question for
>>> you guys!
>>>
>>>
>>> -J
>>>
>>> On Wednesday, March 9, 2016 at 4:28:51 PM UTC-6, Mike Innes wrote:
>>>
>>>> Hey Jorge, me and Shashi Gowda are organising GSoC this year and there
>>>> are a few others with admin access – why do you ask?
>>>>
>>>> On Wed, 9 Mar 2016 at 22:17 Jorge  wrote:
>>>>
>>>>> Hi Mike,
>>>>>
>>>>> Do you know who are Julia's GSoC 2016 org admins?
>>>>>
>>>>> Best,
>>>>> Jorge
>>>>
>>>>

Re: [julia-users] Priority Order of 2 proposals for Images.jl

[Mike Innes]

Hi Anchit,

As a rule the best project is probably the one that's the best fit for you,
although you can also submit multiple proposals if you want to. Perhaps you
could open a roadmap issue for one or more of those ideas on the Images.jl
repo and see which ones gains the most attention / enthusiasm from the
project's maintainers.

Cheers,
Mike

On Tue, 15 Mar 2016 at 01:11 Anchit Navelkar  wrote:

> Hi,
>
> I am Anchit Navelkar, an undergraduate studying Computer Science at IIT
> Kharagpur. I've been interested in Computer Vision since my freshman year
> and worked on many projects in this field. I am interested in submitting a
> proposal for Images.jl for GSoC 2016.
>
> The ideas page on julialang.org has a project proposal
> 
>  for
> writing high performance multithreaded kernels for image processing, more
> specifically multithreaded versions of imfilter and imfilter_gaussian.
>
>
> I am also interested in adding functionality to Images.jl like Image
> Stitching, Face Detection, Object Tracking, Feature Descriptors or Drawing
> Functions.
>
>
> Which project would be higher in the priority list for Images.jl?
>
>
> Thanks!
>

Re: [julia-users] GSOC2016: Iterative solvers

[Mike Innes]

Great – it would probably be a good idea to poke your head up in the
roadmap issue there, and perhaps try to solve a smaller item as a start (if
you haven't already). Let us know if you pair up with a mentor!

On Mon, 14 Mar 2016 at 20:15 Kevin Keys  wrote:

> Hello,
>
> I would like to work on the GSOC 2016 project with iterative solvers
> .
> I am a doctoral candidate trained in scientific computing, mathematical
> optimization, and genomic technology. I am familiar with
> IterativeSolvers.jl  since
> I use it in my dissertation codebase. Please do not hesitate to email me
> (klkeys [at] g [dot] ucla [dot] edu) if you are interested!
>
> --Kevin
>

Re: [julia-users] Intrested in working for julia in GSoC 2016 .

[Mike Innes]

Definitely check out SymPy.jl if you haven't already – getting involved
over there is a great way to get a deeper understanding of what needs to be
done, and will introduce you to potential mentors.

On Mon, 14 Mar 2016 at 20:04 Kristoffer Carlsson 
wrote:

> Regarding SymPy, you should know about this active package:
> https://github.com/jverzani/SymPy.jl

Re: [julia-users] QML (Qt5) binding for Julia (GSOC?)

[Mike Innes]

That should be fine for now – the only other thing would be to keep an eye
out for proposals and lend some feedback where possible.

On Mon, 14 Mar 2016 at 19:30 Uwe Fechner  wrote:

> Ok, I added a pull request to the GSOC ideas page:
> https://github.com/JuliaLang/julialang.github.com/pull/357
>
> Is there anything else, I should do?
>
>
> Uwe
>
>
> On Monday, March 14, 2016 at 8:11:17 PM UTC+1, Mike Innes wrote:
>
>> That would be great! There are guidelines from Google on mentorship which
>> are a better authority, but roughly speaking you'd be looking at a few
>> hours a week; time for a video call + answering questions over email and
>> such. This will vary depending on the student, so student ability and
>> mentor expertise and/or time commitment are things we'll weigh against each
>> other when looking at proposals.
>>
>> On Mon, 14 Mar 2016 at 19:02 Uwe Fechner  wrote:
>>
>>>
>>>
>>> On Monday, March 14, 2016 at 8:01:01 PM UTC+1, Uwe Fechner wrote:
>>>
>>>> Hello,
>>>>
>>>> perhaps I could become mentor of such a project?
>>>> At least I know a little bit of Julia and a little bit of QML.
>>>>
>>>> I am currently implementing optimizations and simulations
>>>> in Julia, and a QML GUI would be nice.
>>>>
>>>> What would be needed to offer such a project?
>>>>
>>> How much workload would be expected for a mentor?
>>>>
>>>
>>>>
>>>> Regards:
>>>>
>>>> Uwe Fechner, TU Delft
>>>>
>>>> On Monday, March 14, 2016 at 2:23:32 PM UTC+1, Maurice Diamantini wrote:
>>>>>
>>>>>
>>>>>
>>>>> Le lundi 14 mars 2016 13:24:13 UTC+1, Uwe Fechner a écrit :
>>>>>
>>>>>
>>>>>> What Julia is missing is mainly an easy to use GUI toolkit, and QML
>>>>>> could play that role.
>>>>>>
>>>>>
>>>>> That's exactly why I think a QML binding would be easier to do than a
>>>>> Qt5 one, and sufficient for most use case from Julia : no need to be able
>>>>> to use yet another string type et socket or http or..., just application
>>>>> GUI with callback to Julia methods.
>>>>>
>>>>>
>>>>>> Implementing a Julia - QML binding sound not so difficult as there is
>>>>>> already a C binding.
>>>>>>
>>>>>> I do not understand the following sentence:
>>>>>> "Being able to build Qt interface directly from Julia without the
>>>>>> need of  the anaconda
>>>>>> would be a great advantage for Julia users."
>>>>>>
>>>>>
>>>>> Because I know there already exists a Python binding Qt4 (or there
>>>>> will be some day for Qt5) but it require about 1.2 G bytes in the 
>>>>> `pkgs/v0.4/Conda`
>>>>> of the Julia directory.
>>>>>
>>>>>
>>>>> If you would write a QML wrapper for the C binding, the C/ C++ code
>>>>>> from the C wrapper
>>>>>> would still need to be compiled included in the package in some way
>>>>>> (binutils). So there
>>>>>> would still be a dependency on C/C++ code (pre-compiled or not), that
>>>>>> is always a little
>>>>>> bit difficult to install and to maintain.
>>>>>>
>>>>>
>>>>> Yes, but this extension should be more robust because less sensible to
>>>>> the Qt core changes...
>>>>>
>>>>>  -- Maurice
>>>>>
>>>>>

Re: [julia-users] QML (Qt5) binding for Julia (GSOC?)

[Mike Innes]

That would be great! There are guidelines from Google on mentorship which
are a better authority, but roughly speaking you'd be looking at a few
hours a week; time for a video call + answering questions over email and
such. This will vary depending on the student, so student ability and
mentor expertise and/or time commitment are things we'll weigh against each
other when looking at proposals.

On Mon, 14 Mar 2016 at 19:02 Uwe Fechner  wrote:

>
>
> On Monday, March 14, 2016 at 8:01:01 PM UTC+1, Uwe Fechner wrote:
>
>> Hello,
>>
>> perhaps I could become mentor of such a project?
>> At least I know a little bit of Julia and a little bit of QML.
>>
>> I am currently implementing optimizations and simulations
>> in Julia, and a QML GUI would be nice.
>>
>> What would be needed to offer such a project?
>>
> How much workload would be expected for a mentor?
>>
>
>>
>> Regards:
>>
>> Uwe Fechner, TU Delft
>>
>> On Monday, March 14, 2016 at 2:23:32 PM UTC+1, Maurice Diamantini wrote:
>>>
>>>
>>>
>>> Le lundi 14 mars 2016 13:24:13 UTC+1, Uwe Fechner a écrit :
>>>
>>>
 What Julia is missing is mainly an easy to use GUI toolkit, and QML
 could play that role.

>>>
>>> That's exactly why I think a QML binding would be easier to do than a
>>> Qt5 one, and sufficient for most use case from Julia : no need to be able
>>> to use yet another string type et socket or http or..., just application
>>> GUI with callback to Julia methods.
>>>
>>>
 Implementing a Julia - QML binding sound not so difficult as there is
 already a C binding.

 I do not understand the following sentence:
 "Being able to build Qt interface directly from Julia without the need
 of  the anaconda
 would be a great advantage for Julia users."

>>>
>>> Because I know there already exists a Python binding Qt4 (or there will
>>> be some day for Qt5) but it require about 1.2 G bytes in the 
>>> `pkgs/v0.4/Conda`
>>> of the Julia directory.
>>>
>>>
>>> If you would write a QML wrapper for the C binding, the C/ C++ code from
 the C wrapper
 would still need to be compiled included in the package in some way
 (binutils). So there
 would still be a dependency on C/C++ code (pre-compiled or not), that
 is always a little
 bit difficult to install and to maintain.

>>>
>>> Yes, but this extension should be more robust because less sensible to
>>> the Qt core changes...
>>>
>>>  -- Maurice
>>>
>>>

Re: [julia-users] QML (Qt5) binding for Julia (GSOC?)

[Mike Innes]

Sure, but adding a project idea doesn't commit you to being a mentor or
anything. The ideas page is where students are going to take project
suggestions from, so that's the best place if you want people to see it and
potentially take it on.

On Mon, 14 Mar 2016 at 13:05 Maurice Diamantini <
maurice.diamant...@gmail.com> wrote:

> Le lundi 14 mars 2016 13:45:13 UTC+1, Mike Innes a écrit :
>
> Ah ok, so you're not actually going for this project as a student?
>>
>
> No.
>
> In that case, how about suggesting the project on the ideas page
>> <https://github.com/JuliaLang/julialang.github.com/blob/master/soc/ideas-page.md>
>> ?
>>
>
> Because I'm not going to be a mentor neither!
> I just wanted to suggest a binding QML as a potential GSOC.
>
> -- Maurice
>

Re: [julia-users] QML (Qt5) binding for Julia (GSOC?)

[Mike Innes]

Ah ok, so you're not actually going for this project as a student? In that
case, how about suggesting the project on the ideas page
<https://github.com/JuliaLang/julialang.github.com/blob/master/soc/ideas-page.md>
?

On Mon, 14 Mar 2016 at 12:24 Uwe Fechner  wrote:

> Well, I am not an expert on QML, but as far as I understand, QML is mainly
> for writing GUIs, whereas
> the QT library contains a lot of functions for a lot of other tasks.
>
> What Julia is missing is mainly an easy to use GUI toolkit, and QML could
> play that role.
>
> Implementing a Julia - QML binding sound not so difficult as there is
> already a C binding.
>
> I do not understand the following sentence:
>
> "Being able to build Qt interface directly from Julia without the need of
>  the anaconda
> would be a great advantage for Julia users."
>
> If you would write a QML wrapper for the C binding, the C/ C++ code from
> the C wrapper
> would still need to be compiled included in the package in some way
> (binutils). So there
> would still be a dependency on C/C++ code (pre-compiled or not), that is
> always a little
> bit difficult to install and to maintain.
>
> Sounds like a great project!
>
>
> Uwe
>
>
>
>
> On Monday, March 14, 2016 at 11:04:02 AM UTC+1, Maurice Diamantini wrote:
>
>> My interest in QML/Qt5 is limited as a user which is looking for a
>> reliable multi-platform toolbox for building gui applications (with
>> native menu, open and save box...).
>>
>> There is the old designes Tk-8.6 which works everywere. But Julia
>> seams only to install Tk8.5.
>>
>> Gtk is not (yet) really multi-platform although it claims to.
>> It is very promising... for years, much like the D language before
>> Go and Julia appear.
>> Also there is no much example on the github page.
>>
>> So Qt5 would be the best solution (true multi-platform GUI, full feature
>> and very good documentation).
>> But Qt5 is a C++ code and even with the Cxx.jl package, I guess there
>> is much time before someone (Tom ;-) has time to build such an interface.
>> Also The library should be maintained.
>>
>> In the meantime, I thought a QML binding would be easier to do (not by
>> me :) and above all easier to maintained because most features are
>> available in QML and there has no need  (I think) to have its Julia
>> associated method.
>>
>> Can someone who know QML confirm that?
>> Also what feature are provided by Qt5 which are not available with QML?
>>
>> Regard,
>> -- Maurice
>>
>> Le 13 mars 2016 à 18:33, Mike Innes  a écrit :
>>
>> > Hey Maurice,
>> >
>> > Glad to see your interest in this project! I don't know a lot about
>> this area personally, but you might be able to learn more about the
>> approaches and issues involved by looking at Gtk.jl, which is a fairly
>> complete effort in a similar area. Other than that, a simple protoype might
>> help us to evaluate the idea.
>> >
>> > I'd be interested in your take on the relative pros and cons of
>> wrapping Qt5 wholesale vs. taking the QML approach you've described.
>> >
>> > Cheers,
>> > Mike
>> >
>>
> > On Fri, 11 Mar 2016 at 15:35 Maurice Diamantini 
>> wrote:
>> > While trying to find some Qt5 binding for Julia, I only found the Qt5
>> startup projet from Tom Breloff https://github.com/tbreloff/Qt5.jl which
>> is intended to bind the full feature from Qt5. This is a huge task and will
>> take some time.
>> >
>> > So I wonder if there is some interest for a QML binding which would
>> allows Julia code to display simple QML file (with callback to Julia
>> methods!).
>> >
>> > I just found a git repository about two QML library which could serve
>> as a basis  and as an example:
>> >
>> >
>> > • https://github.com/seanchas116/libqmlbind A C library for
>> creating QML bindings for other languages easily
>> > • https://github.com/seanchas116/ruby-qml a Ruby binding for
>> QML which uses libqmlbind
>> >
>> > Being able to build Qt interface directly from Julia without the need
>> of  the anaconda would be a great advantage for Julia users.
>> >
>> > That seems to be a true Julia GSOC candidate project (i.e. which could
>> not be affected to another language...)
>> >
>> > Regard,
>> >
>> > -- Maurice
>> >
>> >
>>
>>

[julia-users] Re: GSoC 2016 - Simple persistent distributed storage Project

[Mike Innes]

Hey Soujanya,

Glad to have your interest! I don't know a lot about this project 
personally, but you might be interested to take a look at the recent work 
on ComputeFramework.jl , 
which is in a similar area. Getting stuck in over there would be a great 
way to meet potential mentors and get a hard start on the project.

Cheers,
Mike

On Friday, 11 March 2016 14:35:06 UTC, Soujanya Ponnpalli wrote:
>
> Hello!
>
> I am Soujanya Ponnapalli, a junior at International Institute of 
> Information Technology, Hyderabad (IIIT-H), majoring in Computer Science 
> and Engineering (CSE). I got introduced to Julia at International 
> Parallel and Distributed Processing Symposium - IPDPS 2015 and was taken 
> aback by the features of Julia like performance efficiency, parallel and 
> distributed computation support.
>
> I would rate my competency level in C++, Java and Python as intermediate 
> and getting my hands on Julia. I would like to contribute to the project " 
> Simple persistent distributed storage" as I'm interested in Distributed 
> Systems. My experience in this field includes, implementing a file system 
> similar to HDFS in java. 
>
> I would be thankful if I could get some information regarding,
> 1. What is expected from your side, in context to this project?
> 2. How do I contact the mentors and get involved in the project 
> discussions?
>
> Regards,
> Soujanya Ponnapalli.
>
>

Re: [julia-users] QML (Qt5) binding for Julia (GSOC?)

[Mike Innes]

Hey Maurice,

Glad to see your interest in this project! I don't know a lot about this
area personally, but you might be able to learn more about the approaches
and issues involved by looking at Gtk.jl, which is a fairly complete effort
in a similar area. Other than that, a simple protoype might help us to
evaluate the idea.

I'd be interested in your take on the relative pros and cons of wrapping
Qt5 wholesale vs. taking the QML approach you've described.

Cheers,
Mike

On Fri, 11 Mar 2016 at 15:35 Maurice Diamantini <
maurice.diamant...@gmail.com> wrote:

> While trying to find some Qt5 binding for Julia, I only found the Qt5
> startup projet from Tom Breloff https://github.com/tbreloff/Qt5.jl which
> is intended to bind the full feature from Qt5. This is a huge task and will
> take some time.
>
> So I wonder if there is some interest for a QML binding which would allows
> Julia code to display simple QML file (with callback to Julia methods!).
>
> I just found a git repository about two QML library which could serve as a
> basis  and as an example:
>
>
>- https://github.com/seanchas116/*libqmlbind*
> A C library for creating
>QML bindings for other languages easily
>- https://github.com/seanchas116/*ruby-qml*
> a Ruby binding for QML which
>uses libqmlbind
>
> Being able to build Qt interface directly from Julia without the need of
>  the anaconda would be a great advantage for Julia users.
>
> That seems to be a true Julia GSOC candidate project (i.e. which could not
> be affected to another language...)
>
> Regard,
>
> -- Maurice
>
>

Re: [julia-users] GSOC 2016

[Mike Innes]

Hey Ramchandran,

I think the folks on the julia-opt google group would be interested in your
proposal – could you forward this to them and start a discussion there?

Cheers,
Mike

On Fri, 11 Mar 2016 at 14:35 Ramchandran Muthukumar 
wrote:

> Hi,
> I am M. Ramchandran, I am heavily interested in convex optimization, I
> have been working my way through Professor Boyd's book for a year now as a
> part of independent study course in my institute BITS PILANI - Goa Campus
> India, I am comfortable with C++,Java,Python,R and have prior experiece
> with using CVX and the cvxpy package and convex.jl,
> I am relatively new to Julia but the project mentioned here piqued my
> interest -
> http://julialang.org/soc/ideas-page.html#support-for-complex-numbers-within-convexjl
> Any pointers how to start contributing would be much appreciated :)
>
> I have also attached a formal report I had made on convex optimization as
> a requirement for my project here.
>
> Cheers :)
>

Re: [julia-users] GSoC

[Mike Innes]

Hey Simon,

As far as I can tell this project would overlap with the recent work on
ComputeFramework.jl . I
think your best bet would be to head over there, dig in and play around a
bit and see where you'd best be able to contribute – and most likely the
right person to mentor you would be over there as well.

Cheers,
Mike

On Fri, 11 Mar 2016 at 14:35 'Simon Pfreundschuh' via julia-users <
julia-users@googlegroups.com> wrote:

> Hi Everyone,
>
> I would be highly interested in working on one of the massively parallel
> matrix algebra projects that you proposed for GSoC. I would therefore like
> to ask
> if there is someone who would like to be a mentor for this project?
> Moreover, could you
> maybe provide me with some references about which algorithms should exactly
> be implemented?
>
> Some background about me: My name is Simon Pfreundschuh and I am currently
> studyin at Chalmers University of Technology in Gothenburg Sweden. I am
> just about
> to finish my second Master's degree in physics, already holding a Master's
> degree in
> computational science and a Bachelor's degree in computer science. I am
> currently
> developing a library for remote sensing data processing, which is
> basically a big data problem.
> This is also where my interest in the massively parallel matrix algorithms
> comes from.
>
> I am looking forward to hearing from you!
>
> Best regards,
>
> Simon
>
>
>

Re: [julia-users] gsoc projects

[Mike Innes]

Hey Awanish, feel free to discuss ideas right here!

On Fri, 11 Mar 2016 at 14:35 awanish das  wrote:

> where should i discuss ideas related to gsoc projects?
>

Re: [julia-users] ANN: PlotlyJS.jl

[Mike Innes]

PlotlyJS has been shaping up really nicely, and I plan to get it working
inside of Atom soon as well, so you'll get all the same interactive /
streaming possibilities inside a plot pane with history, saving etc. Really
excited to get those things integrated together. Great work by Spencer!

On Fri, 11 Mar 2016 at 17:26 Spencer Lyon  wrote:

> Callbacks are still not supported yet. Hopefully I can find some time soon
> to work on that.
>
> The data flow is Julia -> json -> js and the same in the other direction:
>  js -> json -> julia.
>
> Even without callbacks, we have the ability to send new data from Julia to
> javascript on the fly. The user is able to send _only_ new data points (the
> entire array is not serialized) and plotly will draw _only_ the new data
> (instead of redrawing the entire image). I haven't benchmarked anything,
> but I believe (hope ;) ) this should be pretty efficient for streaming plot
> updates.
>
> Once I find the time I will write up an example notebook about how this
> works. However, for the impatient, you can check the docstrings to these
> methods:
> https://github.com/spencerlyon2/PlotlyJS.jl/blob/950a21217ad4bb55d8f64f50522765653f2f31ce/src/api.jl#L233-L300
> (they are actually much more flexible than just sending new (x, y, z)
> points to be displayed and allow you to stream updates to any chart
> attribute).
>
>
>
>
>
> On Friday, March 11, 2016 at 12:17:43 PM UTC-5, Tim Holy wrote:
>>
>> This sounds really exciting!
>>
>> I have a couple of technical questions:
>> - Last I checked (a few days ago), the docs said that callbacks aren't
>> supported yet. Has that changed already?
>> - How are data transported? I assume you have to serialize arrays via
>> JSON?
>> When new data arrive, do you reserialize the entire array, or is this
>> doing
>> something uber-clever?
>>
>> Best,
>> --Tim
>>
>> On Friday, March 11, 2016 08:18:14 AM Spencer Lyon wrote:
>> > New package announcement. I've just registered PlotlyJS.jl with
>> metadata.
>> > The package leverages the plotly.js javascript library to provide a
>> backend
>> > for offline plot generation (no interaction with plotly's web API).
>> This
>> > will be the backend used to generate figures in the soon to be revamped
>> > Plotly.jl package. The latter will serve as the interface between Julia
>> and
>> > plotly's REST API.
>> >
>> > The package has two main goals
>> >
>> >1. Make it convenient to construct and manipulate plotly
>> visualizations
>> >2. Provide infrastructure for viewing plots on multiple frontends
>> and
>> >saving plotly graphics to files
>> >
>> >
>> >
>> > Up to this point I have intentionally not put effort into creating a
>> > plotting API for this package, but rather have made it easy to leverage
>> > plotly's declarative API from Julia. If you are looking for a lot of
>> API
>> > extensions, see the plotlyjs backend in Plots.jl.
>> >
>> > One main feature is a dedicated plotting GUI in an electron window
>> (powered
>> > by Blink.jl). This allows us to have full 2 way communication between
>> Julia
>> > and javascript, taking interactive plotting to a new level (enabling,
>> among
>> > other things, streaming workflows where plots are updated inplace as
>> new
>> > data arrives)
>> >
>> > Check out the docs here: http://spencerlyon.com/PlotlyJS.jl/
>>
>>

Re: [julia-users] Re: Status of Plots.jl?

[Mike Innes]

Just FYI, this is actually the old Juno on Light Table, not Atom – which I
recommend everyone uses at this point :)

On Fri, 11 Mar 2016 at 19:28 Josef Heinen  wrote:

> GR.jl is also supported inside Atom, either standalone (see screenshot),
> or as a backend for Plots.jl or PyPlot.jl (Matplotlib).
>
>
> 
>
>
> On Friday, March 11, 2016 at 3:35:07 PM UTC+1, Philippe Roy wrote:
>>
>> Hi! Nice package Tom. Is this supposed to work inside Atom with the julia
>> "IDE" ? The plots seems to work, but I really don't know where they appear!
>> they're not in the plots pane (I think only Gadfly is supported as of now
>> inside Atom).
>>
>> Thanks for any help!
>>
>> Le jeudi 10 mars 2016 14:08:23 UTC-5, Tom Breloff a écrit :
>>>
>>> You should read up more on PlotlyJS: http://spencerlyon.com/PlotlyJS.jl/
>>>
>>> Or from the Plots docs:
>>>
>>> Plotly / PlotlyJS
 These are treated as separate backends, though they share much of the
 code and use the Plotly javascript API.  plotly() is the only
 dependency-free plotting option, as the required javascript is bundled with
 Plots. It can create inline plots in IJulia, or open standalone browser
 windows when run from the Julia REPL.
 plotlyjs() is the preferred option, and taps into the great
 functionality of Spencer Lyon's PlotlyJS.jl. Inline IJulia plots can be
 updated from any cell... something that makes this backend stand out. From
 the Julia REPL, it taps into Blink.jl and Electron to plot within a
 standalone GUI window... also very cool.
>>>
>>>
>>> On Thu, Mar 10, 2016 at 2:03 PM, Daniel Carrera 
>>> wrote:
>>>
 On 10 March 2016 at 18:23, Tom Breloff  wrote:

>
> On Thu, Mar 10, 2016 at 12:08 PM, j verzani  wrote:
>
>> As someone who has watched his calculus students struggle with what
>> should be a trivial task -- the installation of `Plots` on `juliabox`, 
>> I've
>> wished it were part of base.
>>
>
> While in my (very biased) opinion I think Plots should be the first
> package new users install, I don't think it belongs in base.  (please 
> don't
> make me rebuild julia to hack on Plots ;)
>


 I think Plots could be part of the "standard library" (to borrow a term
 from Python). So it would not be in Base, but it could be pre-installed.
 Plotting is one of the most common things that scientists and engineers do.
 Maybe not right now, but when Plots is more mature.

 Speaking of which, I'm also having trouble with PlotlyJS.


 julia> plotlyjs()
 Plots.PlotlyJSPackage()

 julia> plot(Plots.fakedata(50,5),w=3)
 [Plots.jl] Initializing backend: plotlyjs
 INFO: Precompiling module Blink...
 INFO: Recompiling stale cache file
 /home/daniel/.julia/lib/v0.4/Nettle.ji for module Nettle.
 ERROR: Cannot find Electron. Try `AtomShell.install()`.
  in electron at
 /home/daniel/.julia/v0.4/Blink/src/AtomShell/process.jl:49
  ...


 For some reason, PlotlyJS seems to think that I am running it from
 Atom. :-(



>>>

Re: [julia-users] Re: a excellent Julia IDE, JuliaDT

[Mike Innes]

Yes, the old Juno on LightTable was starting to code rot badly – we've
taken those binaries down now. In Atom you'll find that you can get the
same features through the julia-client plugin.

On Thu, 10 Mar 2016 at 14:41 Daniel Carrera  wrote:

> I've had code crashes with Juno. So I just use Atom with syntax
> highlighting for Julia.
>
> Daniel.
>
>
> On Wednesday, 9 March 2016 12:27:50 UTC+1, Avik Sengupta wrote:
>>
>> Fair enough. Eclipse is, in many ways, a "buy into the ecosystem"
>> proposition. For many that do, that is the simplest way to work. But if you
>> don't, Juno/Atom is great, and Mike's been hard at work making it better.
>>
>> Regards
>> -
>> Avik
>>
>> On Tuesday, 8 March 2016 20:22:45 UTC, J Luis wrote:
>>>
>>> Ok, thanks ... but will wait for a simpler thing to use.
>>>
>>> terça-feira, 8 de Março de 2016 às 19:32:28 UTC, Avik Sengupta escreveu:

 Use the "Eclipse IDE for Java Developers". That should give you the
 least amount of cruft.

 Regards
 -
 Avik

 On Tuesday, 8 March 2016 19:00:22 UTC, J Luis wrote:
>
> A quick previous question. Which Eclipse version from the (many)
> available options should we install  (Java is completely out of my
> interest)?
>
> http://www.eclipse.org/downloads/
>
> Thanks
>
> terça-feira, 8 de Março de 2016 às 13:56:39 UTC, Liye zhang escreveu:
>>
>> If you are trying to find an IDE for Julia which is as convenient as
>> PyDev for python, or RStudio for R, you can test JuliaDT. Thanks for
>> the authors' excellent work!
>>
>> https://github.com/JuliaComputing/JuliaDT/releases/tag/v0.0.1
>>
>> More about this software,
>> http://juliacomputing.com/blog/2016/02/06/Eclipse-JuliaDT.html
>>
>

Re: [julia-users] Google Summer of Code 2016

[Mike Innes]

Sure thing, well if it's a question about admin or organisation you can go
ahead and email julia-gsoc-2...@googlegroups.com. For more technical
questions, or feedback on ideas and plans, you're always welcome to post on
this julia-users as well.

On Thu, 10 Mar 2016 at 04:39 Jorge  wrote:

> Thanks Mike! I'm preparing my proposal to apply as a student this year,
> so, just wanted to know who could I contact if I ever have a question for
> you guys!
>
>
> -J
>
> On Wednesday, March 9, 2016 at 4:28:51 PM UTC-6, Mike Innes wrote:
>
>> Hey Jorge, me and Shashi Gowda are organising GSoC this year and there
>> are a few others with admin access – why do you ask?
>>
>> On Wed, 9 Mar 2016 at 22:17 Jorge  wrote:
>>
>>> Hi Mike,
>>>
>>> Do you know who are Julia's GSoC 2016 org admins?
>>>
>>> Best,
>>> Jorge
>>
>>

Re: [julia-users] Google Summer of Code 2016

[Mike Innes]

Hey Jorge, me and Shashi Gowda are organising GSoC this year and there are
a few others with admin access – why do you ask?

On Wed, 9 Mar 2016 at 22:17 Jorge  wrote:

> Hi Mike,
>
> Do you know who are Julia's GSoC 2016 org admins?
>
> Best,
> Jorge

Re: [julia-users] GSoC project - "Calling Julia from Python"

[Mike Innes]

Hey Manu,

Glad to see you're interested in this project! There's already some work on
this over at pyjulia , and it'll
probably be relevant to take a look at PyCall.jl
 as well. I recommend starting out
by taking a look over those packages and seeing what issues they have and
where they can be improved. I'm sure you'd also be welcome to open issues
where you need to ask for help or start discussion. That'll help you get to
grips with things and introduce you to potential mentors as well.

Cheers,
Mike

On Sun, 6 Mar 2016 at 02:53 Manu Jain  wrote:

> Hi
>
> I am Manu Jain, a third year undergraduate in Computer Science and
> Engineering from IIIT-Hyderabad. I have a good knowledge of C,C++ and
> Python languages. I am interested in the project "Calling Julia from
> Python". I am reading about Julia from past 3-4 days and has developed
> quite interest in it. This project requires Julia as a separate package of
> python so it can be imported and called from python itself. Julia has many
> built-in libraries which can directly be called from python and thus easing
> user's work.
> Can someone guide to develop a more deeper understanding about this. Also
> is someone ready to mentor this project?
>
> Thanks
>
> Manu Jain
>

Re: [julia-users] The "contact mail" on the GSoC page does not exist

[Mike Innes]

Ok, it's julia-gsoc-2...@googlegroups.com

On Tuesday, 8 March 2016 03:38:39 UTC, Dawei Si wrote:
>
> I still get a failure after sending a mail to the new address..
>
> 在 2016年3月8日星期二 UTC+8上午12:37:34，Mike Innes写道：
>>
>> Whoops, sorry about that! The correct group is julia-soc-2014 and it 
>> should be fixed now.
>>
>> On Mon, 7 Mar 2016 at 16:34 Dawei Si  wrote:
>>
>>> https://summerofcode.withgoogle.com/organizations/6453977159827456/
>>>
>>> The mail address on the above page is juliasoc at googlegroups.com, 
>>> maybe it should be updated?
>>>
>>

Re: [julia-users] Google Summer of Code 2016

[Mike Innes]

My mistake; it's julia-gsoc-2...@googlegroups.com. Thanks for reporting.
On Wed, 9 Mar 2016 at 14:10 Tom Breloff  wrote:

> The julia-soc-2014 address doesn't work... is there another one to replace
> it?
>
> On Wed, Mar 9, 2016 at 8:53 AM, Mike Innes  wrote:
>
>> Hey All,
>>
>> As you may have heard by now, the Julia language is proud to be part of 
>> Google
>> Summer of Code
>> <https://summerofcode.withgoogle.com/organizations/6453977159827456/>
>> 2016! We’re inviting students to get paid to work on a Julia-related
>> project of their choice during their summer break. I’ll explain more about
>> how everyone can get involved below, and any questions can be directed to
>> this group or to the aptly-named julia-soc-2...@googlegroups.com.
>>
>> *Students*: Start by thinking about the kind of projects you’d like to
>> work on! As a starting point, there are a bunch of interesting projects on
>> our ideas page <http://julialang.org/soc/ideas-page>. At this stage,
>> it’s also a good idea to start getting involved with the community around
>> your area of interest by opening issues, sending PRs and speaking to
>> developers. Finding a good mentor for your project will be a big help for
>> most applications, and showing mentors your enthusiasm is a great way to
>> get them on board. Feel free to start discussions on this group, although
>> note that it’s easier for us to answer broad questions about the process
>> than to give specific technical feedback.
>>
>> *Everyone else*: If you happen to know any students, please let them
>> know! We’d also like to encourage people to step up as mentors, so if
>> you’re interested then please contact us at the above julia-soc group and
>> let us know what areas you’d like to help with. Please also feel free to
>> give technical feedback on proposals that come up on this list.
>>
>> Cheers,
>> Mike
>>
>
>

[julia-users] Google Summer of Code 2016

[Mike Innes]

Hey All,

As you may have heard by now, the Julia language is proud to be part of Google
Summer of Code
 2016!
We’re inviting students to get paid to work on a Julia-related project of
their choice during their summer break. I’ll explain more about how
everyone can get involved below, and any questions can be directed to this
group or to the aptly-named julia-soc-2...@googlegroups.com.

*Students*: Start by thinking about the kind of projects you’d like to work
on! As a starting point, there are a bunch of interesting projects on our ideas
page . At this stage, it’s also a good
idea to start getting involved with the community around your area of
interest by opening issues, sending PRs and speaking to developers. Finding
a good mentor for your project will be a big help for most applications,
and showing mentors your enthusiasm is a great way to get them on board.
Feel free to start discussions on this group, although note that it’s
easier for us to answer broad questions about the process than to give
specific technical feedback.

*Everyone else*: If you happen to know any students, please let them know!
We’d also like to encourage people to step up as mentors, so if you’re
interested then please contact us at the above julia-soc group and let us
know what areas you’d like to help with. Please also feel free to give
technical feedback on proposals that come up on this list.

Cheers,
Mike

Re: [julia-users] The "contact mail" on the GSoC page does not exist

[Mike Innes]

Whoops, sorry about that! The correct group is julia-soc-2014 and it should
be fixed now.

On Mon, 7 Mar 2016 at 16:34 Dawei Si  wrote:

> https://summerofcode.withgoogle.com/organizations/6453977159827456/
>
> The mail address on the above page is juliasoc at googlegroups.com, maybe
> it should be updated?
>

Re: [julia-users] Re: Concurrently install two versions of Julia

[Mike Innes]

You don't have to use Juno with the bundled copy of Julia, you can point it
to the external (0.4.3) version and use the same for both. Just poke around
in the settings and you should find the option.
On Mon, 7 Mar 2016 at 04:44 Vishnu Raj  wrote:

> In my system I have Juno with 0.4.2 and julia with 0.4.3. Every time I
> start one, all my packages are getting recompiled. They are all under same
> v0.4 folder and I think that's why this is happening.
> Is there a way to avoid this?
>
>
> On Sunday, March 6, 2016 at 3:28:40 PM UTC+5:30, Andreas Lobinger wrote:
>>
>> Depends on your definition of installed and what system you use. I use
>> since 0.2 (and the 0.3dev) a local build -on a linux system- and this quite
>> nicely encapsulated in a single directory inside my home so they live in
>> parallel. The package directory which is inside .julia is has versioning
>> (v0.3/v0.4/v0.5), too.
>>
>> On Saturday, March 5, 2016 at 11:48:37 PM UTC+1, Pulkit Agarwal wrote:
>>>
>>> Hi,
>>>
>>> Is there a way to have the stable version of Julia as the global Julia
>>> (i.e. something which can be accessed by calling `julia` from the command
>>> line) and the development version of Julia (which will be stored in some
>>> other folder).
>>>
>>> Thanks,
>>> Pulkit
>>>
>>

Re: [julia-users] Make the computer make a beep?

[Mike Innes]

In julia-client: client.handle 'beep', -> atom.beep()
In Atom.jl: beep() = @msg beep()

That will allow you to call `Atom.beep()` from Julia. However, it's a bit
moot if the function does nothing on your system anyway.

On OS X we show system notifications when evaluations are complete, which
is very handy and I guess it's what you're going for. Unfortunately it
doesn't seem to work on Windows by default but I can put some time into
fixing that (or you're of course welcome to take a look yourself).

On Sun, 28 Feb 2016 at 10:46 FQ  wrote:

> No i can't show you the two-liner, because it was Mike who suggested
> that and i have no idea ^^
>
> If you don't care where the beep comes from, you could also use the
> AudioIO package and just let your normal speaker play the beep
>
> using AudioIO
> play([sin(x) for x=0:0.03*pi:441])
>
> according to the docs on github, audioio should also work on windows.
>
> Am 28.02.2016 um 06:08 schrieb Chris Rackauckas:
> > Couldn't get Atom to buzz at all with atom.beep(). print(`\a`) only
> > works in the REPL and run(`beep`) doesn't work for me at all (on the
> > Windows computer). Could you show me that 2-line Julia function?
> >
> > On Saturday, February 27, 2016 at 4:11:53 PM UTC-8, FQ wrote:
> >
> > from normal REPL, you could do
> > print('\a')
> > which "prints" the bell character. i don't know how whether that
> works
> > for your configuration though.
> >
> > given there's the program beep available and working on your system,
> > you
> > could also do
> > run(`beep`)
> > note the backticks, see
> >
> http://docs.julialang.org/en/release-0.4/manual/running-external-programs/
> > <
> http://docs.julialang.org/en/release-0.4/manual/running-external-programs/
> >
> >
> >
> > Am 28.02.2016 um 00:39 schrieb Chris Rackauckas:
> > > Hey,
> > >   I was wondering about a quick way to make the computer beep when
> > code
> > > is finished. Usually there's a beep() function. The one in Julia at
> > > Base.Terminals.beep takes as input a terminal. Where do I find this
> > > terminal object? If it matters, I am using Juno with Atom.
> >
>
>

Re: [julia-users] Make the computer make a beep?

[Mike Innes]

As it happens, you can do this from Atom itself; `C-Alt-I` to get to the
dev tools and `atom.beep()`.

It would be easy (as in two lines) to expose this as a Julia function, and
I can help with that if you're interested.

Of course, there may well be a simpler way to do it directly within Julia ;)

On Sat, 27 Feb 2016 at 23:39 Chris Rackauckas  wrote:

> Hey,
>   I was wondering about a quick way to make the computer beep when code is
> finished. Usually there's a beep() function. The one in Julia at
> Base.Terminals.beep takes as input a terminal. Where do I find this
> terminal object? If it matters, I am using Juno with Atom.
>

Re: [julia-users] Re: Google Summer of Code 2016 - Ideas Page

[Mike Innes]

Hey Zheng – I'm no optimisation expert, but this looks like an interesting
proposal! I think your best bet would be to get in contact with someone who
*is* an optimisation expert, either by posting an issue on an appropriate
repo or by getting in touch directly. It'd be great to have someone we know
with some experience vouching for your idea.

On Mon, 15 Feb 2016 at 10:41 Zheng  wrote:

> I would like to propose a Julia optimization package for *Generic
> Frank-Wolfe* algorithm.
>
> This is an algorithm regaining popularity with this ICML article 2013
> 
> And there is future research on this direction since.
>
> This algorithm has a beautiful property when applied to the constrained
> optimization with the atom norm constrain, such as L1-norm, nuclear norm
> etc.. It embeds the sparsity into the solution searching process, and
> guarantees a linear convergence rate, and is optimal within the same
> sparsity.
>
> There exist currently some code in Matlab, Python and C. But they work all
> on specific problems such as Lasso, Matrix Completion, and not ready for
> deployment.
>
> It will be nice if we can realize a fast, generic Julia implementation. It
> will benefit both the academy and the industry, and probably bring a lot of
> citation to Julia.
>
> I would like to apply to this proposal as a *student*. I met this
> algorithm last summer and am interested in its development. I have also
> some idea about the multiple-level APIs to implement it. And I happen to
> have some interaction with the paper authors, which will be a plus to this
> project.
>
> I like Julia, and I have used it for one year. I have learned a lot from
> it, and am prepared to learn more. I hope to find a mentor who could help
> me (mainly) on the Julia side, which is the key of a fast and generic
> algorithm package. And if possible, it will be nice to have it be
> integrated into the JuliaOpt.
>
>
> Zheng
>
>
>
> On Thursday, February 11, 2016 at 4:49:19 AM UTC+1, Shashi Gowda wrote:
>
>> Hi all,
>>
>> I have merged the previous ideas pages (2015, 2014) into a canonical one
>> https://julialang.org/soc/ideas-page (and set up the appropriate
>> redirects)
>>
>> Please add your Summer of Code ideas and edit previous ones here
>> https://github.com/JuliaLang/julialang.github.com/edit/master/soc/ideas-page.md
>>
>> Let us also try and keep this page updated all year round so that ideas
>> get carried over to the next summer.
>>
>> Julia will be applying for GSoC 2016. The organization application
>> deadline is on 19th, it will be nice to have a high quality ideas page by
>> then.
>>
>> Thank you
>>
>

[julia-users] Re: [julia-dev] Re: Google Summer of Code 2016 - Ideas Page

[Mike Innes]

We definitely wouldn't be against having a really solid Julietta.jl /
GtkIDE.jl based application. There are pros and cons to all of the
different IDE approaches, and GSoC is a great opportunity to work on
whatever interests you the most!

In general, please don't be shy about adding ideas, or even just making
suggestions that we can fill out in detail – and feel free to ask us
questions if you're not sure about anything.

On Thu, 11 Feb 2016 at 09:51 Sisyphuss  wrote:

> Since Atom will be the canonical IDE for Julia, maybe the project juliette
> can be removed from that list.
>
>
> On Thursday, February 11, 2016 at 4:49:19 AM UTC+1, Shashi Gowda wrote:
>>
>> Hi all,
>>
>> I have merged the previous ideas pages (2015, 2014) into a canonical one
>> https://julialang.org/soc/ideas-page (and set up the appropriate
>> redirects)
>>
>> Please add your Summer of Code ideas and edit previous ones here
>> https://github.com/JuliaLang/julialang.github.com/edit/master/soc/ideas-page.md
>>
>> Let us also try and keep this page updated all year round so that ideas
>> get carried over to the next summer.
>>
>> Julia will be applying for GSoC 2016. The organization application
>> deadline is on 19th, it will be nice to have a high quality ideas page by
>> then.
>>
>> Thank you
>>
>

Re: [julia-users] Juno IDE

[Mike Innes]

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  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] Juno IDE

[Mike Innes]

Thanks for the feedback, it's always good to hear what teething problems
people have. Many of these things are one the roadmap and over the next
couple months we'll be aimed at making the first-time Juno experience
really good.

In particular:

1) Don't worry about the LT update. In fact, I highly recommend trying out
the Juno/Atom bundles instead; that's where our future work will be
happening, and we'll put bundles up officially on the website soon.

2) You can get a more recent Julia by downloading the bundle from the
website, *or* by downloading Julia separately and pointing Juno to it.

3) The use of commands is partly just the way that it works in LT/Atom.
It's pretty powerful in many ways, although to make things easier for
people getting started we will be sorting out menus / toolbars as well. (In
Atom this is under Packages->Julia)

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.

On Tue, 2 Feb 2016 at 05:23 David Blake  wrote:

> Hi guys, some help please.
>
> A while back I downloaded and installed Julia Studio and wrote 10-20
> little programs in it.  I found it quite good but now it's been
> discontinued of course.
>
> So I'm looking at Juno, but man I find it hard to use.  I've read a bit on
> here about it, but I still feel like I have no idea what I'm doing.  I'd
> very much appreciate some help with this:
>
> These are pretty basic questions, so please don't flame me.  I'm on
> Windows 10, 64 bit.
>
> 1) Every time I start Juno, it tells me a new binary version of LightTable
> (LT) is available and do I want to download it.  It doesn't sort of update
> automatically, just opens a link to the download site for LT.  So then I'm
> unclear as to what to do, I can download the LT binary but then what?  I
> have Juno, which is on top of LT, how to upgrade the underlying LT
> version?  Or should I just not worry about it?
>
> 2) Also, how would I upgrade the underlying Julia language to the latest
> version please?  In another site, I saw how to use versioninfo, it shows
> 3.10.
>
> 3) There seem to be very few commands available via the menu, but lots and
> lots via Ctrl-space.  I find this quite different to most IDEs.  Is this
> just the way LT works? And just a matter of getting used to it?  If so, I'm
> OK with that.
>
> 4) The workflow pattern I normally like to use with other languages like
> Python is to write my code in scripts and then run from a console,
> preferably all within an IDE.  So I use Spyder for Python and find it very
> good.  I'd like to use Juno the same way.  As opposed to say having a text
> editor open to code in, and a separate console window to run files from
> etc.  Do people use Juno like this? i.e. like a standalone thing?
>
> Any help appreciated.
>
>

Re: [julia-users] Re: a good IDE for Julia ? (Julia Studio does not work with Julia v 0.3.0)

[Mike Innes]

Since Juno/Atom came up, I'll mention that we've just posted some (beta)
bundles here . In theory,
they should be very easy to get going with; in practice, let me know how it
goes and we'll start to iron out the cracks.
On Tue, 26 Jan 2016 at 20:11 cdm  wrote:

>
> an ESS-Julia-mode appears available ...
>
>
> https://github.com/syl20bnr/spacemacs/blob/ef5a2ad5ee6362588244374364fe4ac2df066f37/layers/%2Blang/ess/packages.el#L41
>

Re: [julia-users] Julia vs Clojure for Distributed Scientific Simulations

[Mike Innes]

With Clojure you're likely to get much better deployment / networking
support, as well as the general robustness and tooling of the JVM. It's
also really expressive for data manipulation (though not necessarily fast).
Julia loses out on that but will blow Clojure out of the water for anything
more computationally advanced; numerics, fiddly data structures etc.

To over simplify the decision a little, I'd probably use Clojure for
something running indefinitely (e.g. web server) and Julia for something
finite (e.g. a simulation). But I think you just have to look at what you
expect the key pain points to be, and compare that to the strengths of each
language.

On Wed, 27 Jan 2016 at 04:07 George  wrote:

> I'm working on a scientific simulation that is going to require a
> distributed environment.  There has been some discussion about whether to
> use Julia or Clojure for this project.  A few micro benchmarks seem to have
> different results for each language.  I'm not yet sold as to which language
> may be more expressive in this situation, but Lisp might be a preferred
> option mathematically for modeling purposes.
>
> Does anyone have any practical experience in dealing with both of these
> languages and what your experiences were?
>
> Are there any meaningful benchmarks that compare the two, especially in a
> distributed environment?
>
>
> Thanks!
>
> -George
>

Re: [julia-users] Cumulative Profiling

[Mike Innes]

It might also be worth trying out the DevTools.jl profiler:
https://github.com/JunoLab/DevTools.jl

On Thu, 31 Dec 2015 at 19:32 Tim Holy  wrote:

> If I understand what you're asking, Profile.print(format=:flat) should do
> the
> trick.
>
> --Tim
>
> On Thursday, December 31, 2015 07:56:37 AM Cedric St-Jean wrote:
> > I like ProfileView.jl a lot, but there are times where a traditional flat
> > profiling output with `cumulative` would be more appropriate (eg. if I
> have
> > 10 expensive functions with 10 call sites each, it's hard to tell which
> > function to optimize in a heavily nested ProfileView visualization).
> > Profile.print gives me how many samples landed in this function exactly,
> > but I would like to know for each function F how many samples were caught
> > while F was on the call stack. Is there an easy way to get that?
> >
> > Cédric
>
>

Re: [julia-users] Mysterious boxing

[Mike Innes]

I think this is down to Julia avoiding specialisation on the `ykey` type in
`reshape`, which sometime happens if it's (heuristically) determined that
doing so will prevent large amounts of unnecessary code being generated.
You can always force specialisation with a type parameter:

reshape{T}(xs, ys, ykey::Type{Val{T}}) = begin

However, this is unnecessary if you make the types simpler. Changing
`::Type{Val{T}}` to `::Val{T}` and `Val{T}` to `Val{(1,3)}()` will do the
trick if you want to stick with that approach, but just use a tuple
directly:

@generated construct(key::Tuple, value) = begin
  :(begin
  $(Expr(:meta, :inline))
  tuple($([:(value[key[$i]]) for i in 1:length(key.parameters)]...))
end)
end

reshape(xs, ys, ykey) = begin
  for x in xs
push!(ys, construct(ykey, x))
  end
  return ys
end

reshape([(10,11,12),(13,14,15)],NTuple{2,Int}[],(1,3))

Above: 0.021351 seconds (500.00 k allocations: 30.518 MB, 17.76% gc time)
Type{Val{T}} reshape2: 0.021599 seconds (500.00 k allocations: 30.518 MB,
19.60% gc time)


On Tue, 29 Dec 2015 at 07:16 Jamie Brandon  wrote:

> I have two versions of this reshape function -
> https://gist.github.com/jamii/62b3c3695fba95f3f09b
>
> The produce near-identical ast from code_warntype -
> https://www.diffchecker.com/awnv9zvv
>
> But code_lowered shows that reshape naively boxes tuples whereas reshape2
> does something much more complicated -
> https://www.diffchecker.com/jb6aurpl
>
> The result is that reshape2 is much faster:
>
> reshape: 0.316513 seconds (2.00 M allocations: 95.036 MB, 5.41% gc time)
> reshape2:  0.218963 seconds (41 allocations: 34.001 MB, 0.85% gc time)
>
> What's going on? How can I make reshape avoid boxing?
>

Re: [julia-users] Re: Juno bundles for Julia v0.4

[Mike Innes]

Randy – for the detection you could try `isdefined(Main, :Jewel)`.
Unfortunately we don't have a good approach to dependencies yet (I think
Gadfly just dumps in its dependencies with every plot) but this is
something I'll be looking into as part of the Atom work. From your tweets
it looks like Vega is coming along really nicely, so I'm going to have to
start playing around with it, and I'll help with getting it integrated
where I can.

Sheehan – it looks like the signing may have failed on the OS X release.
For now, right clicking and selecting "open" should do the trick.

On Sun, 20 Dec 2015 at 02:43 Sheehan Olver  wrote:

> Hmm, double clicking Juno doesn't work (Says "Application can't be
> opened") but running Juno.app/Contents/MacOS/Electron works fine.  This is
> on El Capitan
>
>
> On Saturday, December 19, 2015 at 3:24:39 AM UTC+11, Mike Innes wrote:
>>
>> Hey All,
>>
>> Juno bundles including Julia v0.4 are now available on the Julia
>> downloads page <http://julialang.org/downloads/>. If you're still using
>> Juno with Julia v0.3 the upgrade is definitely recommended – among other
>> things, features like precompilation make using packages like Gadfly much
>> easier. Enjoy!
>>
>> Cheers,
>> Mike
>>
>

Re: [julia-users] Re: Operations on TypeVars

[Mike Innes]

I think you can get what you want with

foo{T}(::V{5,T}) = print("hello I'm spechial")

On Sat, 19 Dec 2015 at 10:45 Kristoffer Carlsson 
wrote:

> Found some discussion here:
> https://github.com/JuliaLang/julia/issues/7311#issuecomment-46563315
>
>
> On Saturday, December 19, 2015 at 11:43:39 AM UTC+1, Kristoffer Carlsson
> wrote:
>>
>> Slightly related.
>>
>> Are there any issues regarding explicit specialization of parameterized
>> methods (on value)?
>>
>> immutable V{N, T}
>>a::NTuple{N,T}
>>  end
>>
>> foo{N, T} = print("hello")
>>
>> v = V{5, Float64}((1.0,2.0,3.0,4.0,5.0))
>>
>> foo(v)
>> # hello
>>
>> # Explicit specialization, nope:
>>
>> foo{5, T}(::V{5,T}) = print("hello I'm spechial")
>> # ERROR: syntax: malformed type parameter list
>>
>>
>>
>> On Friday, December 18, 2015 at 10:36:42 PM UTC+1, Kristoffer Carlsson
>> wrote:
>>>
>>> Thanks for the link.
>>
>>

[julia-users] Juno bundles for Julia v0.4

[Mike Innes]

Hey All,

Juno bundles including Julia v0.4 are now available on the Julia downloads
page . If you're still using Juno with
Julia v0.3 the upgrade is definitely recommended – among other things,
features like precompilation make using packages like Gadfly much easier.
Enjoy!

Cheers,
Mike

Re: [julia-users] Writing a function for two different types, avoiding code duplication

[Mike Innes]

myf(x::Union{T1,T2}) sounds like it would do the trick for you.

On Thu, 17 Dec 2015 at 10:45  wrote:

> Hi,
>
> I'm writing a module inside which I want to define a function for two
> different types T1 and T2 that are defined outside the module, and there is
> no relation available (they are not subtypes of another type...).
> How could I write only one function instead of having code duplication?
>
> Currently, my code is as follows:
>
> function myf{T1}(x::T1)
> ...
> end
>
> function myf{T2}(x::T2)
> ...
> end
>
> I'd like a mechanism similar to:
>
> function myf{T <: Real}(x::T)
> ...
> end
>
> Ideally something like (I know this doesn't work, that's just the idea):
>
> function myf{T in [T1, T2]}(x::T)
> ...
> end
>
> Is such a thing possible?
>
> Many thanks.
>

Re: [julia-users] Re: File downloading and caching best practices?

[Mike Innes]

For the download step, just run `curl -O $url` or something similar. The
`download` function in Base tries to use some API call on Windows, but
since the Julia distribution includes Curl anyway you can just use that
safely on all platforms.

On Wed, 2 Dec 2015 at 09:48 Milan Bouchet-Valat  wrote:

> Le mercredi 02 décembre 2015 à 00:47 -0800, Mohammed El-Beltagy a écrit
>  :
> > I don't think your package directory is good place for file caching.
> > It would be better to put your caches in the system's temporary
> > directory, for Mac (also check echo $TMPDIR) and Linux that is at
> > "/tmp" for windows it is at "C:\Users\\AppData\Local\Temp"
> > (check ECHO %Temp%)
> I don't know for Windows, but for Linux /tmp is usually cleaned on
> reboot or even every few hours. A possible place would be
> $XDG_CACHE_HOME/$YOUR_PACKAGE, with ~/.cache/$YOUR_PACKAGE as a
> default.
>
> But storing data inside the Julia package dir sounds like a logical
> solution. Maybe we could have an explicit policy about this, and
> standardize on a subdirectory name ? Please file an issue on GitHub to
> discuss this unless some developers chime in.
>
>
> Regards
>
>
> > On Tuesday, December 1, 2015 at 8:18:27 PM UTC+2, Penn Taylor wrote:
> > > I'm working on a package that downloads and caches large datasets.
> > > The user accesses information in the datasets via the package, but
> > > likely has no interest in otherwise having direct access to the raw
> > > files. In this early stage, my package uses Base.download to grab
> > > the files, and then stores them in Pkg.dir("MyPackageName")/cache.
> > > This works great, but I have some concerns about the strategy that
> > > I'd like input/advice on.
> > >
> > > 1. Downloading
> > > Base.download includes this warning in its documentation: "For
> > > production use or situations in which more options are needed,
> > > please use a package that provides the desired functionality
> > > instead."
> > >
> > > I don't need more options, but the "production use" part leads me
> > > to believe I shouldn't rely on Base.download inside a package. Is
> > > there a particular package that most people tend to use for
> > > fetching remote uris from within another package? Or is
> > > Base.download generally "good enough" for use in my situation?
> > >
> > >
> > > 2. Caching
> > > I haven't found information on whether package directories are
> > > guaranteed to be user-writable, so don't know whether my caching
> > > location is likely to be problematic. Is
> > > Pkg.dir("MyPackageName")/cache generally a good place for this kind
> > > of file caching, or is there a different location or pattern that
> > > is preferable for a package?
> > >
> > > Thanks,
> > > Penn Taylor
> > >
>

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

[Mike Innes]

I'm not necessarily saying google groups is fundamentally bad for
discussion, e.g. if you set up a daily digest and such, just that for most
people here it's not the expectation. For the most part every email you
send to -users ends up in the inbox of every Julia dev and many more in the
community. That's a great set up for getting fast feedback and help from
the right person, but it's much less convenient when there's a lot of
back-and-forth between a subset of users.

But I take your point – we could use more guidelines about what the
expectations actually are, as well as alternatives for people who want to
have those kinds of discussions.

On Thu, 17 Sep 2015 at 20:09 Daniel Carrera  wrote:

> On 17 September 2015 at 17:33, Mike Innes  wrote:
>
>>
>> Quick meta-note about this thread: I think it's important to emphasise
>> that the julia-users list isn't designed to handle this kind of open-ended
>> discussion. It's not that discussion is bad per se, but this list has a lot
>> of subscribers who are mostly interested in sharply-focused technical
>> issues – usually announcements or giving and receiving help. Topics that
>> involve, say, debating the merits of various technologies are better suited
>> to platforms such as reddit with features like comment threads for
>> tangents, more focused notifications for other users, etc.
>>
>
> I don't agree. A Google group is well designed for open-ended discussion.
> I receive a daily digest, where I can scan topics and subscribe only to the
> ones that I find interesting. Also, the Julia community page does not
> recommend any other forum for general discussion besides the users group.
> Nor have am I aware of any official policy that when threads reach some
> number of posts the participants are expected to relocate to Reddit. When
> the time comes, and a new group is made for open-ended discussion about
> Julia, I will be happy to subscribe to that group.
>
> Just my two cents.
>
> Cheers,
> Daniel.
>
>
>
>
>
>
>

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

[Mike Innes]

Hey folks,

If you're interested in Juno/Atom you might like to check out the demos
 I just published which give an idea
of some of the UI work we've done so far. Like any tool, Atom certainly
isn't going to be Everybody's Everything, but you might be pleasantly
surprised how far we can push it towards being a fully-featured IDE.
(Although really, the core utility of the IDE is not so much the flashy ui
bits so much as the improved workflow it enables – more on that here

).

Alternative approaches are welcome and even encouraged, but I really think
that Atom provides the fastest route to a high-quality Julia IDE – and if
you want to speed that along even more, it's well worth poking around in
the code to see where you can make improvements. It's pretty easy to get
into and we're more than happy to help out where we can.

Quick meta-note about this thread: I think it's important to emphasise that
the julia-users list isn't designed to handle this kind of open-ended
discussion. It's not that discussion is bad per se, but this list has a lot
of subscribers who are mostly interested in sharply-focused technical
issues – usually announcements or giving and receiving help. Topics that
involve, say, debating the merits of various technologies are better suited
to platforms such as reddit with features like comment threads for
tangents, more focused notifications for other users, etc.

– Mike

On Thu, 17 Sep 2015 at 15:24 Daniel Carrera  wrote:

> On 17 September 2015 at 15:57, Kristoffer Carlsson 
> wrote:
>
>> Look up GitSavy if you want git integration in Sublime.
>>
>> I guess different people have different tolerances to latency. I try atom
>> over and over because it is open source and I want it to be the best but
>> everytime it feels like running through syrup.
>
>
>
> It might also depend on our use case. For instance, I never close Atom, so
> I wouldn't notice if it is slow to start up. Maybe I also have smaller or
> fiewer files than you do.
>
> Cheers,
> Daniel.
>
>
>

Re: [julia-users] Re: Juno + Julia 0.4

[Mike Innes]

Actually, I've spent some time over the last couple days updating Jewel
etc. to work with Julia v0.4 as well as 0.3. The Juno/LT bundles will
probably be around for a little while longer – at least until Juno/Atom
reaches feature parity, I think.

If you're using Juno/LT with 0.4 currently I'd appreciate feedback on what
works and doesn't – I should get round to uploading new 0.4-rc1 bundles
fairly soon.

On Tue, 15 Sep 2015 at 13:00 Nils Gudat  wrote:

> Yes, it does (that's the point of having the bundle(!) available on the
> website).
> To connect to a different instance of Julia, follow the steps here:
> http://junolab.org/docs/install-manual.html
> However, I don't think JunoLT is working with 0.4 (at least it wasn't when
> I last checked two weeks ago), and in general efforts have shifted to the
> new Juno Atom client.
>
> Long story short, if you want to work in 0.4 you should probably do this:
> https://github.com/JunoLab/atom-julia-client/tree/master/manual
>

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

[Mike Innes]

My experience with Discourse so far has been pretty good, but I haven't had
enough volume over there to really test the moderation tools, maintenance
requirements and so on. It's certainly functional but I couldn't say for
certain that the value-add is worth the disruption and effort of moving.

If a small pool of users here are interested, I don't mind people
piggy-backing on the Juno board for Julia discussion as something of a
trial run – if people find that it works really well then we can always
discuss next steps from there.

On Thu, 10 Sep 2015 at 16:41 Nils Gudat  wrote:

> The Rust example probably explains this:
> https://youtu.be/pYYmnBma9qk?list=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM&t=337
> :)
>

Re: [julia-users] julian style for assignments in a try block?

[Mike Innes]

Would `t, data = try take!(outbox) catch ...` work?

On Thu, 3 Sep 2015 at 22:08 Spencer Russell  wrote:

> I often find myself wanting to do an assignment inside a try...catch
> block, as in the following real-world code I'm working on to read from a
> Channel until it's closed
>
> global outbox = Channel()
> @async while true
> try
> t, data = take!(outbox)
> catch e
> # InvalidStateException is thrown when the channel is closed
> isa(e, InvalidStateException) || rethrow(e)
> break
> end
> println(sock, json(c(t, data)))
> end
>
> But the problem is that try...catch blocks introduce their own scope, so t
> and data don't exist after the exception handling. One thing I've done
> before is introducing the variables before the try block, (t = nothing;
> data = nothing) block before the try...catch, but that kills the type
> stability of the variables and doesn't feel right.
>
> Is there a more Julian idiom for this sort of thing?
>
> Thanks,
> -s
>

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

[Mike Innes]

FWIW I mocked up a json syntax macro:

using MacroTools, Lazy

import MacroTools: prewalk

function prockey(key)
  @capture(key, (a_:b_) | (a_=>b_)) || error("Invalid json key $key")
  isa(a, Symbol) && (a = Expr(:quote, a))
  :($a=>$b)
end

function procmap(d)
  @capture(d, {xs__}) || return d
  :(Dict{Any, Any}($(map(prockey, xs)...)))
end

macro json(ex)
  @>> ex prewalk(procmap) esc
end

Michael's original example becomes:

data = @json {
displayrows: 20,
cols: [
{ col: "l1" },
{ col: "l2" },
{ col: "l3" },
{ col: "num", display: true },
{ col: "sum", display: true, conf: { style: 1, func: {
method: "sum", col: "num"  } } }
]
  # ...
}

You might argue that it's actually nicer than the original.

On Thu, 3 Sep 2015 at 21:22 Scott Jones  wrote:

> Another use is marking off the keyword arguments or parameters.
>
>
> On Thursday, September 3, 2015 at 3:11:34 PM UTC-4, Jonathan Malmaud wrote:
>>
>> What are the other uses of ; in Julia? I can only think of suppressing
>> output on the REPL and separating expressions on a single line - neither
>> seems inconsistent or really related at all to the use within [].
>>
>> On Thursday, September 3, 2015 at 3:06:22 PM UTC-4, Scott Jones wrote:
>>>
>>>
>>>
>>> On Thursday, September 3, 2015 at 1:47:07 PM UTC-4, Sean Marshallsay
>>> wrote:

 [1:10;] is simply a consequence of matrix literal syntax (like [1:10;
 11:20]) and gets translated into vcat(1:10). It might be a bit confusing
 but there's no point in making it a special case

>>>
>>> Yes, I understand that, and that too is not consistent with the use of ;
>>> outside of [ ].
>>> spaces, colon, semicolon, and commas are all treated specially instead
>>> of [ ], which can be rather confusing.
>>> Some of that special behavior is being deprecated, but some remains.
>>>
>>>
>>

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

[Mike Innes]

You might consider creating an alias, e.g.

d(xs...) = Dict{Any, Any}(xs...)

d(:a=>1, :b=>2)

It's not as nice, but it's not awful either. You could also do

macro d(xs...)
  for x in xs
@assert x.head == :(=>)
isa(x.args[1], Symbol) && (x.args[1] = Expr(:quote, x.args[1]))
  end
  :(Dict{Any, Any}($(map(esc, xs)...)))
end

@d(a=>1, b=>2)

Saving on the colons might just be enough to make the lack of literal
syntax less painful.

On Wed, 2 Sep 2015 at 18:45 Michael Francis  wrote:

> With the change to 0.4 happening soon I'm finding the the new Dict syntax
> in 0.4 (removal of {}, []) is extremely verbose.
>
> I find myself interfacing with JSON APIs frequently, for example a
> configuration dictionary :
>
> data = {
> :displayrows => 20,
> :cols => [
> { :col => "l1" },
> { :col => "l2" },
> { :col => "l3" },
> { :col => "num", :display => true },
> { :col => "sum", :display => true, :conf => { :style
> => 1, :func => { :method => "sum", :col => "num"  } } }
> ]
>... # Lots more
> }
>
> becomes -
>
> data = Dict{Symbol,Any}(
> :displayrows => 20,
> :cols => [
> Dict{Symbol,Any}( :col => "l1" ),
> Dict{Symbol,Any}( :col => "l2" ),
> Dict{Symbol,Any}( :col => "l3"   ),
> Dict{Symbol,Any}( :col => "num", :display => true ),
> Dict{Symbol,Any}( :col => "sum", :display => true, :conf
> => Dict{Symbol,Any}( :style => 1,
> :func
> => Dict{Symbol,Any}( :method => "sum", :col => "num" ) ) )
> ]
>... # Lots more
> )
>
> This feels like asking a person using arrays to write the following
>
> Array{Int64,2}( Vector{Int64}( 1,2,3), Vector{Int64}( 4,5,6) )
>
> vs
>
> [ [ 1, 2, 3] [ 4,5,6 ] ]
>
> Can we please reconsider ?
>
>

Re: [julia-users] Re: PSA: Changes to Base Docstrings

[Mike Innes]

Hey all,

Really good to see the enthusiasm about this change. If you're interested
in helping out with the final parts of the transition, head on over to
https://github.com/JuliaLang/julia/pull/12703

– Mike

On Sat, 8 Aug 2015 at 13:36 Joshua Adelman  wrote:

> Public service announcement. It's actually on that Wikipedia page under
> the "other" section:
> https://en.m.wikipedia.org/wiki/Public_service_announcement
>
> Josh
>
> On Aug 8, 2015, at 8:15 AM, Uwe Fechner  wrote:
>
> Hello,
> what does PSA in the title mean?
>
> Wikipedia didn't help: https://en.wikipedia.org/wiki/Psa
>
> Uwe
>
> Am Sonntag, 2. August 2015 21:22:03 UTC+2 schrieb Mike Innes:
>>
>> Hi All,
>>
>> As of #11943 <https://github.com/JuliaLang/julia/pull/11943>, Julia uses
>> the shiny new doc system to provide help for functions in the REPL.
>> Previously, docstrings were stored in ReStructured text files
>> <https://github.com/JuliaLang/julia/tree/master/doc/stdlib> as part of
>> the manual, but now all docstrings are kept in Base
>> <https://github.com/JuliaLang/julia/blob/master/base/docs/helpdb.jl> and
>> the rst docs are automatically generated.
>>
>> What this means immediately is that any updates to Base docstrings must
>> happen in the helpdb.jl file
>> <https://github.com/JuliaLang/julia/blob/master/base/docs/helpdb.jl>, as
>> opposed to the RST docs. Note that it's still fine to edit the main body of
>> the manual; only function docstrings, which can be identified by the `..
>> function::` syntax, are affected by this change.
>>
>> Right now everything is in one big file, but we'd like to move the
>> docstrings to appropriate places in Base and convert them to Markdown.
>> We'll need some help with that, as there are a *lot* of docstrings, but
>> when we're ready we'll send out a call for help so that people can get
>> involved.
>>
>> There's still a lot of work to do, but I think this will be a big step
>> forward for documentation in Julia.
>>
>> – Mike
>>
>

[julia-users] PSA: Changes to Base Docstrings

[Mike Innes]

Hi All,

As of #11943 , Julia uses
the shiny new doc system to provide help for functions in the REPL.
Previously, docstrings were stored in ReStructured text files
 as part of the
manual, but now all docstrings are kept in Base
 and
the rst docs are automatically generated.

What this means immediately is that any updates to Base docstrings must
happen in the helpdb.jl file
, as
opposed to the RST docs. Note that it's still fine to edit the main body of
the manual; only function docstrings, which can be identified by the `..
function::` syntax, are affected by this change.

Right now everything is in one big file, but we'd like to move the
docstrings to appropriate places in Base and convert them to Markdown.
We'll need some help with that, as there are a *lot* of docstrings, but
when we're ready we'll send out a call for help so that people can get
involved.

There's still a lot of work to do, but I think this will be a big step
forward for documentation in Julia.

– Mike

Re: [julia-users] Juno - Orphan messages W7-64

[Mike Innes]

I've seen this before a couple of times but it shouldn't happen too often.
If it does, your best bet is to just close and open the current editor.

Unfortunately, there have been a few issues like this with Light Table
recently – it's not getting much maintenance effort. We're working on ways
of moving forward IDE-wise and will have more concrete plans to announce
soon.

On Tue, 28 Jul 2015 at 11:45 Joe Tusek  wrote:

> In Juno when I get errors in my code I get pink message boxes either
> inline or at the end or both. But after a while I get an accumulation of
> boxes and I cannot clear them. They just stack up and clutter the editor
> space. Right clicking on the older ones only gives an evaluate and other
> not useful options. If I inspect the box and remove it right away without
> leaving it there, then it appear to not be a problem. In general, a lack of
> an ability to close any message box or any pop-up at will seems
> undesirable.
>

Re: [julia-users] Re: :(a.b)

[Mike Innes]

This is a good example of where the MacroTools
 package comes in handy:

@match :(a.b) begin
  x_.y_ => (x, y)
end
# (:a, :b)

Since you don't have to worry about the internal structure of the
expression.

On Sun, 26 Jul 2015 at 23:21 David Gold  wrote:

> Perhaps it's related to the fact that `getfield` takes a `Symbol` argument:
>
>
>
> julia> type MyType
>b
> end
>
> julia> a = MyType(10)
> MyType(10)
>
> julia> getfield(a, :b)
> 10
>
> So you could just do `getfield(x, $(rhs.arg[2]))`.
>
> On Sunday, July 26, 2015 at 6:00:58 PM UTC-4, Cedric St-Jean wrote:
>
>> Why is . non-symmetric in a and b?
>>
>> > :(a.b).args
>>
>> 2-element Array{Any,1}:
>>  :a
>>  :(:b)
>>
>>
>> The second argument is a quotenode, how am I supposed to get to the :b
>> inside it? eval works, but in the Lisp world, that was bad style. I've
>> got a macro that works on this expression, and instead of
>> x.$(rhs.arg[2])
>>
>> I have to write
>>
>> x.$(eval(rhs.arg[2])
>>
>> Cédric
>>
>

[julia-users] Re: Juno/LightTable - "Connected to Julia" but cannot evaluate

[Mike Innes]

Have you tried using `Ctrl-Enter` to evaluate instead of the right click 
menu?

On Thursday, 16 July 2015 21:16:55 UTC+1, Eric Forgy wrote:
>
> julia> versioninfo()
> Julia Version 0.3.10
> Commit c8ceeef* (2015-06-24 13:54 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: AMD Opteron(tm) Processor 4171 HE
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Barcelona)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> -
>
> Hi,
>  
> I was happily using Juno/LightTable on MacOS and now I am trying to 
> install Juno/LightTable (version 0.7.2) on a Windows VM on Azure. Here are 
> my user.behaviors:
>
> [
>  ;; The app tag is kind of like global scope. You assign behaviors that 
> affect
>  ;; all of Light Table to it.
>  [:app :lt.objs.style/set-skin "dark"]
>  [:app :lt.objs.plugins/load-js "user_compiled.js"]
>  [:app :lt.objs.langs.julia/julia-path "C:\\Program 
> Files\\Julia-0.3.10\\bin\\julia.exe"]
>  ;; The editor tag is applied to all editors
>  [:editor :lt.objs.editor/no-wrap]
>  [:editor :lt.objs.style/set-theme "june-night"]
>  ;; Here we can add behaviors to just clojure editors
>  [:editor.clojure :lt.plugins.clojure/print-length 1000]
>  ;; Behaviors specific to a user-defined object
>  [:user.hello :lt.plugins.user/on-close-destroy]
>  ;; To subtract a behavior, prefix the name with '-' e.g.
>  ;;  [:app :-lt.objs.intro/show-intro]
> ]
>
> When I launch LightTable, it says "Spinning up Julia" and then after a few 
> seconds, it says "Connected to Julia". However, when I try to highlight or 
> select any code and right-click, the "Evaluate" option is greyed out so I'm 
> not able to run any code.
>
> Any ideas?
>
> Thanks a lot!
>  
>

Re: [julia-users] Re: Julia-lang TCO / femto-lisp TCO

[Mike Innes]

It's a neat trick; Clojure
 actually
uses the same idea, built into the standard library, because while Clojure
is functional the JVM doesn't support TCO either (boo!). You have to admit,
though, that the UI for this is pretty lacking; just convert all your
functions to return closures and call them through `trampoline`? Hmm...
surely we can do better than that, right?

Seeing this thread I figured I'd take up the challenge, and I last night I
managed to trim this down to:

using Lazy

@bounce even(n) = n == 0 ? true : odd(n-1)
@bounce odd(n) = n == 0 ? false : even(n-1)

even(10^6)

Tada! Just wrap your functions in @bounce and you're done, no brainpower or
funny business at the callsite required. It's also just as fast as Zach's
by-hand version (which is to say not very).

Technically this covers all tail recursion, but for simple cases you
probably want the faster (though more limited) @rec macro, which takes
Steven Johnson's excellent advice so you don't have to; i.e. it transforms
your code into a nice loop for you. I was testing this recently and
realised that

@rec zero(n) = n == 0 ? n : zero(n-1)

actually gets optimised down to `return 0`, which is pretty neat.

Not sure if this will actually be useful to anyone, but there we have it.

On Wed, 8 Jul 2015 at 00:11 Stefan Karpinski  wrote:

> You can only do TCO if the recursive call is in tail position, which
> implies that you are linearly traversing the data structure and not doing
> any backtracking. In which case you *can* just use a loop. The value
> proposition of using recursion to traverse a recursive data structure (e.g.
> visiting all the nodes in a tree) is that you can avoid keeping an explicit
> stack of nodes to revisit by using the implicit function call stack. If you
> can do TCO, however, that necessarily implies that you didn't need a stack
> – implicit or explicit – which means that you can do it with a loop.
>
> On Wed, Jul 8, 2015 at 12:50 AM, Steven Sagaert 
> wrote:
>
>> The point was doing it using recursion not iteration. When the data
>> structures themselves are recursive, a recursive algorithm can be a lot
>> simpler/shorter/more elegant than iteration. That's kind of the whole point
>> of functional programming.
>>
>>
>> On Tuesday, July 7, 2015 at 9:28:01 PM UTC+2, Steven G. Johnson wrote:
>>>
>>>
>>>
>>> On Tuesday, July 7, 2015 at 11:11:19 AM UTC-4, Steven Sagaert wrote:

 see http://blog.zachallaun.com/post/jumping-julia to work around not
 having TCO and still use recursion to traverse LARGE data structures
 without stackoverflow. That's also how a bunch of other languages (e.g.
 Scala & F#) do this (called "trampolining").

>>>
>>> (You could also just use a loop.)
>>>
>>
>

Re: [julia-users] Documentation system

[Mike Innes]

Ease of reading and writing are definitely the most important factors (for
humans more so than computers). Doc strings are often read in the source
file or in a terminal, for example, so they need to be readable as-is, and
writing them shouldn't be a burden.

Actually though, Markdown is just the default – you can use anything you
want for docs, including RST. Just create an rst"blah" string macro that
builds an RST("blah") object, or similar, and you're halfway there. Of
course, you'll miss out on tooling we build for Markdown (e.g. formatting
in the repl, text searches etc.) unless you implement it yourself. But you
could make an RSTDoc package that does all of that stuff, if you really
want it.

On 24 May 2015 at 14:54, Yuri D'Elia  wrote:

> Hi everyone,
>
> I'm just wondering, why markdown is being used for the built-in
> documentation as opposed to rst? I guess emergent convention?
>
> Since sphinx is used to build the manual, I would have preferred to have
> the same formatting at least as an option. I was able to successfully
> reuse inline rst documentation in python projects to build parts of the
> manual, saving myself to rewrite good chunks of text.
>
> But I admit I'm partial to rst because of that (I use it everywhere I can).
>
> Is md maybe slightly shorter or has some advantage I don't immediately
> see? Easier/faster to parse?
>
>

Re: [julia-users] Julia in LightTable is slow

[Mike Innes]

This has come up on some OSs with the node-webkit version of LT. See this
thread for one workaround:

http://discuss.junolab.org/t/editing-julia-code-is-very-slow-due-to-slow-suggestions/212

On 25 April 2015 at 17:46, Bo Ning  wrote:

> I want to use LightTable instead of Juno because I could run python,
> Julia, LaTex (LiTeX) at the same time. However, I found when I use Julia in
> LightTable, the typing becomes very slow. When I type a word, I may need to
> wait several seconds. Anyone has similar problem?
>
>

Re: [julia-users] Re: "Newbie" issue tag?

[Mike Innes]

Part of the issue is figuring out what "Newbie" means. New to programming?
Experienced in programming, but new to Julia? Experienced in Julia, but new
to Base? New to open source? Arguably all of these are valid targets, but
mixing them together ends up not being that helpful since people still have
to sort through them.

I agree with what Tomas has said about writing packages. I can definitely
understand people wanting to contribute to Base, but if you just want to
get some code out there and/or get a taste of the process contributing to
packages will be much quicker and easier.

The great thing about Julia's early stage is that (a) it's really easy to
find holes in functionality and (b) if you fill those holes, chance are
you'll have "the package" for that functionality, and people are actually
going to use it. On top of that, you're much more likely to be interested
in the work. That's a really great opportunity IMO.

It's easy enough to pick something you're interested in and, depending on
your level of confidence, start from scratch, port it from another
language, experiment, whatever. As one option, the web stack is
particularly ripe for development right now. (Which is a polite way of
saying that there isn't much of one.)

On 8 May 2015 at 07:03, Tomas Lycken  wrote:

> I just want to put some emphasis on what Scott hinted at: if you want to
> contribute to Julia, start with figuring out what *you* know a little about.
>
> Sometimes there's code in base that does some of those things, but not all
> of them, and/or not as well as you know how to.
>
> Sometimes there's not a place in base for your problem domain, but I've
> found that contributing to a package (or building a new one) is just as
> good a way to get started writing some Julia code. And chances are pretty
> high that after a while you stumble upon something in base that needs
> improvement for your package development to be as easy as possible - voila!
> We've found someplace in base for you to contribute :)
>
> Bottom line is, it's usually pretty easy to write Julia code as long as
> you know what the code should do - the hard part is finding something that
> you know how to do (and where to put the code that does it).
>
> // T

Re: [julia-users] Juno LightTable Freezes Using images.jl

[Mike Innes]

What OS is this on? Your best bet here, if you can, is to reproduce this in
the terminal REPL ("open a terminal repl" command) and file an issue on
Images.jl.

On 3 April 2015 at 00:49, will ship  wrote:

> So have discovered weird behaviour in Juno LightTable (which I have been
> using without issue for sometime now)..
>
> When using Images.jl package with following code
>
> using Images, Color, FixedPointNumbers, ImageView
>
> img=imread(1.png")
> show(img)
>
> props=properties(img)
> A=data(img)
>
> Julia spins then crashes on trying to assign data(img) to A..
>
> The same exact code works fine in Julia from the command line...
>
> Using LightTable 9.1 and Julia 0.3.1
>
> Any help greatly appreciated
>
> Cheers Will
>
>

Re: [julia-users] calling c functions from dll works in Juno but not Julia REPL

[Mike Innes]

Looks like a really helpful report – thanks!

On 3 April 2015 at 16:38, Siyi Deng  wrote:

> Hi, following your suggestion, I opened a new issue on Julia repo:
> https://github.com/JuliaLang/julia/issues/10734
>
>
> On Friday, April 3, 2015 at 7:15:19 AM UTC-7, Mike Innes wrote:
>>
>> Would you be able to produce a minimal test case that works in the 0.3.4
>> REPL but not in 0.3.7, then file that as an issue on the Julia repo?
>>
>> On 3 April 2015 at 15:09, Siyi Deng  wrote:
>>
>>> Hi Mike:
>>> I followed your suggestion , the Julia version used by Juno was 0.3.4
>>> and the standalone REPL was 0.3.7 (all x86_64-w64-mingw32), so indeed it
>>> seems that new version introduced a bug of some kind.
>>>
>>>
>>>
>>>
>>>
>>> On Friday, April 3, 2015 at 3:12:47 AM UTC-7, Mike Innes wrote:
>>>>
>>>> Well, this is the first time it's happened this way around :)
>>>>
>>>> The first thing I would do is open the copy of Julia that Juno is
>>>> running using the "open a terminal" command, and see whether that gives the
>>>> right results. If the version is different, a bug may have been introduced
>>>> by a backport or something similar.
>>>>
>>>> On 3 April 2015 at 05:50, Kevin Squire  wrote:
>>>>
>>>>> Hi Siyi,
>>>>>
>>>>> Can you give a short example of your code?  It's generally pretty hard
>>>>> to debug these things without that.
>>>>>
>>>>> Cheers!
>>>>>Kevin
>>>>>
>>>>> On Thursday, April 2, 2015, Siyi Deng  wrote:
>>>>>
>>>>>> Hi,
>>>>>> I have created a c shared library using visual-studio; then I called
>>>>>> the c functions in Juno IDE, everything worked as expected.
>>>>>>
>>>>>> Then I installed the julia command line version, and ran the same
>>>>>> script again, and this time it seems that the c functions has not been
>>>>>> called properly, no exception was thrown, but the functions never return
>>>>>> meaningful values.
>>>>>>
>>>>>> I was using the 64bit stable release in both cases.
>>>>>>
>>>>>> Any insight? Thanks!
>>>>>>
>>>>>
>>>>
>>

Re: [julia-users] calling c functions from dll works in Juno but not Julia REPL

[Mike Innes]

Would you be able to produce a minimal test case that works in the 0.3.4
REPL but not in 0.3.7, then file that as an issue on the Julia repo?

On 3 April 2015 at 15:09, Siyi Deng  wrote:

> Hi Mike:
> I followed your suggestion , the Julia version used by Juno was 0.3.4 and
> the standalone REPL was 0.3.7 (all x86_64-w64-mingw32), so indeed it seems
> that new version introduced a bug of some kind.
>
>
>
>
>
> On Friday, April 3, 2015 at 3:12:47 AM UTC-7, Mike Innes wrote:
>>
>> Well, this is the first time it's happened this way around :)
>>
>> The first thing I would do is open the copy of Julia that Juno is running
>> using the "open a terminal" command, and see whether that gives the right
>> results. If the version is different, a bug may have been introduced by a
>> backport or something similar.
>>
>> On 3 April 2015 at 05:50, Kevin Squire  wrote:
>>
>>> Hi Siyi,
>>>
>>> Can you give a short example of your code?  It's generally pretty hard
>>> to debug these things without that.
>>>
>>> Cheers!
>>>Kevin
>>>
>>> On Thursday, April 2, 2015, Siyi Deng  wrote:
>>>
>>>> Hi,
>>>> I have created a c shared library using visual-studio; then I called
>>>> the c functions in Juno IDE, everything worked as expected.
>>>>
>>>> Then I installed the julia command line version, and ran the same
>>>> script again, and this time it seems that the c functions has not been
>>>> called properly, no exception was thrown, but the functions never return
>>>> meaningful values.
>>>>
>>>> I was using the 64bit stable release in both cases.
>>>>
>>>> Any insight? Thanks!
>>>>
>>>
>>

Re: [julia-users] calling c functions from dll works in Juno but not Julia REPL

[Mike Innes]

Well, this is the first time it's happened this way around :)

The first thing I would do is open the copy of Julia that Juno is running
using the "open a terminal" command, and see whether that gives the right
results. If the version is different, a bug may have been introduced by a
backport or something similar.

On 3 April 2015 at 05:50, Kevin Squire  wrote:

> Hi Siyi,
>
> Can you give a short example of your code?  It's generally pretty hard to
> debug these things without that.
>
> Cheers!
>Kevin
>
> On Thursday, April 2, 2015, Siyi Deng  wrote:
>
>> Hi,
>> I have created a c shared library using visual-studio; then I called the
>> c functions in Juno IDE, everything worked as expected.
>>
>> Then I installed the julia command line version, and ran the same script
>> again, and this time it seems that the c functions has not been called
>> properly, no exception was thrown, but the functions never return
>> meaningful values.
>>
>> I was using the 64bit stable release in both cases.
>>
>> Any insight? Thanks!
>>
>

Re: [julia-users] Re: HTML construction package

[Mike Innes]

I have Hiccup.jl  which is
aimed at having the nicest possible syntax. Competition is always welcome,
though!

On 2 April 2015 at 20:43, Iain Dunning  wrote:

> I'm not aware of anything like that, but I've been using Mustache.jl as a
> very different means to similar ends.
>
> On Thursday, April 2, 2015 at 3:15:08 PM UTC-4, Michael Francis wrote:
>>
>> As part of a project I've been working on I have put together a small
>> package for generating well-formed html documents from Julia.
>>
>> Is there a similar package available? and if not is there any interest in
>> releasing this?
>>
>> The below is a simple example (attached is a sample output, there is not
>> doctype tag on the sample),
>>
>>
>> hdr   = [ h_th( "col$i") for i in 1:10 ]
>> rows  = [ h_tr( [ h_td( "Cell[$j,$i]") for i in 1:10]) for j in 1:5]
>> table = h_table( id = h_unique(), class = "display", border = 1, h_thead(
>> h_tr( hdr ) ), h_tbody(rows) )
>> html  = h_html( h_head( h_title( "My Simple HTML")), h_body( table ))
>> println( table )
>>
>>

Re: [julia-users] Is there a Julia equivalent to Mathematica's Tally?

[Mike Innes]

Lazy.jl has a version of this called `frequencies`, but I just tried it and
turns out it's broken. Here's the (fixed) source:

function frequencies(xs)
  freqs = Dict{eltype(xs),Int}()
  for x in xs
freqs[x] = get(freqs, x, 0) + 1
  end
  return freqs
end

On 26 March 2015 at 21:11, DumpsterDoofus 
wrote:

> In Mathematica, there is a function called Tally which takes a list and
> returns a list of the unique elements of the input list, along with their
> multiplicities. I.e, it takes a list of length N and returns an array of
> dimensions (N,2), namely the pairs of elements and the number of times they
> appear.
>
> Is there a similar (but perhaps differently-named) function in Julia to
> tally a list?
>

Re: [julia-users] code generation with @eval

[Mike Innes]

For some reason the parser doesn't like interpolating into import/export
statements, but you can do this just fine by constructing the `Expr` object
by hand. It's not pretty, but it works OK.

You best bet is to construct expressions like `:(export foo, bar)` and
`dump` them to see how the Expr is constructed. I think for export it's
something like `Expr(:export, :foo, :bar)`.

Example:
https://github.com/one-more-minute/Hiccup.jl/blob/073f47314d1f08e0e5c8a958a25051248bb85039/src/Hiccup.jl#L95-L100

On 26 March 2015 at 12:52, Andreas Noack 
wrote:

> Distributed reduce is already implemented, so maybe these slightly simpler
> with e.g. sum(A::DArray) = reduce(Base.AddFun(), A)
>
> 2015-03-26 8:41 GMT-04:00 Jameson Nash :
>
> `eval` (typically) isn't allowed to handle `import` and `export`
>> statements. those must be written explicitly
>>
>> On Thu, Mar 26, 2015 at 8:18 AM Amit Murthy 
>> wrote:
>>
>>> I was trying to add a bunch  of common functions to DistributedArrays.jl
>>> with the below code block
>>>
>>> for f in [:sum, :minimum, :maximum, :mean]
>>> @eval begin
>>> import Base: ($f)
>>> export ($f)
>>> function ($f)(D::DArray)
>>> refs = [@spawnat p ($f)(localpart(D)) for p in procs(D)]
>>> ($f)([fetch(r) for r in refs])
>>> end
>>> end
>>> end
>>>
>>>
>>>
>>> But I get an error
>>>
>>> ERROR: LoadError: syntax: invalid "import" statement: expected
>>> identifier
>>>  in include at ./boot.jl:250
>>>  in include_from_node1 at ./loading.jl:129
>>>  in reload_path at ./loading.jl:153
>>>  in _require at ./loading.jl:68
>>>  in require at ./loading.jl:51
>>>  in process_options at ./client.jl:292
>>>  in _start at ./client.jl:402
>>> while loading /home/amitm/.julia/v0.4/DistributedArrays/src/
>>> DistributedArrays.jl, in expression starting on line 497
>>>
>>>
>>>
>>> What am I doing wrong ?
>>>
>>>
>

Re: [julia-users] metaprogramming for modifying expression inside anonymous function?

[Mike Innes]

Try

map(f -> (x, y) -> -f(x, y), foolist)

On 24 March 2015 at 09:35, Andrei Berceanu  wrote:

> Hi guys,
>
> Say I have a tuple of anonymous functions, such as:
>
> *foolist = ((x,y)-> exp(x*y), (x,y)-> sin(x+y))*
>
> and would like to (programatically) produce another tuple where every
> function has its overall sign changed. In my example this would be
>
>
>
> *newfoolist = ((x,y)-> -exp(x*y), (x,y)-> -sin(x+y))*Can this be done,
> i.e. metaprogramming or some other technique? How?
>
> Tnx!
>

Re: [julia-users] Re: Basic install question

[Mike Innes]

This seems to happen on OS X occasionally, for some reason. What you can do
is try the "open a terminal repl" command which will open a plain copy of
the version of Julia that Juno is running from. You should be able to
`Pkg.update()` from there, but if you see another error then let us know.

On 17 March 2015 at 21:06, Novice69  wrote:

> This is copied from:
>
>
>-
>
>Error evaluating REPL:
>unknown package
> in wait at task.jl:51
> in sync_end at 
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
> in add at pkg/entry.jl:319
> in add at pkg/entry.jl:71
> in anonymous at pkg/dir.jl:28
> in cd at 
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
> in __cd#227__ at 
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
> in add at pkg.jl:20
> in include_string at loading.jl:97
> in include_string at /Users/petar/.julia/v0.3/Jewel/src/eval.jl:36
> in anonymous at /Users/petar/.julia/v0.3/Jewel/src/LightTable/eval.jl:68
> in handlecmd at 
> /Users/petar/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:65
> in handlenext at 
> /Users/petar/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:81
> in server at 
> /Users/petar/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:22
> in server at /Users/petar/.julia/v0.3/Jewel/src/Jewel.jl:15
> in include at 
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
> in include_from_node1 at loading.jl:128
> in process_options at 
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
> in _start at 
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
>
>
>
>

Re: [julia-users] Re: Some simple use cases for multi-threading

[Mike Innes]

In eval clients like Juno autocomplete locks up while evaluating, so that's
something I'm looking forward to solving with some thready goodness. Not
quite GUI as such but close.
On 18 Mar 2015 18:12, "Sebastian Good" 
wrote:

> Task stealing parallelism is an increasingly common use case and easy to
> program. e.g. Cilk, Grand Central Dispatch,
>
> On Thursday, March 12, 2015 at 11:52:37 PM UTC-4, Viral Shah wrote:
>>
>> I am looking to put together a set of use cases for our multi-threading
>> capabilities - mainly to push forward as well as a showcase. I am thinking
>> of starting with stuff in the microbenchmarks and the shootout
>> implementations that are already in test/perf.
>>
>> I am looking for other ideas that would be of interest. If there is real
>> interest, we can collect all of these in a repo in JuliaParallel.
>>
>> -viral
>>
>>
>>
>>

Re: [julia-users] Re: Julia T-shirt and Sticker

[Mike Innes]

"The distance between Julia and insanity is measured only in segfaults"

Re: [julia-users] Re: Getting people to switch to Julia - tales of no(?) success

[Mike Innes]

Robert, I think it might be helpful to point you towards the Juno docs:

http://junolab.org/docs/

If you look over it you should find references for the basic commands
you'll need (really you shouldn't need many at all), and if there's
anything missing I'm happy to help out / add things in. Should help take
the guesswork out of things.

That said, I appreciate that Juno isn't for everyone right now. I do
eventually want for it to be a great tool for new users (and old ones), so
hopefully when you come back things will look up a bit.

So I think that Julia is fantastic, but you sell people on packages, not
> the language. The language enables better packages to be made.


This can't really be emphasised enough, I think. Julia is nothing short of
freakin' awesome for building APIs and libraries, but at the user level
it's often a painful experience compared to Python and friends. You don't
realise this until you're doing a hackathon and realise you don't have time
to (re-) implement all the libraries you need ;)

Of course, the former point will mean that the latter one will change with
time, and I think we're beginning to see that.

On 4 March 2015 at 17:42, Robert  wrote:

> I tried to use Julia, but give up. Right now.
> I just came here to search again for posts about IDEs for Julia and found
> this thread. So let me comment why I am giving up: because there is no IDE
> available which would really support me to get my things done.
>
> MATLAB speed can be slow, and Julia might be faster, but my limited
> programming skills are by far the most significant factor lowering progress
> speed. MATLAB, as you all know, is not just a language, it is a very
> advanced programming environment, with rich documentation, including
> tutorials and code examples for beginners. It is a useful tool also for
> people who are not first hand programmers, but just people who need to get
> a solution for a problem glued together. Nothing against the Julia REPL,
> but that is just not a straight forward environment like the IDE of MATLAB
> with a "variable" browser, an editor with code folding and cell evaluation,
> etc, tools for data inspection and IDE and data output configure
> possibilities, and File Exchange and Help forums serving you with whatever
> you might need. Although Julia is an impressive language project, its
> infrastructure is not. Not at all. I just tried to get warm with Juno, for
> several days. No way, it is not intuitive to handle. I have -as a not
> native english speaker- to guess english words for putting them into the
> CTRL+Space command line just to hope that maybe some useful link to a
> function appears. If not, then I wonder if my search term was not the
> correct one or if a function does not exist. Simple tasks like changing the
> background and foreground colors of the editor are not available. Maybe
> such functionality is available, but first you have to study for a week how
> LightTable is programmed, and learn how to program its configuration files.
> And things which work on my Win7 computer do not work on my WinXP notebook.
> Eclipse integration of Julia is costly and still not rich, Spyder
> integration is hard to find, IJulia is not really comparable with a full
> featured editor or IDE neither.
>
> Conclusion: in order to get my programming work done, I either would have
> to spend a lot of time to study too many new tools without finding in them
> convenient and known workflow offered as in MATLAB, SPYDER, ECLIPSE or MS
> Visual Studio, or I just don't start to use Julia by now and better wait
> until the infrastructure supporting the language became built as well.
> Don't get me wrong, I am impressed by the Julia project, and all of you out
> there designing tools like Juno for sure are far ahead of me in your
> programming skills and it is my fault to not have gained skills enough to
> support the Julia world myself with some useful utility. Well, I am just a
> user. A user looking forward to come back to Julia when the infrastructure
> more addresses also the not-professional-programmer and the
> not-million-key-shortcut-knowing scientist who just needs to get some
> algorithm up and running. I guess that is why you find it hard to attract
> new, "normal" users to use Julia. Julia to me still appears to be only made
> for geeks, not because of the language, not because of programming
> something in Julia, but because you have to be a geek to handle Julia, you
> have to be a geek to first get a whole programming environment set up by
> yourself - instead of just using one and concentrate on you Julia algorithm.
>

Re: [julia-users] conflicts when reloading module

[Mike Innes]

If you use Juno you can eval into modules directly, without having to
reload them, which makes stuff like this a lot nicer. AFAIK there's no
other way to work around this, but I'd love to be corrected on that.

On 18 February 2015 at 08:53, Tamas Papp  wrote:

> Hi,
>
> I thought that using modules would solve my problems with iterative
> development, but apparently not: when reloading a module that was used
> in Main, conflicts mask the new definitions.
>
> Eg
>
> --8<---cut here---start->8---
> module Foo
> export Bar, baz
> type Bar
>   x
> end
> baz(b::Bar) = b.x
> end
>
> using Foo
>
> baz(Bar(1)) # 1
>
> module Foo
> export Bar, baz
> type Bar
>   x
> end
> baz(b::Bar) = b.x+1
> end
>
> using Foo
>
> baz(Bar(1)) # 1
> Foo.baz(Foo.Bar(1)) # 2
> --8<---cut here---end--->8---
>
> What's the recommended way to work around this? Is there an approach
> that would allow me to experiment with code in Main, while working on a
> module that I keep reloading?
>
> Best,
>
> Tamas
>

Re: [julia-users] Re: Display Help in JUNO

[Mike Innes]

No problem, glad you like it!

On 11 February 2015 at 16:52, Christoph Ortner 
wrote:

> ah - just saw your reply there
> http://discuss.junolab.org/t/julia-0-4-docile-doc-strings/120/2
>
> Thanks a lot!
>
> Also: I am quite enjoying working with Juno, even though I normally use
> only EMACS - I just found that neither the standard Julia mode more the ESS
> Mode are quite mature enough. So thank you for producing Juno.
>
> Christoph
>

Re: [julia-users] Re: Display Help in JUNO

[Mike Innes]

The Juno forum isn't dead but is is unfortunately a bit slow, which
basically comes down to the fact that there are far fewer people who know a
lot about its internals (and most of them have other commitments, at least
for the very near future). I try to respond to everything within a few
days, or at least once a week - I've probably left it a bit longer than I
should recently but I'm looking over the backlog now.

On 11 February 2015 at 15:32, Michael Hatherly 
wrote:

> It’s not just Juno — I just haven’t gotten around to implementing output
> for anything but console yet. I won’t have a chance to add this for the
> next few weeks though, so here’s the issue
>  in case you’ve
> got any ideas you’d like to discuss.
>
> — Mike
> ​
>
> On Wednesday, 11 February 2015 18:08:24 UTC+2, Christoph Ortner wrote:
>>
>> [The Juno mailing list seems dead? Hence I am re-posting my question
>> here; apologies for posting twice.]
>>
>> Juno doesn't seem to recognise doc strings, or am I getting something
>> wrong? Here is a short piece of code:
>>
>> using Docile, Lexicon
>> @doc doc"Some doc with `markdown`."->function blah()
>> println("bleh")
>> end
>>
>> If I past this into a REPL, then type ?blah, then I get the correct
>> doc-string displayed. If I type blah into Juno and hit CTRL-D, then I
>> just get blah (generic function with 1 method)
>>
>> On playing around with this, I noticed that even in the REPL help(blah) will
>> display blah (generic function with 1 method), while ?blah will display
>> the correct doc-string.
>>
>> Am I doing something wrong again or is this not expected to work (yet)?
>>
>> Thanks,
>> Christoph
>>
>

Re: [julia-users] Juno+Julia installation

[Mike Innes]

First, try opening a Terminal window and launching `git`. You should find
it asks you to agree to an apple license or something similar, and after
that Juno should work.

If not, if you press `Ctrl-Space` to open the command bar, type "open
terminal" and Enter, a plain Julia REPL should launch. From there, call
Pkg.add("Jewel"). If it's still not working try posting any errors you get.

Juno requires the Jewel.jl package, and Julia's package manager requires
git, and OS X requires either agreeing to a license or seperate
installation to use git. I think. The other thing to try would be looking
up "xcode developer tools" or "xcode command line tools".

On 6 February 2015 at 21:07, Joseph Cullen  wrote:

> I am trying to install Juno+Julia on my Mac. According to the site this is
> as easy as downloading their the juno-mac-x64.dmg and then dragging the
> icon to the applications folder. But when lauching Juno I get this error
> below. I have searched for solutions, but none of them seem to work. I need
> to perfect this process as I will  be having students installing Julia and
> don't want to be inundated with questions. Is there a simple way to install
> Juno+Julia? Thanks for your help.
>
> Couldn't connect to Julia
>
> INFO: Couldn't find Jewel package, attempting installation...
> INFO: Installing Color v0.3.15
>
>
> Agreeing to the Xcode/iOS license requires admin privileges, please re-run
> as root via sudo.
>
>
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> ---
> We couldn't install Jewel.jl for you.
> Try using Pkg.add("Jewel") in a Julia repl.
> ---
>
> ERROR: failed process: Process(`git clone -q
> /Users/Joseph/.julia/v0.3/.cache/Color Color`, ProcessExited(128)) [128]
>  in wait at
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
> (repeats 2 times)
>  in wait at task.jl:48
>  in sync_end at
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
>  in add at pkg/entry.jl:319
>  in add at pkg/entry.jl:71
>  in anonymous at pkg/dir.jl:28
>  in cd at
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
>  in __cd#227__ at
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
>  in add at pkg.jl:20
>  in include at
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
>  in include_from_node1 at loading.jl:128
>  in process_options at
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
>  in _start at
> /Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
> while loading
> /Applications/Juno.app/Contents/Resources/app/plugins/Julia-LT/jl/init.jl,
> in expression starting on line 24
>
>
> Close
>

Re: [julia-users] movingpastasquishedcaseconvention?

[Mike Innes]

An underscore is basically the only option here, seeing basically every
other operator imaginable is taken.

Still, I'm personally happy with the current convention of underscore_case
alongside squished case where it doesn't hurt readability.

I agree that things like `searchsortedlast` could probably be made a bit
clearer but short things like `isequal` are almost less readable (to me at
least) when they're made longer. The other thing that's nice about the
squished case option is that it does encourage you to avoid underscores,
i.e. by choosing a name that's concise and clear to begin with, ideally in
one word.

I'm sure opinions will vary, but just throwing my two cents in.

On 5 February 2015 at 19:12, David James  wrote:

> Hello,
>
> The title of this post is "Moving Past a Squished Case Convention" not
> "Moving Pastas Quiche...". :)
>
> The Julia standard library tends to use the "squishedcase" notation. Being
> concise is great for mathematical functions, like sin, cos, and ln.
> However, it is cognitively harder for people for "compound" function names;
> e.g. "searchsortedlast". Such a naming convention flies in the face of real
> programming experience. It makes programming harder for people.
>
> There are many sane ways to name functions. Lisps tend to use hyphens,
> others often use underscores. R libraries use a non-standard mix [1].
> Interestingly, the Julia parser code itself uses hyphens; e.g.
> prec-assignment and prec-conditional:
> https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm
>
> It would be a shame for squishedcase to persist as the language reaches
> 1.0. What are some possible ways to address this problem without breaking
> compatibility in the short-run?
>
> I see a possible solution. Choose a character and encourage its use to
> break apart words; e.g. -, _, or a middot (·) [2]. Make it highly
> recommended but non-breaking until 1.0. Deprecate
> functionsusingsquishedcase.
>
> Julia is great overall but lacking in this way. Let's make it better.
>
> Sincerely,
> David
>
> [1]
> http://stackoverflow.com/questions/1944910/what-is-your-preferred-style-for-naming-variables-in-r
>
> [2] The middot is relatively unobtrusive and doesn't take up much space
> horizontally, e.g. search·sorted·last. It is also useful for variables
> representing compound units; e.g. N·m.
>
>
>
>

Re: [julia-users] Save state in a function

[Mike Innes]

I don't know why the word "functor" was originally used in Julia for
"function-like type", but it doesn't seem to have anything to do with the
functional programming / haskell / category theory functor (or any
particular relevance to monads). Might be a good idea to use a different
term since it clearly confuses the issue in some cases.

On 4 February 2015 at 15:20, Matt Bauman  wrote:

> The idiom that seems to be used most commonly in Base is a closure around
> a variable hidden in a let scope.  Note that your function must be declared
> global.  See base/combinatorics.jl:L361-L380
> 
>  for
> an example.
>
>
> On Wednesday, February 4, 2015 at 9:49:33 AM UTC-5, Peter Simon wrote:
>>
>> Thanks, that looks like the ticket!  I will try this out.
>>
>> On Tuesday, February 3, 2015 at 7:10:40 PM UTC-8, Erik Schnetter wrote:
>>>
>>> On Feb 3, 2015, at 20:30 , Erik Schnetter  wrote:
>>> >
>>> >> On Feb 3, 2015, at 20:22 , Peter Simon  wrote:
>>> >>
>>> >> Thanks, I will take a look at functors when I upgrade to 0.4.
>>>
>>> I didn't see this before. Here's another approach, without objects; it's
>>> functional and very Lispy. Probably also Julialy.
>>>
>>> Let's assume that there's an algorithm, and you have to pass a function
>>> f(x) to the algorithm. This function is expensive to evaluate, so you want
>>> to keep state around. In my field, this could be a residual evaluator that
>>> I need to pass to a solver
>>>
>>> First, define a function res(x, state) that takes the state as explicit
>>> argument. Here's an example:
>>>
>>> function res(x, state)
>>> y = state[1]
>>> state[1] = x
>>> return y
>>> end
>>>
>>> Then define your function f(x), together with the initial state:
>>>
>>> function myapplication
>>> mystate = [1]   # just a list
>>> f(x) = res(x, mystate)   # yes, f(x) is a local function
>>> ... solver(f) ...
>>> end
>>>
>>> Whenever f(x) is called, it remembers the state variable that you
>>> created. Since f(x) is a local function, it will go out of scope at some
>>> point. You can also create another function g(x) from res with a different
>>> state.
>>>
>>> Note that the state variable needs to be a reference type. I used a list
>>> here; you can also use an array, or a type that you declare yourself.
>>> However, it cannot be an immutable type.
>>>
>>> -erik
>>>
>>> --
>>> Erik Schnetter 
>>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>>
>>> My email is as private as my paper mail. I therefore support encrypting
>>> and signing email messages. Get my PGP key from
>>> https://sks-keyservers.net.
>>>
>>>

Re: [julia-users] Markdown Strings as Messages

[Mike Innes]

Markdown.jl lives in base Julia now so it should probably go there.

On 1 February 2015 at 15:18, Christoph Ortner 
wrote:

> should this go in Docile, Lexicon, or Julialang?
> Christoph
>

Re: [julia-users] Markdown Strings as Messages

[Mike Innes]

No, feel free to open one if you want (ping me too).

On 1 February 2015 at 12:18, Christoph Ortner 
wrote:

> Is this an existing issue somewhere?
>
>
> On Sunday, 1 February 2015 12:18:42 UTC, Christoph Ortner wrote:
>>
>>
>> Thanks for the clarification. It would be really great to have this
>> functionality, especially, if it can be combined with MathJax!
>>
>> Thanks,
>> Christoph
>>
>

Re: [julia-users] Markdown Strings as Messages

[Mike Innes]

This is something I've been thinking about as well, and overloading `print`
etc. to work with markdown is definitely doable. I'm not sure how it would
work in IJulia, but it would definitely be ok in the terminal.

Use md"" unless you're writing inline docs (you might have to do a using
Base.Markdown first). At the moment both are interchangeable but the idea
is that doc"" needs to treat e.g. relative image and link paths specially,
and may potentially also add things like reference syntax.

On 1 February 2015 at 11:22, Christoph Ortner 
wrote:

>
> I've tried (but failed), with Julia 0.4, to use Markdown strings doc" . .
> ." as messages, e.g., error messages or just to make some complex program
> output more readable.
>
> If, in a REPL or IJulia, I just write
>doc"blah `code` bleh"
> in a single line, then this shows ok. But of course in a function or
> script, it will just generate an object of type `Base.Markdown.MD`,
> without output.
>
> [1] Question: how can I actually send it to the output, correctly
> formatted?
>
> [2] Suggestion: could `print`, `println`, `error` etc automatically
> interpret markdown strings and output them accordingly?
>
> [3] Question: why doc" . . ." and not md" . . ." ? Could these at least be
> used synonymously?
>
> Thanks,
> Christoph
>
>
>

Re: [julia-users] short circuit list comprehension

[Mike Innes]

Ok, I now see that `all` isn't short-circuiting, which is kind of
surprising/annoying. Anyone know why that is?

You can easily define your own short-circuiting `all` to do this:

all′(f, xs) =
  isempty(xs) ? true :
  f(xs[1]) && all′(f, xs[2:end])

The other thing you could try is to check out Lazy.jl. If you call, for
example,

@time all(map(f,list(1,2,3,5)))

The `list` construct actually takes care of short-circuiting for you, so
what looks like a very expensive `map` operation is actually very cheap.

On 30 January 2015 at 08:05, Mike Innes  wrote:

> How about `all(f, values)`?
>
> On 30 January 2015 at 06:51, Wai Yip Tung  wrote:
>
>> I want to apply function f() over a range of value. f() returns true for
>> success and false for failure. Since f() is expensive, I want short circuit
>> computation, i.e. it stops after the first failure.
>>
>> In python, I can do this in an elegant way with the all() function and
>> generator expression.
>>
>> if all(f(x) for x in values)
>>   # success
>> else
>>   # failure
>>
>> From what I understand, there is no generator expression in Julia. List
>> comprehension will evaluate the full list. Even if I try to use for loop, I
>> can't use the control variable to check if the loop has run to finish or
>> not.
>>
>> i = 0
>> for i in 1:length(values)
>> if !f(values[i])
>>   break
>>end
>> end
>> # The status is ambiguous if i==length(values)
>>
>> My last resort is to add flags to indicate if is success or not. Is there
>> some more elegant way to do this?
>>
>>
>

Re: [julia-users] short circuit list comprehension

[Mike Innes]

How about `all(f, values)`?

On 30 January 2015 at 06:51, Wai Yip Tung  wrote:

> I want to apply function f() over a range of value. f() returns true for
> success and false for failure. Since f() is expensive, I want short circuit
> computation, i.e. it stops after the first failure.
>
> In python, I can do this in an elegant way with the all() function and
> generator expression.
>
> if all(f(x) for x in values)
>   # success
> else
>   # failure
>
> From what I understand, there is no generator expression in Julia. List
> comprehension will evaluate the full list. Even if I try to use for loop, I
> can't use the control variable to check if the loop has run to finish or
> not.
>
> i = 0
> for i in 1:length(values)
> if !f(values[i])
>   break
>end
> end
> # The status is ambiguous if i==length(values)
>
> My last resort is to add flags to indicate if is success or not. Is there
> some more elegant way to do this?
>
>