I do basically the same thing Tim described, but I use "julia -L
mymoduletests.jl" when I start julia. -L executes the file, then drops to
the REPL in state after execution. The slowest part about the process is
usually loading PyPlot.
On Wednesday, January 21, 2015 at 5:29:04 AM UTC-7, Tim Holy wrote:
>
> Sure, want to add it to the FAQ?
>
> --Tim
>
> On Tuesday, January 20, 2015 08:27:06 PM Viral Shah wrote:
> > Should we capture this in the documentation somewhere? This is generally
> a
> > useful set of hints for newcomers.
> >
> > -viral
> >
> > On Wednesday, January 21, 2015 at 5:38:29 AM UTC+5:30, Tim Holy wrote:
> > > 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
>
>
