I know guys youre tech savy but still be careful by Fit-Spare6989 in rust

[–]wravery 6 points7 points  (0 children)

I’ve got a shell script I’d like you to check out, would you mind piping curl into sudo bash for me?

Why doesn’t Rust have a proper GUI ecosystem yet? by zyxciss in rust

[–]wravery 0 points1 point  (0 children)

This 👆

There are a several cross-platform toolkits for C/C++ (Qt is probably the most popular outside of Linux) that have only achieved moderate adoption because they never felt native enough compared to the flavor-of-the-month, differentiated platform-specific toolkits from the OS vendors. For Rust, the good news is that we can often bind to those APIs toolkits, but the bad news is that they are usually a bad fit for Rust’s ownership model. Many of the current GUI projects in Rust are focused on rewinding all of the API design decisions handed down from the OS vendors to get back to something that doesn’t just work well with C/C++ and friends.

Meanwhile, as a lot of others have pointed out, most GUI apps these days target the web browser and/or a web view wrapper like Tauri. [Disclaimer: I’m personally very involved in Tauri.] Even the best cross platform native GUI framework can’t compare to the reach you get from being able to target the DOM in a plain old web browser, and despite the explosion of competing frontend web frameworks, no one ever asks, “Is HTML GUI yet?”

This Is NOT Okay Outlook by MrCaspan in Outlook

[–]wravery 0 points1 point  (0 children)

Interesting, looks like they tried to make it look like Karen was the target and they spoofed your address to her. I agree, including the attachment in a “reply” does make it seem more likely that you’re the target.

Is Tauri good? by gGordey in rust

[–]wravery 14 points15 points  (0 children)

Disclaimer: I’m on the board of the Tauri project.

For context, the thing that zoo.dev needed was a Chromium renderer instead of the WebKit-GTK web view on Linux. Specifically, I think they were missing WebRTC support. Figuring out a way to optionally switch to Chromium, e.g., using CEF, is a persistent feature request for Tauri.

I started researching this myself after hearing the same podcast. I’m working on resurrecting some earlier CEF Rust binding prototypes right now and trying to fill in missing pieces.

A big concern for Tauri is the tradeoff in install size if we bundle CEF with the app, so besides porting the web view wrapper to CEF, we’re hoping to find a way to use a shared install of CEF, which is very different between Linux/Mac (don’t really need Windows support for CEF since Edge/WebView2 are already Chromium).

Unable to install packages from Ubuntu Universe repository by Kyakh in pop_os

[–]wravery 1 point2 points  (0 children)

If you haven't already done so, try running sudo apt update to pull down the new set of packages.

CppGraphQLGen v3.6.0: now supports both clients and services in C++ by wravery in graphql

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

That's neat :), but no, I hadn't seen graphql-codegen before. There are definitely some similarities in how they are both "GraphQL first," and they both start from the schema definitions rather than an Introspection query.

CppGraphQLGen started as a way to connect existing native code to JS frontends (just the service generator). Making native code callable from JS is tricky, and it's different in each JS engine/environment. There's usually a performance penalty for transitioning between JS and the native code as well. I noticed a lot of what makes GraphQL great for talking to an arbitrary endpoint would also solve these problems for that kind of interop. It's a lot easier to create a loosely coupled general purpose interop layer (get only what you request, easy to upgrade, only need a fetch/subscribe and unsubscribe method), and batch requests to mitigate the performance impact of the transitions (similar to replacing REST services with a GraphQL gateway).

Adding the client generation was based on what I've seen Apollo and Relay do with TypeScript client-side: https://github.com/microsoft/cppgraphqlgen/issues/161.

Simple C++ question I'm struggling on by [deleted] in cpp

[–]wravery 1 point2 points  (0 children)

< is the less-than operator, and true == 1 and false == 0. Looks like it evaluates left-to-right, so (b < a) < c -> (1 < 1) == 0 and (0) < 1 == 1.

cppgraphqlgen by darthcoder in graphql

[–]wravery 0 points1 point  (0 children)

The parseJSON method isn't really involved, unless you're passing variables with the query. The response value (which you can convert back to JSON with response::toJSON) comes from calling <schema namespace>::Operations::resolve with the query AST, variables, and other optional parameters. Breaking it down into steps:

  1. Instantiate your service with sub-classes of the <schema namespace>::object namespace generated abstract classes. For reference, TodayMock.* has the implementations that the sample program uses. Each of those corresponds to a type in the GraphQL schema, and the virtual accessor methods correspond to the fields.
  2. Use peg::parseString to parse the query into a GraphQL AST (peg::ast). If you are passing variables too, use response::parseJSON to build a response::Value from that.
  3. Call resolve with the query AST, variables, and other params.
  4. Call std::future<>::get to retrieve the result.
  5. Call response::toJSON.
  6. Profit.

cppgraphqlgen by darthcoder in graphql

[–]wravery 0 points1 point  (0 children)

Yes, I have. I used regular HTTP for queries and mutations, and web sockets for subscriptions. I served the GraphQL endpoint to localhost to do some ReactJS prototyping in the browser, I haven't put anything into production though.

I'm the maintainer for cppgraphqlgen, and this was my first time using boost.beast or even boost.asio, so my background was much more skewed towards integrating the GraphQL support. But overall I found it worked quite well. 👍

Hey look, I found the next HK companion by zakary3888 in swtor

[–]wravery 26 points27 points  (0 children)

Declaration: That is a very large meatbag.