I worked many years ago (like 10) in a Clojure project to define UIs in Photoshop files, with a predefined language you would use on groups and layers names to add semantics to them, and then this "compiler" generated java (android) and objective-c (ios) UI code from it. I got it to work okish, but never got any serious use.

Ah that's pretty interesting. Seems a lot more difficult than what we're trying to do though.

Seems a lot more difficult than what we're trying to do though.I'm pretty sure it is the other way around hehe. I'm not sure about the ASTs returned by acorn, never used that, but JS has many features (unless you constraint to only use a subset of it in your javascript files). IIUC you then need to render a UI from those ASTs, allow users to tweak that tree, and then emitting JS back from it? I'm not sure acorn allows that, so you need to write the emitter also?

If you just need to generate JS from a UI, then maybe you can generate Clojure instead, which is much easier to build because s-expressions, and then call the ClojureScript compiler to generate the JS for you?

Not certain it fits, but instead of direct Clojurescript, you might take a look at #squint if the goal is to produce Javascript. (https://github.com/squint-cljs/squint)

@U0739PUFQ we're only using arrays, logical operators, variables, and string templates. I think acorn has its own export tree to code feature. I'd love to use clojure(script), but the dev working on the project has no experience and that's a bit of a plunge for them to take. @U068R74HE thanks for the suggestion! We're trying to stay purely in the JS ecosystem though. No one other than me has clojure(script) experience. I was just asking here because clojure devs are usually on the more experienced side and though maybe someone has done this before.

i think it’s an unambiguous, determinate differentiator in the face of no other good way to differentiate the releases. Using an autoincrementing number requires knowing how many releases are before it so it’s an input to your code from a build and release system. Assuming you just tag a release, the number of commits is discernable from the code itself so it can know it’s version without getting feedback from the release system.

The first two parts are semantic, the last tied you concretely to a commit

Annoying thing about gitlab and commit counts, gitlab only clones up to pretty shallow depth by default

It is all subjective with pros and cons... I was a fan of the commit count - but now prefer the auto-incrementing release count because: • it is predictable, and I can use it before a release, like for a meta :added or whatever • it is less to type and easier for users to remember and visually compare (at least for my little libs with not so many releases!) I did compare various strategies when thinking of this for rewrite-clj, https://cljdoc.org/d/rewrite-clj/rewrite-clj/1.1.47/doc/design/merging-rewrite-clj-and-rewrite-cljs#_library_version_scheme.

What I like about the commit count is that it provides some indication of how many changes were made between releases, especially when major/minor haven't changed. The downside is that it's definitely harder to make releases and update the documentation around a release.

I have always been on rebasing, linear history camp on my projects

I always rebase, but by default popular forges insert merge commits on MR/PR I'm beginning to think this is a very bad default

Yeah, merge commits are not good

I discovered my dislike of them when I had an issue with a merge conflict, fixed it but accidentally introduced a new bug, and then couldn't find the source commit of the bug because it was "hiding" in a merge commit that both github and git cli didn't show by default (merges were treated as empty)

Merge commits give us a simple anchor for reverting sets of commits

Merge commits are fine but only if the history is linear and you --ff-only merges.

@U45T93RA6 simple or easy? 😉

I prefer having a merge commit for a PR/MR with several meaningful commits. Obviously, the merge commit itself must be empty.

it's simple, actually not so easy when it comes to reverting but I like it as a simple, universally understood fact i.e. this PR was merged at this point (which also is helpful for jumping from the CLI to the PR on the browser)

anyway, what was today's discovery? Curious about that part

