Re: [julia-users] Re: [Announcement] Moving to Discourse (Statement of Intent)

[Valentin Churavy]

`julia-dev` has now moved to discourse.

One possibility would be to start forwarding posts for `julia-users` from
Google Groups to Discourse, but that is a one way street. So before I
enable that I would like to hear what everybody thinks about it.

On Wed, 9 Nov 2016 at 02:01 Tom Breloff  wrote:

> +1... can we move already?  Discourse is a huge improvement.  I
> specifically don't answer some questions here because of the difficulty in
> writing answers with code.
>
> On Sun, Nov 6, 2016 at 3:16 PM, Stefan Karpinski 
> wrote:
>
> - Selectively subscribe to certain topics/categories of discussion and not
> others.
> - Selectively see threads that reach certain quality/interest thresholds.
> - Take links directly from where one reads messages
> (I really dislike the Google groups interface, so I use Gmail for
> reading messages, but then getting a link to a post is a real pain; the
> Discourse interface is much better).
> - Real tools for moderation, management and administration.
> - Active, open development
> Google Groups is not only proprietary, but it's also effectively
> abandonware.
>
> On Sun, Nov 6, 2016 at 8:33 AM, Simon Byrne  wrote:
>
> Personally, I find the following an improvement over google groups:
> - code blocks (copying and pasting code into the google groups interface
> always tends to look bad)
> - the ability to edit posts
> - the ability to move threads to different categories (i.e. posts to
> julia-dev which should have gone to julia-users, etc)
>
>
> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>
> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit :
> > Hello colleague,
> >
> > > The Julia community has been growing rapidly over the last few
> > > years and discussions are happening at many different places: there
> > > are several Google Groups (julia-users, julia-dev, ...), IRC,
> > > Gitter, and a few other places. Sometimes packages or organisations
> > > also have their own forums and chat rooms.
> > >
> > > In the past, Discourse has been brought up as an alternative
> > > platform that we could use instead of Google Groups and that would
> > > allow us to invite the entire Julia community into one space.
> > >
> >
> > What problem with the julia-users mailing-list and the google groups
> > web interface is solved by using discourse?
> You can have a look at the previous thread about this:
> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ
>
> I also encourage you to give a try to Discourse (this can be done
> without even creating an account on their test instance).
>
> > Why do you think (can you prove?) more centralisation will happen
> > with discourse?
> Centralization will be made possible by allowing for sub-forums
> dedicated to each topic (stats, optimization, data...) inside Discourse
> itself, instead of creating totally separate mailing lists as is
> currently done. Of course people will still be free to use something
> else, but that's quite unlikely.
>
> > > We would like to solicit feedback from the broader Julia community
> > > about moving julia-users to Discourse as well, and potentially
> > > other mailing lists like julia-stats.
> > >
> >
> > Please define 'We'.
> "We" meant "Julia core developers".
>
> > > If you have feedback or comments, please post them
> > > at http://discourse.julialang.org/t/migration-of-google-groups-to-
> > > discourse or in this thread.
> > >
> >
> > In some parts of the world, asking for feedback on a topic via a
> > different medium is seen as unfriendly act ... but still there is
> > this thread.
> The idea was that we would like to see how well it works by having
> people use Discourse for this discussion. But as you noted there's this
> thread for people who don't want to to that.
>
>
> Regards
>
> > Wishing a happy day,
> >  Andreas
>
>
> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>
> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit :
> > Hello colleague,
> >
> > > The Julia community has been growing rapidly over the last few
> > > years and discussions are happening at many different places: there
> > > are several Google Groups (julia-users, julia-dev, ...), IRC,
> > > Gitter, and a few other places. Sometimes packages or organisations
> > > also have their own forums and chat rooms.
> > >
> > > In the past, Discourse has been brought up as an alternative
> > > platform that we could use instead of Google Groups and that would
> > > allow us to invite the entire Julia community into one space.
> > >
> >
> > What problem with the julia-users mailing-list and the google groups
> > web interface is solved by using discourse?
> You can have a look at the previous thread about this:
> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ
>
> I also encourage you to give a try to Discourse (this can be done
> without even creating an account on their test instance).
>
> > Why do you think 

Re: [julia-users] Re: problems (and some fixes) for using Plots and PlotlyJS on FreeBSD

[Kostas Oikonomou]

It seems that the problem is in Blink/src/AtomShell/process.jl.   The error 
report indicates line 62 there.
So I tried running some lines by hand:

julia> port() = rand(2_000:10_000)   # line 57
port (generic function with 1 method)

julia> p = port()  # line 72
5287

julia> connect(ip"127.0.0.1", p)  # line 76
ERROR: connect: connection refused (ECONNREFUSED)
 in yieldto at ./event.jl:136
 in _init at /opt/julia/0.5.0/lib/julia/sys.so:?
 in wait at ./event.jl:169
 in wait at ./event.jl:27
 in _init at /opt/julia/0.5.0/lib/julia/sys.so:?
 in stream_wait at ./stream.jl:44
 in wait_connected at ./stream.jl:265
 in connect at ./stream.jl:960 [inlined]
 in connect(::IPv4, ::Int64) at ./socket.jl:677

julia> 


