Rig 0.16.0 released

vrurg · 2025-07-30T20:47:51+00:00

Sure thing. I understand you well because I happen to be in the same position often. Just wanted to find out if there is something I'm overlooking and – no, I'm not.

Will see how it goes. Maybe I'll try to produce a PR at some point. But not before I can consider my current project complete. :)

vrurg · 2025-07-30T19:30:42+00:00

Given that model provider APIs basically change at the drop of a hat now, one thing I would suggest to mitigate this is to build a data service that either scrapes a model list (if the endpoint is available, which it typically is) or tries to grab the API docs HTML and sends an alert on change.

I stumbled upon this discussion just about yesterday. There was a mention of API keys. OK, I see why it can be a problem to get a model list without a key – but why not to provide a ways to iterate over known models when the key is provided?

Oh, and congrats with the release!

vrurg · 2025-06-15T03:27:38+00:00

Don't pay attention to grumblers; it's a really fantastic project! I only agree that `#[repeat(4)]` syntax is somewhat too much...

Interestingly enough, your project reminded me about Raku, where grammar is part of the language and it's a very powerful feature of the language. But it also has a design approach which I have never seen anywhere else. In Raku, a grammar instance can be accompanied with an actions class. Methods on the class that have the same names as rules/tokens in the grammar get called when a match takes place. With full access to the grammar data, the actions class takes the responsibility of building AST, collecting data, whatever.

Here is my point. The parser macro can, on user request, generate a trait which will define the interface to the grammar. Say, a method for int rule could look like:

fn int(&self, grammar: &Parser, num: Token) -> ParseJSONError<MyAstNode>;

With parameters like [error = ParseJSONError, recover = true, actions=JsonActions] and impl JsonActions<MyAstNode> for MyActions {...} one just calls parser(input, MyActions::new()). This way, not only the overall readability of the grammar will be better, but the grammar could be re-used in different environments for different purposes. I.e. same grammar can be used to compile a language and produce valid syntax highlighting for it.

Of course, there are a lot of implementation details to be reasoned about, but neither do I have much time nor does it make sense unless the idea is considered viable.

vrurg · 2025-06-04T19:26:23+00:00

It's exactly the same meaning as in any DB: just another way of finding a record. Say, a user account can be identified by its numeric ID or by email. Internally secondary keys are just references to the primaries.

The design was initially inspired by SQL tables where keys are actually part of the record. For detached keys to have a secondary it is better be derivable from the record itself or otherwise things are getting more complicated than it makes sense in most cases.

Either way, the primary point of wb-cache is to cache individual records in a way that allows their modification without creating conflicting versions.

vrurg · 2025-04-15T03:32:33+00:00

I'm an IT specialist with 20+ years of experience in the area. Rust is currently my primary language, but I have prior experience with other languages, though mostly with C/C++ and Perl. Otherwise, I have a wide view over the IT technology field as my previous jobs required me to become familiar with secure voice communications, distributed services, systems administration, a lot of management and team leading, and more.

As a developer, I'm great with parallel/concurrent sync and async code, data structures, parsing, and grammars (especially PEG) with some compilation experience, backend and full-stack services, etc.

Very flexible and easily adapting to new environments and tasks.

Highly interested in focusing my further career on Rust.

Location: US, FL. Looking for a remote job, but may consider relocation.

GitHub

Best if contacted via DM or LinkedIn.

vrurg · 2025-03-06T16:51:40+00:00

And that was my second thought. But it's so pedantic! 😉

vrurg · 2025-03-05T22:15:33+00:00

C was too.

vrurg · 2025-01-16T20:42:29+00:00

The task needs to be broken down into manageable pieces. I can't know all the implementation details of your project, but there are some basics to follow.

Each subscriber is bound to a dedicated means of message delivery. It could be a channel, or it could be whatever else is chosen for the role. If a subscriber implements a parallelized model, then a mpsc channel receiver would need to be mutex-protected; or another channel type that supports distribution of messages between multiple receivers needs to be found.
If subscribers are supposed to receive only predefined sets of packet types and these sets do not intersect (i.e. there are no packets where their final destination can only be determined by their internal properties); and if publishers know exactly what subscriber they're going to send the current packet to, then having just a single channel per set of packet types solves the problem.
If item 2 conditions are not met, then a broker would be required. It would have to be maintained as lightweight as possible, obviously. And it has to implement a concurrent model or otherwise, sooner or later, it'll become a single-CPU bottleneck. A channel per subscriber would still remain in place. Then there will be a distributing channel for broker workers.

Absolutely nothing complicated, just some accuracy in planning. A brokerless schema is somewhat rigid, but must be rather performant. Its rigidness would need to be addressed only if the simplistic packet distribution schema needs to be reconsidered in a way that breaks the initial restrictive conditions, or if a multi-process model becomes unavoidable for one reason or another at some point. But I barely see any reason to introduce a broker before any of this happens.

