[julia-users] The package Debug is not working with the latest version of julia
Hi, I was trying to debug my code and I used for that this package : https://github.com/toivoh/Debug.jl But I always get this error : ERROR: UndefVarError: T not defined Is there another way to debug a julia code? Thanks
Re: [julia-users] The package Debug is not working with the latest version of julia
Thank you for your answer. It's working with julia 0.3.5 Mariem On Thu, Jan 22, 2015 at 12:45 PM, Tim Holy tim.h...@gmail.com wrote: This is best filed as an issue with the Debug package, if there isn't such an issue already filed. If you're using julia 0.4, be aware that you should be prepared to fix problems yourself and contribute your fixes upstream. If not, julia 0.3 is the recommended, stable release for most users. You can always debug with @show or println statements, although that's not always as efficient. --Tim On Thursday, January 22, 2015 03:33:54 AM El Afrit Mariem wrote: Hi, I was trying to debug my code and I used for that this package : https://github.com/toivoh/Debug.jl But I always get this error : ERROR: UndefVarError: T not defined Is there another way to debug a julia code? Thanks
Re: [julia-users] Re: Almost at 500 packages!
As an R user I'm surprised to see CRAN held up as a model to aspire to. There is a _lot_ of overlapping functionality among those 6k packages, making it hard to figure out which one is best for a particular purpose. There are also a lot of unfocused packages providing miscellaneous collections of functions, which makes it difficult to understand exactly what the package offers you as a user. As a user things are easier if a) each package has a clearly defined scope (i.e., does one thing well), and b) there are not too many similar packages to choose from for any particular task. None of this is to say that julia isn't on the right track in terms of packages, just that I question the wisdom of emulating CRAN in this regard. Best, Ista On Wed, Jan 21, 2015 at 7:46 PM, Iain Dunning iaindunn...@gmail.com wrote: Yes indeed Christoph, a package that doesn't work is a package that might as well not exist. Fortunately, and fairly uniquely I think, we can quantify to some extent how many of our packages are working, and the degree to which they are. In my mind the goal now is grow fast and don't break too many things, and I think our pace over the last month or so of around 1 package per day is fantastic, with good stability of packages (i.e. they pass tests). I've also noticed that packages being registered now are often of a higher quality than they used to be, in terms of tests and documentation. I talked about this a bit at JuliaCon, but in some sense NPM and CRAN represent different ends of a spectrum of possibilities, and it seems like the consensus is more towards CRAN. So, we're doing good I think. On Wed, Jan 21, 2015 at 7:02 PM, Kevin Squire kevin.squ...@gmail.com wrote: Additional references: PyPI lists 54212 packages, currently (roughly half as many as node) but, CRAN only has 6214. Cheers, Kevin On Wed, Jan 21, 2015 at 3:37 PM, Sean Garborg sean.garb...@gmail.com wrote: You wouldn't like node ;) On Wednesday, January 21, 2015 at 4:29:53 PM UTC-7, Christoph Ortner wrote: Great that so many are contributing to Julia, but I would question whether such a large number of packages will be healthy in the long run. It will make it very difficult for new users to use Julia effectively. -- Iain Dunning PhD Candidate / MIT Operations Research Center http://iaindunning.com / http://juliaopt.org
Re: [julia-users] Re: Almost at 500 packages!
I wasn't really trying to hold CRAN up as an example of the best type of package registry, just that it represents an extreme (to my understanding) in terms of quality control and size, while still regarded as being of pretty high quality. Any online discussion comparing R and Julia invariably includes at some point how R has so many great packages. My point is then that CRAN has 6000 packages, and is regarded as good, and NPM has 100k, and also has some good packages (although it has far too many trivial packages in my opinion, like a package to lower-case a string!). There is no right or wrong, I just think they are extremes. On Thu, Jan 22, 2015 at 1:49 PM, Ista Zahn istaz...@gmail.com wrote: As an R user I'm surprised to see CRAN held up as a model to aspire to. There is a _lot_ of overlapping functionality among those 6k packages, making it hard to figure out which one is best for a particular purpose. There are also a lot of unfocused packages providing miscellaneous collections of functions, which makes it difficult to understand exactly what the package offers you as a user. As a user things are easier if a) each package has a clearly defined scope (i.e., does one thing well), and b) there are not too many similar packages to choose from for any particular task. None of this is to say that julia isn't on the right track in terms of packages, just that I question the wisdom of emulating CRAN in this regard. Best, Ista On Wed, Jan 21, 2015 at 7:46 PM, Iain Dunning iaindunn...@gmail.com wrote: Yes indeed Christoph, a package that doesn't work is a package that might as well not exist. Fortunately, and fairly uniquely I think, we can quantify to some extent how many of our packages are working, and the degree to which they are. In my mind the goal now is grow fast and don't break too many things, and I think our pace over the last month or so of around 1 package per day is fantastic, with good stability of packages (i.e. they pass tests). I've also noticed that packages being registered now are often of a higher quality than they used to be, in terms of tests and documentation. I talked about this a bit at JuliaCon, but in some sense NPM and CRAN represent different ends of a spectrum of possibilities, and it seems like the consensus is more towards CRAN. So, we're doing good I think. On Wed, Jan 21, 2015 at 7:02 PM, Kevin Squire kevin.squ...@gmail.com wrote: Additional references: PyPI lists 54212 packages, currently (roughly half as many as node) but, CRAN only has 6214. Cheers, Kevin On Wed, Jan 21, 2015 at 3:37 PM, Sean Garborg sean.garb...@gmail.com wrote: You wouldn't like node ;) On Wednesday, January 21, 2015 at 4:29:53 PM UTC-7, Christoph Ortner wrote: Great that so many are contributing to Julia, but I would question whether such a large number of packages will be healthy in the long run. It will make it very difficult for new users to use Julia effectively. -- Iain Dunning PhD Candidate / MIT Operations Research Center http://iaindunning.com / http://juliaopt.org -- *Iain Dunning* PhD Candidate http://orc.scripts.mit.edu/people/student.php?name=idunning / MIT Operations Research Center http://web.mit.edu/orc/www/ http://iaindunning.com / http://juliaopt.org
Re: [julia-users] Re: Almost at 500 packages!
Great points Ista. I think the main motivation in emulating CRAN is with respect to overall volume of functionality, but your points about too many overlapping or half-baked packages strike home as a former (and still occasional) R user. I think the efforts in the Julia package repository, METADATA, to encourage collaboration and merging packages are the most important and useful in managing the package ecosystem. As a personal anecdote, I initially created the SQLite.jl package closely following the sqldf R package. After an initial sprint, I had other priorities take over and the package languished a bit. Once I found more time (and need!), I started a redesign of the package from the ground up to be more Julian. Coincidently, at the same time, I came across a reddit thread where Sean Marshallsay had published a post about redesigning the SQLite package to be more Julian as well. I pinged him on reddit to see if he'd be willing to combine efforts on redesigning the package with me and he's contributed some of the most useful functionality now to date (being able to register and run custom julia scalar and aggregate functions in SQLite). I think in another world (or another programming language), I would have seen his post and thought, Oh well, someone else is creating a competing package. But having grown with the Julia community for a couple years now, I thought I'd reach out about collaborating, and it's certainly worked out quite well for everyone, IMO. Anyway, TL;DR the collaborative nature of the package community is one of my all-time favorite aspects of Julia. -Jacob On Thu, Jan 22, 2015 at 11:49 AM, Ista Zahn istaz...@gmail.com wrote: As an R user I'm surprised to see CRAN held up as a model to aspire to. There is a _lot_ of overlapping functionality among those 6k packages, making it hard to figure out which one is best for a particular purpose. There are also a lot of unfocused packages providing miscellaneous collections of functions, which makes it difficult to understand exactly what the package offers you as a user. As a user things are easier if a) each package has a clearly defined scope (i.e., does one thing well), and b) there are not too many similar packages to choose from for any particular task. None of this is to say that julia isn't on the right track in terms of packages, just that I question the wisdom of emulating CRAN in this regard. Best, Ista On Wed, Jan 21, 2015 at 7:46 PM, Iain Dunning iaindunn...@gmail.com wrote: Yes indeed Christoph, a package that doesn't work is a package that might as well not exist. Fortunately, and fairly uniquely I think, we can quantify to some extent how many of our packages are working, and the degree to which they are. In my mind the goal now is grow fast and don't break too many things, and I think our pace over the last month or so of around 1 package per day is fantastic, with good stability of packages (i.e. they pass tests). I've also noticed that packages being registered now are often of a higher quality than they used to be, in terms of tests and documentation. I talked about this a bit at JuliaCon, but in some sense NPM and CRAN represent different ends of a spectrum of possibilities, and it seems like the consensus is more towards CRAN. So, we're doing good I think. On Wed, Jan 21, 2015 at 7:02 PM, Kevin Squire kevin.squ...@gmail.com wrote: Additional references: PyPI lists 54212 packages, currently (roughly half as many as node) but, CRAN only has 6214. Cheers, Kevin On Wed, Jan 21, 2015 at 3:37 PM, Sean Garborg sean.garb...@gmail.com wrote: You wouldn't like node ;) On Wednesday, January 21, 2015 at 4:29:53 PM UTC-7, Christoph Ortner wrote: Great that so many are contributing to Julia, but I would question whether such a large number of packages will be healthy in the long run. It will make it very difficult for new users to use Julia effectively. -- Iain Dunning PhD Candidate / MIT Operations Research Center http://iaindunning.com / http://juliaopt.org
[julia-users] Plotting-package-independent API
Hello, I've just read up on most recent conversations mentioning plotting, after I went through a similar install-and-try-out cycle for the various plotting packages. I am busy with a package named ROC https://github.com/davidavdav/ROC (Receiver Operating Characteristic). It is mostly about decision cost functions and efficiently computing ROC statistics, but there is also some support for making various plots related to the ROC. I do not want to decide for a potential user of this package which plotting package she should use. So it would be nice if there would be an abstract plotting API (I suppose this does not exist yet). Supposing that it is possible to make an API that includes some common plotting primitives, and that makes a runtime selection based on `isdefined(plottingpackagename)`, how would you - overload a function, typically `plot()`, when at module-include time it is not yet known which plotting package the user wants - specify the dependence of this package to any one of the available plotting packages. Thoughts? Thanks, ---david
[julia-users] Re: Plotting-package-independent API
Well, I'm planning to introduce some functionality similar to show,
building upon a rich type system.
What I have in mind is something like this:
show(::Matrix{Z}; parameters...) = Surface
show(::Matrix{Red}; parameters...) = Red channel
show(::Matrix{RGB}; parameters...) = Image
show(::Matrix{Vector2}; parameters...) = Vectorfield
show(::Vector{Y}; parameters...) = Line plot
show(::Vector{Point2D}; parameters...) = scatter plot
show(::Vector{Point3D}; parameters...) = 3D point cloud
show(::(Vector{Point3D}, Vector{Face}); parameters...) = mesh
This is nice for visual debugging, but probably not sufficient for more
complicated plots and annotations.
Am Donnerstag, 22. Januar 2015 16:42:37 UTC+1 schrieb David van Leeuwen:
Hello,
I've just read up on most recent conversations mentioning plotting, after
I went through a similar install-and-try-out cycle for the various plotting
packages.
I am busy with a package named ROC https://github.com/davidavdav/ROC
(Receiver
Operating Characteristic). It is mostly about decision cost functions and
efficiently computing ROC statistics, but there is also some support for
making various plots related to the ROC.
I do not want to decide for a potential user of this package which
plotting package she should use. So it would be nice if there would be an
abstract plotting API (I suppose this does not exist yet).
Supposing that it is possible to make an API that includes some common
plotting primitives, and that makes a runtime selection based on
`isdefined(plottingpackagename)`, how would you
- overload a function, typically `plot()`, when at module-include time it
is not yet known which plotting package the user wants
- specify the dependence of this package to any one of the available
plotting packages.
Thoughts?
Thanks,
---david
Re: [julia-users] Re: Almost at 500 packages!
Personally, I think powers of two are obviously more important, so 512 is really the prize. On Thu, Jan 22, 2015 at 4:50 PM, Randy Zwitch randy.zwi...@fuqua.duke.edu wrote: Geez, had I known there would be a race to 500, I'd have submitted my OAuth 1 package (per Stefan's point though, I'm sans documentation and tests at the moment) On Tuesday, January 20, 2015 at 3:39:33 PM UTC-5, Viral Shah wrote: I wonder what the 500th package will be. -viral On Tuesday, January 20, 2015 at 9:02:45 PM UTC+5:30, Iain Dunning wrote: Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 registered packages with at least one version tagged that are Julia 0.4-dev compatible (493 on Julia 0.3). Thanks to all the package developers for their efforts in growing the Julia package ecosystem!
[julia-users] Re: Almost at 500 packages!
Geez, had I known there would be a race to 500, I'd have submitted my OAuth 1 package (per Stefan's point though, I'm sans documentation and tests at the moment) On Tuesday, January 20, 2015 at 3:39:33 PM UTC-5, Viral Shah wrote: I wonder what the 500th package will be. -viral On Tuesday, January 20, 2015 at 9:02:45 PM UTC+5:30, Iain Dunning wrote: Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 registered packages with at least one version tagged that are Julia 0.4-dev compatible (493 on Julia 0.3). Thanks to all the package developers for their efforts in growing the Julia package ecosystem!
[julia-users] Re: Finally, a plotting package that just works !
On Thursday, July 25, 2013 at 4:05:33 PM UTC+2, Billou Bielour wrote: Ok, this is a joke. But since it's so hard to get graphics working, I just made two functions that makes basic ascii plots, it kind of works and the results are not so horrible :) The first picture of the Mandelbrot set was printed similarly, http://en.wikipedia.org/wiki/Mandelbrot_set#mediaviewer/File:Mandel.png.
[julia-users] Re: pkg.julialang.org test
The pkg.julialang.org checks slightly different things from the travis tests. In particular, while the travis tests run only when there is a change to the package code, these tests run nightly, and catch any package breakage due to changes to Julia, or any of your package dependencies. If your dependencies are easy to install on linux, then I'm sure Ian will be happy to discuss installing them on the server. Alternatively, some packages can be marked Untestable rather than broken, if their dependencies are difficult to acquire. Packages with proprietary commercial dependencies are marked this way, for example. Either way, you can raise an issue at https://github.com/IainNZ/PackageEvaluator.jl/issues to discuss the specifics for your package. Regards - Avik On Thursday, 22 January 2015 14:51:16 UTC, Josh Langsfeld wrote: This is a fairly minor topic, but thought I'd bring it up anyway. I noticed the pkg.julialang.org listings generate pass/fail info for the package tests by running the tests locally rather than hooking into Travis. This is a problem for me as my Travis script involves installing dependencies, and so it will always list as Tests fail as things currently are. Is there a way to have it display the travis build status instead? Thanks, Josh
[julia-users] pkg.julialang.org test
This is a fairly minor topic, but thought I'd bring it up anyway. I noticed the pkg.julialang.org listings generate pass/fail info for the package tests by running the tests locally rather than hooking into Travis. This is a problem for me as my Travis script involves installing dependencies, and so it will always list as Tests fail as things currently are. Is there a way to have it display the travis build status instead? Thanks, Josh
[julia-users] Re: comparing compilation times for matlab and julia
Viral, Thanks for the information about possible improvements in the future. Gray, if you look at the 'getAlgs' function in my code you'll see that I do include an alternate (but unused by default) way of encapsulating each algorithm in a function. This doesn't seem to improve the compilation speed. chris On Tuesday, January 20, 2015 at 1:02:17 PM UTC-8, Viral Shah wrote: With Jameson's work on static compilation and very early work towards interpreting Julia code, this will get addressed, but not in the near future. -viral On Tuesday, January 20, 2015 at 12:11:45 AM UTC+5:30, Gray Calhoun wrote: Hi Christian, you can certainly make the code-writing process much faster by splitting large functions into many distinct smaller functions. In your example (which I've only skimmed), `mimosimu` looks like it directly implements and annotates several similar but different algorithms which could all be separate functions. Compilation happens at the function level, not the file level, and shorter functions compile (and usually run) much faster. Also, loading part of a file is something that editors can handle as well, so if there aren't satisfactory packages (I haven't tried the Autoreload.jl package recommended in the last thread, but it looks promising), using an editor like Emacs (with ESS) or Light Table (with Juno) could help. I'm sure there are lots of other editors that do this too, but those are the two I'm familiar with. On Sunday, January 18, 2015 at 10:04:58 PM UTC-6, Christian Peel wrote: I'm enjoying learning Julia. I have the same toy script written in Matlab and Julia at the following URL: https://github.com/ChristianPeel/toySims/tree/master/mimoToys Running the following in matlab tic; mimoUPtoy(200,4,4,4,0,12,12,[-10:5:30]); toc takes about 0.82 seconds on a specific machine. In contrast, with Julia I first need to 'include' it, then the first time through the compiler takes around 7 seconds to compile the code and execute it. Subsequent executions of the code have speed similar to Matlab. julia tic(); include(mimoUPtoy.jl); toc() elapsed time: 0.348886314 seconds 0.348886314 julia tic(); mimoUPtoy(200,4,4,4,0,12,12,[-10.0:5:30]); toq() ...output... 7.002885787 julia tic(); mimoUPtoy(200,4,4,4,0,12,12,[-10.0:5:30]); toq() ...output... 0.860070365 Some questions are (1) is there is some improvement in 0.4 or otherwise which would improve the initial JIT time? (2) is there any way to only recompile the parts of a file that have changed? Say by using a hash on a function to see if it has changed? (3) I'm used to the Matlab development cycle in which I don't need to 'include' anything (it's done automatically) and also any JIT compilation that Matlab does is very fast and is essentially not noticable. So even though Matlab may be slower for code execution, it feels faster for code development. Is there anything that can be done to Julia to make the code writing process quicker? Is there a way to automate the 'include' process? I acknowledge that one option to speed compilation time is to break mimoUPtoy.jl into separate files. I'm also sure that there are things that can be improved in both my Matlab and Julia code. Finally; this function is similar to that which I refered to in a previous post (I was busy at the time and didn't get the code posted) https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/peel/julia-users/thR_80jtE2Q/ymV5i-AXmKkJ
[julia-users] Re: pkg.julialang.org test
Thanks for the info. Unstated in my question was that I didn't know where to go to pursue this so I'm glad you pointed me to the right place. On Thursday, January 22, 2015 at 10:05:42 AM UTC-5, Avik Sengupta wrote: The pkg.julialang.org checks slightly different things from the travis tests. In particular, while the travis tests run only when there is a change to the package code, these tests run nightly, and catch any package breakage due to changes to Julia, or any of your package dependencies. If your dependencies are easy to install on linux, then I'm sure Ian will be happy to discuss installing them on the server. Alternatively, some packages can be marked Untestable rather than broken, if their dependencies are difficult to acquire. Packages with proprietary commercial dependencies are marked this way, for example. Either way, you can raise an issue at https://github.com/IainNZ/PackageEvaluator.jl/issues to discuss the specifics for your package. Regards - Avik On Thursday, 22 January 2015 14:51:16 UTC, Josh Langsfeld wrote: This is a fairly minor topic, but thought I'd bring it up anyway. I noticed the pkg.julialang.org listings generate pass/fail info for the package tests by running the tests locally rather than hooking into Travis. This is a problem for me as my Travis script involves installing dependencies, and so it will always list as Tests fail as things currently are. Is there a way to have it display the travis build status instead? Thanks, Josh
[julia-users] How to convert character to numeric
I crossed this behavior when converting a C code that used atoi() and atof() julia a=12 12 This is fine, we get the number julia float(a) 12.0 but now, surprise, we get the ASCII code julia float(a[2]) 50.0
Re: [julia-users] Getting 0 test coverage, when I know that's not true...
Are you saying that no line has anything higher than a 1 in front of it? I just tried the procedure you described below, as well as the simpler `Pkg.test(Control, coverage=true)` (which now works on julia 0.4 again, if you're up to date). Both approaches worked fine for me. Do you have any problems with your backtraces, or anything else potentially related? What's your platform? --Tim On Thursday, January 22, 2015 11:52:17 AM James Crist wrote: I'm having issues getting coverage to work. Here's what I'm doing: 1. From my package directory I run this: $ julia --code-coverage --inline=no test/runtests.jl This results in *.cov files for all files that are run. 2. Run julia, then: julia using Coverage julia coverage_folder() This prints out a list of files in my src folder. All files that have *.cov associated with them also show Skipped file_name. Looking closer at the *.cov files, I see that all lines that *I know* are run have a 0 next to them, even if they are run several several times in the tests. Lines that have no coverage are still at `-`. Any idea why? I'm kind of baffled on this. The package in question: https://github.com/JuliaControl/Control.jl
Re: [julia-users] Getting 0 test coverage, when I know that's not true...
The one other thing that could be useful would be full versioninfo(); it could be a LLVM-version thing. Please do file this as an issue, so it doesn't get lost. But the bottom line is that I have no clue what's going on. Your version of julia is nominally new enough to not have any coverage-related bugs I know about :-). But it's not behaving in the typical manner, so something is wrong. In case it's a packaging problem, depending on how much you care about this functionality you may want to try building your own julia straight from the git repo. Best, --Tim On Thursday, January 22, 2015 05:41:20 PM James Crist wrote: Yeah. All lines that get run are 0, and all untested lines remain at `-`. My backtraces all look fine (at least I haven't noticed anything weird). Platform is x86_64 arch linux, running 8 day old master, commit eea31ae*. I can replicate this in a small testable case by creating a small script, and running it with coverage, so it's not specific to my package. On Thu, Jan 22, 2015 at 5:31 PM, Tim Holy tim.h...@gmail.com wrote: Are you saying that no line has anything higher than a 1 in front of it? I just tried the procedure you described below, as well as the simpler `Pkg.test(Control, coverage=true)` (which now works on julia 0.4 again, if you're up to date). Both approaches worked fine for me. Do you have any problems with your backtraces, or anything else potentially related? What's your platform? --Tim On Thursday, January 22, 2015 11:52:17 AM James Crist wrote: I'm having issues getting coverage to work. Here's what I'm doing: 1. From my package directory I run this: $ julia --code-coverage --inline=no test/runtests.jl This results in *.cov files for all files that are run. 2. Run julia, then: julia using Coverage julia coverage_folder() This prints out a list of files in my src folder. All files that have *.cov associated with them also show Skipped file_name. Looking closer at the *.cov files, I see that all lines that *I know* are run have a 0 next to them, even if they are run several several times in the tests. Lines that have no coverage are still at `-`. Any idea why? I'm kind of baffled on this. The package in question: https://github.com/JuliaControl/Control.jl
Re: [julia-users] Saving Julia dataframe to read in R using HDF5
On Thursday, January 22, 2015 04:48:13 PM Pavel wrote: Thanks Tim for responding. I tried with `JLD.jldopen` instead. Now all the columns are saved including boolean without conversion to integer, as expected. However R session consistently crashes when trying to even look at the file structure with `rhdf5::h5ls(trydf.h5)`. Not sure if this is rhdf5 R-package issue or not, but something goes wrong when JLD annotations are present. From the Bioconductor website it appears that rhdf5 aims to be a generic HDF5 interface. So if it's crashing on a *.jld file---which is an HDF5 file---then it indicates some limitation of rhdf5. On a more conceptual level, are R and Julia DataFrame structures too different to manage read/write without reassembling from separate columns? Can't answer that, because I don't know R. Maybe someone else can. If you try running the jld_dataframe.jl test in HDF5.jl and inspect the results with h5dump, you'll see that each column is already split out for you, if you know where to look. (Start with the df2 data set and follow the references.) Best, --Tim
Re: [julia-users] Saving Julia dataframe to read in R using HDF5
I don't know if it can do it yet, but the RCall package might be able to save data back to an RData file. It's a young package. Also, you could use CSV files. On Thu, Jan 22, 2015 at 2:09 PM, Pavel pavel.paramo...@gmail.com wrote: While reading R datasets in Julia received sufficient attention already, sometimes the results of computations done in Julia need to be readable to R. To accomplish that I was trying to save a DataFrame.jl https://github.com/JuliaStats/DataFrames.jl object in HDF5 file. The code so far is in my StackOverflow question (probably should have posted here instead): http://stackoverflow.com/questions/28084403/saving-julia-dataframe-to-read-in-r-using-hdf5 The dataframe can then be reassembled in R using rhdf5 http://www.bioconductor.org/packages/release/bioc/html/rhdf5.html package tools. It works in principle, but is there a more elegant way to accomplish this? Something that does not require to split the dataframe apart and re-assemble in R, losing some column types (e.g. boolean does not work) along the way?
Re: [julia-users] Getting 0 test coverage, when I know that's not true...
I'm using the arch build from the aur, so it may be an issue with that. I'll try rebuilding it tonight with the latest master and see. I filed an issue here: https://github.com/JuliaLang/julia/issues/9891 On Thursday, January 22, 2015 at 8:18:09 PM UTC-6, Tim Holy wrote: The one other thing that could be useful would be full versioninfo(); it could be a LLVM-version thing. Please do file this as an issue, so it doesn't get lost. But the bottom line is that I have no clue what's going on. Your version of julia is nominally new enough to not have any coverage-related bugs I know about :-). But it's not behaving in the typical manner, so something is wrong. In case it's a packaging problem, depending on how much you care about this functionality you may want to try building your own julia straight from the git repo. Best, --Tim On Thursday, January 22, 2015 05:41:20 PM James Crist wrote: Yeah. All lines that get run are 0, and all untested lines remain at `-`. My backtraces all look fine (at least I haven't noticed anything weird). Platform is x86_64 arch linux, running 8 day old master, commit eea31ae*. I can replicate this in a small testable case by creating a small script, and running it with coverage, so it's not specific to my package. On Thu, Jan 22, 2015 at 5:31 PM, Tim Holy tim@gmail.com javascript: wrote: Are you saying that no line has anything higher than a 1 in front of it? I just tried the procedure you described below, as well as the simpler `Pkg.test(Control, coverage=true)` (which now works on julia 0.4 again, if you're up to date). Both approaches worked fine for me. Do you have any problems with your backtraces, or anything else potentially related? What's your platform? --Tim On Thursday, January 22, 2015 11:52:17 AM James Crist wrote: I'm having issues getting coverage to work. Here's what I'm doing: 1. From my package directory I run this: $ julia --code-coverage --inline=no test/runtests.jl This results in *.cov files for all files that are run. 2. Run julia, then: julia using Coverage julia coverage_folder() This prints out a list of files in my src folder. All files that have *.cov associated with them also show Skipped file_name. Looking closer at the *.cov files, I see that all lines that *I know* are run have a 0 next to them, even if they are run several several times in the tests. Lines that have no coverage are still at `-`. Any idea why? I'm kind of baffled on this. The package in question: https://github.com/JuliaControl/Control.jl
Re: [julia-users] Re: Almost at 500 packages!
As a tangent about conda and package granularity: something that has stuck with me is a comment from Travis Oliphant that the scipy package itself is only as big as it is because of the historical difficulty of binary packaging; ideally scipy would have been split into separate inter-related libraries. Certainly seems to me that Julia is on the right track in this regard. http://vimeo.com/79862018 (skip to 14:35 for the comment) Kyle On Thu, Jan 22, 2015 at 11:10 AM, Joshua Adelman joshua.adel...@gmail.com wrote: Personally (and I am definitely biased by experience), I really like the model that is used pretty widely in the scientific python community. A lot of people use Continuum's Anaconda Python distribution, which includes about 200 packages (not all of them are actually python though). It's tested and represents most of the really important core libraries that one might use. I think that I end up having less than 20 other packages that I've installed in my python environment manually either via pip (using PyPi), a standard setup.py install, or an auxiliary conda (Anaconda's package manager) channel: http://docs.continuum.io/anaconda/pkg-docs.html Sure PyPi has many more packages available, but that a package is included in Anaconda sends a signal that it is being (relatively) widely used. Enthought has a similar distribution as well. A curated distribution may be better suited for a more mature ecosystem. Somewhat unrelated, another really nice feature of Anaconda (actually of it's package manager Conda), is the ability to create isolated, named environments to test out new packages or new versions of a package. I'm sure that there is a way to do this with Julia's Pkg interface (I've seen Playground.jl that does something similar too). Since a number of Julia packages leverage PyCall, and Continuum is now building official conda packages for R (http://continuum.io/blog/preliminary-support-R-conda), maybe it would be useful to do something similar for Julia. Perhaps this has been discussed previously. Josh On Jan 22, 2015, at 1:49 PM, Ista Zahn wrote: As an R user I'm surprised to see CRAN held up as a model to aspire to. There is a _lot_ of overlapping functionality among those 6k packages, making it hard to figure out which one is best for a particular purpose. There are also a lot of unfocused packages providing miscellaneous collections of functions, which makes it difficult to understand exactly what the package offers you as a user. As a user things are easier if a) each package has a clearly defined scope (i.e., does one thing well), and b) there are not too many similar packages to choose from for any particular task. None of this is to say that julia isn't on the right track in terms of packages, just that I question the wisdom of emulating CRAN in this regard. Best, Ista On Wed, Jan 21, 2015 at 7:46 PM, Iain Dunning iaindunn...@gmail.com wrote: Yes indeed Christoph, a package that doesn't work is a package that might as well not exist. Fortunately, and fairly uniquely I think, we can quantify to some extent how many of our packages are working, and the degree to which they are. In my mind the goal now is grow fast and don't break too many things, and I think our pace over the last month or so of around 1 package per day is fantastic, with good stability of packages (i.e. they pass tests). I've also noticed that packages being registered now are often of a higher quality than they used to be, in terms of tests and documentation. I talked about this a bit at JuliaCon, but in some sense NPM and CRAN represent different ends of a spectrum of possibilities, and it seems like the consensus is more towards CRAN. So, we're doing good I think. On Wed, Jan 21, 2015 at 7:02 PM, Kevin Squire kevin.squ...@gmail.com wrote: Additional references: PyPI lists 54212 packages, currently (roughly half as many as node) but, CRAN only has 6214. Cheers, Kevin On Wed, Jan 21, 2015 at 3:37 PM, Sean Garborg sean.garb...@gmail.com wrote: You wouldn't like node ;) On Wednesday, January 21, 2015 at 4:29:53 PM UTC-7, Christoph Ortner wrote: Great that so many are contributing to Julia, but I would question whether such a large number of packages will be healthy in the long run. It will make it very difficult for new users to use Julia effectively. -- Iain Dunning PhD Candidate / MIT Operations Research Center http://iaindunning.com / http://juliaopt.org
[julia-users] Re: How to convert character to numeric
On Thursday, January 22, 2015 at 3:27:59 PM UTC-8, J Luis wrote: I crossed this behavior when converting a C code that used atoi() and atof() julia a=12 12 This is fine, we get the number julia float(a) 12.0 but now, surprise, we get the ASCII code julia float(a[2]) 50.0 This is because a[2] returns Char, which is then evaluated as int 50, as you observed. To get the presumably desired behavior (2.0), float(string(a[2])) should work.
Re: [julia-users] Saving Julia dataframe to read in R using HDF5
In your code, could you basically replace `h5open` with `jldopen`? That way when you try reading the same file again with julia, you'll have all the type information. JLD is basically HDF5 with annotations that JLD knows how to interpret. If you're reading the file from another language, you don't have to pay attention to the annotations (unless you want to). --Tim On Thursday, January 22, 2015 11:09:25 AM Pavel wrote: While reading R datasets in Julia received sufficient attention already, sometimes the results of computations done in Julia need to be readable to R. To accomplish that I was trying to save a DataFrame.jl https://github.com/JuliaStats/DataFrames.jl object in HDF5 file. The code so far is in my StackOverflow question (probably should have posted here instead): http://stackoverflow.com/questions/28084403/saving-julia-dataframe-to-read-i n-r-using-hdf5 The dataframe can then be reassembled in R using rhdf5 http://www.bioconductor.org/packages/release/bioc/html/rhdf5.html package tools. It works in principle, but is there a more elegant way to accomplish this? Something that does not require to split the dataframe apart and re-assemble in R, losing some column types (e.g. boolean does not work) along the way?
[julia-users] Re: How to convert character to numeric
On Thursday, January 22, 2015 at 3:35:21 PM UTC-8, Seth wrote: On Thursday, January 22, 2015 at 3:27:59 PM UTC-8, J Luis wrote: I crossed this behavior when converting a C code that used atoi() and atof() julia a=12 12 This is fine, we get the number julia float(a) 12.0 but now, surprise, we get the ASCII code julia float(a[2]) 50.0 This is because a[2] returns Char, which is then evaluated as int 50, as you observed. To get the presumably desired behavior (2.0), float(string(a[2])) should work. I forgot to add: float(a[2:2]) will also work, as a range subscript produces a string.
[julia-users] Re: How to convert character to numeric
Thanks, though a bit convoluted. I think these type of operations are common enough to deserve their own functions in Base. quinta-feira, 22 de Janeiro de 2015 às 23:36:42 UTC, Seth escreveu: On Thursday, January 22, 2015 at 3:35:21 PM UTC-8, Seth wrote: On Thursday, January 22, 2015 at 3:27:59 PM UTC-8, J Luis wrote: I crossed this behavior when converting a C code that used atoi() and atof() julia a=12 12 This is fine, we get the number julia float(a) 12.0 but now, surprise, we get the ASCII code julia float(a[2]) 50.0 This is because a[2] returns Char, which is then evaluated as int 50, as you observed. To get the presumably desired behavior (2.0), float(string(a[2])) should work. I forgot to add: float(a[2:2]) will also work, as a range subscript produces a string.
Re: [julia-users] Saving Julia dataframe to read in R using HDF5
Thanks Tim for responding. I tried with `JLD.jldopen` instead. Now all the columns are saved including boolean without conversion to integer, as expected. However R session consistently crashes when trying to even look at the file structure with `rhdf5::h5ls(trydf.h5)`. Not sure if this is rhdf5 R-package issue or not, but something goes wrong when JLD annotations are present. On a more conceptual level, are R and Julia DataFrame structures too different to manage read/write without reassembling from separate columns? On Thursday, January 22, 2015 at 3:25:06 PM UTC-8, Tim Holy wrote: In your code, could you basically replace `h5open` with `jldopen`? That way when you try reading the same file again with julia, you'll have all the type information. JLD is basically HDF5 with annotations that JLD knows how to interpret. If you're reading the file from another language, you don't have to pay attention to the annotations (unless you want to). --Tim On Thursday, January 22, 2015 11:09:25 AM Pavel wrote: While reading R datasets in Julia received sufficient attention already, sometimes the results of computations done in Julia need to be readable to R. To accomplish that I was trying to save a DataFrame.jl https://github.com/JuliaStats/DataFrames.jl object in HDF5 file. The code so far is in my StackOverflow question (probably should have posted here instead): http://stackoverflow.com/questions/28084403/saving-julia-dataframe-to-read-i n-r-using-hdf5 The dataframe can then be reassembled in R using rhdf5 http://www.bioconductor.org/packages/release/bioc/html/rhdf5.html package tools. It works in principle, but is there a more elegant way to accomplish this? Something that does not require to split the dataframe apart and re-assemble in R, losing some column types (e.g. boolean does not work) along the way?
Re: [julia-users] Re: Plotting-package-independent API
Sims.jl uses the Requires.jl approach that Matt mentioned. There are a few helper plotting methods that are optional depending on what packages the user loads: https://github.com/tshort/Sims.jl/blob/master/src/utils.jl#L158-L181 https://tshort.github.io/Sims.jl/plotting/ On Thu, Jan 22, 2015 at 3:36 PM, Matt Bauman mbau...@gmail.com wrote: I've thought some about this in the past, too. Coming from Matlab, I've imagined a Matlab-esque Base.Plots module that has just a handful of definitions, mirroring the IO system: abstract AbstractPlot immutable NoPlots : AbstractPlot end STDPLOT = NoPlots() # When a plotting package loads, it assigns its own AbstractPlot object to STDPLOT line(args...) = line(STDPLOT, args...) line(p::AbstractPlot, ys::AbstractArray) = line(p, 1:size(ys,1), ys) # Then each plotting package would specialize on the following method: line(::NoPlots, xs, ys) = error(Plotting requires a plotting package to be installed. Here, try one of these: …) # … and so on for just a handful of very common (and specific!) names … scatter() … bar() … surface() … Of course, doing anything more complicated would require delving into documentation and using a more package-specific function. But users could easily start from the source for these simple prototypes and grow from there. Sure, this will be heretical for some plotting packages, but I think there's value here, especially for quick and dirty exploratory data analysis. The plot function is tougher — there's not really a meaning to it beyond show this thing graphically, and packages use keywords or other arguments to determine the kind of plot. I could see it being useful in cases like yours, though, where you want to define a plotting routine for a your own ROC object type. You would simply define `plot(p::AbstractPlot, t:: ROCType)` and then use the above primitives. The trouble is, as a package author, you'll want to add fancier features like labels, legends, colors, titles, bounds, error-bars, shaded regions, transforms, etc…. and now we're marching down that crazy never-ending path Daniel fears. So: yes, it's possible. Is it useful? I'm not so sure. I think no matter what you're going to have to learn a specific plotting API, and as a package author I think you're better off picking one to support well and extending its functions directly. Maybe some cavalier users will come by and add support for others they like with lazy loading through Requires.jl. :) Matt On Thursday, January 22, 2015 at 1:03:44 PM UTC-5, Simon Danisch wrote: The reference does seem to fit here, as a general plotting language seems to be awfully complicated. By the way, I totally forgot to mention, that I want to turn GLPlot more into a meta package, offering different plotting interfaces, since I'm generalizing more and more of the render code and a lot of people prefer different interfaces to the same functionality. So it might become a lightweight package, which actually doesn't contain render code and only defines interfaces. If someone has any API that he wants to implement, GLPlot might become the go to package. If this happens, I should rename it though ;) Am Donnerstag, 22. Januar 2015 16:42:37 UTC+1 schrieb David van Leeuwen: Hello, I've just read up on most recent conversations mentioning plotting, after I went through a similar install-and-try-out cycle for the various plotting packages. I am busy with a package named ROC https://github.com/davidavdav/ROC (Receiver Operating Characteristic). It is mostly about decision cost functions and efficiently computing ROC statistics, but there is also some support for making various plots related to the ROC. I do not want to decide for a potential user of this package which plotting package she should use. So it would be nice if there would be an abstract plotting API (I suppose this does not exist yet). Supposing that it is possible to make an API that includes some common plotting primitives, and that makes a runtime selection based on `isdefined(plottingpackagename)`, how would you - overload a function, typically `plot()`, when at module-include time it is not yet known which plotting package the user wants - specify the dependence of this package to any one of the available plotting packages. Thoughts? Thanks, ---david
Re: [julia-users] Re: RFC Display of markdown sections in terminal
left-align seems to be the consensus, so I've updated the PR. Thanks! julia Markdown.parse(# Title) Title === julia Markdown.parse(## Section) Section – julia Markdown.parse(### SubSection) SubSection On Wednesday, 21 January 2015 10:39:17 UTC-8, Stefan Karpinski wrote: Agree. Left-aligning seems better. On Wed, Jan 21, 2015 at 1:35 PM, Tony Kelman to...@kelman.net javascript: wrote: +1 for left-aligning On Tuesday, January 20, 2015 at 11:37:43 AM UTC-8, andy hayden wrote: I posted a PR about this, but would like to gauge thoughts on what formatting for headings (purely in the REPL e.g. in help messages - elsewhere e.g. in html, they are rendered differently). I tentatively put: julia Base.Markdown.parse(#Title) Title -=- julia Base.Markdown.parse(##Section) Section -–––- julia Base.Markdown.parse(###Subsection) Subsection –– Though, as I comment in the PR, personally I dislike centered headings (I find them difficult to read) and prefer left-aligned. Do others feel the same/have other/better ideas for this? https://github.com/JuliaLang/julia/pull/9853
[julia-users] Saving Julia dataframe to read in R using HDF5
While reading R datasets in Julia received sufficient attention already, sometimes the results of computations done in Julia need to be readable to R. To accomplish that I was trying to save a DataFrame.jl https://github.com/JuliaStats/DataFrames.jl object in HDF5 file. The code so far is in my StackOverflow question (probably should have posted here instead): http://stackoverflow.com/questions/28084403/saving-julia-dataframe-to-read-in-r-using-hdf5 The dataframe can then be reassembled in R using rhdf5 http://www.bioconductor.org/packages/release/bioc/html/rhdf5.html package tools. It works in principle, but is there a more elegant way to accomplish this? Something that does not require to split the dataframe apart and re-assemble in R, losing some column types (e.g. boolean does not work) along the way?
Re: [julia-users] Re: Almost at 500 packages!
Personally (and I am definitely biased by experience), I really like the model that is used pretty widely in the scientific python community. A lot of people use Continuum's Anaconda Python distribution, which includes about 200 packages (not all of them are actually python though). It's tested and represents most of the really important core libraries that one might use. I think that I end up having less than 20 other packages that I've installed in my python environment manually either via pip (using PyPi), a standard setup.py install, or an auxiliary conda (Anaconda's package manager) channel: http://docs.continuum.io/anaconda/pkg-docs.html Sure PyPi has many more packages available, but that a package is included in Anaconda sends a signal that it is being (relatively) widely used. Enthought has a similar distribution as well. A curated distribution may be better suited for a more mature ecosystem. Somewhat unrelated, another really nice feature of Anaconda (actually of it's package manager Conda), is the ability to create isolated, named environments to test out new packages or new versions of a package. I'm sure that there is a way to do this with Julia's Pkg interface (I've seen Playground.jl that does something similar too). Since a number of Julia packages leverage PyCall, and Continuum is now building official conda packages for R (http://continuum.io/blog/preliminary-support-R-conda), maybe it would be useful to do something similar for Julia. Perhaps this has been discussed previously. Josh On Jan 22, 2015, at 1:49 PM, Ista Zahn wrote: As an R user I'm surprised to see CRAN held up as a model to aspire to. There is a _lot_ of overlapping functionality among those 6k packages, making it hard to figure out which one is best for a particular purpose. There are also a lot of unfocused packages providing miscellaneous collections of functions, which makes it difficult to understand exactly what the package offers you as a user. As a user things are easier if a) each package has a clearly defined scope (i.e., does one thing well), and b) there are not too many similar packages to choose from for any particular task. None of this is to say that julia isn't on the right track in terms of packages, just that I question the wisdom of emulating CRAN in this regard. Best, Ista On Wed, Jan 21, 2015 at 7:46 PM, Iain Dunning iaindunn...@gmail.com wrote: Yes indeed Christoph, a package that doesn't work is a package that might as well not exist. Fortunately, and fairly uniquely I think, we can quantify to some extent how many of our packages are working, and the degree to which they are. In my mind the goal now is grow fast and don't break too many things, and I think our pace over the last month or so of around 1 package per day is fantastic, with good stability of packages (i.e. they pass tests). I've also noticed that packages being registered now are often of a higher quality than they used to be, in terms of tests and documentation. I talked about this a bit at JuliaCon, but in some sense NPM and CRAN represent different ends of a spectrum of possibilities, and it seems like the consensus is more towards CRAN. So, we're doing good I think. On Wed, Jan 21, 2015 at 7:02 PM, Kevin Squire kevin.squ...@gmail.com wrote: Additional references: PyPI lists 54212 packages, currently (roughly half as many as node) but, CRAN only has 6214. Cheers, Kevin On Wed, Jan 21, 2015 at 3:37 PM, Sean Garborg sean.garb...@gmail.com wrote: You wouldn't like node ;) On Wednesday, January 21, 2015 at 4:29:53 PM UTC-7, Christoph Ortner wrote: Great that so many are contributing to Julia, but I would question whether such a large number of packages will be healthy in the long run. It will make it very difficult for new users to use Julia effectively. -- Iain Dunning PhD Candidate / MIT Operations Research Center http://iaindunning.com / http://juliaopt.org
[julia-users] Debugging: stepping into another package
I'm using the Debug package. I want to set a break point and then step into another external package (in this case Mocha), I tried something like this: *using Mochausing Debug#...set up a lot of Mocha stuff ...#@debug (()- begin println(break point!) @bp solve(solver,net)end)()* It does indeed stop at the @bp: * 142println(break point!) -- 143@bp 144 solve(solver, net)debug:143 sat /home/phil/devel/WASP_TD/algorithm_dev/processing/depth_engine/src/learn_grad_whole.jl:144 143@bp -- 144solve(solver, net) 145 end)()debug:144 s*but at that point it doesn't step into the solve function (defined in Mocha package). Is there any way to do that?
[julia-users] Re: Plotting-package-independent API
Hello,
On Thursday, January 22, 2015 at 5:13:05 PM UTC+1, Simon Danisch wrote:
Well, I'm planning to introduce some functionality similar to show,
building upon a rich type system.
What I have in mind is something like this:
show(::Matrix{Z}; parameters...) = Surface
show(::Matrix{Red}; parameters...) = Red channel
show(::Matrix{RGB}; parameters...) = Image
show(::Matrix{Vector2}; parameters...) = Vectorfield
show(::Vector{Y}; parameters...) = Line plot
show(::Vector{Point2D}; parameters...) = scatter plot
show(::Vector{Point3D}; parameters...) = 3D point cloud
show(::(Vector{Point3D}, Vector{Face}); parameters...) = mesh
This is nice for visual debugging, but probably not sufficient for more
complicated plots and annotations.
This is cool, and I think you can do things this way because `show()` is
defined in Base, and defines the API.
However, the various `plot()` etc defined in modules Winston, PGFSPlots,
etc do not overload a `Base.plot()`, i.e., there is no API defined for the
most common plotting calls AFAIK. So I am still struggling how I can
overload a `plot()` without `using` a specific plotting module like
Winston, PGFSPlots in my module---because I want to leave that choice to
the user.
---david
Am Donnerstag, 22. Januar 2015 16:42:37 UTC+1 schrieb David van Leeuwen:
Hello,
I've just read up on most recent conversations mentioning plotting, after
I went through a similar install-and-try-out cycle for the various plotting
packages.
I am busy with a package named ROC https://github.com/davidavdav/ROC
(Receiver
Operating Characteristic). It is mostly about decision cost functions and
efficiently computing ROC statistics, but there is also some support for
making various plots related to the ROC.
I do not want to decide for a potential user of this package which
plotting package she should use. So it would be nice if there would be an
abstract plotting API (I suppose this does not exist yet).
Supposing that it is possible to make an API that includes some common
plotting primitives, and that makes a runtime selection based on
`isdefined(plottingpackagename)`, how would you
- overload a function, typically `plot()`, when at module-include time
it is not yet known which plotting package the user wants
- specify the dependence of this package to any one of the available
plotting packages.
Thoughts?
Thanks,
---david
[julia-users] Re: Plotting-package-independent API
I don't know if it is a good idea or not, but using the `Requires` package
is one way to do this. That package's `@require` macro lets you define
functions when another package is loaded, such as a plotting package. A
pattern like this can be used:
using Requires
Requires.@require PyPlot begin
end
Requires.@require Gadfly begin
end
On Thursday, January 22, 2015 at 12:20:57 PM UTC-5, David van Leeuwen wrote:
Hello,
On Thursday, January 22, 2015 at 5:13:05 PM UTC+1, Simon Danisch wrote:
Well, I'm planning to introduce some functionality similar to show,
building upon a rich type system.
What I have in mind is something like this:
show(::Matrix{Z}; parameters...) = Surface
show(::Matrix{Red}; parameters...) = Red channel
show(::Matrix{RGB}; parameters...) = Image
show(::Matrix{Vector2}; parameters...) = Vectorfield
show(::Vector{Y}; parameters...) = Line plot
show(::Vector{Point2D}; parameters...) = scatter plot
show(::Vector{Point3D}; parameters...) = 3D point cloud
show(::(Vector{Point3D}, Vector{Face}); parameters...) = mesh
This is nice for visual debugging, but probably not sufficient for more
complicated plots and annotations.
This is cool, and I think you can do things this way because `show()` is
defined in Base, and defines the API.
However, the various `plot()` etc defined in modules Winston, PGFSPlots,
etc do not overload a `Base.plot()`, i.e., there is no API defined for the
most common plotting calls AFAIK. So I am still struggling how I can
overload a `plot()` without `using` a specific plotting module like
Winston, PGFSPlots in my module---because I want to leave that choice to
the user.
---david
Am Donnerstag, 22. Januar 2015 16:42:37 UTC+1 schrieb David van Leeuwen:
Hello,
I've just read up on most recent conversations mentioning plotting,
after I went through a similar install-and-try-out cycle for the various
plotting packages.
I am busy with a package named ROC https://github.com/davidavdav/ROC
(Receiver
Operating Characteristic). It is mostly about decision cost functions and
efficiently computing ROC statistics, but there is also some support for
making various plots related to the ROC.
I do not want to decide for a potential user of this package which
plotting package she should use. So it would be nice if there would be an
abstract plotting API (I suppose this does not exist yet).
Supposing that it is possible to make an API that includes some common
plotting primitives, and that makes a runtime selection based on
`isdefined(plottingpackagename)`, how would you
- overload a function, typically `plot()`, when at module-include time
it is not yet known which plotting package the user wants
- specify the dependence of this package to any one of the available
plotting packages.
Thoughts?
Thanks,
---david
[julia-users] Re: Plotting-package-independent API
The reference does seem to fit here, as a general plotting language seems to be awfully complicated. By the way, I totally forgot to mention, that I want to turn GLPlot more into a meta package, offering different plotting interfaces, since I'm generalizing more and more of the render code and a lot of people prefer different interfaces to the same functionality. So it might become a lightweight package, which actually doesn't contain render code and only defines interfaces. If someone has any API that he wants to implement, GLPlot might become the go to package. If this happens, I should rename it though ;) Am Donnerstag, 22. Januar 2015 16:42:37 UTC+1 schrieb David van Leeuwen: Hello, I've just read up on most recent conversations mentioning plotting, after I went through a similar install-and-try-out cycle for the various plotting packages. I am busy with a package named ROC https://github.com/davidavdav/ROC (Receiver Operating Characteristic). It is mostly about decision cost functions and efficiently computing ROC statistics, but there is also some support for making various plots related to the ROC. I do not want to decide for a potential user of this package which plotting package she should use. So it would be nice if there would be an abstract plotting API (I suppose this does not exist yet). Supposing that it is possible to make an API that includes some common plotting primitives, and that makes a runtime selection based on `isdefined(plottingpackagename)`, how would you - overload a function, typically `plot()`, when at module-include time it is not yet known which plotting package the user wants - specify the dependence of this package to any one of the available plotting packages. Thoughts? Thanks, ---david
[julia-users] Re: Plotting-package-independent API
I've thought some about this in the past, too. Coming from Matlab, I've imagined a Matlab-esque Base.Plots module that has just a handful of definitions, mirroring the IO system: abstract AbstractPlot immutable NoPlots : AbstractPlot end STDPLOT = NoPlots() # When a plotting package loads, it assigns its own AbstractPlot object to STDPLOT line(args...) = line(STDPLOT, args...) line(p::AbstractPlot, ys::AbstractArray) = line(p, 1:size(ys,1), ys) # Then each plotting package would specialize on the following method: line(::NoPlots, xs, ys) = error(Plotting requires a plotting package to be installed. Here, try one of these: …) # … and so on for just a handful of very common (and specific!) names … scatter() … bar() … surface() … Of course, doing anything more complicated would require delving into documentation and using a more package-specific function. But users could easily start from the source for these simple prototypes and grow from there. Sure, this will be heretical for some plotting packages, but I think there's value here, especially for quick and dirty exploratory data analysis. The plot function is tougher — there's not really a meaning to it beyond show this thing graphically, and packages use keywords or other arguments to determine the kind of plot. I could see it being useful in cases like yours, though, where you want to define a plotting routine for a your own ROC object type. You would simply define `plot(p::AbstractPlot, t::ROCType )` and then use the above primitives. The trouble is, as a package author, you'll want to add fancier features like labels, legends, colors, titles, bounds, error-bars, shaded regions, transforms, etc…. and now we're marching down that crazy never-ending path Daniel fears. So: yes, it's possible. Is it useful? I'm not so sure. I think no matter what you're going to have to learn a specific plotting API, and as a package author I think you're better off picking one to support well and extending its functions directly. Maybe some cavalier users will come by and add support for others they like with lazy loading through Requires.jl. :) Matt On Thursday, January 22, 2015 at 1:03:44 PM UTC-5, Simon Danisch wrote: The reference does seem to fit here, as a general plotting language seems to be awfully complicated. By the way, I totally forgot to mention, that I want to turn GLPlot more into a meta package, offering different plotting interfaces, since I'm generalizing more and more of the render code and a lot of people prefer different interfaces to the same functionality. So it might become a lightweight package, which actually doesn't contain render code and only defines interfaces. If someone has any API that he wants to implement, GLPlot might become the go to package. If this happens, I should rename it though ;) Am Donnerstag, 22. Januar 2015 16:42:37 UTC+1 schrieb David van Leeuwen: Hello, I've just read up on most recent conversations mentioning plotting, after I went through a similar install-and-try-out cycle for the various plotting packages. I am busy with a package named ROC https://github.com/davidavdav/ROC (Receiver Operating Characteristic). It is mostly about decision cost functions and efficiently computing ROC statistics, but there is also some support for making various plots related to the ROC. I do not want to decide for a potential user of this package which plotting package she should use. So it would be nice if there would be an abstract plotting API (I suppose this does not exist yet). Supposing that it is possible to make an API that includes some common plotting primitives, and that makes a runtime selection based on `isdefined(plottingpackagename)`, how would you - overload a function, typically `plot()`, when at module-include time it is not yet known which plotting package the user wants - specify the dependence of this package to any one of the available plotting packages. Thoughts? Thanks, ---david
Re: [julia-users] Re: Almost at 500 packages!
I think that multiple dispatch helps here a lot – or really just the fact that methods don't live *inside* of types like they do in class-based single-dispatch o.o. languages. This lets one shared package define a bunch of straightforward types and other packages can use those types without having to agree exactly on what functions those shared types need to support. Distributions is a great example – the definitions of distribution types are pretty uncontroversial and those same types can be used for anything from asking for PDF/CDF values, sampling, or for probabilistic programming. I'm hopeful that this can help Julia to have a more cleanly factored package ecosystem than other languages have been able to. On Thu, Jan 22, 2015 at 2:00 PM, Jacob Quinn quinn.jac...@gmail.com wrote: Great points Ista. I think the main motivation in emulating CRAN is with respect to overall volume of functionality, but your points about too many overlapping or half-baked packages strike home as a former (and still occasional) R user. I think the efforts in the Julia package repository, METADATA, to encourage collaboration and merging packages are the most important and useful in managing the package ecosystem. As a personal anecdote, I initially created the SQLite.jl package closely following the sqldf R package. After an initial sprint, I had other priorities take over and the package languished a bit. Once I found more time (and need!), I started a redesign of the package from the ground up to be more Julian. Coincidently, at the same time, I came across a reddit thread where Sean Marshallsay had published a post about redesigning the SQLite package to be more Julian as well. I pinged him on reddit to see if he'd be willing to combine efforts on redesigning the package with me and he's contributed some of the most useful functionality now to date (being able to register and run custom julia scalar and aggregate functions in SQLite). I think in another world (or another programming language), I would have seen his post and thought, Oh well, someone else is creating a competing package. But having grown with the Julia community for a couple years now, I thought I'd reach out about collaborating, and it's certainly worked out quite well for everyone, IMO. Anyway, TL;DR the collaborative nature of the package community is one of my all-time favorite aspects of Julia. -Jacob On Thu, Jan 22, 2015 at 11:49 AM, Ista Zahn istaz...@gmail.com wrote: As an R user I'm surprised to see CRAN held up as a model to aspire to. There is a _lot_ of overlapping functionality among those 6k packages, making it hard to figure out which one is best for a particular purpose. There are also a lot of unfocused packages providing miscellaneous collections of functions, which makes it difficult to understand exactly what the package offers you as a user. As a user things are easier if a) each package has a clearly defined scope (i.e., does one thing well), and b) there are not too many similar packages to choose from for any particular task. None of this is to say that julia isn't on the right track in terms of packages, just that I question the wisdom of emulating CRAN in this regard. Best, Ista On Wed, Jan 21, 2015 at 7:46 PM, Iain Dunning iaindunn...@gmail.com wrote: Yes indeed Christoph, a package that doesn't work is a package that might as well not exist. Fortunately, and fairly uniquely I think, we can quantify to some extent how many of our packages are working, and the degree to which they are. In my mind the goal now is grow fast and don't break too many things, and I think our pace over the last month or so of around 1 package per day is fantastic, with good stability of packages (i.e. they pass tests). I've also noticed that packages being registered now are often of a higher quality than they used to be, in terms of tests and documentation. I talked about this a bit at JuliaCon, but in some sense NPM and CRAN represent different ends of a spectrum of possibilities, and it seems like the consensus is more towards CRAN. So, we're doing good I think. On Wed, Jan 21, 2015 at 7:02 PM, Kevin Squire kevin.squ...@gmail.com wrote: Additional references: PyPI lists 54212 packages, currently (roughly half as many as node) but, CRAN only has 6214. Cheers, Kevin On Wed, Jan 21, 2015 at 3:37 PM, Sean Garborg sean.garb...@gmail.com wrote: You wouldn't like node ;) On Wednesday, January 21, 2015 at 4:29:53 PM UTC-7, Christoph Ortner wrote: Great that so many are contributing to Julia, but I would question whether such a large number of packages will be healthy in the long run. It will make it very difficult for new users to use Julia effectively. -- Iain Dunning PhD Candidate / MIT Operations Research Center http://iaindunning.com / http://juliaopt.org
[julia-users] Re: Plotting-package-independent API
The issue now is that there are several plotting packages, each with advantages and disadvantages, forcing users to make a choice often from limited information. I'm afraid defining another plotting API in Base, rather than simplifying the matter, will just create another choice you'll have to evaluate. It pains me to reference xkcd 927 http://xkcd.com/927/, since it's so often over-applied, but it seems applicable here. Simon's example of defining show functions for vaguely graphical types could be useful if it's kept simple, but the more complicated/featureful it becomes, the more it will start to exasperate the problem. On Thursday, January 22, 2015 at 7:42:37 AM UTC-8, David van Leeuwen wrote: Hello, I've just read up on most recent conversations mentioning plotting, after I went through a similar install-and-try-out cycle for the various plotting packages. I am busy with a package named ROC https://github.com/davidavdav/ROC (Receiver Operating Characteristic). It is mostly about decision cost functions and efficiently computing ROC statistics, but there is also some support for making various plots related to the ROC. I do not want to decide for a potential user of this package which plotting package she should use. So it would be nice if there would be an abstract plotting API (I suppose this does not exist yet). Supposing that it is possible to make an API that includes some common plotting primitives, and that makes a runtime selection based on `isdefined(plottingpackagename)`, how would you - overload a function, typically `plot()`, when at module-include time it is not yet known which plotting package the user wants - specify the dependence of this package to any one of the available plotting packages. Thoughts? Thanks, ---david
[julia-users] Re: pkg.julialang.org test
Please do file an issue! And if you have a suggestion for where to put a link, please let me know - I've never been able to figure it out. Thanks, Iain On Thursday, January 22, 2015 at 10:29:54 AM UTC-5, Josh Langsfeld wrote: Thanks for the info. Unstated in my question was that I didn't know where to go to pursue this so I'm glad you pointed me to the right place. On Thursday, January 22, 2015 at 10:05:42 AM UTC-5, Avik Sengupta wrote: The pkg.julialang.org checks slightly different things from the travis tests. In particular, while the travis tests run only when there is a change to the package code, these tests run nightly, and catch any package breakage due to changes to Julia, or any of your package dependencies. If your dependencies are easy to install on linux, then I'm sure Ian will be happy to discuss installing them on the server. Alternatively, some packages can be marked Untestable rather than broken, if their dependencies are difficult to acquire. Packages with proprietary commercial dependencies are marked this way, for example. Either way, you can raise an issue at https://github.com/IainNZ/PackageEvaluator.jl/issues to discuss the specifics for your package. Regards - Avik On Thursday, 22 January 2015 14:51:16 UTC, Josh Langsfeld wrote: This is a fairly minor topic, but thought I'd bring it up anyway. I noticed the pkg.julialang.org listings generate pass/fail info for the package tests by running the tests locally rather than hooking into Travis. This is a problem for me as my Travis script involves installing dependencies, and so it will always list as Tests fail as things currently are. Is there a way to have it display the travis build status instead? Thanks, Josh
[julia-users] Re: Google Summer of Code: Your Project Suggestions
ability to rotate and manipulate 3D plots would be nice On Tuesday, January 20, 2015 at 8:38:42 AM UTC-8, cormu...@mac.com wrote: JuliaGraphics https://github.com/juliagraphics, Geometry2D https://github.com/mroughan/Geometry2D.jl, etc. would be attractive to graphics-oriented programmers...