On Tuesday, November 8, 2016 at 1:07:23 PM UTC-5, Tom Breloff wrote:
>
> Sounds like progress.  You might try restarting Julia, and also try the 
> plotting command a few times.  Blink is known to have a race condition on 
> startup that sometimes produces this sort of error.
>
> On Tue, Nov 8, 2016 at 1:02 PM, Kostas Oikonomou  > wrote:
>
>>
>> Thanks.  Before reading your post, I had added an "if is_bsd()" statement 
>> to Blink/src/AtomShell/install.jl, and I set arch to "ia32" as FreeBSD 
>> has default support for 32-bit Linux.  
>>
>>

Re: [julia-users] Re: problems (and some fixes) for using Plots and PlotlyJS on FreeBSD

[Tom Breloff]

Sounds like progress.  You might try restarting Julia, and also try the
plotting command a few times.  Blink is known to have a race condition on
startup that sometimes produces this sort of error.

On Tue, Nov 8, 2016 at 1:02 PM, Kostas Oikonomou <
kostas.oikonomo...@gmail.com> wrote:

> Thanks.  Before reading your post, I had added an "if is_bsd()" statement
> to Blink/src/AtomShell/install.jl, and I set arch to "ia32" as FreeBSD
> has default support for 32-bit Linux.
>
> The result is that when I redo AtomBlink.AtomShell.install(), the 32-bit
> Linux binary is installed.
> However, when I do plotlyjs() and then try to plot something, there is an
> error:
>
> ERROR: connect: connection refused (ECONNREFUSED)
>  in yieldto at ./event.jl:136
>  in _init at /opt/julia/0.5.0/lib/julia/sys.so:?
>  in wait at ./event.jl:169
>  in wait at ./event.jl:27
>  in _init at /opt/julia/0.5.0/lib/julia/sys.so:?
>  in stream_wait at ./stream.jl:44
>  in wait_connected at ./stream.jl:265
> ...
>
>
> On Tuesday, November 8, 2016 at 11:32:42 AM UTC-5, randm...@gmail.com
> wrote:
>>
>> I don't think Electron works on FreeBSD (see here
>> ), but Blink requires
>> it. You could try using the Linux binaries by changing this
>> 
>> line to be is_linux() || is_bsd()and call Blink.AtomShell.install()
>> again, but I'm not sure that'll work.
>>
>> A
>>
>

[julia-users] Re: problems (and some fixes) for using Plots and PlotlyJS on FreeBSD

[Kostas Oikonomou]

Thanks.  Before reading your post, I had added an "if is_bsd()" statement 
to Blink/src/AtomShell/install.jl, and I set arch to "ia32" as FreeBSD has 
default support for 32-bit Linux.  

The result is that when I redo AtomBlink.AtomShell.install(), the 32-bit 
Linux binary is installed.
However, when I do plotlyjs() and then try to plot something, there is an 
error:

ERROR: connect: connection refused (ECONNREFUSED)
 in yieldto at ./event.jl:136
 in _init at /opt/julia/0.5.0/lib/julia/sys.so:?
 in wait at ./event.jl:169
 in wait at ./event.jl:27
 in _init at /opt/julia/0.5.0/lib/julia/sys.so:?
 in stream_wait at ./stream.jl:44
 in wait_connected at ./stream.jl:265
...


On Tuesday, November 8, 2016 at 11:32:42 AM UTC-5, randm...@gmail.com wrote:
>
> I don't think Electron works on FreeBSD (see here 
> ), but Blink requires 
> it. You could try using the Linux binaries by changing this 
> 
>  
> line to be is_linux() || is_bsd()and call Blink.AtomShell.install() 
> again, but I'm not sure that'll work.
>
> A
>

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

[David Anthoff]

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

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

Re: [julia-users] Multiple dispatch algorithm.

[Páll Haraldsson]

On Friday, November 4, 2016 at 8:05:30 PM UTC, Matt Bauman wrote:
>
> I posted an answer to this a year ago on Stack Overflow: 
> http://stackoverflow.com/a/32148113/176071
>

Thanks.

I see "so it's just a linear search to check if the type of the argument 
tuple is a subtype of the signature. So that's just O(n), right? The 
trouble is that checking subtypes with full generality (including Unions 
and TypeVars, etc) is hard. Very hard, in fact. Worse than NP-complete [..] 
that is, even if P=NP, this problem would still take non-polynomial time! 
It might even be PSPACE or worse." That sounds bad..

I'm not to worried about PSPACE, only "worse" and/or non-polynomial time. 
But I assume that is also only a problem with functions with many 
arguments, and if you hit it you know.. You'll never be surprised at 
runtime.

