Hi Petr, > Perhaps you could enable "issues" in your github repository so that we could > carry on this conversation there?
Or should we use your JFinEALE.jl isues list as I think my repo is only intended to be available for a limited time (so not to confuse users). I'm now watching on your JFinEALE repo and enabled issues on mine. A few more responses inserted below. Regards, Rob J. Goedman [email protected] > On Jan 11, 2015, at 4:18 PM, Petr Krysl <[email protected]> wrote: > > Hi Rob, > > I can't keep up with you. Your code is a moving target all the time. :) I apologize for the moving target. Didn't realize you were looking at the PkgStruc branch. The 'master' branch has been stable since this morning and just 50 minutes or so ago I finished a single layer version, fixed most of the issues you refer to below and all examples run equally fast as this morning. I will, for now, not make any further changes. To get it to build on Travis (I added a .travis.yml file) and disabled the Winston part on 3 examples. The plots work fine on my machine. > On Sunday, January 11, 2015 at 11:14:04 AM UTC-8, Rob J Goedman wrote: > Hi Petr, > > 1. I'm not sure I like to the levels of modules. This way a user has to know > which 2nd level modules he/she should be using. > > Is there a reason you choose this setup? > > I thought of that it was going to be easier controlling access to the > methods defined within individual modules. In fact now I can see that you > have transitioned your fork to a single module. And as expected you ran > into some difficulties with exporting. > In both the Acoustics Algorithm module and the Heat conduction Algorithm > module defined the method called steadystate(). When the method is used > by qualification from within the module things are fine, but if you're trying > to export it from the single-layer module the naming convention breaks and > you have to disambiguate the methods by prefixes.. In the PkgStruc branch there are now 2 versions of steadystate(), called heat_conduction_steadystate() and acoustics_steadystate(). A better approach might be to use multiple dispatch for this. > Also problematic is to decide at the top level what is going to be > exported. When these decisions are made where the methods are defined it > seems a little bit more natural. In this case the export happens at a place > that is different from words defined. But, could be that a central location > for all the exports might have an advantage. > > I typically prefer that the end user only needs a single 'using JFinEALE' > statement. That requires some additional work, so wanted to have your views > first before going there. Even then there are a few ways of how we can > implement that, e.g. remove the 2nd layer of modules (make them all methods) > or export more in JFinEALE. > > Two layers of modules would actually not be too bad. All exports in the PkgStruc branch are now in JFinEALE.jl and all intermediate module names have been removed. See if you like that or would prefer a more distributed approach. > 2. For now I've added *.vtk to .gitignore. > > I prefer to have examples in their own directory and .vtk files can be stored > there as well. Do you have a preference? > > The vtk files are not part of my repository as they are generated > on-the-fly when the examples run. I think adding .vtk to .gitignore allows users to upgrade the package in the future after re-running the example scripts (given that the package will not be marked 'dirty'). > 3. I have not Julia-normalized the Paraview paths lines in the examples. In > most cases, for now, I've made them @windows_only ... > > We could check if Paraview is available, e.g. by looking for an environment > variable or a definition in .juliarc.jl. > > Sure, what is in my repository is an ugly hack which is not going to work on > other people's machines. > Your solution would be a good one. Will look into that a bit more. Have not worked with Paraview before. > 4. I do export 'phun' right now in JFinEALE. > > Let me know what your preference is. > > By the way, last time I checked you had the bbasic datatypes defined twice, > once in the foundation module and once in the JFinEALE module. Should be fixed now. > You should be able to Pkg.clone("https://github.com/goedman/JFinEALE.jl > <https://github.com/goedman/JFinEALE.jl>") after Pkg.rm("JFinEALE") first. > Once this version is installed, you can run Pkg.test("JFinEALE"), it should > run all examples (twice in fact, to see if first time is slower than > subsequent times). > > The package test should actually not run all the examples.. It should run > only examples instrumented to perform tests.. Such as the ones I > instrumented for the acoustics. Agreed, I left your test_acoustics.jl intact. We can easily switch back to that test script. Just wanted to make sure coverage was as good as all examples. > Or we could make this version a branch or I could generate a PR first. > Regards, > > Petr > > >> On Jan 11, 2015, at 9:30 AM, Petr Krysl <[email protected] <javascript:>> >> wrote: >> >> Sounds like a good idea. >> P >> >> On Saturday, January 10, 2015 at 7:23:25 PM UTC-8, Rob J Goedman wrote: >> Petr, >> >> Would you like me to prepare a simple pull request tomorrow? >> >> Regards, >> Rob >> >> Sent from my iPhone >> >> > On Jan 10, 2015, at 6:22 PM, Petr Krysl <[email protected] <>> wrote: >> > >> > Hello everybody, >> > >> > I wonder if I could get some advice on how to structure a package? I >> > could see how the SRC and TEST folders had a place in the package >> > structure, but so far I could not discern a systematic way for access to >> > examples that use the package. In particular, when I create a package >> > (clone()),, and the package has an EXAMPLES folder, none of the stuff in >> > that folder is actually visible at the REPL... >> > >> > How should this be handled? >> > >> > Thanks, >> > >> > P >
