Unlike wxWindows and Windows which are very much in the same area of application (graphical interfaces for computers), a plotting package is hardly confusable with a clothing store or radio hardware, so trademark does not apply – there must be a potential for customers being confused or misled by the different uses of the trademarked term.
4 Likes
there must be a potential for customers being confused or misled by the different uses of the trademarked term
The key word here is potential. There is a potential of Makie becoming wildly successful and creating demand for t-shirts and gadgets with word “Makie” printed on them. That would directly interfere with clothing store business.
I know that this sounds very far fetched, so I tried to find a legal precedent. In 1978 Apple Computer was sued by Apple Corps, the Beatles-founded holding company and owner of their record label Apple Records, for trademark infringement. As you know, Apple Computer had nothing to do with music until many years later, when it got sued again by Apple Corps in 1991.
Corporate lawyers wield a lot of power and it is almost impossible for a small entity to fight them.
3 Likes
If the project reaches the point where clothing companies are suing for trademark infringement then it will have been sufficiently successful that we should be so lucky. Even then, that’s such a far-fetched scenario that making naming decisions based on it is verging on paranoia.
3 Likes
Not really. See the left-pad npm debacle.
Sorry, but ‘left-pad npm debacle’ was a completely different situation. And also the above mentioned “wxWidgets debacle” was not really such a debacle: they have been asked politely, got a modest financial compensation and there was a long enough transition period.
I wonder if after the wildly successfull Makie T-Shirts release, which surely will make litiguous clothing lawyers knock, the name could not simply be changed to Makee (or something)?
…and everybody will have to buy a new T-Shirt (2 x 
) … 
Thank you for this! I am looking forward to use it everyday!
I am with @StefanKarpinski here, and I think Visualize sounds much better for the broad functionality that this package will provide. When I read Makie I can only associate the word to build scripts, GNU Make, etc.
2 Likes
The complaint about Plots has mostly been with the time to first plot. With Plots + GR, it takes 20 seconds to first scatter(rand(3), rand(3)). With MakiE I get 40 seconds. Any plans on improving time to first plot?
As Andy Grove used to say: “Only the Paranoid Survive”
1 Like
In my understanding the issue is that Plots + GR is 20 seconds while GR alone is 1 second. MakiE is taking long but:
- The long first plot time is due to GLVisualize and could be improved there
- A GR backend to MakiE would be very fast already at the first plot
If MakiE want to be the successor of Plots it then would be good to start with a mature backend (like GR or PyPlot). Time to plot is with PyPlot just 6 seconds here.
What @piever says! And I really hope that I manage to get MakiE to statically compile or cache the emitted binary in some other way.
I don’t see why we shouldn’t be able to cache binary output for at least everything we test - which should give use a time to first plot in under a second! I regularly try to compile GLVisualize into a single binary and every time I make a few steps forward, so maybe I will succeed by the time I officially release MakiE.
A GR backend is on the horizon as well, so we shall see what times to first plot that will give us!
I just made a big step forward concerning time to first plot, by having MakiE statically compiled as a standalone executable. I will still need to figure out the details, but it shows that this is certainly possible:
The above is real time and is a time to first image under one second 
42 Likes
That’s amazing!! Do you foresee any issue using the plotpane in Juno in Makie?
Well, it’s already implemented It just won’t be interactive in the plotpane…
While this is super promising, for a plotting package, this is only interesting if
using MakiE
plot(1:10)
in the REPL takes < 1 second. I am really looking forward to this.
1 Like
I already think it is interesting.
Any details? This would be superfast in comparison to:
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: https://docs.julialang.org
_ _ _| |_ __ _ | Type "?help" for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.6.0 (2017-06-19 13:05 UTC)
_/ |\__'_|_|_|\__'_| | Official http://julialang.org/ release
|__/ | x86_64-pc-linux-gnu
julia> using MakiE
julia> @time scene = Scene(resolution = (500, 500))
27.273016 seconds (12.54 M allocations: 680.238 MiB, 1.06% gc time)
Scene scene:
Dict{Symbol,Any} with 27 entries:
:screen => name: Makie…
:mouse_button_released => <Node: 0>
I just realized, that this already works, since one can use the compiled shared library as the system image:
It’s a bit slower then the previous, since I’m plotting a million particles.
3 Likes
Any effect on julia startup time?
No, that’s unaffected!