Probably the dumbest question you'll get all day - Proper way to build a julia dev environment

I feel so new! Even at my age! But… I’ve been watching Julia for a while and decided it a try on a real application. I come from Scala/Akka, C and C++, and a bunch of ancient languages. Julia has some really nice concepts that might pull me away from Scala and Akka or C++. It’s sort of like Perl with a PhD and without Python’s ability to make you feel like your being graded in a CompSci class.

But… how do I set up a basic dev environment? I know. it should be simple but…
OK, let’s time travel back to the 1980s. Worst cast, I have a tmux session and I write files with Vi or Emacs in a directory structure, and then I use a Ant/CMake/SBT/Gradle… to run the build script and an application comes out. (After I play the famous dots game where as we said “You see how many dots you can get before it goes beep and dies”)

But how do I do this in Julia (1.4.3 for the moment). I tried:

  • Start a tmux session – create two windows. One has Julia REPL, and one my editor.
  • In the REPL do a Pkg.generate(Module1) followed by Pkg.generate(MOdule2) etc. If I have five modules, I do five Pkg.generates under my top directory.
  • I edit the modules

How do I compile it all to test it before I put it into Githib as packages? What is the old edit/compile/link step cycle to get it built and THEN publish it. I’d love a good IDE, but Jetbrains Julia support isn’t fully baked yet, and, with distributed computing, I’m somewhat stuck in the old text model anyway.

It should be simple but people say I am too :slight_smile: Many thanks.

install vscode and the julia extension in vscode then you can have a julia to play with…

some beginner courses here https://juliaacademy.com/courses/category/Beginner

A start, I did that, installed JuliaPro for my Linux distro. I see that’s the Atom based environment I already did, but I’m still looking for the first steps.

Assume I have a project directory for all projects called ~/Projects
Also assume under that Project root I created a directory Project1 with nothing inside it yet.
In JuliaPro I set a project directory for ~/Projects/Project1

Now in my project I have four modules Mod1, Mod2, Mod3 and Mod4. Each of these modules may have multiple source files underneath. Do I do

pkg.generate(“Mod1”)
pkg.generate(“Mod2”)
pkg.generate(“Mod3”)
pkg.generate(“Mod4”)

And then, go into those subdirectories and create .jl files? And, if Mod3 needs something from Mo1, somehow I need to get that reference for the using before it’s in Github right? Also, it appears I am not doing things the Julia way. One does not compile all of this code from these various modules – like Python, it’s just fast scripting so as long as the .jl files are searched, it just works?

And, for anyone who might be interested, I’m doing this because I’m building some basic CPU simulations for some 12 years in Africa. Cheap as Rapsberry Pi’s are, we have to run this stuff on a shared Linux environment because while we don’t problems getting the PIs, often the students are limited to inexpensive android tables. I can at least count on SSH and WiFI (when we have power).

Think of a soup-ed 68K microprocessor with things like clustering, message passing buses, local area networks (someday maybe more than that), and I’ll probably rig up some arduinos with LED lights, buzzers etc and a raspberry Pi for sound effects. Julia will shine at all of this because I can use the Raspberry Pi as “an I/O controller” to talk to all things C like and just have Julia invoke remote functions and references. Maybe if they take to this, I can start introducing Julia itself. And of course, all of this will be a public package on Github because we all know, someone one day will look at me and say “I could write it better than that!”, and I will say "Absolutely! Here’s the package reference, have a ball! "

1 Like

I’d say dont use JuliaPro for. Atom is in maintenance mode so just use VSCode.

Sounds like u might have different ideas for what a module in Julia is. Maybe read https://benlauwens.github.io/ThinkJulia.jl/latest/book.html and then come back.

Seems like u r starting with preconceptions from ur previous exp and I dont know enough abt ur prev exp to help u.

You probably should use only one Package for your “project”.
A package usually has a “main” module (with the same name as the package), but can have any number of sub-modules.

Here is a great workshop from the current JuliaCon showing this structure (and much more):

For the generation of packages, I suggest using PkgTemplates.jl instead of plain Pkg, it has some very useful additional features.

1 Like

If you are familiar with Emacs, I would recommend the following:

  1. download and install plain vanilla Julia (not Julia Pro)
  2. set up julia-emacs for editing Julia files (eg from MELPA)
  3. pick a way of interacting with a live session from this list (I am the author of julia-repl, so naturally I would recommend that, but there are also other fine solutions). Similar solutions exist for vim if you prefer that.
  4. use Revise.jl, always, setting it up in your startup.jl
  5. for anything nontrivial, work in modules/projects, which you activate

This may be quite a bit of new stuff to get used to, but I think you will get the hang of if quickly. Just ask here if you get stuck.

3 Likes

Most of your questions have been answered. Note, I only use text files (and Juno/Atom currently, planning to migrate to VSCode, no hurry, Juno is great), but none of the above or similar.

You might not know, there’s no separate compilation step (as with Python). You can just use with the Julia runtime, OR you can use PackageCompiler.jl. There are also some other startup/latency tricks like -O0 and/or (undocumented) --compile=min.

Since you’ll use the Pi, Julia should work there. (Pre)Compilation will be slow there, so possibly you would want static binaries (eventually), just develop on something more powerful if you can. Currently PC.jl generates huge hundreds MB executables (can be cut down), should be ok for the Pi, but not smaller platforms.