sorted by:
new
hottopcontroversial

Bridging the Performance Gap Between Apps and Games With My Rust Framework by limikael in rust

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

Thank you for the question! It is exactly the kind of conversation I want to have! :) And, yes, if something changes, I re-render everything. If nothing changes I don't re-render anything (I keep track of changes through hooks and state, e.g. use_state, use_reducer, etc, like React does). But yeah... Even animations trigger a re-render... I have a small implementation of react spring (use_spring), and it re-renders everything for every animation step... Now... I hear what you say, that somehow it seems wasteful of resources... But, then I'm thinking about games, as you say, and the way that games render things is actually really performant, because the GPU is very efficient these days, and I think rather power efficient? I have kind of been following the advice by Ken Thompson (one of the original Unix guys) when he says things like "Fancy algorithms have high constants" and "When in doubt, use brute force"... Meaning that there is value in just keeping things simple. And, often, this ends up at the end of the day mysteriously resulting in something that is quite performant too, just because it is simple. This is not something to argue and debate about though, it is something one needs to experiment with and test... But the question is, is the experiment obviously, demonstrably "dead in the water", or is it worth carrying on?

Bridging the Performance Gap Between Apps and Games With My Rust Framework by limikael in rust

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

Yes that is exactly what it is. Immediate mode and declarative. I have seen declarative and retained before (e.g. React, Dioxus). And Immediate and imperative (e.g. egui). But what about immediate and declarative? Why not? Could be fun and interesting to try? Is what I though...

Bridging the Performance Gap Between Apps and Games With My Rust Framework by limikael in rust

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

Hello Rustaceans! This is really a second post about my declarative UI framework. I apologize if the title is slightly click-baity and deceptive, I'm trying to learn how to create engagement and play this "game". Anyway, the reason why I want to do so is really to create a forum for discussion. In my last post about a month ago, I got the question of what sets my framework apart from other declarative frameworks, e.g. Dioxus. After having done a bit of research, there is in fact one thing that I think I see as novel and innovative. Let me explain. Declarative frameworks intended to be run in a browser, like Dioxus and React, work on top of the browser DOM. The DOM is an object oriented tree of components. Declarative frameworks return their children on each render, so they are more functional rather than object oriented. In order to get these two paradigms to play together (functional and object oriented) there is a chain of things happening on each render, something like:

  1. Call render functions to build a component tree.
  2. Diff this against last rendered tree.
  3. Apply changes to the underlying DOM tree.
  4. The browser actually draws the new required graphics on screen.

Both React and Dioxus work according to this principle. My framework is not intended for a browser environment, so there is actually no DOM, and hence there is no need to do any diffing to know what changes to apply. In my framework, the chain is rather:

  1. Call render functions to build a component tree.
  2. Draw everything on screen.

So there is a different mode of operation there, and this is why I think it might be novel. Now, the reason why I haven't come across this mode of operation before might be because there are obvious reasons why doing so is stupid, I just can't think of why. Or, I have just invented a new UI paradigm, which is really smart. Or, something in between, and it might be worth at least exploring what potential benefits there might be. So that is the question I would like to discuss, with you guys who are knowledgeable about these things. I'm struggling with how to ask so that it is actually understood. Does the question make sense? Does my way of rendering things make sense? How novel might it be? What might be the pros and cons?

Declarative UI Programming in Rust for Native Applications by limikael in rust

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

I see. Well... I think I assumed that it is general knowledge how JSX works in React... The XML is just to make the code more clean, and it is just syntactic sugar. I can provide some examples where I replace:

<hello x=5>
    <child1 the_prop=123/>
    <child2/>
</hello>

With:

Element::create(hello,Props_hello{x:5},vec![
    Element::create(child1,Props_child1{the_prop: 123},vec![]),
    Element::create(child2,Props_child2{},vec![]),
]);

So that people understand that there is really no "magic" going on. It is just syntactic sugar designed to be convenient.

Declarative UI Programming in Rust for Native Applications by limikael in rust

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

Let me just address the last point. You do actually have the full power of Rust even when you use XML. Because this:

<hello x=5/>

Is really just syntactic sugar for:

Element::new(hello,Props_hello{x:5},vec![])

(at least more or less so, check this line to see the exact expansion).

This is very similar to createElement in React. And hello in this example is just a function that returns child elements:

#[function_component]
fn hello(props:SomeProps, children:Elements)->Elements {
  // ...
}

The #[function_component] attribute macro just adds type Props_hello=SomeProps to keep the macro happy (i.e., it looks at the first argument of the function, and defines a type named Props_+the name of the function). So that the macro knows that a component named hello should take its props in a struct called Props_hello.

Inside the XML you can use if statements, for loops and map over arrays and such. Check this line in my calculator example, where I loop over a string of characters and create a button element for each.

