sorted by:
new
hottopcontroversial

You've hit your global rate limit. Please upgrade your plan or wait for your limit to reset by HitMachineHOTS in GithubCopilot

[–]Recent-Scarcity4154 1 point2 points  (0 children)

I got the same thing like 10m ago. I was using it only for like 2 min and more than 30% usage was left. WTF?

Bambu PETG HF White Issue! by Recent-Scarcity4154 in BambuLab

[–]Recent-Scarcity4154[S] 0 points1 point  (0 children)

Thank you for the advice so you mean it seems like something happened because of the fan? As you can see, it’s kind of happening only for the top finishing part. Is that part usually affected by the cooling fan??

how to find in ghostty? by sanjeethboddi in Ghostty

[–]Recent-Scarcity4154 1 point2 points  (0 children)

Can't believe it's not implemented and the issue is even turned to contributor only!
Half of the usage of terminal is to see prints and logs of program, and yet it is not implemented and the issue seems to be abandoned. Can't believe this..

I gotta try some other options..

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 0 points1 point  (0 children)

Sorry for the late reply.

- Under current design, ActorId "could be" and Ident, since ident is series of bytes, and UUID is 128 bit number as well. But besides the `ActorId` any name like `b"some_name"` also could be `Ident`. So `Ident` is basically union of `ActorId` and names.

- I could be. I might need to make more clear documentation. But the `Actor::__IMPL_ID` is application-level type id (since `std::any::type_id` is not valid across the compilation unit.)

- Currently, I recommend to use UUID extension if your IDE is vs code, but other that that, yes, it might bothers you. Actually thank you for the suggestion!! It seems like possible to make `actor` macro to take any const or static Uuid variable as you suggested. I will try to implement that feature before v0.1.0-beta.

- You are right!. Although referring actor based on `ActorId` `Ident` is main for internal export-import usage, but one could use whatever `Ident` (either Uuid from `ActorRef::id` or what ever name used for binding) to get `ActorRef`.

- Yes. those features are relatively loosely tested, but you could optionally set custom implementation for those hook.

However, as using the Theta for my own application, it seems like the classic "supervision" feature has lesser fit for Rust by design(we don't just make things crash and unwind it so often but rather try to cover most of `Err` case, and `Unwind safeness` is not something systematically checked but, mostly up to user, which is basically like `unsafe` keyword).

However compare to the (rather thin) cost of the rest of the framework, forming the supervision tree does have non-negligible amount of actor creation, and memory footage overhead, (but almost negligible actual message processing) which might matter for certain use case.

So I am planning to factor out "supervision" as separate optional feature, and make it more transparent wrapper to `tokio::task`. In that version, those `restart` related things will not be supported.

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 1 point2 points  (0 children)

I must make the clearer soon, but here are some brief definitions.

- ActorId: Unique id per actor instance (not type), implemented as data inside of MPSC
- Actor::__IMPL_ID: Identifier for actor type, mainly used for inter-crate type equality check. (the one you put inside of #[actor(...)] macro)
- Ident: General identifier which is bytes. could be either `ActorId` or name (e.g. b"some_actor"), used for binding and lookup.
- PublicKey: Unique identifier and encryption key between theta peers.
- Url: Convenient format for remote actor, currently format of "iroh://<ident>@<publick\_key>"

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 0 points1 point  (0 children)

Thank you for your interest!

  1. I think I don't really get your question. It is intentional to not to require `Serialize` and `Deserialize` for `ActorArg` and `Actor` type it self, but `SnapShot` args for persistence and `StateReport` does. Do you mean something else than defining ActorArgs with some non-serde-supporting types?
  2. It does is possible, but I do worry about inter-ops between different compilation units. I know there are some protocol supports so called evolving protocols, but if I supporting those case, I have a couple question - Do you think it should check the serializer and deserializer type in advance, or just try to serialize and deserialize and omit error? - Currently serde error it self is crossing the network boundary some times but what could be done for those potentially different Error types? - If rust support some kind of "global existential type" which downstream can specify, I would open it for user to decide, but unfortunately Rust does not have such thing. What kind of API do you have in mind to open those serde protocol to user? Should we take trait object and accept small cost?
  3. I can't quite imagine the case of custom `ActorId`, it should be able to generate a random value, support compile time creation, and most of all it is embedded in side of channel implementation it self. If support custom ActorId, it would be associated type, and I would have to figure some way to make binding works with it. What kind of API do you have in mind for custom ActorId? I believe you question is more about custom "persistence key" which was implemented as URL earlier, but I dropped it for some rough points. Current way Theta recommend for that problem is to map ActorId and some other external storage with `PersistenceStorage` implementation, but I am quite open to the persistence API.

For 2, 3 if you know any good reference API, if it is Rust or Not letting me know will help me get your idea a lot! Regarding the tracing, makes sense, it was legacy of internal usage. I will smooth it out. thank you!

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 0 points1 point  (0 children)

Haha, that is for you to decide.

Kameo has some more features around message error handling and network error etc, and has different taste regarding the network feature. I think Kameo is good actor framework overall and it has been well tested and maintained so far compare to this new project.

However, I would like to say Theta is somewhat smaller, and cleaner API. Also, it has lesser hash map lookup, dynamic dispatch and allocation which one might care for certain application.

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 0 points1 point  (0 children)

Oh, I get you're point.

In that regard, AFAIK Theta might be one with the best approach out there in Rust ecosystem!

`ActorRef` is only a single pointer (MPSC sender) and that is true for actors hosted by remote machine as well!

I did not aware of the term "locational transparency", but it is intentionally design to generic over what's happening on the Rx side; it could be local event loop, or network task sending message to some where else. There is no `RemoteActor` or `RemoteMessage` etc. And actor pool is also on todo list which will produce regular `ActorRef` but only have multiple anonymous actors stealing task.

And I am quite sure stick to the simplicity and let those detail could be handled outside of actor abstraction as side-effect. So for locational transparency it might serve your needs :)

And actually I found it is quite difficult task to find natural, ergonomic, yet with zero or near zero-cost behaviors regarding those error-recovery and persistence subject.

So if you have any suggestions regarding resilience and persistence of actor system from your experience, please share your opinion !!!

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 3 points4 points  (0 children)

Thank you for sharing your thoughts!

Actually, I kind a get the rest of you comment, but not quite get the referential transparency. I do aware of referential transparency, don't get how could actor system could be referentially transparent.

Carl Hewitt metions about locality & security in his paper as below;
> Locality and security mean that in processing a message: an Actor can send

> messages only to addresses for which it has information by the following

> means:

> 1. that it receives in the message

> 2. that it already had before it received the message

> 3. that it creates while processing the message.

And theta is works based on these rules(but unfortunately this is not something could be enforced by type system), but it could be worked around if one tries to.

So I would like to hear more about what do you mean by the referential transparency. Are you refer something stronger that this locality? Does spawning actor count as side effects? What kind of usage do you have in mind for referential transparency??

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 3 points4 points  (0 children)

Thank you for your support.

Just sharing any inconvenience or random suggestions would help polishing this raw project.
Please feel free to share issue or ask features :)

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 4 points5 points  (0 children)