Just putting words to a feeling having seen a branch which merged master into itself to catch up. (I don't believe you always need to catch up, either) I guess I could live with empty merge commits.

Just putting words to a feeling having seen a branch which merged master into itself to catch up.Merge commits may be fine in the main branch but never in the feature branches. Squash and rebase there is the only acceptable way.

The sweet spot which I've seen many teams converge to is: regularly rebase main into $feature_branch, then merge $feature_branch into master

May I present you The Braid:

a classic

@U45T93RA6 you might be disgusted, but we tend to squash our commits into “revertable units” and then rebase or merge with fast forward or whatever. Gives us easy reverts and a linear history.

Squash is godsent if the developers don't prettify their local history before merging. But I personally dislike when several meaningful commits from a single PR that do different things get squashed together.

Agreed. Commits to master should be meaningful units of work. No more no less. Problem is that “meaningful unit of work” requires thinking from the devs…

Yep, normally I don't mind if others prefer to squash, but forcing it for everyone seems to assume that everyone is lazy 🙃

The only thing we encourage (enforce :) is a master with a linear history of commits with meaningful units of work. How the devs arrive at that, don’t care.

Well, I actually disagree with most opinions here, but I know I lost this battle long ago :rolling_on_the_floor_laughing:. I am on the team that hates rebases with the strength of a thousand suns

Stand up for what you believe in!

Would you say that you rebased your opinion and merged with the common voice?

Also, the "Guitar example" for me is just how git works. I really don't understand why it bothers so much people, but work happens in parallel and I feel it's amazing that git captures that, instead of telling a lie like "hey, this change was applied over this old version" which is actually not what happened (and usually breaks bisect too)

@U06PNK4HG actually, no, that's why my opinion and the common voice ever end in conflict :rolling_on_the_floor_laughing:

How can it break bisect and how do you bisect across parallel branches?

Actually, I think I understand what you mean.

Finally - some workflows are impossible with rebase

I do much more code reading than bisecting, that's why I'm OK with the tradeoff.

I also do more code reading; but I never actually review individual commits, and honestly, I still don't get when this started to be a big deal

I also like how git blame can tell me "hey, this code here was added with a weird commit message so it might not be as good because that's probably what it worked at the time", instead of a pretty, but meaningless commit message like "added connection feature"

I don't think I understand your last point

Git hygiene is an interesting concept, but I prefer the harsh, ugly, and weird truth of the world - that sometimes, a commit is just "CI broke again, not our fault" so I know that this weird line that cleans the cache is just because CIs are weird :rolling_on_the_floor_laughing:

Finally, my last point, is how Pulsar - our Atom fork - uses git. Unfortunately, the old code we inherited was not in a good shape, so we usually have long-lived branches. An interesting example is the newest Electron branch

You can have both. A pretty commit message that broke CI again. Git hygiene to me is the same as not including all typos, undos, and non-compiling code in your commits. The fact that it was once in this state and you changed it is not important (and distracting) to future you.

To test stuff, usually we check if it works on master and then we merge it on Electron branch; sometimes, these things can conflict with other ongoing features, so there are some short-lived branches that are basically "newest Electron + tree-sitter enhancements + SQlite bump + Fixes on recompilation of packages" so we can test stuff; and also, because Electron branch is long-lived, usually we merge from time to time our master on it, and the only thing that conflicts is the lockfile (because older conflicts were already solved)

What you describe sounds like parallel implementations. I agree that rebases wouldn't work there, but it's a different usecase for branches. Maybe it is the "originally intended" usecase, but not the one we appropriated to use branches for nowadays.

> not including all typos, undos, and non-compiling code in your commits Yep, that's what I don't like. Maybe non-compiling is the only I agree, but if I have a typo and fixed it, and then something broke, I prefer to have the first breaking commit the "fix typo". And the "undo" is "the path not taken", and I kinda like the possibility of going back in time and checking what was different

I still feel that we need a "better git" - maybe treat all "merge to default branch" as "commits" and then all the intermediate stuff is hidden, but you could find it if you wanted? Also, get rid of the default merge message and force users to write a commit message always for merges, and allow us to bring our own "diff/patch algorithm" so that Clojure don't conflict on the "Pringles lines" and stuff.

I don't believe that in 2024, we still use a tool that reverts changes with git checkout, that changes branches with git checkout, that creates branches with git checkout, that deletes branches and tags with git push, and that have some weird names like "git blame" (I really don't like the message - like, "git explain" or "git last-changes" is way better). Like, for example, "Pull Requests" and "Merge requests". They both represent the same thing, and the name is meaningful on both cases. "Push request" could also work. We're discussing "merge" and "rebase" but they are both "merges" in a way...

