docs at gpds.simulton.com seems to need an update

[bjornstromberg]

just to be thorough with #18 i was going to serialize and deserialize the color demo to xml at

well it seems they differ in the code snippets from the code here

just though you should know that the usage page is out of date..

[bjornstromberg]

the examples really should be as small as possible to easily find out the minimal stuff that is needed to get stuff running.

the serialize example snippet:

class car car;

std::sstream stream;
gpds::archiver_xml ar;
ar.save(stream, car, "car");

std::cout << stream.str() << std::endl

save takes stream, const container and std::string_view root-name

so sending in gpds::serialize wont do much good there.. it should likely be car.to_container() that is expected.

and deserialize:

class car car;

gpds::archiver_xml ar;
ar.load(stream, car, "car");

here we need a container first to load the stream into, then use car.from_container(container).

[bjornstromberg]

main.cxx

class Color
  : public gpds::serialize
{
public:
  std::string name;
  int red, green, blue;

  virtual
  gpds::container
  to_container() const override
  {
    gpds::container c;

    c.add_attribute("format", "rgb");
    c.add_attribute("name", name);

    c.add_value("red", red).add_attribute("depth", "32");
    c.add_value("green", green).add_attribute("depth", "32");
    c.add_value("blue", blue).add_attribute("depth", "32");

    return c;
  }

  virtual
  void
  from_container(const gpds::container& c) override
  {
    // Retrieve format
    const std::string& format_string = c.get_attribute<std::string>("format").value_or("n/a");
    assert(format_string == std::string("rgb"));

    name = c.get_attribute<std::string>("name").value_or("n/a");
    red = c.get_value<int>("red").value_or(0);
    green = c.get_value<int>("green").value_or(0);
    blue = c.get_value<int>("blue").value_or(0);
  }
};

int
main(int argc, char **argv)
{
// test so gpds + system tinyxml2 behaves as it should
  Color color;
  color.red   = 25;
  color.green = 30;
  color.blue  = 15;

  std::stringstream stream;
  gpds::archiver_xml ar;
  ar.save(stream, color.to_container(), "color");

  std::cout << stream.str() << std::endl;

  gpds::container color_container;

  gpds::archiver_xml ar_load;
  ar_load.load(stream, color_container, "color");

  Color color2;
  color2.from_container(color_container);

  assert(color.name   == color2.name);
  assert(color.red    == color2.red);
  assert(color.green  == color2.green);
  assert(color.blue   == color2.blue);

  return 0;
}

should be a minimal test, and it links, runs as it should with qschematic + gpds + system tinyxml2.

[bjornstromberg]

you can use that code snippet if you want for your usage page.

and sorry that I've got a big issue with out of date documentation.. sometimes it feels like I'm the only one actually reading the damn things.. 🙄

[Tectu]

You're correct on this. (Un)fortunately, I & we are aware of that.
The currently existing documentation that you're referring to was created with DITA and the plan is (for some time now) to drop that in favor of something based on hugo given that it's not exactly a complex documentation effort.
I like to play with tools in my spare time before I use company resources. My "test" for this approach was with https://github.com/tectu/cpp-properties (docs at: https://cppproperties.insane.engineer).
Both https://github.com/tectu/malloy and https://github.com/simulton/QSchematic are awaiting the same treatment.

Feedback on that approach is welcomed :)

and sorry that I've got a big issue with out of date documentation.. sometimes it feels like I'm the only one actually reading the damn things.. 🙄

Do not apologize for that - Don't even thing about it!
What you're doing is the correct, proper way of doing things and I 100% feel you there.
Updating that documentation has been on the back of my mind for many moons now. It's just difficult to allocate company time for this right now so I try to handle it in my spare time.

[bjornstromberg]

You're correct on this. (Un)fortunately, I & we are aware of that. The currently existing documentation that you're referring to was created with DITA and the plan is (for some time now) to drop that in favor of something based on hugo given that it's not exactly a complex documentation effort. I like to play with tools in my spare time before I use company resources. My "test" for this approach was with https://github.com/tectu/cpp-properties (docs at: https://cppproperties.insane.engineer). Both https://github.com/tectu/malloy and https://github.com/simulton/QSchematic are awaiting the same treatment.

