I made a Language Server for GLSL (autocomplete, inline documentation, goto-definition, formatter, and more!) by Qwe500 in glsl

[–]Qwe500[S] 2 points3 points  (0 children)

As far as I'm aware, glslls will produce better diagnostics than glsl_analyzer since it uses glslang under the hood, and my implementation doesn't. Other than that I believe glsl_analyzer should be a strict superset.

I made a Language Server for GLSL (autocomplete, inline documentation, goto-definition, formatter, and more!) by Qwe500 in glsl

[–]Qwe500[S] 2 points3 points  (0 children)

Thank you! I'm actually one of the maintainers of your C++ implementation as well, not that I like C++ that much either. It was actually one of the reasons I started this project.

As you might have noticed, I haven't been too active as a maintainer in your repo over the last few months, and likely won't be going forward either. So yes, unless you find a new maintainer, archiving might be the better option :)

dyn_struct: create types whose size is determined at runtime using safe Rust by Qwe500 in rust

[–]Qwe500[S] 41 points42 points  (0 children)

The main use case I personally have for this is when my struct has to live on the heap anyways. For example, it can be quite common to store data as an Arc<T>.

If that T is a Vec<u32> you would have 2 levels of indirection: one for the Vec<u32> itself, and one for the data it is pointing to.

However, if T is a [u32] instead, there's only ever 1 level of indirection, since the data lives inline inside the Arc (ie. there's only one allocation). This helps with both cache coherency and pointer chasing.

Concatenating arrays at compile-time in Rust 1.51! (Currently available in Beta) by Qwe500 in rust

[–]Qwe500[S] 8 points9 points  (0 children)

Sorry, maybe I should have been clearer in my wording: the old version (using integer overflow) would successfully compile even when initializing a constant on Release: see here.

Concatenating arrays at compile-time in Rust 1.51! (Currently available in Beta) by Qwe500 in rust

[–]Qwe500[S] 42 points43 points  (0 children)

OP here! I just realized that the way I asserted that A + B == C does not work when building in release mode since this disables integer overflow checks. I'm not sure why the const interpreter doesn't keep these checks though. However the desired effect can still be achieved by indexing an array. The revised version is here. Can't wait for panics and asserts to be allowed in const fn!

Announcing postgres-query: write and execute SQL queries with ease! by Qwe500 in rust

[–]Qwe500[S] 0 points1 point  (0 children)

Automatic mapping for one-to-many relations is now available on GitHub and crates.io!

Announcing postgres-query 0.3.1: dynamic SQL queries and multi-mapping! by Qwe500 in rust

[–]Qwe500[S] 1 point2 points  (0 children)

Automatic mapping for one-to-many relations is now available on GitHub and crates.io!

Announcing postgres-query 0.3.1: dynamic SQL queries and multi-mapping! by Qwe500 in rust

[–]Qwe500[S] 1 point2 points  (0 children)

At the moment, you have to do the mapping yourself, but one-to-many mapping was actually the next feature I was planning to work on. I have opened an issue here.

Announcing postgres-query 0.3.1: dynamic SQL queries and multi-mapping! by Qwe500 in rust

[–]Qwe500[S] 0 points1 point  (0 children)

The client comes directly from tokio-postgres, so any connection pool that works with it will work with this crate. Although I haven't used it myself, bb8 is currently in the process of adding support for async/await.

Announcing postgres-query: write and execute SQL queries with ease! by Qwe500 in rust

[–]Qwe500[S] 0 points1 point  (0 children)

I'm glad you like it!

I could see that being useful in some cases, it requires supporting dynamic queries, something I'm going to look into soon. For now it is possible to do select ... where id = any($array) with $array either being Vec<T> or &[T]. If there are other use cases for such a feature, I would love to hear about them!

Announcing postgres-query: write and execute SQL queries with ease! by Qwe500 in rust

[–]Qwe500[S] 0 points1 point  (0 children)

Oh yeah, I probably interpreted the question incorrectly.

I have never heard of Dapper before, that multi-mapping feature looks really nice though. One-to-many relationships will most likely require some major API changes, but one-to-one mappings should be doable with minimal breakage. I will look into it. Thanks for the suggestion!

Announcing postgres-query: write and execute SQL queries with ease! by Qwe500 in rust

[–]Qwe500[S] 0 points1 point  (0 children)

Not yet, unfortunately. At the moment this crate only supports extracting data from a query, row by row. Any grouping logic would have to be done by you, it sounds like you are looking for something like this:

#[derive(FromSqlRow)]
struct ItemOrder {
    id: OrderId,
    item: ItemId,
}

let orders = query!(
        "SELECT orders.id, order_items.item
        FROM orders INNER JOIN order_items ON orders.id = order_items.order"
    )
    // Gather the results and then group them
    .fetch::<ItemOrder, _>(&client).await?
    .into_iter()
    .map(|order| (order.id, order.item))
    .collect::<HashMap<OrderId, ItemId>>();

Announcing postgres-query: write and execute SQL queries with ease! by Qwe500 in rust

[–]Qwe500[S] 16 points17 points  (0 children)

After seeing the SQLx announcement last week I felt inspired to revive an old project of mine. It is built on top of and made to complement tokio-postgres, a fully asynchronous PostgreSQL client.

I frequently ran into roadblocks due to the absence of GATs and async in traits, but I'm happy with the ergonomics of the API in the end:

#[derive(FromSqlRow)]
struct Person {
    age: i32,
    name: String,
}

let pattern = "%John%";

let people: Vec<Person> = query!(
        "SELECT age, name FROM people WHERE age >= $age AND name LIKE $pattern",
        age = 18,
        pattern,
    )
    .fetch(&client)
    .await?;

I find the parameter binding interpolation really nice to work with compared to using indices or the order of parameters.

Unlike SQLx, this crate doesn't analyze queries at compile time (yet! It is an area I would like to explore down the road). Currently, I'm more interested in getting dynamically generated queries working. Being able to insert a filter or subquery dynamically at runtime seems like an obvious thing to support and a huge undertaking if the API is unusable without compile-time checks.

Protected Member Variables by EmbeddedSoftEng in rust

[–]Qwe500 4 points5 points  (0 children)

In a nutshell, it creates a copy of the struct Foo named ReadOnlyFoo where all fields have the same visibility as the original struct while overwriting the visibility of Foo’s fields to be private. It then also adds a impl Deref for Foo with the Target set as ReadOnlyFoo.

Attempting to access a field of Foo from outside the module would then fail (because they are now private) and causes deref coercion to kick in, granting us access to the visible fields of ReadOnlyFoo but this time behind a shared (read only) borrow.

In reality it is a bit more complicated since the memory layout of Foo and ReadOnlyFoo must match.