As i am quite interested in having julia create binaries, and I have been snippets here and there about the juliac development I wanted to ask where exactly (on which branch, or github) juliac is developed such that i could sneak a peak in.
1 Like
Hi,
Others can add more information, but as far as I know, the term juliac appeared in this pr:
JuliaLang:master ← JuliaLang:kf/newclidrivers
opened 11:51AM - 21 Sep 23 UTC
Following the discussion in #50974, it became clear that there is significant ob… jection to changes to the behavior of the julia CLI driver. Some commenters found changes to the behavior acceptable if they were unlikely to impact existing code (e.g. in the case of #50974 using `__main__` instead of `main`), while other were worried about the reputational risks of even changing behavior in the corner case. In subsequent discussion it became relatively clear that the only way forward that did not raise significant objection was to introduce a new CLI driver for the new behavior. This may seem a bit drastic just for the change in #50974, but I actually think there's a number of other quality-of-life improvements that this would enable us to do over time, for example:
- Autoloading/caching of all packages in the manifest
- auto-selection of julia versions (integrate juliaup?)
In addition, it doesn't seem so bad to have some CLI design flexibility to make sure that the `juliac` driver is aligned with what we need.
This PR is the minimal infrastructure to add the new drivers. In particular, it does the following:
1. Adds two new cli drivers, `juliax` and `juliac`. At the moment, `juliac` is a placeholder and just errors, while `juliax` behaves the same as `julia` (except to error on the deprecated `--math-mode=fast`, just as an example of a behavior difference).
2. Documents that the behavior of `julia` (but not `juliax` or `juliac`) is pat of the julia public API.
3. Switches the cli mode based on the argv[0] of the binary. I.e. all three binaries are identical, except for their name, the same way that, e.g. `clang` and `clang++` are the same binary just with different names. On Unix systems, these are symlinks. On windows, separate copies of the same (small) binary. There is a fallback cli option `--cli-mode` that can be used in case the argv[0] detection is not available (e.g. for some fringe embedded use cases).
4. There is currently no separate `-debug` version of the new drivres. My intention is to make this dependent on the ordinary debug flags, rather than having a separate driver.
Once this is merged, I intend to resubmit #50974 (chaning `juliax` only), and then finish and hook up `juliac` shortly thereafter.
Then there was this pr:
JuliaLang:master ← JuliaLang:kf/main3
opened 01:04PM - 23 Sep 23 UTC
As they say, if at first you don't succeed, try again, then try again, add an ex… tra layer of indirection and take a little bit of spice from every other idea and you've got yourself a wedding cake. Or something like that, I don't know - at times it felt like this cake was getting a bit burnt.
Where was I?
Ah yes.
This is the third edition of the main saga (#50974, #51417). In this version, the spelling that we'd expect for the main use case is:
```
function (@main)(ARGS)
println("Hello World")
end
```
This syntax was originally proposed by `@vtjnash`. However, the semantics here are slightly different. `@main` simply expands to `main`, so the above is equivalent to:
```
function main(ARGS)
println("Hello World")
end
@main
```
So `@main` is simply a marker that the `main` binding has special behavior. This way, all the niceceties of import/export, etc. can still be used as in the original `Main.main` proposal, but there is an explicit opt-in and feature detect macro to avoid executing this when people do not expect.
Additionally, there is a smooth upgrade path if we decide to automatically enable `Main.main` in Julia 2.0.
which got merged as a different take on 51417
2 Likes
I think the better reference is separate `julia-compile` from `julia` · Issue #15864 · JuliaLang/julia · GitHub . But the thing is… juliac isn’t really “one” feature. It’s a snowballing of core compiler features and behaviors (and performance). It’s stripping the IR and metadata. It’s improving the static compile-ability of Base and the stdlibs. It’s figuring out what’s needed for that and improving tooling for figuring out what’s not static.
7 Likes
I consider interesting that a word named a couple of times deep down into PR discussions is generating so much interest and questions in this forum…
1 Like
jar1
April 16, 2024, 9:22pm
5
I like that it sounds like ENIAC .
1 Like
I think the recent wave of juliac discussion where triggered by overinterpreting the last sentence of this post
Yeah, but this is ~100% startup/compilation time. It’s kinda like timing:
hyperfine --shell=none --warmup 30 "cc pangram.c && ./a.out wjjqevffkkgbcehhiqpvqutmwxawzvjnbvukmlzxyhkgfddzfjhcujnlkjbdfgghjhujkiuytghjioplkjhgfdsaqwertyujioplkjhgfdsaqwertzuioplkjhgfdsazxcvbnmlkjhgfdsaqwertyuioplkjhgfdsazxcvbnmlkjhgfdsaqwertyuioplkjhgfdsaqwertyuioplkjhgfdsazxcvbnmlkjhgfdsaqwertyuioplkjhgfdsaqwertyuioplkjhgfdsazxcvbnmlkjhgfdsaqwertyuioplkjhgfdsaqwertyuioplkjhgfdsazxcvbnmlkjhgfdsaqwertyuioplkjhgfdsaqwert…
Edit: This preview looks very odd if you don’t expand it
2 Likes
thats very intersting, I will admit that i only skim the discourse once or twice a month. The Juliac name just caught my eyes and I thought that it was something specific. Thank you for enlightening me more on this subject.
this is what prompted me to be interested as such you are correct.
