cpcloud

Nice. I would definitely consider making it locale sensitive.

Yes, one of the other comments alluded to this as well. I am also in this boat, so other than bizarroland LLM ingest stuff, I'll probably work on this next. Having never written a mobile app, I'm sure it'll be fine.

Probably right. My brain is probably stuck in old-man spreadsheet land and I did not explore any new horizons that might have obviated micasa. That said, I also didn't want to invest a bunch of time in developing a domain specific app using spreadsheets as the API, I wanted to invest a bunch of time developing a domain specific app using AI. Might end up being a choice I regret!

I often find myself wanting answers to questions that require linking data, and I also want to codify those links somehow, so a single-file, row-oriented database seemed like the appropriate way to get that.

You might actually be able to get away with less structure and just dumps thoughts and ideas, statuses, and documents into $AI and have it generate ad-hoc reports.

In which case, a text file might be the right interface.

Kind of a non-answer, I realize.

I suppose the answer is: because I had a relatively specific idea of what I wanted to build and I didn't consider not building it.

This is super interesting. I do have a GitHub issue for LLM-powered data entry: "Add a landscaping project to do the backyard. Still ideating, thinking a budget of $40k."

I've honestly never explored HA. Is there a world where HA obviates micasa. That seems like a win, at least in terms of not having yet another piece of software duplicating an existing thing.

100% on the phone app. Maybe the web app is the phone app? Dunno. Being able to enter information as close to receiving as possible seems key actually. I'll probably poke on this soon.

One of my first thoughts after getting a working prototype was: "Doesn't the car battery need to be replaced?"

So, yeah. This would obviously be called micarro.

I definitely waffled a bit on multi-property support, but decided against it for initial launch. Multi-property avid terminal users seems even more niche!

> This looks awesome but I think I might still prefer to have an agent make these changes. Not sure though.

Not entirely sure what you mean here, but the next big feature for micasa is an autopopulation pipeline. Upload a quote PDF and populate the project, quote, and vendor tables. It might not be viable ultimately, but I would love to see how far I can get.

Overkill? Definitely.

> can a TUI app bundled with an icon to simply click and start it?

Almost certainly. I personally don't use clicky things to the extent that I am able to avoid them, so I can't describe the specific mechanism or name any of the nouns/tools involved, but I'm pretty sure this exists.

I'm not sure if you're asking whether micasa should use a text file as its format, or if you're suggesting that a text file can be a substitute for micasa.

Maybe it's that TUIs feel manageable with an agent. They can be well scoped without a ton of effort, which at least for me makes me a tiny bit more comfortable letting them write code.

I hadn't considered theming it differently, though in theory it should be adaptive to light versus dark terminals. I only use dark terminals and I couldn't be bothered to test that before there were any users, so if it doesn't work, I will happily task it out to an agent!

Now I kind of want custom themes...

Pandas support as input and output isn't going anywhere. People can continue to bring their pandas DataFrames to Ibis and run Ibis expressions against them.

> pandas made sense and might still make sense for many, especially who are migrating from R and are already comfortable with dataframe paradigm.

Yes, and nothing is different about the paradigm after the changes outlined in the blog post, it's still a dataframe paradigm.

> using the same paradigm and just saying "we run faster" does not solve the ergonomics or the reason why people adopted this way of processing data.

This seems to indicate you _do_ understand that the paradigm isn't changing but then does a complete 180 into complaining about Ibis not solving pandas ergonomics issues. Which is it?

Pandas compatibility as input and output will remain. Not sure what's in doubt here.

> Ibis announcing they’re dropping support for pandas would be like Astro announcing they’re dropping support for React.

This is extremely misleading and a false analogy. Read the blog post.

If you still come to the same conclusion after reading the blog post, feel free to reach out on Zulip, more than happy to chat about it.

Feel free to put up a pull request with an alternate title that you feel communicates the message in a more accurate way!

Ibis is not an ORM. It has no opinion of or knowledge about your data model, or relationships between tables and their columns.

Check out SQLAlchemy's ORM (https://docs.sqlalchemy.org/en/20/orm/) for what that looks like.

No idea who the person is who defended what I said. If they're a co-worker of mine, I don't know who it is.

The original purpose of my comment was to, in a light-hearted way, point out redundant information, not to incite a flame war about tone on HN.

This thread reminds me of why I don't come here very often.

Sounds like a solid plan. No reason to incur switching costs if things are working!

I think you're misunderstanding what "removing pandas" means.

You can still compute on DataFrames, it'll just be with something other than Pandas itself, probably DuckDB, Polars, or DataFusion.

So, the bridge was there, is there, and isn't going anywhere.

I've been working with pencil and paper recently. Thinking about starting an Ibis backend for it.

I'll also suggest inscribing stone tablets with a chunked version of your computation and distributing the described chunked computation to your friends, and then gathering the tablets and finishing up the compute.

It's scalable to ~billions of nodes.

On the contrary, very related to that pandas!

As a joke, I wrote an Ibis backend (https://github.com/cpcloud/ibish) that processes expressions using shell commands strung together with named pipes. It supports joins using the coreutils join command, projections, filters and some aggregations with awk.

It's faster than pandas in some cases and folks should put it into production immediately!

Segmentation violations are often the result of different underlying problems, one of which can be running out of memory.

We (the Ibis team) have opened related issues and the usual response is to not use streaming until it's ready, or to fix the problem if it can be fixed.

Not sure what else there is to do, seems like things are working as expected/intended for the moment!

We'll definitely be the first to try out any improvements to the streaming engine.

On the flip side, Ibises (Ibisii ??) have been around for years and aren't going anywhere.

Multi-indexes definitely have their place. In fact, I got involved in pandas development in 2013 as part of some work I was doing in graduate school, and I was a heavy user of multi-indexed columns. I loved them.

Over time, and after working on a variety of use cases, I personally have come to believe the baggage introduced by these data structures wasn't worth it. Take a look at the indexing code in pandas, and the staggering complexity of what's possible to put inside square brackets and how to decipher its meaning. The maintenance cost alone is quite high.

We don't plan to ever support multi-indexed rows or columns in Ibis. I don't think we'd fare well _at all_ there, intentionally so.

In my experience, Polars streaming runs out of memory at much smaller scales than both DuckDB and DataFusion and tends to use much more memory for the same workload when it doesn't outright segfault.

Polars is faster than those two once you get to less than a few GB, but beyond that you're better off with DuckDB or DataFusion.

I would love for this to improve in Polars, and I'm sure it will!

`_` definitely clashes with IPython and Jupyter's use of it.

However, if you import it from Ibis then it ceases to be used as "most recent result" and remains the ibis underscore object (unless of course you explicitly assign it to something else).

Regarding backend compatibility, there are definitely a few kinds of things that we don't currently abstract over. One is regular expression syntax and another is floating point math (e.g., various algebraic properties that are violated that result in slightly different outputs).

Hope you give it a go, and please report issues at https://github.com/ibis-project/ibis.