Re: Possible solution to template bloat problem?
On Friday, 23 August 2013 at 02:41:35 UTC, Ramon wrote: On Friday, 23 August 2013 at 01:17:55 UTC, bsd wrote: Well, that's a bit harsh. Can we close this thread? Aren't you a bit harsh here? After all, as a quick forum search suggests, "Wise Words", or more correctly the person who usually writes under another screen name here made the effort to bravely use another screen name in order to ... uhm ... troll. I guess "Wise Words" didn't mean me but rather told us about an experience where someone told him "Grow a pair and move on". Evidently he didn't follow at least the first part of the advice given to him. Amusing. Indeed, BS you are a troll :D
Re: Possible solution to template bloat problem?
On Friday, 23 August 2013 at 01:14:19 UTC, WiseWords wrote: On Thursday, 22 August 2013 at 19:20:37 UTC, Ramon wrote: Regan Heath You try to wrap it nicely but in the end you just prove my hypothesis right. The newcomer not only has to know all local habits and quirks of the group but he also has to know the history behind it. As a helpful hint you pick up dicebots hint that a newcomer probably should be read only for a while. Great. And what exactly kept you away from formalizing that, such making it known to newcomers? You try different funny tricks on me, for instance, by mixing up responsabilities. If this group has rules - which it is perfectly entitled to have - then it's the groups responsability to make those rules known in advance. It is *not* the newcomers responsability to somehow find out about them, possibly by getting accused of destruction. Another little trick of yours is, I'm putting it bluntly, to play the card "We are many, you are just 1; we are here since years, you are new - so bend over and obey". Frankly, the original matter doesn't even matter that much anymore to me. I've since quite a while put it aside as "he's a cheap asshole with micro-alpha syndrome but he has done very useful and partly brilliant work. That's all I want from him. So what?". What drives me now is the desperate, abstruse and stubborn group dynamics at play. And no, I'm not doing that just for the fun of it; it can actually be a useful service (and it does have a certain relation to the original problem). In two words: Context counts. (Which btw. is something you should like as you try playing it a lot). In this context here group seniority might be a big thing. Or particular technical skills. As soon as we leave the area of code, however, the cards get mixed again and who was big then might be surprisingly small. In this discussion here, for instance, the capability to analyze and recognize e.g. social and rhetorical mechanisms is way more important than D skills (No suprise. After all it *is* a group, social and human thing). To put it bluntly: Chances are that I can take apart whatever smart tricks you come up with. But why, what for? Why don't you yourself just stick to your own advice and assume - and correctly assume - that I have no bad intentions? You even have proof! If I had bad intentions or just were out for a fight or revenge, I would certainly not have recognized A's work as brilliant and lauded his book. Nor would I quite politely and patiently discuss and respond to statements that I, no offense intended, perceive as, uh, less than intellectually exciting. Take what I offer. Because it's good and because you will definitely not succeed in getting any femtogram more from me. a) Mr. A. did act in an unfair und unjustified way, no matter how you try to bend it. Maybe what he did was well known and usual here. But not toward myself. b) It's long forgiven and I'm in a peaceful and constructive state of mind. But don't you dare to convince me that Mr. A. was right and I should bend over and adapt to absurd group rules that demand inter alia precognition and possibly telepathy. Can we now finally return to discussing D, algorithms, code and the like or do you insist to educate me and to continue your route toward nada, nothing, zilch? Just consider me a miserable creature and really ugly on top of it if that helps. Nice tantrum :D Wise Words are spoken unto thee "Grow a pair and move on" Well, that's a bit harsh. Can we close this thread?
Re: std.serialization: pre-voting review / discussion
Seems like your memory has indeed faded a bit. ;) Versioning is an integral idea of formats like Protobuf and Thrift. For example, see the "A bit of history" section right on the doc overview page. [1] You might also want to read through the (rather dated) Thrift whitepaper to get an idea about what the design constraints for it were. [2] The main point is that when you have deployed services at the scale Google or Facebook work with, you can't just upgrade all involved parties simultaneously on a schema change. So, having to support multiple versions running along each other is pretty much a given, and the best way to deal with that is to build it right into your protocols. David [1] https://developers.google.com/protocol-buffers/docs/overview [2] http://thrift.apache.org/static/files/thrift-20070401.pdf Getting old! :-) Thanks for the heads up.
Re: std.serialization: pre-voting review / discussion
On Sunday, 18 August 2013 at 20:33:01 UTC, Jonathan M Davis wrote: On Sunday, August 18, 2013 21:45:59 Jacob Carlborg wrote: If versioning is crucial it can be added. I don't know if it's crucial or not, but I know that the Java guys didn't have it initially but ended up adding it later, which would imply that they ran into problems that made them decide that it should be there. I'd certainly be inclined to think that it's better to have it, and it's probably easier to add it before it's merged than later. But I don't know how crucial it is. - Jonathan M Davis I think this versioning idea is more important for protocol buffers, msgpck, thrift like libraries that use a separate IDL schema and IDL-compiled code. std.serialization uses the D code itself to serialize so the version is practically dictated by the user. It may as well be manually handledas long as it throws/returns error and doesn't crash if one tries to deserialize an archive type into a different/modified D type. From memory the Protocol Buffers versioning is to ensure schema generated code and library are compatible. You get compile errors if you try to compile IDL generated code with a newer version of the library. Similarly you get runtime errors if you deserialize data that was serialized with an older version of the library. This is all from memory so I could be wrong... Orange seems/feels more like the BOOST.serialization to me but much better. It's D for a start and allows custom archive types. In BOOST, the library stores a version number in the archive for each class serialized. This number defaults to 0 but can be set by the user via a #define. http://www.boost.org/doc/libs/1_54_0/libs/serialization/doc/tutorial.html#versioning I think adding it later can be done without breaking existing API, if it is deemed necessary. It just needs to default to 0 or something similar when missing from an archive and ensure it won't clash with any fields in existing archives.
Re: Passing string from D to c++
(damn, no edit!)
I'm using toStringz() and it works fine if you're c++ function
parms are const ref or by value:
void funk(const std::string& val) {}
void funk(std::string val) {}
then use a very simple D script to auto-generated C wrapper
functions from headers. All the script does is:
void funkD(const char* c) {funk(c);}
It wouldn't work for functions taking a string by ref or pointer,
that would require too much effort in the generating script for
my liking.
You may baulk at the idea of writing a script for auto-generating
the code but really it is very simple.
Re: Passing string from D to c++
I'm using toStringz() and it works fine if you're c++ function
parms are const ref or by value:
void funk(const std::string& val) {}
void funk(std::string val) {}
