tinkralge 1mo ago • 100%
Thanks. It does look like the right library to use. A little surprising that it seems to be the only one that's up to date, but at least it exists!
I have no experience with android apps and just started working on one that needs to work with relational data. The relational data has multiple many-to-many relationships and the inbuilt ORM ([Room](https://developer.android.com/training/data-storage/room/relationships#many-to-many)) is leads to class explosion. While looking at ORM libraries for android, there seem to be many that are out of date: From [5 of the Best Android ORMs](https://www.sitepoint.com/5-best-android-orms/) (2014) and [AlexeyZatsepin/Android-ORM-benchmark](https://github.com/AlexeyZatsepin/Android-ORM-benchmark) (2017) - [ORMLite](https://ormlite.com/javadoc/ormlite-core/doc-files/ormlite.html): 3 years old and the [M2M example](https://github.com/j256/ormlite-jdbc/blob/main/src/test/java/com/j256/ormlite/jdbc/examples/manytomany/ManyToManyMain.java#L168) makes me feel quite queasy - [SugarORM](SugarORM): description explicitly only mentions 1:1, 1:n - [GreenDAO](https://github.com/greenrobot/greenDAO) is unmaintained but replaced by [ObjectBox](https://docs.objectbox.io) which I haven't yet looked at - [Active Android](https://www.activeandroid.com/): abandoned - [Realm](https://realm.io) redirects to MongoDB 💀 - [Freezer](https://github.com/florent37/Freezer): abandoned - [DBFlow](https://dbflow.gitbook.io/dbflow): no documentation and 3 seemingly abandoned - [Requery](https://github.com/requery/requery): 4 years old (abandoned?). Actually my favorite in terms of API - [Sprinkles](https://github.com/emilsjolander/sprinkles): 10 years old, dead I'm leaning towards Requery because I like its API the most (hides SQL the most), but haven't looked at ObjectBox yet.
tinkralge 2mo ago • 100%
Sure, why not. I'm not the creator of the room 🙂
tinkralge 2mo ago • 100%
I know that @Ategon@programming.dev is there. Maybe he can make you a mod there too? And the channel could be added to the sidebar of this community too.
tinkralge 7mo ago • 100%
This week some more work was done on inheriteRS to support inheriting non-trait implementations of functions.
Basically
use inheriters::specialisations;
specialisations!(
struct Parent {
attr1: u8,
}
impl Parent {
fn from_parent(self) -> u8 { 8 }
fn overridden(self) -> u8 { self.attr1 }
}
#[inherit(Child)]
struct Child {
attr2: u8,
}
impl Child {
fn overridden(self) -> u8 { self.attr2 }
}
);
results in
struct Parent {
attr1: u8,
}
impl Parent {
fn from_parent(self) -> u8 { 8 }
fn overridden(self) -> u8 { self.attr1 }
}
struct Child {
attr1: u8, // new
attr2: u8,
}
impl Child {
fn from_parent(self) -> u8 { 8 } // new
fn overridden(self) -> u8 { self.attr2 }
}
There might be some clean-up necessary code-wise and the README has to be expanded. But the project is well on its way to version 1! It's a pity codeberg doesn't have easy CI/CD yet nor domain hosting e.g inheriters.codeberg.io or something. So auto-formatting, testing, auto-tagging, etc. will have to come once I can convince myself to setup a VPS somewhere that hosts all that.
tinkralge 7mo ago • 100%
That sounds like fun! Wow. How stable is it at the moment?
tinkralge 7mo ago • 80%
Working on some form of inheritance in rust. It's my first foray into procedural macros and so far it's fun. The idea is quite simple: generate structs with common attributes (and eventually functions) instead writing them yourself.
use inheriters::specialisations;
specialisations!(
struct Parent {
attr1: u8,
}
#[inherit(Child)]
struct Child {
attr2: u8,
}
);
becomes
struct Parent {
attr1: u8,
}
struct Child {
attr1: u8,
attr2: u8,
}
not
struct Parent {
attr1: u8,
}
struct Child {
attr1: u8,
parent: Parent,
}
The latter leads to indirection which I'm not a fan of.
Last week I squashed one bug on the order of attributes according to inheritance. In the example above attr2
was coming before attr1
. A feature is nearly done to exclude the Parent
from the output and only output the child. That's useful for parents that just serve as holders for shared attributes.
The goal for v1 was to also support basic inheritance of implementations: Parent
has an impl
block, then that block is copied for the Child
. Not sure yet if I'll implement overrides in v1 or v2. Overrides being if Parent
implements do_something()
and Child
does too, then the implementation of Parent
is not copied into the impl
block.
That's what I'll try to tackle in the coming weeks.
tinkralge 10mo ago • 100%
Great, thank you! I'll be moving on to mkDerivation
soon. Hopefully budding packagers will be less intimidated than I was when I started.
It's a WIP, but I hope it's understandable and contains the necessary information to start packaging something using the builtin `derivation` function.
Despite the name, the nixlang wiki is a community contributor wiki to document things around nix that the maintainers haven't gotten around to, to short-circuit the lengthy review process for the official documentation, and an attempt to make an entry into the nix ecosystem easier. It's difficult to write things from a perspective of somebody who doesn't know, despite once being that person! It would be great to have some feedback on the wiki. P.S I'm **not** the maintainer, just a contributor.
tinkralge 10mo ago • 100%
Thank you! I implemented some of the feedback (haven't pushed yet) and responded to the comments. Learned something 👍
tinkralge 11mo ago • 100%
Jottacloud is what I want to use. Unlimited storage for ~100€/month
Close behind is 1fichier for 2€/TB/month or 12€/TB/year, but they are in France and "uptobox" (a similar provider) was shutdown by the US on French soil because they allowed providing links to the files.
You can probably find others in the list of storage systems supported by rclone
TL;DR No archive format like tar, zip, ... but how would you theoretically represent a symlink in a manner that can be stored on the cloud and retrieved back to the system as a symlink? **Backstory** I heavily use symlinks to organise my media and even wrote an [application that helps me do so](https://gitlab.com/NamingThingsIsHard/linky) (it's in Python and being rewritten in Rust). But I also use stuff like [`home-manager`](https://nix-community.github.io/home-manager/) and `nix` which makes **heavy** use of symlinks. My goal is to back up my media and /home to the cloud at regular intervals. There are services that cost just about 60-100€ **yearly** for **limitless** storage in the cloud. So having part of my library purely in the cloud and using terrabytes of space would cost less than a single 15TB HDD (500+€). To have a local backup, I'd even need a least a second one, which would put me at >1000€ - the equivalent of at least 10 years of cloud storage. **Options explored** *[rclone](https://rclone.org/)* It is pretty sweet as it supports mounting a cloud drive as a folder and has transparent encryption! However there are [multiple open issues](https://github.com/search?q=repo%3Arclone%2Frclone%20symlink&type=issues) on uploading symlinks and I don't know Go. I wouldn't mind trying to learn it if I had an idea how to upload a symlink **without following it** (following symlinks breaks them). *[git-annex](https://git-annex.branchable.com/) etc.* git-annex and using a bare git repo with a remote worktree is great, but I don't need to make diffs of stuff and follow how things moved around, etc. I just need to replace backups with a view of what's there. Plus, storing all that history will probably take enormous amounts of space which is wasteful. **Ideas** *store a blob of `stat()` call for every file* I'm not sure about this. The [`stat` struct](https://www.man7.org/linux/man-pages/man3/stat.3type.html) does contain information about the filetype (directory, hard link, symlink, ...), but my knowledge of linux internals is limited and maybe that's too complicated for this usecase. **a db of links** Instead of storing the links themselves, I store a DB (sqlite? CSV?) of links, upload that DB and use the DB to restore links after pull it back down. 🤔 Actually this might be the simplest thing to do, but maybe y'all have better ideas.
I wrote a simple algorithm for predictive text that uses preceding words as context. Without looking at prior, it was an attempt as seeing what I could come up with. The goal is for it to be incorporated in chorded input and pick the best candidate for the entered chord with the given context. Chorded input is the method of hitting all keys for a word simultaneously instead of hitting each key individually in expected order. E.g you've typed "this is the worst" and hit the chord "aet", which word should be chosen? ate? tea? eta? This algorithm is there to answer that. What I'm looking for in the code review in order of importance: - documentation (is it understandable? are there things missing? ...) - code architecture, code structure (function should be a member? composition could be changed? clarity, ...) - algorithm review (optimisations, improvements) - variable and class names (naming things is hard) - rust specific stuff (f64 instead of u32 maybe? dyn vs impl? ...) The code is linted and automatically formatted.