A lot of Hindu calendars do this. They use śukla and kr̥ṣṇa pakṣa (waxing and waning phases respectively). Days are numbered 0-14 with 0 referring to the full/new moon. Problem is each regional calendar is slightly different. And days might repeat.
I tried this yesterday using the hosted demo. The project info is being circulated in many Sanskrit-related WA and other groups.
The documentation of the `transliteration to Kannada` workflow is good. I (and I think a few others) was using this last year to produce story narrations of Chandamama and other Sanskrit stories using the audio models available on Google AI Studio. The schwa deletion on the Hindi side is infuriating with Sanskrit content.
Also, I wonder if this can support prose? Would be helpful for proofreading efforts because you can focus on the page image rather than constantly switch between two panes.
- The e-ink screen is great for reading. The feeling of ink on paper it produces cannot be replicated on any other screen. Not to my satisfaction.
- The microcontroller is so weak that you cannot add crappy features like more powerful e-readers are wont to do. This produces minimal distraction-free UIs. No messaging, no browsing.
- The form factor is the biggest win. It fits in a pocket and is great for the 5-10m you find when traveling or waiting somewhere. I cannot carry e-readers that way.
- It is great for fiction, and text-heavy non-fiction: history, philosophy etc. Stuff with a lot of images, tables, code blocks etc ... nope.
Every item you add to the device adds a failure mode. Light is fine. Touch ... I don't know. I like the tactile feel of buttons.
And Android means the device no longer runs on a microcontroller which has consequences for battery life etc. As long as they keep the original, minimal model active with minor QoL improvements, I guess it is fine.
Yes. I read multiple books in parallel. Each on a different reader. So syncing is not something I usually need though I did build myself a local sync server for fun.
> It's not the best reader I own, but it's the best reader I have on me at any given moment
This. The form factor is almost the right one for an e-reader. The battery lasts for weeks. It is so open that you could probably write your own firmware for it based on CrossPoint or similar for your own needs.
Needs some iterative development while ruthlessly culling requests for random features.
Got the X4. Put CrossPoint on it. Works like a charm. The http server accessible over wifi makes transferring books extremely simple. (Shame on the Kindle for locking everything down.) This is proof-of-concept that a microcontroller is more than enough for something like an e-reader.
I have a Kindle and a Kobo. They are sturdy devices. But the X4 is the one that is a genuine e-reader. Would not get it as my one and only e-reader though as you tend to miss the size and backlight of the larger ones.
What would I want from future iterations?
- backlight even if it compromises on battery a bit
I like typst. But I am not a fan of the syntax. I use it as an intermediate format on the way to PDF. A document markup language should avoid building a programming language inside it. Pick python, or lua, or whatever.
Depends on the state and the political environment. Some people will deliberately sabotage projects for political reasons. The biggest problem with metros in India is the inability to provide last mile connectivity. Some cities will run buses in competition to metro lines, or provide free bus travel to women. Both actions compete against a fast mode of travel.
So, it is an India problem, not a government problem.
There are people running sites hosting old religious texts and hymns and a hundred other things that have nothing to do with programmers. A 4x jump in the bill for someone on limited income not gaining anything from it is not trivial. It results in the disappearance of a site that will not come back.
In the same way that most public utilities are: train stations, railway lines, airports, garbage dumps, sewage treatment plants, military bases and a hundred other things. The negatives are concentrated to the locality and everyone else reaps the benefits.
I get it if you wish to put a 99% self-sufficiency condition (water/power etc) but everything else reeks of luddism and nimbyism.
This is very common as they have no conception of time. They are just using ballpark figures based on what they see in the wild. I see estimates for modules in weeks/months when it can produce it in a single afternoon of prompting.
Not comparable, but the story of Gerald Bull is interesting. I read Frederick Forsyth's The Fist of God in the late 90s and only came to know about Bull and Project Babylon when I chanced upon the Wikipedia article on the subject.
While it sounds interesting, I do not see this gaining traction. My main complaint would be that I do not want to think about errors except when I want to. This system sounds like Java checked exceptions in a way. You have to handle every exception that a function might throw every single time. That eventually resulted in the famous catch-swallow stratagem.
I distinguish between Faults and Errors. Faults are system level events you cannot recover from. Errors are things you may encounter in the course of doing business. Most applications do not really need to do any recovery; simply tell the user something bad happened and ask them to fix the problem.
For workflows that do need error recovery, or functions with logical failure conditions, you are free to use a Result or Optional type.
Also, I have implemented exception handling with stack unwinding for my VM. The code that does it is not really that complex. If you want to retry... then things get messy.
Any language that uses error codes instead of exceptions is a non-starter for me. Produces code that craps all over the happy path.
Python has a different problem: it is slow as f---. I did a micro benchmark comparison against 5 other languages in preparation for my python replacement language. Outside of dictionary lookups, it is 50-600 times slower than C depending on the workload.
Go, Rust etc are fine. They land at 1.25-3x slower than C. But I prefer the readability of python minus its dynamic nature.
- The base is a freestanding register VM deeply tied to the Linux kernel.
- It supports a set of primitives types, array types and record types.
- Concurrency is Erlang-ish --- an M:N scheduler that can manage tens of thousands of green processes. VM uses instruction fuel to preempt processes.
- GC is Cheney for the nursery + M&S for the rest. Each process has its own GC.
- tailcall support.
- first class functions.
- Phase One will only have Vm0, which is clean (it has access to a bounded set of Linux syscalls). Will think about Vm1 that handles the libc infection later.
- JIT is not on the table in Phase One.
- The language is statically typed and borrows syntax from python extensively, but drops OOP entirely.
- OOP is faked using UFCS.
- Operator overloading is supported.
- Exceptions are the default error handling mechanism. There are two hierarchies: Fault and Error. Fault cannot be trapped without rethrowing. Fault WILL crash the VM.
- It is being developed in private right now. As I am User # 0, all the choices I make reflect my own opinions and biases. I might release the code as OSS once the core is stabilized.
- I have done very basic microbenchmarking and the VM is so much faster than python right now that it is not a fair comparison anymore. I can also create and iterate over massive primitive arrays with ease. The principal comparison should be C, and here it is consistently about 8x slower and that performance profile will probably remain constant because dispatch has a real cost that cannot be magically wished away. I will be very happy with 5/6x.
Recovery is simple depending on your syntax (and whether your language supports exceptions). You pick a few places where you trap exceptions, add it to your log and continue. My current project is the first one that might becomes public. So it is the first time I have worked a little bit on usability. So multiple errors at a time, not one.
The older ones, no. The current project will be. I am developing in private and occasionally rewriting the jj tree to make each commit self-contained. So it won't contain all the false-starts and bad code, only the cleaned up version.
"ut" (https://github.com/s-i-e-v-e/ut) exists, but it is more of a POC for the syntax more than anything. So lexer+parser+typechecker. Did this during COVID in TypeScript but did not finish.
Student of संस्कृतम्
https://www.adhyeta.org.in/