Feedback on that approach is welcomed :)

playing with new tools are fun!

I'll do a proper review of the doc updates for a few hours, this on saturday this weekend, family (evening) and my current project needs today (QSchematic) and tomorrow (actual project using QSchematic).

and sorry that I've got a big issue with out of date documentation.. sometimes it feels like I'm the only one actually reading the damn things.. 🙄

Do not apologize for that - Don't even thing about it! What you're doing is the correct, proper way of doing things and I 100% feel you there. Updating that documentation has been on the back of my mind for many moons now. It's just difficult to allocate company time for this right now so I try to handle it in my spare time.

👍

[bjornstromberg]

how come i've never found malloy when i been searching for a lean, modern useful websocket solution? (oatpp was the closes i got and its filled with macros.. ugh..) hopefully i wont find much macros in malloy!

now i just need to ahem shoe horn mbedtls into that instead of openssl and it will fit like a shoe!

[Tectu]

how come i've never found malloy when i been searching for a lean, modern useful websocket solution?

I suck at the whole marketing / PR / public exposure type thing.
You can help by starring it and telling your friends :p

hopefully i wont find much macros in malloy!

If I'm not mistaken you shouldn't find a single macro in there.

now i just need to ahem shoe horn mbedtls into that instead of openssl and it will fit like a shoe!

Malloy itself us using boost::asio under the hood. This was an intentional choice on my side because once the C++ STL lands the networking TS it will be extremely easy to migrate from boost::asio to stock C++ STL.
As another consequence of that, malloy is (almost?) agnostic to OpenSSL. It's using boost::asio::ssl under the hood which means that you can use malloy with non-OpenSSL fairly easily.

My normal modus-operandi is to start something as a hobby project and once it reached some level of maturity I pass it over to our company (obviously still as fully open-source). Malloy is close to that point. We're using it in several projects intensively but I certainly would be very happy to have someone to "work with" to address some of the mood points (have a look at the issues if you are interested).

[bjornstromberg]

how come i've never found malloy when i been searching for a lean, modern useful websocket solution?

I suck at the whole marketing / PR / public exposure type thing. You can help by starring it and telling your friends :p

yea guess that makes two of us that suck at that..
my initial use case is to only depend on alpine main, since everything inside the containers run on alpine in a controlled environment, but ssl is still required..

hopefully i wont find much macros in malloy!

If I'm not mistaken you shouldn't find a single macro in there.

sounds good.

now i just need to ahem shoe horn mbedtls into that instead of openssl and it will fit like a shoe!

Malloy itself us using boost::asio under the hood. This was an intentional choice on my side because once the C++ STL lands the networking TS it will be extremely easy to migrate from boost::asio to stock C++ STL. As another consequence of that, malloy is (almost?) agnostic to OpenSSL. It's using boost::asio::ssl under the hood which means that you can use malloy with non-OpenSSL fairly easily.

my reason for mbedtls & openssl is to be able to switch between in case one of them go bad since alpine community will be the maintainers of what i 'need'.

in a-sence dont let the boat sink on a rock cause someone messed up a sail or oar, keep a spare..

ssl is a key technology to keep a spare! think ssl as a 'plugin'

My normal modus-operandi is to start something as a hobby project and once it reached some level of maturity I pass it over to our company (obviously still as fully open-source). Malloy is close to that point. We're using it in several projects intensively but I certainly would be very happy to have someone to "work with" to address some of the mood points (have a look at the issues if you are interested).

I'll experiment some with it when i get to next server-side project and see how it goes, it does sound like what i look for just from a quick look, and the fact its not copyleft licensed is a big plus, all your projects seems to have good licenses what i could see.

if we cant use it at/for work, why waste time on it.. imho.

my approach is to not have to marry a framework (except stl) everytime i want to get something done, so the fact that network-ts is on the horizon to get rid of boost, that makes me happy.

i've been waiting for network-ts for ages it feels like..

i really like Qt for client-side UI stuff, when i work on server-side, i dont want it anywhere close to the code..