[This kind of reminds me, SQL query tuning is exponential in general, not a 
problem in practice, or you just deal with it by simplifying your query or 
give hints; and PostgreSQL at least has genetic algorithm as a fallback: 
https://www.postgresql.org/docs/9.1/static/geqo-pg-intro.html ]


And thankfully you add "But, really, your question was about the *runtime* 
complexity of dispatch. In that case, the answer is quite often *"what 
dispatch?"* — because it has been *entirely eliminated*!"

as I expected.



If Julia would need:
https://en.wikipedia.org/wiki/EXPSPACE

I would get a little worried, not for:

https://en.wikipedia.org/wiki/PSPACE

"PSPACE is also equal to PCTC, problems solvable by classical computers 
using closed timelike curves 
,[6] 
 as well as to BQPCTC, 
problems solvable by quantum computers 
 using closed timelike 
curves.[7] "

https://en.wikipedia.org/wiki/Closed_timelike_curve
"who discovered a solution to the equations of general relativity 
 (GR) allowing CTCs known 
as the Gödel metric ; and 
since then other GR solutions containing CTCs have been found, such as the 
Tipler 
cylinder  and traversable 
wormholes . 
[..] 
Some physicists speculate that the CTCs which appear in certain GR 
solutions might be ruled out by a future theory of quantum gravity 
 which would replace GR, an 
idea which Stephen Hawking  
has labeled the chronology protection conjecture 
. Others 
note that if every closed timelike curve in a given space-time passes 
through an event horizon , a 
property which can be called chronological censorship, then that space-time 
with event horizons excised would still be causally well behaved and an 
observer might not be able to detect the causal violation.[2] 





> The internal implementation of the method caches has since changed, but 
> the concepts should still apply.  If I remember right, Stefan's remarks 
> were about the addition of triangular subtyping, which will plug into the 
> dispatch system seamlessly since it's "just" an extension to the type 
> system.
>
> On Friday, November 4, 2016 at 10:44:28 AM UTC-5, Mauro wrote:
>>
>> Have a read of: 
>> https://github.com/JeffBezanson/phdthesis/blob/master/main.pdf 
>>
>> (Note that multiple dispatch is not a 1.0 thing, it was there from the 
>> beginning.) 
>>
>> On Fri, 2016-11-04 at 16:22, Ford O.  wrote: 
>> > Hi, 
>> > 
>> > I have watched the Julia 1.0 video where Stefan briefly mentions new 
>> > multiple dispatch algorithm. I don't have much insight into this so I 
>> would 
>> > like to ask: 
>> > 
>> > What is the cost of multiple dispatch? ( What is the complexity of 
>> naive 
>> > implementation? What is the complexity of current implementation in 
>> julia? ) 
>> > 
>> > Could you briefly highlight the difficulties of creating an efficient 
>> > implementation? 
>> > 
>> > Thank you 
>>
>

Re: [julia-users] Re: Plots.jl: layout of several plots, with more than one curve per plot

[Tom Breloff]

Even better... you should add a tutorial for how to do:
https://github.com/tbreloff/Plots.jl/issues/541

On Tue, Nov 8, 2016 at 12:00 PM, Scott T  wrote:

> Sure, happy to add to ExamplePlots! Do you have any more suggestions for
> layout-related features you'd like to showcase? Inset plots? I think the
> key things to get across are how to define layouts and how to overlay/facet
> series within a layout.
>
> Scott
>
>
> On Tuesday, 8 November 2016 16:28:11 UTC, Tom Breloff wrote:
>>
>> Thanks for putting those examples together Scott.  Do you want to
>> contribute that to ExamplePlots?
>>
>> Ferran: as Scott has shown nicely, there's an ton of different ways to do
>> what you want, and the "right" way is going to depend on your problem...
>> what the layouts/data look like.  Many times it's easiest to build the
>> plots independently and then just do: plot(p1, p2, p3, p4, p5, layout = ...)
>>
>> On Tue, Nov 8, 2016 at 11:18 AM, Ferran Mazzanti 
>> wrote:
>>
>>> Oh!
>>> Scott you're very kind to take your time helping me with the notebook...
>>> thanks a lot. I'll take a careful look and report back if I find problems.
>>> Best,
>>> Ferran.
>>>
>>>
>>> On Tuesday, November 8, 2016 at 1:22:20 PM UTC+1, Scott T wrote:

 You can break down the plot command into chunks and then call plot on
 those chunks to build up a plot from several pieces. In this way, you can
 make individual plots with multiple series. Then you can combine them
 according to your desired layout.

 This isn't the best place to post a full example so I put a notebook up
 for you to have a look at here:
 https://gist.github.com/swt30/54701d09cfa479dab78a5bc2fa857fd7

 Cheers,
 Scott

 On Tuesday, 8 November 2016 09:20:39 UTC, Ferran Mazzanti wrote:

> Hi,
>
> I'm gathering interest in Plots.jl in order to make complex plotting
> structures. Just as an example, I have a set of data (called y) and some
> operations performed on it, stored in arrays of obvious names y2, logy,
> expy etc...
>
> I have managed to create something that displays one curve per plot
>
> lay = @layout [  a{0.4w} grid(2,2) ]
> plot(
> [y y2 sqrty logy expy],
> layout = lay,
> grid   = [true false false false false],
> title = ["y" "y^2" "sqrt(y)" "log(y)" "exp(y)"],titleloc="center",ti
> tlefont=font(12),
> xlims = [(0,12)  (0,10) (0,20) (0,20) (0,12) ],
> )
>
> which puts one curve in each plot. What would be the needed
> modifications here in order to
> plot y and cosy in the first plot, and sqrty and siny on the second
> plot?
>
> Thanks for your help,
>
> Ferran.
>

>>

Re: [julia-users] Re: [Announcement] Moving to Discourse (Statement of Intent)

[Tom Breloff]

+1... can we move already?  Discourse is a huge improvement.  I
specifically don't answer some questions here because of the difficulty in
writing answers with code.

On Sun, Nov 6, 2016 at 3:16 PM, Stefan Karpinski 
wrote:

> - Selectively subscribe to certain topics/categories of discussion and not
> others.
> - Selectively see threads that reach certain quality/interest thresholds.
> - Take links directly from where one reads messages
> (I really dislike the Google groups interface, so I use Gmail for
> reading messages, but then getting a link to a post is a real pain; the
> Discourse interface is much better).
> - Real tools for moderation, management and administration.
> - Active, open development
> Google Groups is not only proprietary, but it's also effectively
> abandonware.
>
> On Sun, Nov 6, 2016 at 8:33 AM, Simon Byrne  wrote:
>
>> Personally, I find the following an improvement over google groups:
>> - code blocks (copying and pasting code into the google groups interface
>> always tends to look bad)
>> - the ability to edit posts
>> - the ability to move threads to different categories (i.e. posts to
>> julia-dev which should have gone to julia-users, etc)
>>
>>
>> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>>>
>>> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit :
>>> > Hello colleague,
>>> >
>>> > > The Julia community has been growing rapidly over the last few
>>> > > years and discussions are happening at many different places: there
>>> > > are several Google Groups (julia-users, julia-dev, ...), IRC,
>>> > > Gitter, and a few other places. Sometimes packages or organisations
>>> > > also have their own forums and chat rooms.
>>> > >
>>> > > In the past, Discourse has been brought up as an alternative
>>> > > platform that we could use instead of Google Groups and that would
>>> > > allow us to invite the entire Julia community into one space.
>>> > >
>>> >
>>> > What problem with the julia-users mailing-list and the google groups
>>> > web interface is solved by using discourse?
>>> You can have a look at the previous thread about this:
>>> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ
>>>
>>> I also encourage you to give a try to Discourse (this can be done
>>> without even creating an account on their test instance).
>>>
>>> > Why do you think (can you prove?) more centralisation will happen
>>> > with discourse?
>>> Centralization will be made possible by allowing for sub-forums
>>> dedicated to each topic (stats, optimization, data...) inside Discourse
>>> itself, instead of creating totally separate mailing lists as is
>>> currently done. Of course people will still be free to use something
>>> else, but that's quite unlikely.
>>>
>>> > > We would like to solicit feedback from the broader Julia community
>>> > > about moving julia-users to Discourse as well, and potentially
>>> > > other mailing lists like julia-stats.
>>> > >
>>> >
>>> > Please define 'We'.
>>> "We" meant "Julia core developers".
>>>
>>> > > If you have feedback or comments, please post them
>>> > > at http://discourse.julialang.org/t/migration-of-google-groups-to-
>>> > > discourse or in this thread.
>>> > >
>>> >
>>> > In some parts of the world, asking for feedback on a topic via a
>>> > different medium is seen as unfriendly act ... but still there is
>>> > this thread.
>>> The idea was that we would like to see how well it works by having
>>> people use Discourse for this discussion. But as you noted there's this
>>> thread for people who don't want to to that.
>>>
>>>
>>> Regards
>>>
>>> > Wishing a happy day,
>>> >  Andreas
>>>
>>
>> On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>>>
>>> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit :
>>> > Hello colleague,
>>> >
>>> > > The Julia community has been growing rapidly over the last few
>>> > > years and discussions are happening at many different places: there
>>> > > are several Google Groups (julia-users, julia-dev, ...), IRC,
>>> > > Gitter, and a few other places. Sometimes packages or organisations
>>> > > also have their own forums and chat rooms.
>>> > >
>>> > > In the past, Discourse has been brought up as an alternative
>>> > > platform that we could use instead of Google Groups and that would
>>> > > allow us to invite the entire Julia community into one space.
>>> > >
>>> >
>>> > What problem with the julia-users mailing-list and the google groups
>>> > web interface is solved by using discourse?
>>> You can have a look at the previous thread about this:
>>> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ
>>>
>>> I also encourage you to give a try to Discourse (this can be done
>>> without even creating an account on their test instance).
>>>
>>> > Why do you think (can you prove?) more centralisation will happen
>>> > with discourse?
>>> Centralization will be made possible by allowing for sub-forums

Re: [julia-users] Re: Plots.jl: layout of several plots, with more than one curve per plot

[Scott T]

Sure, happy to add to ExamplePlots! Do you have any more suggestions for 
layout-related features you'd like to showcase? Inset plots? I think the 
key things to get across are how to define layouts and how to overlay/facet 
series within a layout.

Scott


On Tuesday, 8 November 2016 16:28:11 UTC, Tom Breloff wrote:
>
> Thanks for putting those examples together Scott.  Do you want to 
> contribute that to ExamplePlots?
>
> Ferran: as Scott has shown nicely, there's an ton of different ways to do 
> what you want, and the "right" way is going to depend on your problem... 
> what the layouts/data look like.  Many times it's easiest to build the 
> plots independently and then just do: plot(p1, p2, p3, p4, p5, layout = ...)
>
> On Tue, Nov 8, 2016 at 11:18 AM, Ferran Mazzanti  > wrote:
>
>> Oh!
>> Scott you're very kind to take your time helping me with the notebook... 
>> thanks a lot. I'll take a careful look and report back if I find problems.
>> Best,
>> Ferran.
>>
>>
>> On Tuesday, November 8, 2016 at 1:22:20 PM UTC+1, Scott T wrote:
>>>
>>> You can break down the plot command into chunks and then call plot on 
>>> those chunks to build up a plot from several pieces. In this way, you can 
>>> make individual plots with multiple series. Then you can combine them 
>>> according to your desired layout.
>>>
>>> This isn't the best place to post a full example so I put a notebook up 
>>> for you to have a look at here: 
>>> https://gist.github.com/swt30/54701d09cfa479dab78a5bc2fa857fd7
>>>
>>> Cheers,
>>> Scott
>>>
>>> On Tuesday, 8 November 2016 09:20:39 UTC, Ferran Mazzanti wrote:
>>>
 Hi,

 I'm gathering interest in Plots.jl in order to make complex plotting 
 structures. Just as an example, I have a set of data (called y) and some 
 operations performed on it, stored in arrays of obvious names y2, logy, 
 expy etc...

 I have managed to create something that displays one curve per plot

 lay = @layout [  a{0.4w} grid(2,2) ]
 plot(
 [y y2 sqrty logy expy],
 layout = lay,
 grid   = [true false false false false],
 title = ["y" "y^2" "sqrt(y)" "log(y)" 
 "exp(y)"],titleloc="center",titlefont=font(12),
 xlims = [(0,12)  (0,10) (0,20) (0,20) (0,12) ],
 )

 which puts one curve in each plot. What would be the needed 
 modifications here in order to
 plot y and cosy in the first plot, and sqrty and siny on the second 
 plot?

 Thanks for your help,

 Ferran.

>>>
>

[julia-users] Re: problems (and some fixes) for using Plots and PlotlyJS on FreeBSD

[randmstring]

I don't think Electron works on FreeBSD (see here 
), but Blink requires it. 
You could try using the Linux binaries by changing this 
 
