Hi Rob,
I can't keep up with you. Your code is a moving target all the time. :)
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..
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.
> 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.
>
> 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.
>
> 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.
> You should be able to Pkg.clone("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..
>
> Or we could make this version a branch or I could generate a PR first.
>
Perhaps you could enable "issues" in your github repository so that we
could carry on this conversation there?
Regards,
Petr
> Regards,
> Rob J. Goedman
> [email protected] <javascript:>
>
>
>
>
>
> 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
>>
>
>