You suddenly jumped from fundamental issues (which may or may not have to be addressed – different usecases require different solutions) to minor things like command names. If you don't like the names, just use a porcelain that offers better ones ;)

like git since version 2.23.0 🙂 > * Two new commands “git switch” and “git restore” are introduced to > split “checking out a branch to work on advancing its history” and > “checking out paths out of the index and/or a tree-ish to work on > advancing the current history” out of the single “git checkout” > command.

Actually, kinda - I meant that we should be researching on something different, more "modern", that can accommodate use cases that were not predicted by the original git command line, and also fix some of the "naming" issues

I don't know what is checkout, but I know what is b b and k 😄

"Blame" is a wonderful name by the way. Its inherent non-git meaning is universally understood (even if it has ironic connotation) and at the same time "artificial" in the sense how @U066UJ2KE defines such names in Elements of Clojure. It is easy to google and everybody knows what are you talking about when you say "blame" in git context.

An example is - while I do like merge workflow... a "merge commit" is not exacly like a normal commit. Supposedly, it just captures all the work on parent commits, but you can't actually revert a merge commit, you can't cherry-pick a merge commit, you can't do a lot of things that you can with "normal" ones. Sure, you can create a "patch" and then revert or apply that "patch", but now you're "out" of git; Also, we do have git log --first-parent for the illusion of a linear commit; but there's no option for it in blame or other arguments

Squash fan here 👌 You can (dare I say should) always attempt to deliver a feature as a series of smaller squashed commits (rather than just one fat one). Makes history simple and that is a win in the long run. :face_in_clouds:

Again, depends on the case. In Pulsar, that would not work because we would conflict lots of things over and over with our eternally long-lived branches

Sorry if I didn't get it, but what is the constraint that requires a separate Electron branch?

We still have bugs, but we need to test the newer Electron over the most popular plug-ins and the newer features. Electron (and Node) is a huge mess regarding backwards compatibility, and there are very weird cases like Pulsar working correctly in every system, except Macos on ARM for example

And the reason you are holding onto the older Electron is...? Or does most of Pulsar not work on the new Electron and you just have some test suites to prevent regressions? (Sorry, never coded for Electron) Edit: I think I get it. "We still have bugs" means for the newer version.

FWIW here is gpt-4o take on this https://chat.openai.com/share/7e1d1ba5-efa2-4aa7-87ae-975d69e70239 At the end :

While ZFS offers robust features, the additional complexity and resource requirements make Btrfs a more practical choice for most developer laptops.

Have not used btrfs, but I have used zfs pretty heavily over the past 3 years and it is very solid for a lot of use cases. I will definitely use it again, but admittedly need to dive into btfs more to compare

I'm running BTRFS on my homelab. I don't use any of the fancy features like snapshotting, snapshot checkouts, etc. I use RAID0 (called SINGLE in btrfs) and RAID1, and LUKS2 encryption. This is my storage setup:https://i.redd.it/cx7tebnepr4b1.png

I use ZFS - been using ZFS for about 11 years

I have 2x24TB ZFS raidz2 clusters

From a completely subjective perspective, BTRFS is in a weird place. It's in the kernel but it seems that it doesn't receive enough love for ongoing development. RAID5/6 is completely broken. There are new darling FSes on the block. However, I've heard only good things from people who use ZFS.

I've never had a failure.

And when zfs does it's regular monthly scrubs, I love it when it says it's self-repaired files that may have been bit corrupted 😉

I do love me some zfs 🙂

Really useful info so far, thanks all!

