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
>
>
