Oh, sure, rpath/runpath shenanigans will work in some situations but then you'll be tempted to make such shenanigans work in all situations and then the madness will get you...
To save everyone a click here are the first two bullet points from Exhibit A:
* If an executable has `RPATH` (a.k.a. `DT_RPATH`) set but a shared library that is a (direct or indirect(?)) dependency of that executable has `RUNPATH` (a.k.a. `DT_RUNPATH`) set then the executable's `RPATH` is ignored!
* This means a shared library dependency can "force" loading of an incompatible [(for the executable)] dependency version in certain situations. [...]
Further nuances regarding LD_LIBRARY_PATH can be found in Exhibit B but I can feel the madness clawing at me again so will stop here. :)
I vaguely wondered if FreeHand would make an appearance in this thread. :)
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)
> I've been thinking about bluetooth and a standard protocol and generic app.
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
"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit
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" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit
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" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit
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:
The linked site contains a token-based (rather than line-based) git "blame" annotation view for Linux kernel releases, i.e. it allows you to discover which commit added a particular token--where "a token is what the C syntax considers a token".
An advantage of a per-token commit attribution view is you don't need to transit through the history of an entire line.
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.
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...)
This is extremely useful when you're looking for granularity finer that a line. Being able to have "blame"-like functionality per token is wonderful, when needed.
My personal use case was when trying to decide origin of some code. Instead of getting who touched "something on the line" (which might be a comment after the code), you really get where each piece is coming from.
Heed the above warning as down this rpath madness surely lies!
Exhibit A: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...
Exhibit B: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...
Exhibit C: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...
Oh, sure, rpath/runpath shenanigans will work in some situations but then you'll be tempted to make such shenanigans work in all situations and then the madness will get you...
To save everyone a click here are the first two bullet points from Exhibit A:
* If an executable has `RPATH` (a.k.a. `DT_RPATH`) set but a shared library that is a (direct or indirect(?)) dependency of that executable has `RUNPATH` (a.k.a. `DT_RUNPATH`) set then the executable's `RPATH` is ignored!
* This means a shared library dependency can "force" loading of an incompatible [(for the executable)] dependency version in certain situations. [...]
Further nuances regarding LD_LIBRARY_PATH can be found in Exhibit B but I can feel the madness clawing at me again so will stop here. :)
reply