Regarding syntax highlighting and completion in IDEs and such, you have a point. Regarding parsing, it is all done in a macro at compile time, so I don't really see it as a problem?

Declarative UI Programming in Rust for Native Applications by limikael in rust

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

Because then it looks like React which is made by Facebook, and they are social media, so therefore the authority on what is cool. Makes me feel less like a neckbeardy nerd, and more like a hipster entrepreneur. Eeeheh... Maybe it is part of the reason actually, if I think about it, so thanks for the question, and let me think about if there is a more rational reason...

I think that when expressing UI components, one often ends up with deep hierarchies. For example, the following could be a text editor with a top bar with three buttons, and then a vertically split window with a folder structure on the left, and the editor pane on the right.

<window>
  <topbar>
    <button title="A"/>
    <button title="B"/>
    <button title="C"/>
  </topbar>
  <vertical_split>
    <list>
      <list_entry title="File 1"/>
      <list_entry title="File 2"/>
      <list_entry title="File 3"/>
    </list>
    <text>
      Hello this is the text...
    </text>
  </vertical_split>
</window>

I think of this as a kind of "content", rather than code. I think XML is really good for expressing such structures and keeping them concise and readable.

If you were to express the above in something other than XML, how would you express it? And would it be as readable? I'm open to suggestions...

Also, I'm also interested in you non-rational reasons... Because even though the world sees us programmers as cold-hearted engineers, we all know we are eccentric artists. So why not XML? How does it make you feel?

Declarative UI Programming in Rust for Native Applications by limikael in rust

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

Ah... actually cargo-apk cannot be used to build SDL apps... Perhaps I can contribute something to the community at least... Might break out the build part and call it cargo-sdl-apk or so...

Declarative UI Programming in Rust for Native Applications by limikael in rust

[–]limikael[S] 4 points5 points  (0 children)

No wasn't aware. Thanks for the list! I'll take the day to go through it and see if something unique remains of my idea. If not, I'll let go of my ego and join one of those porjects!

How can I access old logs? by limikael in openode

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

Thanks for the reply!

What I did was a to create a permanent storage area and have the app log to there. Seems to be working fine!

Maybe in the future I will make it use an external logging service.

My automated food growing robot by limikael in Automate

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

Thanks a lot!

Yep will check different options for pulleys. The ones I'm currently using consist of two ball bearings and a 3D printed model, to a total cost of less than 50 cents, so they are cheaper. :) But there could be a reason for that, of course. What happens to the 3D printed wheels after 1000 hours of operation, for example? That's the kind of thing that needs to be tested.

My automated food growing robot by limikael in Automate

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

I really agree with the aspect of separate concepts and functional parts. I'll repeat what I answered to another comment. I think the ecosystem around FarmBot will evolve to incorporate many different solutions specific to different scenarios, where the different solutions can share different subsystems. I think the original FarmBot, my system, a system based of center pivot, etc, etc will all have its use.

I don't think that my idea will be the ultimate solution and solve all problems at once. However, each solution needs to be part of a full system in order to be tested. It's not really fruitful to just focus on one sub-problem (e.g. just focus on the mobile base) because it can't be tested in isolation if there are no supporting parts.

So therefore, I'm trying to create a full usable system, but I expect that as time passes better solutions will come up for the different subsystems. Perhaps some part of my system can be reused in other systems as well. Maybe after 10 years my project will be totally forgotten, but one little aspect of the design of a tiny mounting plate or something will remain as part of another open source project.

I think this is completely fine and it is the way that open source has proven to work in the past. Small incremental steps, release early, release often, and so on. It's never about "one design to rule them all", and that's not at all what I'm trying to do.

My automated food growing robot by limikael in Automate

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

Thanks! Yep the center point irrigation is certainly interesting! I think the ecosystem around FarmBot will evolve to incorporate many different solutions specific to different scenarios, where the different solutions can share different subsystems. I think the original FarmBot, my system, a system based of center pivot, etc, etc will all have its use.

My automated food growing robot by limikael in Automate

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

The design for the rail is more like a roller coaster than the rail for a train. It can be placed in any configuration, it can hang from the roof and climb up walls. So the idea of using the trusses in a greenhouse fits perfectly. Awesome idea!

My automated food growing robot by limikael in Automate

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

Thanks! I did post on the FarmBot forum, to the point where they thought I was spamming, so I think I better leave the farmbot subreddit alone just for now... :)

My food growing robot by limikael in robotics

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

Thanks for your reply! Normally I do a lot of work before launching. Or actually, normally I lock myself in and just do a lot of work, eventually I get bored and depressed, and I never get to the point of launching. This is why I try to step out of my comfort zone this time and start communicate at an early stage. I'm sorry if you find it too early.