line to be is_linux() || is_bsd()and call Blink.AtomShell.install() again, 
but I'm not sure that'll work.

Am Montag, 7. November 2016 21:35:30 UTC+1 schrieb Kostas Oikonomou:
>
> I am using Julia 0.5.0 on FreeBSD 11.  I've had a few problems trying to 
> install the Plots and PlotlyJS packages:
>
> 1. Just after installing Plots, I had to make this fix in
> ~/.julia/v0.5/Plots/src/backends/web.jl, function open_browser_window:
>
>@static if is_linux() || is_bsd()
> return run(`xdg-open $(filename)`)
>end
>
> 2. Now trying to install PlotlyJS.  HttpParser doesn't build, because in
> BinDeps.jl, function unpack_cmd(...), says
>
>elseif extension == ".zip"
>return (`unzip -x $file -d $directory`)
>
> The /usr/bin/unzip on FreeBSD doesn't understand "-x" (more precisely, it 
> thinks
> it means "exclude").  GNU gunzip doesn't understand it either.  What 
> "unzip" is
> this supposed to be?  I made an ugly hack to work around this.
>
>
> 3. In ~/.julia/v0.5/Blink/src/AtomShell/process.jl: I had to add is_bsd() 
> to
>
> @static if is_apple()
>   const _electron = resolve("Blink", 
> "deps/Julia.app/Contents/MacOS/Electron")
> elseif is_linux() || is_bsd()
>   const _electron = resolve("Blink", "deps/atom/electron")
> elseif is_windows()
>   const _electron = resolve("Blink", "deps", "atom", "electron.exe")
> end
>
> 4. After all this, I still get the error:
>
> julia> using Plots
> julia> plotlyjs()
> julia> plot(x -> x^2, rand(10))
> Error showing value of type Plots.Plot{Plots.PlotlyJSBackend}:
> ERROR: Cannot find Electron. Try `Blink.AtomShell.install()`.
>  in electron() at 
> /usr/home/ko/.julia/v0.5/Blink/src/AtomShell/process.jl:53
>
>
> Thanks for any help.
>
> Kostas
>

