This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-19
Channels
- # announcements (19)
- # asami (9)
- # babashka (26)
- # beginners (87)
- # biff (23)
- # calva (6)
- # clerk (7)
- # clj-kondo (3)
- # cljsrn (3)
- # clojure (115)
- # clojure-belgium (1)
- # clojure-berlin (1)
- # clojure-europe (31)
- # clojure-gamedev (5)
- # clojure-nl (2)
- # clojure-norway (8)
- # clojure-uk (2)
- # clojurescript (43)
- # clr (23)
- # datalevin (1)
- # datomic (14)
- # dev-tooling (23)
- # fulcro (38)
- # graphql (1)
- # gratitude (1)
- # jobs (1)
- # lsp (30)
- # off-topic (7)
- # pathom (25)
- # portal (21)
- # quil (6)
- # releases (5)
- # remote-jobs (1)
- # shadow-cljs (34)
- # sql (5)
- # tools-deps (6)
- # xtdb (13)
Given .NET remains kind of fragmented in terms of runtimes, and allowing that there are three "major" such fragments - .NET Core, .NET Framework, and Mono - I'm starting to think *.cljr files should support their own reader conditionals - e.g., #?(:core ... :net ... :mono). I'll adorn my hockey gear and expect incoming projectiles from @dmiller now... lol.
Looks like the .NET folks are actively labbing with AssemblyBuilder.Save(), .NET 8 maybe? 🤞 https://github.com/dotnet/runtimelab/tree/feature/assembly-builder-save
No projectiles. I've conceded already.
Re AssemblyBuilder.Save() Wow. Fingers crossed indeed. But I'll still need to support Core3.1 and .Net 6/7 for a long while. Unless we can get everyone to upgrade.
If AssemblyBuilder.Save() get's re-introduced would it be possible to still support Core3.1 and 6/7 without compilation but anyone who uses .Net 8 and onwards can compile standalone dll's?
"No projectiles. I've conceded already." <-- So, alpha4? :rolling_on_the_floor_laughing: (Just kidding!)
It does require some thought about scope and what symbols we use. @U064X3EF3 raises some good points to consider along these lines.
Though Core3.1 has reached end-of-life https://github.com/dotnet/core/blob/main/releases.md
Maybe use namespaced keywords for the cljr-specific reader conditionals. I saw that somewhere. babashka, maybe?
just as another data point, CLJS has had the same debate for years re conditional for browser vs node. they've resisted the urge so far, trying to avoid too much fragmentation. I don't have any data with which to make a decision, but I would consider it carefully
I would also request that you not take such generic words in the keyspace, given that this crosses all clojure dialects
I agree the keywords should not be too general, but I envision these conditionals only having meaning in *.cljr files. If that mitigates the concern at all. It's just a reality that the .NET APIs are inconsistent across the divergent runtimes. Although they are trying to converge them into core eventually, their unification won't be reality for some time yet (if ever).
that does help that they are limited in scope
so at the least, using namespaces would be a good idea probably
I'm actively looking into this but this is also not without its trade-offs depending how tooling would support it.
OK, I guess not babashka, but I saw it somewhere. But I think :cljr/mono, for instance, would be intuitive and also answer Alex's (perfectly reasonable) request above.
@terry.poot you might have seen it with shadow-cljs perhaps
I don't know, I've been reading so much stuff trying to get rolling on clojure-clr development and figuring out project setups and everything, I truly can't recall where, or what the namespace was, but I noticed it because it was novel and at the same time made a lot of sense when I did.