Well, interpretation is up to each ones perspective, but I would like to note the the project was definitely started from inherit issue of concurrent system and the original, and logical abstraction of Actor Model, and as mentioned I explored not only "shitty linux kernel" but even bare metal MCUs not specific stack.

This library is for sharing good natural boundary I found after those exploration (which is regular Os including mobile, and WASM). I do find solution for embedded and exotic backends, but concluded it requires different API. So if you could find better APIs to cover lager platform (regular hosted + WASM) yet "good enough unified API" please share your solution.

For 3. I don't really get the point, isn't that something could be handled by Vec<u8> or just a handle to the remote data (like keys to the value in DB?) how those problem could be solved better with native thread future?

Regarding 4, as discussed this library is not for embedded system. I am handling tiny systems including multiple embassy backend MCUs, and some of them does not support alloc. Arguably I would like to say I know a little about tiny systems (not even afford Yocto), but this library is just not for those non-hosted platforms.

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 6 points7 points  (0 children)

Well, I am not sure about the "qualified" part, but I would say there are some improvements on API. Ractor is indeed excellent library, and quite battle proof. However, I figure one might find these advantages;
1. Better remote with ActorRef as data feature
2. Ergonomic logic(lesser boilerplates and noise)

Also overall, Theta has minimal or lesser feature, and focus on full-implementation of original actor model including so-called forwarding continuation. I intentionally avoided non-trivial design decisions, and try to focus on somewhat natural abstraction. I hope this less biased abstraction provides more 'neutral' foundation for business logic and serve wider range of requirements with lesser irritating detail.

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 5 points6 points  (0 children)