I'm actually going to put my home on zfs, so that when I do what I think may be something I want to roll back, I'll just create a snapshot of my home, then do a rollback if required.

A summer project 🙂

I think the linux kernal part was the strongest point I'd seen in favor of btrfs so far, so it's good to know that's not perfect

For my cluster, it runs ubuntu (I will swap to FreeBSD in due course - I actually started with FreeBSD)

BTRFS has some advantages over ZFS for multi-disk setups. ZFS requires all disks to be of the same size, BTRFS is flexible in that regard. But this is irrelevant for your usecase.

for home, I run Arch, so will just roll with the archzfs repo

This paper from 2010 outlines data corruption on ZFS when there's memory corruption. So at least up to ~2010, ZFS wasn't infallible. But probably still better than most other FSs. https://research.cs.wisc.edu/adsl/Publications/zfs-corruption-fast10.pdf No clue whether anything has changed since 2010 in this regard. Use ECC. :)

And if anyone's up for a bit of a deep dive that doesn't require specialized knowledge: https://danluu.com/file-consistency/

Maybe obscure, but if you use a lot of snapshots, btrfs performance degrades badly and quickly after a few hundred (i.e. 300). The btrfs docs do mention this if you go digging, but the suggested mitigation was an unhelpful "don't do that". I switched a snapshot heavy project (10^4+) to ZFS, and have yet to see any similar degradation.

I've also managed zfs pools of up to 100 TB across Linux and FreeBSD with hundreds and hundreds of snapshots without problems. But that brings up something else to consider. If you only do an occasional manual snapshot you won't need anything else, but if you snapshot automatically, want to thin those out as they age, replicate to other systems, etc (which are things you'd typically need in server use cases), the zfs ecosystem has some great packages that people have built like syncoid/sanoid and zrepl that can help significantly if you don't want to script all that yourself. Not sure about such things in the btrfs world. Even in personal usage cases I can see someone wanting automatic snapshotting (with automatic prucning) and potentially replication to somewhere else for backup/redundancy. In the latter case I have heard of people running encrypted zfs on their local system and replicating offsite (just a simple ssh session required) and keeping the encryption key only local so that zfs manages all those offsite snapshots but access is protected. Certainly a lot of possibilities

IMHO, ZFS rocks 🙂

☝️:skin-tone-2: JDK 23 with preview features enabled

https://openjdk.org/jeps/477

are those read and print functions static imports or are they available without importing them?

Both. They're static methods from a new class that are implicitly static imported when you use an implicit class like this

"Every implicitly declared class automatically imports these static methods, as if the declaration" from the link you sent

So you can use them yourself in larger programs too

yeah, i see

And I think you can run a single file source .java now without compiling it

Multiple, actually. It started with what you said, but now it'll also find related files for you

The on ramp is definitely smoother

JDK 22: https://openjdk.org/jeps/458

you can probably also use the var keyword for the name variable:

void main() {
    var name = readln("Please enter your name: ");
    print("Pleased to meet you, ");
    println(name);
}

I read somewhere that the footprint of Java “hello world” programs were some sort of canary driving these changes

People who write about Java should be strongly-typed, so their typewriter should segfault if they put a canary in that position. Canaries are boolean (they die for lack of oxygen, or not). A more likely analogy is the truffle-pig.

so when can we expect clojure to consume .java files? 👀

@UEENNMX0T I don't think so. Clojure has a special class loader and other wired things to make classpath dynamic in JVM. I think that it is doable, but clojure team will only do when JVM23 turn old

@U06B8J0AJ https://openjdk.org/projects/amber/design-notes/on-ramp

TLDR it's about stripping away as many unnecessary concepts as possible (static, classes, tooling) and allowing someone to get started very minimally, gradually introducing new concepts if and when necessary

all you need to directly consume .java files is a classloader that compiles them on demand, I am sure there is one on github somewhere

apparently there was a series of jeps for that https://openjdk.org/jeps/330

https://openjdk.org/jeps/458