Re: [julia-users] Re: Plots.jl: layout of several plots, with more than one curve per plot

[Tom Breloff]

Thanks for putting those examples together Scott.  Do you want to
contribute that to ExamplePlots?

Ferran: as Scott has shown nicely, there's an ton of different ways to do
what you want, and the "right" way is going to depend on your problem...
what the layouts/data look like.  Many times it's easiest to build the
plots independently and then just do: plot(p1, p2, p3, p4, p5, layout = ...)

On Tue, Nov 8, 2016 at 11:18 AM, Ferran Mazzanti 
wrote:

> Oh!
> Scott you're very kind to take your time helping me with the notebook...
> thanks a lot. I'll take a careful look and report back if I find problems.
> Best,
> Ferran.
>
>
> On Tuesday, November 8, 2016 at 1:22:20 PM UTC+1, Scott T wrote:
>>
>> You can break down the plot command into chunks and then call plot on
>> those chunks to build up a plot from several pieces. In this way, you can
>> make individual plots with multiple series. Then you can combine them
>> according to your desired layout.
>>
>> This isn't the best place to post a full example so I put a notebook up
>> for you to have a look at here:
>> https://gist.github.com/swt30/54701d09cfa479dab78a5bc2fa857fd7
>>
>> Cheers,
>> Scott
>>
>> On Tuesday, 8 November 2016 09:20:39 UTC, Ferran Mazzanti wrote:
>>
>>> Hi,
>>>
>>> I'm gathering interest in Plots.jl in order to make complex plotting
>>> structures. Just as an example, I have a set of data (called y) and some
>>> operations performed on it, stored in arrays of obvious names y2, logy,
>>> expy etc...
>>>
>>> I have managed to create something that displays one curve per plot
>>>
>>> lay = @layout [  a{0.4w} grid(2,2) ]
>>> plot(
>>> [y y2 sqrty logy expy],
>>> layout = lay,
>>> grid   = [true false false false false],
>>> title = ["y" "y^2" "sqrt(y)" "log(y)" "exp(y)"],titleloc="center",ti
>>> tlefont=font(12),
>>> xlims = [(0,12)  (0,10) (0,20) (0,20) (0,12) ],
>>> )
>>>
>>> which puts one curve in each plot. What would be the needed
>>> modifications here in order to
>>> plot y and cosy in the first plot, and sqrty and siny on the second plot?
>>>
>>> Thanks for your help,
>>>
>>> Ferran.
>>>
>>