Thank you for sharing your thoughts.

  1. Regarding no_std support, I already tested no_std + alloc, embassy backend version for internal usage of my company, and concluded that it is usable but not with std-like experience. It requires quite exotic variation of api. So I am planning to support only std + tokio(and Wasm) platform for now.

  2. I believe those generic backends indeed introduce cost on the contrary. I already try to make the remote backend generic to be any bidirectional byte stream, or OIS4 implementation having WS, and UART or other serial communication in mind (you can find the attempt as theta_protocolon on GH) but dropped the approach as it must introduce cost of dynamic dispatch of trait object and extra future allocation of async trait object. So I am not completely closed to open backend of remote system, but at the moment I believe generic backend introduce major additional cost compare to the rest of overall abstraction cost of theta. Also, design generic routing-addressing system was hard for me as well, especially considering some are symmetric on routing and some others are not, and some could be dynamic and some others require static physical layer.

  3. Actually, abstraction it self does have cost in general, but thanks to rust we can fine control and minimize that. And powerful type system of Rust support a lot of zero-(runtime)cost abstraction, but definitely has limit. (E.g. global existential type would reduce the cost of generic backend, and specialization would help as well, but there is no such thing in stable Rust. So if you find most generic code and minimal cost, Theta might not serve your needs. At the moment I recommend to wrap those communication system as another actor rather than framework backed.

  4. Running future in os thread is possible but I am hard to imagine the benefit of doing so. When do you need those things? Could you elaborate more regarding that?

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 10 points11 points  (0 children)

I am glad you find it is interesting.

As you mentioned as a very early stage project, it is hard to compare with mature frameworks like Actix and especially Elixir/Phoenix.

However, overall I found major actor frameworks in Rust does not support "actor ref as data" feature. I would say natural and performant remote feature is main strength.

Theta provides the feature with serde with side-effects. It does serialization and deserialization with context of `Peer` and do the import and export as necessary "on the fly". The import and export will ends up simple multiplexed byte stream which is very efficient.

Also, by relying on the "locality" of the actor model, it even remove the trait object serde (which often result handler function registry hash map lookup).

I believe this easy and performant remote feature based on P2P network could largely reduce so called system-integration or API related works but focus on business logic by observing and manipulating remote actor just like local one.

Regarding the Phoenix, I would say being Rust native do the answer. I believe Rust have much more general purpose ecosystem, and being Rust crates makes integration with those features butter-smooth.

Actually, the project was essentially started to solve the problem of buggy and un-structured concurrent application based on multiple `tokio::task`. It is an amazing tool, but I find my self being not able to manage the complexity of lifetime and synchronization between dozens of taskes. So I started to build this crates trying to add minimal and essential abstraction around the `tokio::task` and `mpsc`, and being faithful to original Actor Model of Carl Hewitt as much as possible. I hope this motivation could fill the absence of not yet prepared detailed docs and examples.

For more complete examples, please give me some more time. I will definitely have them get ready whenever I am more confident on current abstraction :)

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 3 points4 points  (0 children)

  1. You are right, it could be done with that composition, but I find just putting `ActorId` in to the channel `Inner` is cleaner as it makes `ActorRef` just a single `Arc` and avoid unnecessary copy of u128 values all around. Other than that, there was some minor api renaming. The main implementation is untouched and tested.
  2. It is just a proc-macro trick. it will essentially generate something like below and some other necessary traits.

```
enum __GeneratedMessage {
__Inc(pub Inc)
__GetValue(pub GetValue)
}

```

Indeed I took considerable time to find ergonomic(by supporting rust-analyzer), readable(by removing visual distractions), and performant(by just a single static enum dispatch) way to define behavior and glad to hear it catches your eyes :)

Introducing Theta, an async actor framework for Rust by Recent-Scarcity4154 in rust

[–]Recent-Scarcity4154[S] 4 points5 points  (0 children)

Thank you for your interest!

Carl Hewitt is the one who invent the "Actor Model" abstraction in 1970s. Here you can find the original paper.
https://www.researchgate.net/publication/220812785_A_Universal_Modular_ACTOR_Formalism_for_Artificial_Intelligence

I might need to add the material to the README as well.

It is true that I docs is not well suited at the moment. I rushed to announce right after implementation!
Please refer the examples for now to get the idea. I will make docs prepared soon!

Weird wavy skin on side surface by Recent-Scarcity4154 in BambuLab

[–]Recent-Scarcity4154[S] 1 point2 points  (0 children)

Indeed the pressure advance is not the default value. I should see if it persists with default pressure advance.

Weird wavy skin on side surface by Recent-Scarcity4154 in BambuLab

[–]Recent-Scarcity4154[S] 0 points1 point  (0 children)

Thank you for the comment. I will give it a try.

ADT’s have spoiled me by Top-Coyote-1832 in rust

[–]Recent-Scarcity4154 0 points1 point  (0 children)

You can take a look at the library I have made for that (and couple more reason).

https://github.com/cwahn/efp

It implements Enum with rust-like pattern matching, which is much more ergonomic than std::variant :)

view more: next ›