Agreed there are advantages in putting ones test script into a module. There
is also at least one disadvantage: if you get an error, you don't already have
the "state" prepared to examine the variables you'll be passing as arguments,
try the call with slightly different arguments, etc., from the REPL.
But this is a small point, and either strategy can work fine.
Best,
--Tim
On Tuesday, January 20, 2015 04:01:14 PM Petr Krysl wrote:
> I think it would be worthwhile to point out that enclosing the code of
> one's "scratch" file in a module has a number of advantages.
>
> 1. The global workspace is not polluted with too many variables and
> conflicts are avoided.
> 2. The variables defined within that module are accessible from the REPL
> as if the variables were defined at the global level.
>
> Example:
>
> module m1
>
> using JFinEALE
>
> t0 = time()
>
> rho=1.21*1e-9;# mass density
> c =345.0*1000;# millimeters per second
> bulk= c^2*rho;
> Lx=1900.0;# length of the box, millimeters
> Ly=800.0; # length of the box, millimeters
>
> fens,fes = Q4block(Lx,Ly,3,2); # Mesh
> show(fes.conn)
>
> end
>
> julia> include("./module_env.jl")
> Warning: replacing module m1
> [1 2 6 5
> 5 6 10 9
> 2 3 7 6
> 6 7 11 10
> 3 4 8 7
> 7 8 12 11]
> julia> m1. # I hit the tab key at this point, and I got this list of
> variables that I can access
> Lx Ly bulk c eval fens fes rho t0
>
> I'm sure this is no news to the Julian wizards, but to a newbie like me it
> is useful information. (I haven't seen this in the documentation.
> Perhaps it is there, but if that is not the case I would be all for
> adding it in.)
>
> Petr
>
> On Tuesday, January 20, 2015 at 1:45:02 PM UTC-8, Jameson wrote:
> > My workflow is very similar. I'll add that I'll make a throwaway module
> > ("MyModuleTests") so that I can use "using" in the test file. Doing this
> > at
> > the REPL (defining a new module directly at the prompt) is also a nice way
> > of encapsulating a chunk of code to isolate it from existing definitions
> > (including old using statements). It's also similar to how I'll use a
> > large
> > begin/end block to group a large chunk of initialization code so that I
> > can
> > iterate and rerun it easily.
> > On Tue, Jan 20, 2015 at 4:34 PM Tim Holy <[email protected] <javascript:>>
> >
> > wrote:
> >> My workflow (REPL-based, Juno in particular is probably different):
> >> - Open a file ("MyModule.jl") that will consist of a single module, and
> >> contains types & code
> >> - Open a 2nd file ("mymodule_tests.jl") that will be the tests file for
> >> the
> >> module. Inside of this file, say `import MyModule` rather than `using
> >> MyModule`; you'll have to scope all calls, but that's a small price to
> >> pay for
> >> the ability to `reload("MyModule")` and re-run your tests.
> >> - Open a julia REPL
> >> - Start playing with ideas/code in the REPL. Paste the good ones into the
> >> files. And sometimes vice-versa, when it's easier to type straight into
> >> the
> >> files.
> >> - When enough code is in place, restart the repl. Cycle through
> >>
> >> reload("MyModule")
> >> include("mymodule_tests.jl")
> >> <edit these two files>
> >>
> >> until things actually work.
> >>
> >> --Tim
> >>
> >> On Tuesday, January 20, 2015 01:09:01 PM Viral Shah wrote:
> >> > This is pretty much the workflow a lot of people use, with a few julia
> >> > restarts to deal with the issues a) and b). I often maintain a script
> >> > as
> >> > part of my iterative/exploratory work, so that I can easily get to the
> >> > desired state when I have to restart.
> >> >
> >> > -viral
> >> >
> >> > On Tuesday, January 20, 2015 at 4:15:13 PM UTC+5:30, Tamas Papp wrote:
> >> > > Hi,
> >> > >
> >> > > I am wondering what the best workflow is for iterative/exploratory
> >> > > programming (as opposed to, say, library development). I feel that
> >> > > my
> >> > > questions below all have solutions, it's just that I am not
> >>
> >> experienced
> >>
> >> > > enough in Julia to figure them out.
> >> > >
> >> > > The way I have been doing it so far:
> >> > > 1. open a file in the editor,
> >> > > 2. start `using` some libraries,
> >> > > 3. write a few functions, load data, plot, analyze
> >> > > 4. rewrite functions, repeat 2-4 until satisfied.
> >> > >
> >> > > I usually end up with a bunch of functions, followed by the actual
> >> > > runtime code.
> >> > >
> >> > > However, I run into the following issues (or, rather, inconveniences)
> >> > > with nontrivial code:
> >> > >
> >> > > a. If I redefine a function, then I have to recompile dependent
> >> > > functions, which is tedious and occasionally a source of bugs
> >> > > (cf. https://github.com/JuliaLang/julia/issues/265 )
> >> > >
> >> > > b. I can't redefine types.
> >> > >
> >> > > I can solve both by restarting (`workspace()`), but then I have to
> >> > > reload & recompile everything.
> >> > >
> >> > > I am wondering if there is a more organized way of doing this --- eg
> >>
> >> put
> >>
> >> > > some stuff in a module in a separate file and just keep reloading
> >>
> >> that,
> >>
> >> > > etc. Any advice, or pointers to tutorials would be appreciated.
> >> > >
> >> > > I am using Emacs/ESS.
> >> > >
> >> > > Also, is there a way to unintern symbols (a la CL) that would solve
> >>
> >> the
> >>
> >> > > type redefinition issue?
> >> > >
> >> > > Best,
> >> > >
> >> > > Tamas
