I created a pull request <https://github.com/JuliaLang/julia/pull/9910> to get this process started. I'm hoping everybody chips in to share their hard-earned wisdom.
On Sat, Jan 24, 2015 at 9:47 AM, Viral Shah <[email protected]> wrote: > How about in the FAQ and also in the manual? I will get to it next week, > if someone doesn't beat me to it. > > -viral > > On Wed, Jan 21, 2015 at 5:58 PM, Tim Holy <[email protected]> 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 >> >> > > > -- > -viral >