[julia-users] Julia 0.5.0 together with Codec.jl (Base64) slower than on 0.4.5

[Páll Haraldsson]

I was running [not my code..]:

https://github.com/kostya/benchmarks/blob/master/base64/test.jl

[and looking into why Base64-benchmark was slower than in Ruby.. and then 
even slower under 0.5]


and lines 12, 13 and 21 (e.g. here add 2 to what profile says) seem 
predictable slow.


A. Why is it slower than Ruby in the first place? Codec.jl must not be as 
optimized; no good reason for it; at least not Julia's fault.

B. Why is it slower under 0.5? I changed ASCIIString->String (the usual 
recommendation, but not here?):

I see it now..

Lines 12-13:
  str2 = ASCIIString(encode(Base64, str)) 
  s += length(str2)


I was then thinking, would it be unfair to other languages (e.g. C), to get 
the byte-length directly instead of scanning. Then I realized, that's 
exactly what happens in 0.4, because of ASCIIString, as it can. 0.5 no 
longer can (unless you use LegacyEncoding.jl), it seemed.


I see other languages do it:

https://github.com/kostya/benchmarks/blob/master/base64/test.cr [Crystal 
language]

str2 = Base64.strict_encode(str)
s += str2.bytesize

[not sure how this with them or should be defined, returns an ASCIIString?]


This seemed the obvious change:;
  str2 = String(encode(Base64, str))
  s += length(str2)


This solved the speed (at least B.) problem:
  str2 = encode(Base64, str)
  s += length(str2)

[This is a slight semantic difference, if you would print out str2? That 
never happens..]


In line with the sample code:

using Codecs

data = "Hello World!"
encoded = encode(Base64, encode(Zlib, data))println(bytestring(encoded))


[that is however broken, gives an error]

In general data that encode gives is an UInt8 Vector, as it should be, e.g. for 
Zlib; is that also for sure meant for Base64? Should it then return UTF-8 
strings, that happen to be ASCII strings? This may be by design. What is 
appropriate on decode?



Are these lines for sure correct in the code, do they work for all string 
types?:

function encode{T <: Codec}(codec::Type{T}, s::AbstractString) 
encode(codec, convert(Vector{UInt8}, s)) 
end 


function decode{T <: Codec}(codec::Type{T}, s::AbstractString) 
decode(codec, convert(Vector{UInt8}, s)) 
end



julia> @profile x = @timed main(100)
encode: 133600, 4.1400511264801025
decode: 10, 2.7664570808410645
(nothing,7.185494864,2343364208,0.027672998,Base.GC_Diff(2343364208,201,0,417,0,0,27672998,84,0))

