Re: Oh My Gentool [v0.0.1] (Yet another binding generator)
On Saturday, 27 October 2018 at 16:55:23 UTC, Atila Neves wrote: On Tuesday, 23 October 2018 at 20:32:29 UTC, Andrea Fontana wrote: On Tuesday, 23 October 2018 at 20:03:42 UTC, Atila Neves wrote: We do - it's just very far from being complete. dpp can do some simple C++ and would have been able to do C-with-classes-style C++ ages ago. My focus is on templates though, since for me I can't see any useful C++ libraries that I'd actually want to call from D that don't use templates. And sometimes it's as silly as wanting to bind to an existing not-that-complicated library that happens to have a std::vector in its structs. For that, you need to be able to translate the standard library. Interesting. I'm using it for many different c libraries but I didn't think it worked for c++ already! The only problem I found with DPP is that simple consts declared with #define are not translated if not explicitly used. I think i can understand the reason (macro evaluation, I guess) but it would be useful to have a way to export them if they are simple consts... The whole idea of dpp is to be able to use headers as they are used in C and C++. Macros there don't exist unless they're expanded, so it's the same thing with dpp. Maybe it's good idea to add a runtime flag to translate non-function-like macros as enums... hmm. My tool already does simple value-macro extraction, I also thinking about replacing macro with shortcut-to-self(see below) so in AST it will look like a function call, then the user can convert the macro itself to a template or mixin, so this way the code can be preserved more or less as-is. Though I don't have exact date or plan. ``` #define REG_FN(A) gContext->reg(#A) ... // somewhere in code REG_FN(sum); ``` So in this trivial example REG_FN will be preserved in code as written. This way in more complex cases, such as whole class creation with macro, it should be possible to retain that information. But again this will require studying, it might sound useful in theory, however bindings is done for a specific conditions, and so whether it is really useful or not is an open question.
Re: Oh My Gentool [v0.0.1] (Yet another binding generator)
On Tuesday, 23 October 2018 at 20:32:29 UTC, Andrea Fontana wrote: On Tuesday, 23 October 2018 at 20:03:42 UTC, Atila Neves wrote: We do - it's just very far from being complete. dpp can do some simple C++ and would have been able to do C-with-classes-style C++ ages ago. My focus is on templates though, since for me I can't see any useful C++ libraries that I'd actually want to call from D that don't use templates. And sometimes it's as silly as wanting to bind to an existing not-that-complicated library that happens to have a std::vector in its structs. For that, you need to be able to translate the standard library. Interesting. I'm using it for many different c libraries but I didn't think it worked for c++ already! The only problem I found with DPP is that simple consts declared with #define are not translated if not explicitly used. I think i can understand the reason (macro evaluation, I guess) but it would be useful to have a way to export them if they are simple consts... The whole idea of dpp is to be able to use headers as they are used in C and C++. Macros there don't exist unless they're expanded, so it's the same thing with dpp. Maybe it's good idea to add a runtime flag to translate non-function-like macros as enums... hmm.
Re: New Initiative for Donations
On Sat, 27 Oct 2018 10:54:30 +, Joakim wrote: > I see, so you want other taxpayers to bail you out for your mistakes, > interesting. One of the major points of having a government is to create these regulations that make it less likely for individuals to suffer from the actions of other people and organizations. Another major point is to help people in need using the collective efforts of society. Programs like FDIC in the United States exist to serve both of these: it's an extra set of regulations for banks, and compliant banks will be bailed out if circumstances require. If I choose an FDIC bank and the owners run off with my money, I didn't make an avoidable mistake, any more than being mugged in the street is me making a mistake. If you oppose that, you're gunning for an eventual repeat of the Great Depression. >> I think my concerns are rather normal. Judging by adoption, there's >> some set of concerns that's normal. > > Some of them are popularly held, but most are fairly irrational. > > In any case, whether crypto-currencies ever go mainstream is irrelevant > to this thread. They're already fairly popular among techies, from whom > the D foundation is soliciting donations. As such, providing a way to > accept such donations is literally a no-brainer: the work put into > taking them will likely pay for itself many times over. I suspect more techies use zloty than ethereum.
Re: New Initiative for Donations
On Friday, 26 October 2018 at 17:20:08 UTC, Neia Neutuladh wrote: On Fri, 26 Oct 2018 06:19:29 +, Joakim wrote: On Friday, 26 October 2018 at 05:47:05 UTC, Neia Neutuladh wrote: On Fri, 26 Oct 2018 02:38:08 +, Joakim wrote: As with D, sometimes the new _is_ better, so perhaps you shouldn't assume old is better either. There's no assuming going on. Cryptocurrencies are worse than credit cards for everything that normal people care about, Such as? I already noted that they're easier and cheaper, you simply flatly state that "normal people" find them worse. In most countries where people are going to donate to D, the vast majority of people have access to a credit card. That's not really true, and that's not actually something "worse" about cryptocurrencies. If you really mean have some lying around, it is true that more are using credit cards. If you actually mean access, crypto-currencies are pretty easy to buy these days. If for some reason cryptocurrencies become popular and sufficiently stable to be used as currency, I have no doubt that existing credit card companies will start offering automatic currency exchange, so you can have an account in USD and pay a vendor who accepts only Ethereum, or vice versa. As such, accepting credit card payments is good enough. I don't know what we'd be waiting for, the tokens I mentioned are all worth billions and widely used, particularly by techies: Very few merchants accept any sort of cryptocurrency. I think I've found three. One was through a cryptocurrency forum, and one was Valve announcing that they would stop accepting it. You must not have looked very hard, there are online retailers accepting crypto-tokens and websites that will make payments for you on Amazon or other sites through Bitcoin: https://www.overstock.com/blockchain https://purse.io/shop Why would I wait for antiquated credit-card companies to accept these tokens? The whole point of these new tokens is to obsolete the credit card companies. You wouldn't wait. You haven't waited. For you, the benefits are large enough and the downsides small enough that it doesn't make sense to wait. But I'm not you. No, I'm not much of a cryptocurrency user or online shopper even. I mostly buy locally with cash. I would wait because I've lost access to important credentials before and had to send a copy of my government-issued ID to a company to get them to deactivate two-factor authentication. I've had to use password reset mechanisms frequently. I don't trust myself not to lose access to a cryptocurrency private key. And that would destroy currency and lose me my life savings. I don't blame you for being careful if you've had these problems, most of which I've never had, but you wildly exaggerate with your last sentence. Crypto-tokens are a replacement for cash and credit cards, which you should never be carrying around more than a couple hundred or thousand dollars worth of. If you're carrying around your life savings in cash or credit cards and are worried about moving them to bitcoin, you have much bigger problems. ;) I would wait because I want a mechanism to dispute transactions. Maybe I authorized that transaction, but the merchant didn't deliver. I don't think the payment provider is the right mechanism for that. The seller wants to protect their reputation and your payment is publicly verifiable through the blockchain. There are much better ways to build trust through those building blocks than the currently broken credit card chargeback process: https://www.shopify.com/retail/what-is-a-chargeback I would wait because I want an environmentally-friendly system instead of one that uses as much electricity as Afghanistan to process fifteen transactions per second. Yes, I noted the Bitcoin "Proof of work" problem in this forum almost five years ago, so I'm well aware: https://forum.dlang.org/post/xzuzvykrqouqlsjmk...@forum.dlang.org There are "Proof of stake" crypto-tokens out there that purport to avoid that issue: https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/ Ether, one of the tokens I mentioned originally, is moving to this scheme. I would wait because cryptocurrencies have extremely volatile exchange rates, which makes it difficult to set prices or store value in them. If you're buying online, which is what we're talking about, it's trivially simple to track the exchange rates and instantaneously set store prices accordingly. It may be a bit different for consumers, but by the time they're all using some payments tech like this, the exchange rates will likely have settled down. I would wait because I can't use cryptocurrency to do anything useful, so I would incur a fee to transfer money into it and another to transfer money out of it. Not necessarily- it depends on who you're buying your tokens from- and crypto-tokens usually work out cheaper once you include other
