alefminus

Thanks, that works, it is still faster than joblib.Parallel(backend='multiprocessing') this way, and probably what joblib did that caused it to work. You can close this (or should I? not sure...

Am I mistaken that a possible solution would be to return a tuple of the last expression and the return value, discarding the last expression when used as a notebook...

Right, that would work. But then I have to forgo having the logic in sequence. An async cell running concurrently would be nicer.

This is what I wanted to achieve, it works, although clunky Screencast: [Screencast from 2024-05-05 10-25-40.webm](https://github.com/marimo-team/marimo/assets/103570620/17c0ac6e-19a9-4e65-95ab-7fcb81958657) Code: ```python import marimo __generated_with = "0.4.11" app = marimo.App() @app.cell def imports(): import...

@dmadisetti yes, you got it right. I reached the same solution you suggested, the thread is just a result of the API I'm wrapping not having a poll option (polars.read_database).

Importantly the case of a single cell containing getter and setter does work (does not cause an infinite loop, only evaluates once when caused to evaluate), so is there some...

Alright, I thought working on the additional edges in the dependency sidebar would be cool, so if you change your mind about it let me know :) Closing for now.

This works - just to show what I am talking about; Tested on CC1352R1 with Sysbios 6.20 ```rust -pub fn initialize_sys_tick(syst: &mut SYST, clock_hz: u32) { +pub fn initialize_sys_tick(syst: &mut...

sure, if I manage to get to it :) not promising anything, if I'll find the time I'll make a note that I'm working on it.

That is a pretty confusing aspect. The different Ctrl-F behavior for instance, between being in cell focused and not focused (how do you call that mode? do you use mode...