julia> Profile.print()
6987 ./event.jl:68; (::Base.REPL.##3#4{Base.REPL.REPLBackend})()
 6987 ./REPL.jl:95; macro expansion
  6987 ./REPL.jl:64; eval_user_input(::Any, ::Base.REPL.REPLBackend)
   6987 ./boot.jl:234; eval(::Module, ::Any)
6987 ./:?; anonymous
 6987 ./profile.jl:16; macro expansion;
  6987 ./util.jl:278; macro expansion;
   88   ./REPL[17]:3; main(::Int64)
1  ./strings/types.jl:172; repeat(::String, ::Int64)
84 ./strings/types.jl:173; repeat(::String, ::Int64)
 31 ./array.jl:0; copy!(::Array{UInt8,1}, ::Int64, 
::Array{UInt8,1}, ::Int64, ::Int64)
 3  ./array.jl:60; copy!(::Array{UInt8,1}, ::Int64, 
::Array{UInt8,1}, ::Int64, ::Int64)
 5  ./array.jl:62; copy!(::Array{UInt8,1}, ::Int64, 
::Array{UInt8,1}, ::Int64, ::Int64)
 33 ./array.jl:65; copy!(::Array{UInt8,1}, ::Int64, 
::Array{UInt8,1}, ::Int64, ::Int64)
  7  ./array.jl:0; unsafe_copy!(::Array{UInt8,1}, ::Int64, 
::Array{UInt8,1}, ::Int64, ::Int64)
  19 ./array.jl:51; unsafe_copy!(::Array{UInt8,1}, ::Int64, 
::Array{UInt8,1}, ::Int64, ::Int64)
   1  ./abstractarray.jl:737; pointer
   18 ./array.jl:44; unsafe_copy!
  1  ./array.jl:56; unsafe_copy!(::Array{UInt8,1}, ::Int64, 
::Array{UInt8,1}, ::Int64, ::Int64)
   2206 ./REPL[17]:10; main(::Int64)
16  /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:60; 
encode(::Type{Codecs.Base64}, ::Array{UInt8,1})
264 /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:63; 
encode(::Type{Codecs.Base64}, ::Array{UInt8,1})
416 /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:64; 
encode(::Type{Codecs.Base64}, ::Array{UInt8,1})
270 /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:65; 
encode(::Type{Codecs.Base64}, ::Array{UInt8,1})
313 /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:66; 
encode(::Type{Codecs.Base64}, ::Array{UInt8,1})
608 /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:67; 
encode(::Type{Codecs.Base64}, ::Array{UInt8,1})
319 /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:68; 
encode(::Type{Codecs.Base64}, ::Array{UInt8,1})
   1929 ./REPL[17]:11; main(::Int64)
4./strings/string.jl:48; length(::String)
1925 ./strings/string.jl:49; length(::String)
   2764 ./REPL[17]:19; main(::Int64)
1./strings/string.jl:48; length(::String)
1438 ./strings/string.jl:49; length(::String)
9/home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:106; 
decode(::Type{Codecs.Base64}, ::Array{UInt8,1})
121  /home/qwerty/.julia/v0.5/Codecs/src/Codecs.jl:109; 
decode(:

[julia-users] Re: Plots.jl: layout of several plots, with more than one curve per plot

[Ferran Mazzanti]

Oh!
Scott you're very kind to take your time helping me with the notebook... 
thanks a lot. I'll take a careful look and report back if I find problems.
Best,
Ferran.

On Tuesday, November 8, 2016 at 1:22:20 PM UTC+1, Scott T wrote:
>
> You can break down the plot command into chunks and then call plot on 
> those chunks to build up a plot from several pieces. In this way, you can 
> make individual plots with multiple series. Then you can combine them 
> according to your desired layout.
>
> This isn't the best place to post a full example so I put a notebook up 
> for you to have a look at here: 
> https://gist.github.com/swt30/54701d09cfa479dab78a5bc2fa857fd7
>
> Cheers,
> Scott
>
> On Tuesday, 8 November 2016 09:20:39 UTC, Ferran Mazzanti wrote:
>
>> Hi,
>>
>> I'm gathering interest in Plots.jl in order to make complex plotting 
>> structures. Just as an example, I have a set of data (called y) and some 
>> operations performed on it, stored in arrays of obvious names y2, logy, 
>> expy etc...
>>
>> I have managed to create something that displays one curve per plot
>>
>> lay = @layout [  a{0.4w} grid(2,2) ]
>> plot(
>> [y y2 sqrty logy expy],
>> layout = lay,
>> grid   = [true false false false false],
>> title = ["y" "y^2" "sqrt(y)" "log(y)" 
>> "exp(y)"],titleloc="center",titlefont=font(12),
>> xlims = [(0,12)  (0,10) (0,20) (0,20) (0,12) ],
>> )
>>
>> which puts one curve in each plot. What would be the needed modifications 
>> here in order to
>> plot y and cosy in the first plot, and sqrty and siny on the second plot?
>>
>> Thanks for your help,
>>
>> Ferran.
>>
>

Re: [julia-users] most generic way to request iterable type as input

[Mauro]

There is no proper way to do this.  But note that your suggestion below
is not any more performant than just not typing the field.  You could
check in the constructor whether the type can be iterated on:

immutable Test{T}
  a::T
  function Test(a)
@assert eltype(a)<:Integer
tmp = [aa in a] # better make sure the compiler does not remove this no-op
new(a)
  end
end


On Tue, 2016-11-08 at 16:49, Kevin Kunzmann  wrote:
> Hi,
>
> say I want to define a custom type with a field that accepts any kind of
> iterable integer type as valid input (both 1:3 as well as collect(1:3)),
> how would I do that in the most generic way? I know that I can use
>
> type test{T<:integer}
>  a::Union{Range{T},Vector{T}}
> end
>
> But there might be other iterable integer types that I did not think of
> during implementation - how can I make the code even more generic?
>
> Best,
>
> Kevin

[julia-users] most generic way to request iterable type as input

[Kevin Kunzmann]

Hi,

say I want to define a custom type with a field that accepts any kind of 
iterable integer type as valid input (both 1:3 as well as collect(1:3)), 
how would I do that in the most generic way? I know that I can use

type test{T<:integer}
 a::Union{Range{T},Vector{T}}
end

But there might be other iterable integer types that I did not think of 
during implementation - how can I make the code even more generic?

Best,

Kevin 

[julia-users] Re: JLD crash on WIN

[Igor Cerovsky]

I've also submitted an issue to JLD, and the problem is originally 
addressed here: https://github.com/JuliaIO/JLD.jl/issues/103

On Tuesday, 8 November 2016 14:50:49 UTC+1, Igor Cerovsky wrote:
>
> Hello,
>
> Julia 0.5 crashes when loading previously saved data using JLD; code below 
> shows a simple example, that causes crash:
> using JLD
>
> type foo 
>   a::Int
>   b::String
> end
> f = foo(1, "a")
> save("d:/work/Julia/data.jld", "f", f)
> l = load("d:/work/Julia/data.jld", "f") # crashes here
>
> however, everything works fine with:
> using JLD
>
> a = [1,2]
> save("d:/work/Julia/data.jld", "a", a)
> l = load("d:/work/Julia/data.jld", "a")
>
> Julia Version 0.5.0 (2016-09-19 18:14 UTC); Official http://julialang.org/ 
> release; x86_64-w64-mingw32
>
> Any idea how to fix the problem?
>
> Thanks.
>

[julia-users] JLD crash on WIN

[Igor Cerovsky]

Hello,

Julia 0.5 crashes when loading previously saved data using JLD; code below 
shows a simple example, that causes crash:
using JLD

type foo 
  a::Int
  b::String
end
f = foo(1, "a")
save("d:/work/Julia/data.jld", "f", f)
l = load("d:/work/Julia/data.jld", "f") # crashes here

however, everything works fine with:
using JLD

a = [1,2]
save("d:/work/Julia/data.jld", "a", a)
l = load("d:/work/Julia/data.jld", "a")

Julia Version 0.5.0 (2016-09-19 18:14 UTC); Official http://julialang.org/ 
release; x86_64-w64-mingw32

Any idea how to fix the problem?

Thanks.

Re: [julia-users] problems (and some fixes) for using Plots and PlotlyJS on FreeBSD

[Tony Kelman]

Most likely there are various platform-checking if statements that don't 
properly handle the freebsd situation of being not linux and not macos and not 
windows. Does Atom support FreeBSD, do they have binaries available? If so, a 
few more careful fallbacks might be able to fix this?

Re: [julia-users] Re: How to built an array with some keys of a dictionary ?

[Fred]

Thank you Dan, this solution works to ! I don't know which one is better :)

Le mardi 8 novembre 2016 08:40:37 UTC+1, Dan a écrit :
>
> I meant,
>
> a = Vector{String}()
>
>

[julia-users] Re: Plots.jl: layout of several plots, with more than one curve per plot

[Scott T]

You can break down the plot command into chunks and then call plot on those 
chunks to build up a plot from several pieces. In this way, you can make 
individual plots with multiple series. Then you can combine them according 
to your desired layout.

This isn't the best place to post a full example so I put a notebook up for 
you to have a look at here: 
https://gist.github.com/swt30/54701d09cfa479dab78a5bc2fa857fd7

Cheers,
Scott

On Tuesday, 8 November 2016 09:20:39 UTC, Ferran Mazzanti wrote:

> Hi,
>
> I'm gathering interest in Plots.jl in order to make complex plotting 
> structures. Just as an example, I have a set of data (called y) and some 
> operations performed on it, stored in arrays of obvious names y2, logy, 
> expy etc...
>
> I have managed to create something that displays one curve per plot
>
> lay = @layout [  a{0.4w} grid(2,2) ]
> plot(
> [y y2 sqrty logy expy],
> layout = lay,
> grid   = [true false false false false],
> title = ["y" "y^2" "sqrt(y)" "log(y)" 
> "exp(y)"],titleloc="center",titlefont=font(12),
> xlims = [(0,12)  (0,10) (0,20) (0,20) (0,12) ],
> )
>
> which puts one curve in each plot. What would be the needed modifications 
> here in order to
> plot y and cosy in the first plot, and sqrty and siny on the second plot?
>
> Thanks for your help,
>
> Ferran.
>

[julia-users] Plots.jl: layout of several plots, with more than one curve per plot

[Ferran Mazzanti]

Hi,

I'm gathering interest in Plots.jl in order to make complex plotting 
structures. Just as an example, I have a set of data (called y) and some 
operations performed on it, stored in arrays of obvious names y2, logy, 
expy etc...

I have managed to create something that displays one curve per plot

lay = @layout [  a{0.4w} grid(2,2) ]
plot(
[y y2 sqrty logy expy],
layout = lay,
grid   = [true false false false false],
title = ["y" "y^2" "sqrt(y)" "log(y)" 
"exp(y)"],titleloc="center",titlefont=font(12),
xlims = [(0,12)  (0,10) (0,20) (0,20) (0,12) ],
)

which puts one curve in each plot. What would be the needed modifications 
here in order to
plot y and cosy in the first plot, and sqrty and siny on the second plot?

Thanks for your help,

Ferran.