You mean: uncheck the option Use Standard Layout
. That absolutely works for me on MacOS. Have you tried that, @BLI ?
BTW, why isnât âuncheck Use Standard Layoutâ the default?
I cannot really imagine why, after painstakingly having set up the layout the way I want it, would I want it to automatically revert to the completely arbitrary default layout.
Iâm sure some people would want it, but it doesnât seem to me like it should be the default.
Mh, there should be a pop-up that asks whether you want it enabled or not when Juno is installed.
Itâs only a true default on JuliaPro, and it kinda makes sense there (and isnât my decision anyways).
No, I have not unchecked the Standard Layout option⌠I have not been aware of it â I have googled extensively to try to find a way to do it, but googling only works if you know or are lucky to guess useful search wordsâŚ
Maybe there is a package⌠once, someone suggested to install a âconvert-to-htmlâ package and print the resulting html file. All syntax highlighting got lost, so not a good solution. To me, support for print-file (with syntax highlighting is something that should come packed with the editorâŚ)
Youâre welcome
Whatâs important is the experience not how it was achieved.
No user would care of IDE is built from ground up or based on any other solution.
It just has to have good development experience - Handling text, Lint, good debugging experience, profiling, easy integration with visualization tools.
MATLABâs IDE, in my opinion, is a good benchmark.
Renark
Maybe JupyterLab is the way to goâŚ
How to achieve it is extremely relevant.
It is relevant to the developer.
For which I think the best would be the path which requires the least resources (Development time mainly).
So if it can be done using VS Code / Juno / Spyder or Jupyter Lab any of the is as welcome as any other solution.
Still waiting for a credible equivalent to MPI and OpenMP⌠sighâŚ
Data transfer and package visibility is pretty opaque with pmap, which is the closest to what I mean.
Still waiting for a credible equivalent to MPI and OpenMP⌠sighâŚ
Have you looked at PARTR? (Parallel Task Run-time).
Itâs a work in process, but looked very interesting to me.
Thereâs a video on Youtube about it, made during the talk a month ago at the C.A.J.U.N. (Cambridge Area Julia Users Network) Meetup.
It is relevant to the developer.
For which I think the best would be the path which requires the least resources (Development time mainly).
So if it can be done using VS Code / Juno / Spyder or Jupyter Lab any of the is as welcome as any other solution.
Youâre talking on the forums to the developers. HenceâŚ
How to achieve it is extremely relevant.
âOh man, thereâs no way I want to deal with troubleshooting 30 students through this setup process. Iâm just gonna use matlabâ
I donât use Matlab, but recently I needed to run a script from someone so I spent 2 hours with our IT trying to install it on my Linux laptop, wading through cryptic messages from the license server. Finally I gave up and went with Octave
I sincerely hope that grad students who otherwise use computers should be able to figure out the setup for a Julia environment, even without JuliaPro.
Itâs a work in process, but looked very interesting to me.
lots of WiP with great promise. many, many possibilities 2-5 years outâŚrisk is unless packages become abandoned along the way, as the original authors are done with what they themselves needed and now have to move on to day jobs elsewhere.
julia 1.0 could use more adopters in 2018-9. a growing user base to get to 1% in https://www.kdnuggets.com/2018/05/poll-tools-analytics-data-science-machine-learning-results.html â yes, their survey is misrepresenting juliaâs situation. itâs early. it ainât over until the fat lady sings. she hasnât even started singing yet.
my takeaway from this thread is that julia 1.0 is world-class ready for numerical analysis, mathematical programming (optimization, etc.) of many forms in fall. matlab users are probably one primary target. I hope it is a big market. I hope this segment has many prominent evangelists. stepheng and othersâŚ
/iaw
PS: I am just a little sad that it wonât be for mixed data set IO programming in this iteration. I hope for 2.0.
PS: I am just a little sad that it wonât be for mixed data set IO programming in this iteration. I hope for 2.0
Iâm hoping for a lot sooner than that - and I think there are enough of us who really need this, who also have the skill set to do some interesting things in this area, that this is very possible.
This is where the advantages of Julia in programmer productivity, will come into play, IMO.
because companies tend to be a bit conservative, and until Julia is v1.0, they wonât touch it,
this is a multiple equilibrium situation. it may well be that companies wonât touch it, because they donât touch itâŚmaybe because they worry about julia being around, getting market share, hiring people that can code in it, many other reasons. for computer languages, there are important âexternalitiesâ in having others adopt it, too.
this is why I believe it is more important for julia to become a superior solution for some segment, rather than to be ânearly competentâ or even just a little better than existing solutions in many places. (I originally thought the target was data analytics, but now I think it is numerical analysis / mathematical programming.)
julia needs a few initial niches, where it can establish a major foothold. it can branch out from there. itâs a â1.0 targetâ question.
I am not sure physics people will be that excited about Julia, Fortran and c have been used for such a long time.
Isnât it mostly a legacy code issue? I see that there are some new physics software/packages written in C++ and Python nowadays.
My experience is that the development cost of writing Fortran code far outweighs the little gain in performance. I donât enjoy hand coding a matrix inversion subroutine in Fortran when I know that NumPy and Julia can do it already and probably do better than me. And I doubt if there are many grad students or postdocs who can actually be enthusiastic about coding in Fortran if not insisted by their PI that code be written in Fortran. My point is that, if given a free choice, not bound by PIâs will or grant proposal or a legacy project codebase, it is likely that thereâll be more people prefer Julia to Fortran in their daily work.
Isnât it mostly a legacy code issue? I see that there are some new physics software/packages written in C++ and Python nowadays.
No itâs not. Most physics PhD programs seem to still teach and use Fortran. Most ODE solvers in use are still Fortran programs. Modern Fortran really isnât that bad of a language anyways. But this is a big pool of people who would like to modernize but cannot:
- Sacrifice the array-based semantic loss of a Fortran â C++ conversion
- Sacrifice the speed of a Fortran â Python conversion
- Sacrifice the loss of a common language of a Fortran â C++ + Python conversion
And I doubt if there are many grad students or postdocs who can actually be enthusiastic about coding in Fortran if not insisted by their PI that code be written in Fortran. My point is that, if given a free choice, not bound by PIâs will or grant proposal or a legacy project codebase, it is likely that thereâll be more people prefer Julia to Fortran in their daily work.
Sure, I agree with this one. There are a lot of legacy people . You can see this is the biggest pool of people in the SoCal Julia meetups: lots of ex-Fortran physics grad students.
Its a similar situation in biophysical sciences, except the choice of Fortran seems to be arbitrary as there isnât as much heavy array work. People tend to experiment with C++ for structure and R for its ecosytem, but usually with terrible results. Obfuscated terrible OOP or painfully slow sludge.
And yeah modern Fortran seems so much better, but I rarely see it used, and I just reviewed 30 Fortran codebases!
The whole field desperately needs generics but doesnât even know the term.
The whole field desperately needs generics but doesnât even know the term.
Too true.