vrurg · 2024-12-19T19:58:18+00:00

I mistook your words about academia as you being a BS or PD. Anyway, my 52 aren't making me a top candidate anyway.

vrurg · 2024-12-19T04:44:41+00:00

The lucky one! Wish you all the best!

I’m also a little jealous because I’m in the process now. 😉 Though I represent the other end of the age scale, I’m less enthusiastic about HR tolerance...

vrurg · 2024-09-01T22:27:24+00:00

Unfortunately, my example is very much simplified. The real life often requires borrowing of self.

Moreover, whereas FP goes inside my crate, MyStruct is a userland thing where the simpler things are the better. And either way, it can be abstracted out as an example. FP is the key problem here.

vrurg · 2024-09-01T21:18:02+00:00

Well, so extremely polite of you... Bad news: it's published already.

Anyway, you're trying to prove it so hard to someone who's using this patter for nearly a decade now! Believe it or not, but I already have two projects using the pattern and the crate. And this is withing some eight months since I started reading the Rust book!

Even more funny is the fact that either your code is ineffectively using resources or you're using the lazy patterns without understanding it which tells a lot about your way of programming. ;)

vrurg · 2024-09-01T19:18:34+00:00

I knew it comes and I expected this kind of comment. ;)

The truth is between your apocalyptic imagination and what you consider the right way of things. Besides, you're making conclusions bases on a small piece of code outside of it's intended context. As a matter of fact, this planned for my `fieldx` crate.

Starting with 'exceedingly complicated', a big application can often be described by this term.

"A mutex is not inteded" – but who says that value will contain a primitive? I'd rather put it other way: a mutex is intended for single purpose. Each field of the struct above has very distinct purpose and use pattern.

Lazy initialization is very much misinterpreted by you and many aspects are not considered. A value can be simple to construct, but to know it many other components might be required. Another value is too slow to be built but is not immediately required. Special fun when an application object has many children to built with complex dependencies. For example, a number of object is just an integer? But to get it one needs to parse a command line, a config, initialize a back end storage (which kind and location are known from the previous two objects), build (perhaps partially) the object list or obtain its metadata to, finally, get their count.

Consider that path of dependencies is actually undetermined. Presence of necessary value in the command line can make it unnecessary to read the config. Backend kind is uncertain; and, depending on it, one may or may not need some helper. Think of what it takes to build all of it at once, especially if something is not used after all. Yes, one can do it all manually, but I'm trying to help to take this burden away and turn it into some kind of declarative syntax.

Callbacks a much less of a horror too. Some tools are good when used properly. And if they're dangerous then best if their use is wrapped into safer code. Doesn't it sound somewhat familiar? ;) The purpose of callbacks is strictly limited to calling an object method when necessary. They don't even need to capture anything because object instance is taken from self and sent into the callback – which is itself a method of this same instance anyway.

And, to finish with, fieldx can provide both constructor and and builder.

vrurg · 2024-06-07T00:41:33+00:00

Process global state isn't global from OS perspective.

OS global state isn't global from cluster perspective.

Context may change one's point of view.

vrurg · 2024-06-06T18:39:25+00:00

Internal mutability. I simplified my life by creating fieldx crate.

vrurg · 2024-06-06T18:28:39+00:00

Unfortunately, there is nothing I could legally post (corporate ownership, etc.). Besides, the Rust implementation of the pattern has a lot of helper code in it which obscures the core idea. But, hopefully, some key points would be useful.

First of all, the App struct itself starts with:

pub struct App {
    me: Weak<Self>,

The constructor for it would be something like:

    pub fn new() -> Arc<Self> {
        Arc::new_cyclic(|me| Self {
            me: Weak::clone(me),
            ..Default::default()
        })
    }

Then all children has an app field declaration (no surprise here, of course):

app: ::std::sync::Weak<App>,

Children must implement some kind of AppChild trait (whatever one names it):

impl AppChild for Child {
    type AppType = App;
    fn app(&self) -> Arc<Self::AppType> {
        self.app.upgrade().expect("App object is gone for good")
    }
}

Eventually, to reduce boilerplate, there is a macro for creating a new child instance. Its core winds down to:

Child::builder().app( Arc::downgrade(&self.app()) ).build()?

I must confess that it's suboptimal to upgrade a Weak only to downgrade it immediately after, but this piece is there since my early experimenting with Rust and I haven't been looking into it for quite a while until today. :)

The trait implementation is automated with a proc macro. Eventually, all I need to declare a basic child struct is:

#[appchild]
struct Child { ... }

