Readit News* Rethinkdb: I made some small projects with it in the past and it was easy to easy
While not perfect, I have some hope that Jujutsu may be a path forward for improved ergonomics in version control: https://github.com/jj-vcs/jj/blob/main/README.md#introductio...
Two features that come to mind as IIRC being unique (as compared to Illustrator) were multi-page documents and multiple page size multi-page documents. Ideal for the complete standard set of company branded print documents: business card, "With Compliments" slip, and letterhead. :D
Adobe's acquisition of Macromedia and subsequent killing of (the IMO superior) FreeHand contributed directly to my subsequent decision to avoid closed source application software--especially for creative tools--even if alternatives were "technically inferior".
(And, indeed, "creative tool killed/hampered for business reasons" is a story which has been repeated elsewhere multiple times in the quarter century[0] since.)
While Inkscape is still missing features compared to FreeHand it is however also still here many years later and is what I've used ever since when I need 2D vector design software. (Although I've also been keeping an eye on Graphite: https://graphite.rs)
----
[0] Oh, weird, apparently it's actually less than 25 years: https://en.wikipedia.org/wiki/Adobe_FreeHand#Adobe_FreeHand Seems I've been holding the grudge for less time than I thought. :D
Kinda of like a bluetooth X-terminal, but way way simpler. Think tkinter over bluetooth, probably sans canvas.
A bunch of people will say to just use wifi, make the device a Hotspot, and use your web browser. That's not a bad idea, but tiny devices aren't going to run web servers dishing out multi megabits frameworks.
A long time ago I developed a project called "Handbag[0] for Android"[1] based around a similar concept--it targeted the short-lived "Android Open Accessory Protocol" initially over USB & later also over network/WiFi.
(My project notes from the time mentioned a long-term goal of also supporting Bluetooth but that never eventuated...)
Handbag made use of a "generic" Android app for UI display/interaction and an Arduino library that communicated with the app over a binary protocol.
The app would display various UI widgets such as labels/progress bars to display feedback from the accessory and text inputs/buttons to accept input forwarded to the accessory.
While the project did not take the world by storm, I was reminded when digging up these links that at least one person called the concept genius[2]. :)
----
[0] Because it let you "accessorize your Android phone or tablet". :D
[1] https://web.archive.org/web/20130205135845/http://handbagdev...
[2] https://www.doctormonk.com/2011/11/handbag-android-and-ardui...
"git blame" and similar tools often always show my name, even though I didn't write the code.
Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:
"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654
Of course, in your situation I guess such a tool would only help if other people use it. :D
- blame on file
- scroll to line 123, click on commit to see the change
- ok, that commit wasn’t the “meaningful change” I’m looking for
- click on parent commit
- browse files (for that sha)
- go to file
- click blame
- scroll to line 123 (or similar)
- repeat
Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments (yours being one I've had open in a tab for a week to remind me! :) ) discussing issues related to line-based "blame" annotation granularity:
"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654
I really want to find or build a tool that can automatically traverse history this way, like git-evolve-log.
Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:
"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654
An advantage of a per-token commit attribution view is you don't need to transit through the history of an entire line.
Cregit is the tool used to produce the per-token view: https://github.com/cregit/cregit
I encountered Cregit recently while doing some "code history spelunking/archaeology" and thought it seemed pretty nifty.
Decided to share the link as there have been a couple of recent HN threads which included discussion about the poor granularity of line-based git "blame" functionality.
The most recent kernel version on the site is v6.13: https://cregit.linuxsources.org/code/6.13/
Unfortunately, the tool itself seems not to be under active development, the most recently modified branch is from 2 years ago & the main branch was last modified 6 years ago: https://github.com/cregit/cregit/tree/newinter
Unfortunately the direct line-number link above doesn't seem to provide the same view as manually choosing "squash_the_stupid_serial_number(...)" rather than "Overall" in the selection/option menu accessible via the page link: https://cregit.linuxsources.org/code/6.13/arch/x86/kernel/cp...
(Apparently the only code directly from Linus' original commit for that function is `, lo, hi`. :) And, unfortunately, being from the pre-git era, it is lacking any sort of informative commit message...)
Also, as the documentation mentions the token-tracing isn't perfect, e.g. the `squash_the_stupid_serial_number` name did actually exist before the cregited commit: https://github.com/torvalds/linux/commit/0a488a53d7ca46ac638...
(Perhaps this could be related to there being multiple function implementations selected via #ifdef?)
An advantage of a per-token commit attribution view is you don't need to transit through the history of an entire line.
Cregit is the tool used to produce the per-token view: https://github.com/cregit/cregit
I encountered Cregit recently while doing some "code history spelunking/archaeology" and thought it seemed pretty nifty.
Decided to share the link as there have been a couple of recent HN threads which included discussion about the poor granularity of line-based git "blame" functionality.
The most recent kernel version on the site is v6.13: https://cregit.linuxsources.org/code/6.13/
Unfortunately, the tool itself seems not to be under active development, the most recently modified branch is from 2 years ago & the main branch was last modified 6 years ago: https://github.com/cregit/cregit/tree/newinter