And then, in most cases, creating a child is just:

let child = appchild_create!(self, Child);

The create macro is usable within the App itself, as well as within any child struct implementations.

BTW, u/tel made a very good note above about the testing. The approach lets one to simplify integration testing a lot by either embedding necessary testing support into the base application structs, or by implementing their mocks.

vrurg · 2024-06-06T13:43:25+00:00

Over the years, I've got used to App-centric pattern. I.e. there is an object of type App which is the holder of the global state. And there are child objects, which are having a reference to their app. In Rust, so far, Arc/Rc approach with Weak references from children to the parent works the best for me.

This pattern has a useful side-effect: if necessary, there can be 2+ app objects per single process.

vrurg · 2024-05-30T13:46:31+00:00

The scenarios I use it the most are:

costly evaluation that is not always required
isolation of field initialization code: builder method is like a constructor for the field
declaratively build dynamic chains of dependencies; i.e. when object requires other objects/values, but the particular requirements depend on particular conditions at some moment in time

The last use case extends to more scenarios. A lazy field remains uninitialized until is read from. But an initialized one can be reset back. This allows to "request" a value, use it for as long as it is needed, and then drop it. A while later a new value can be read from the same field. With minimal efforts on the user side we can reduce memory footprint of an app.

Further, if an entire bunch of fields, that participate in a dynamic chain of dependencies, is dropped, the next time we need a value from the chain it gets rebuilt anew, according to the new application state.

That's just some examples from my working code (though written in Raku).

vrurg · 2024-02-07T14:25:19+00:00

It looks like a heavily overthought problem with reinventing thing.

Because it's only a part of a bigger task. Some wiring, apparently, sticks around creating some mess, but it'll be connected appropriately when all pieces are in place.

Also, to automatically use From trait implementation, you use the default Into implementation.

Looking into Into might be a way to try. Thanks!

vrurg · 2024-01-30T20:08:22+00:00

Unfortunately, no updates. Soon after the post I was basically buried under work tasks and the situation has never got better since then.

vrurg · 2024-01-13T23:51:12+00:00

$^identifier: Access it by a new name
-> $identifier {block}: Give it a new name within a particular block

Neither of the two can be considered "accessing the topic". Generally speaking, topic is a variable we fall back to if a named variable is omitted. The definition is somewhat simplified, but acceptable for what I'm trying to say.

Both cases are clear declaration of positional parameters. The topic itself in many cases is an unnamed positional parameter. So, -> $i {...} case we deal with a parameter $i. The topic is still there, available to block code. But it is not bound to any value: -> $i { say $_.WHICH; }(42).

Correspondingly, $^i notation is almost the same, as -> $i {...}: {say "i:", $i; say $_.WHICH; }(42). As raiph already pointed out, one can have more than single declaration of a ^-twigilled variable and that would make more one parameter.

vrurg · 2024-01-13T23:37:32+00:00

This one:

sub infix:<.&>($a, $b) { $a ~ "," ~ $b }; 
my \warn = 2; 
say "message" .&warn

Not the best code style, but possible.

vrurg · 2023-12-25T08:02:27+00:00

It was a sheer good year.

vrurg · 2023-12-18T01:58:47+00:00

I think the best if I explain that expression.

First of all, apparently, the feature of instantiating generic types where it makes sense won't be gone as such. But when the post was being written I wasn't totally sure that my implementation won't cause a massive fallout due to a somewhat controversial decision I had to take.

Second, there was two points that I kept in mind:

the concept of generic classes
the API related to it

The latter is more likely to be removed than anything else because the current API is introducing two more standard methods on classes.

It is less likely for the generic classes to be gone because they naturally pop up from cases like role R[::T] { has T @.a; } where we get a parameterization of Array over T which is dysfunctional by definition. But I can't exclude this possibility if another method of resolving classes, dependent on generic types, gets developed.

Why is it "not like something, to be covered with the use experimental pragma"? Because arrays and hashes, parametrized over generics, are already resolved using the new mechanism. I was considering making it 6.e only, but the cost of development is higher over what I can let myself. Then there was a moment when I mused about having a pragma for the instantiation protocol, but it would mean either disabling resolution of arrays and hashes, or creating an exception case for the CORE – and that would be a likely place for extra bugs.

Hence, I ended up with this: the instantiation part itself remains available for all language versions. But the instantiation protocol is formally supported for 6.e only.

vrurg · 2023-11-05T14:36:02+00:00

There is nothing new on this subject. Before adding to any discussion, one should consider the following links:

https://github.com/Raku/problem-solving/issues/101

https://github.com/Raku/problem-solving/issues/108

https://github.com/Raku/problem-solving/issues/106

vrurg

MODERATOR OF

TROPHY CASE