initial implementation

Sharing initial commit for design feedback. Please pick it to pieces. Glad to split into smaller commits if it'd be helpful. I figured it was short enough that seeing the whole picture might be useful.
Some specific questions:
Crate name
Is compute-heavy-future-executor too long? Most crates are like 6 letters long. I was trying to make it clear what it does, but it's pretty klunky. Open to alternatives
Strategy-setting API
I don't love the current ergonomics of initializing a strategy. We have all these calls like initialize_block_in_place_strategy() which either initialize the oncelock or panic.
I was considering something like a builder or an enum, but it felt ridiculous given that there is only really one step for these and then we stash any output in the once lock. And then they are more verbose to call.
Other ideas welcome.
Custom executor
I wanted to put in an escape hatch to allow alternative async runtimes / customizing existing strategies with extra metrics or whatever / etc. But, the current form isn't particularly pleasant.
Ideally the caller would be able to implement the ComputeHeavyFutureExecutor trait themselves, but there were a few issues:

We can't just accept a generic since we need to store the executor in the once lock, and we can't have generics in the static context
We can't accept Box<dyn ComputeHeavyFutureExecutor> because the trait isn't object safe to its own generic bounds on its execute(fut: F) method

Instead I stored a closure inside of the CustomExecutor struct. That closure takes a future with Any output on the way in, and returns one with Any output. Because our execute call does have concrete typing, we can temporarily type erase the future's output before sending it into the closure, and then downcast it back on the flip side.
I think it's sound (please correct me, of course). Unfortunately we only are validating that the closure we get doesn't mangle the type, on initialization, not at compile time.
In addition to complexity, this also adds quite a few extra allocations due to all the added vtables and such.
I'm open to alternative approaches. Or, if it's better just to drop this functionality from the library entirely, and force people to stay on the rails, I'm open to that too.
Using get_or_init() inside spawn_compute_heavy_future()
Feedback on some dummy code in https://github.com/rustls/tokio-rustls/issues/94#issuecomment-2518177116 was that get_or_init() was overkill top call from inside the spawn handling.
As best as I can tell, using get_or_init() rather than matching against the runtime flavor every time this function is called, is strictly more efficient - since, it anyway starts off with OnceCell::get(), and then only calls the secondary logic if it was uninitialized - ref https://doc.rust-lang.org/beta/src/std/sync/once_lock.rs.html#387
This means that with get_or_init(), in case we need to use defaults, we have the single get branch every call, and the first call, the additional initialization logic.
Meanwhile with just a naked get().unwrap_or_else(), we still have the single get branch every call, and then the additional match branch against runtime flavor.
Probably a minor point either way, just calling out my reasoning so that it can be corrected as needed :)
Use of log crate
It felt strange depending on tracing when tokio itself is optional. I was browsing other libraries and was seeing that many of them just use the simple log crate. Which has interop with tracing anyway.
Is that the right choice? Or are libraries just using log because they were written before tracing was widely used?
Testing
Unit tests + doc tests succeed locally, with and without the tokio cfg flag enabled. I didn't want to overload this PR even further by setting some github actions, but I'll get to it!

@arielb1  - all comments should be addressed, thanks again for the close read
The main thing I want to call out is, I ended up adding a secondary OnceLock for the default strategy, that is lazily set and then subsequently ignored if a strategy is initialized afterwards.
I needed this because I started having lifetime issues on the Default impl for ExecutorStrategyImpl once I added in the possible Semaphore usage, even though it is always None when constructed as a default.
I figured it was probably fine since it still avoids the sharp edge of libraries calling spawn_compute_heavy_future() before the caller initializes. Open to alternatives.
Otherwise, I tried to break changes into commits, though some got a bit bigger. Here's the rundown:
Changes since last review

migrate from config flags to features
Add global_strategy_builder() method
Optional concurrency control for all executors
All executors are cancellable

I considered adding a knob to remove this behavior, but figured it was scope creep and cancellable is the right default behavior. I can open a github issue to see if anybody is interested in that later.

Moved the custom executor over to using a oneshot channel rather than having dyn Any

I considered keeping some support for Any in case the closure wants to know the future's output type for prioritization or other selective handling. But that's scope creep, I can cut a github issue to see if anybody cares about having support for that via a new executor / new knob.

Removed the default to BlockInPlace strategy for multi-threaded executor, there are too many footguns with it. Anyway the caller can choose it explicitly.
Moved tests to integration tests rather than requiring nextest, it's awkward because it forces a flat directory structure but it's still better than doctests I feel
Uses COMPUTE_HEAVY_FUTURE_EXECUTOR_STRATEGY::get() rather than get_or_init() inside spawn_compute_heavy_future() (though there is now a secondary oncelock for the default strategy as mentioned above)
Various other small cleanup / tweaks

Additional feedback from ariel - better to keep log messages on setting strategy inside a shared function where the once lock is actually set. Similarly only error there rather than sprinkled throughout constructor.

LGTM but plz rustfmt

Appreciate the review @arielb1
I'll follow up with separate issues on:

avoiding holding permits across i/o sleeps (maybe impl a wrapper future)
support for propagating future type inside the custom executor, for prioritization purposes
support for more variability in handling based on caller-specified 'likiness to block' / 'length of block', etc

My main feedback here is that I'm not sure about the mental model / use cases.
It seems like the strategy to use isn't necessarily application-global (or at least, there isn't a sensible default). Instead, if may make more sense to pick it based on the individual future? The properties of the future (or the number of futures) might dictate that choice.
Or perhaps put another way: I am a customer. How should I pick between these different options? Is there one that is the best?

Thanks for that @rcoh . Well stated.
I do have a few issues open that touch on this:

https://github.com/jlizen/compute-heavy-future-executor/issues/5
https://github.com/jlizen/compute-heavy-future-executor/issues/3
https://github.com/jlizen/compute-heavy-future-executor/issues/4

I think we need some clearer recommendations around defaults.  And then, if you know you have an issue with frequently blocking futures, the secondary tokio runtime might be better.
I want to validate those assumptions a bit more and then intend to flesh out the defaults as well as provide better explanations + recommendations in the module docs.
W/r/t to selective handling per future, I agree with that as well. I see two parts of this:

Better 'turnkey' handling for libraries to more granularly define likeliness/length of blocking. I kept initial PR scope narrower to avoid scope creep, but I want to probe this and probably publish with at least two modes of operation (likely 'sometimes/briefly blocking' and 'frequently/extended blocking'. Needs more validation first though.
I do think there is a place for exposing the specific shape of the input future into a custom closure-based executor as well (or perhaps a new turnkey strategy that allows injecting a selector between strategies based on input type, without requiring the full custom executor closure). Need to play around with that more.


Parallelize CUDA-C program for matrix addition

Must be faster than non-parallelized algorithm on the GPU.


feat: add icons and possibility for multiple links to portfolio

Description
I want to display multiple links for one portfolio item and use icons there. I changed the data/portfolio.yml to contain a list with multiple link items. Every item consists of url, text and icon. text and icon are optional. This is a breaking change for existing configurations. I adapted the exampleSite accordingly.
Issue Number:

Should I create one?

Checklist
Yes, I included all necessary artefacts, including:

[ ] Tests
[ ] Documentation
[ ] Implementation (Code and Ressources)
[ ] Example

Testing Checklist
Yes, I ensured that all of the following scenarios were tested:

[ ] Desktop Light Mode (Default)
[ ] Desktop Dark Mode
[ ] Desktop Light RTL Mode
[ ] Desktop Dark RTL Mode
[ ] Mobile Light Mode
[ ] Mobile Dark Mode
[ ] Mobile Light RTL Mode
[ ] Mobile Dark RTL Mode

@Sohn123 Thanks for the PR. I have added an fallback for the previous way of setting up links in the Portfolio. Please let me know, what you think.


Update quick start docs

What does this PR do?

Part of docs revamp #7666
Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you list all the breaking changes introduced by this pull request?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃
cc @borda

All the small formatting improvements and fixes to the code samples are great. I'm not a fan of the changes to the introduction. There are too bold statements about what Lightning is or what it does. For example, to say that "Lightning has all you need to do deep learning, you are in the right place" is the wrong approach to explain it. The way I like to distinguish Lightning is: "Lightning is not a framework, PyTorch is. Lightning is a philosophy."
My view is that this page is meant to be a quick start guide, so it should make it quick for people to get started.

@awaelchli Marc suggested putting in what is Lightning, and why someone wants to use it.. so that's why I added those 2 extra sections.
Do you think there should be 2 separate sections in the sidebar?
Introduction
Quick start

??
Then we can move it out of the quick start guide.

requesting @awaelchli for re-review.


build issues amazon_aia on ESP32-LyraTD-SYNA (IDFGH-11270)

.espressif/python_env/idf4.2_py3.11_env/lib/python3.11/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: undefined symbol: FIPS_mode
my build is failing at Generating x509_crt_bundle.  anyone know how to fix this?
rpi3 deb bookworm python3.11 OpenSSL 3.0.11
update -
i compiled openssl with fips module only to discover ossl 3 no longer supports fips_mode.
update - nuclear option
i downgraded to deb 11 openssl1.0.2 fips 2 mod  pyhton3.9 - and was able to build & flash but using ESP32-LyraTD example which looks like doesnt work with ESP32-LyraTD-SYNA

I'm sorry but ESP-IDF v4.2 is not supported anymore. I would guess that a relatively very new version of operating system combined with a very old ESP-IDF is causing the problem. The cryptography package is probably linked to older openssl library. You might be able to work around the issue by installing an older openssl library.
Also please consider to upgrade to the latest bugfix release of v4.4. It should contain no breaking changes in comparison with v4.2.

This has been tracked in https://github.com/espressif/esp-va-sdk/issues/189, let us follow up there, closing this one, thanks for reporting.


1.21 Fees

https://github.com/dogecoin/dogecoin/commit/18850d359bbc4d3333d9f1ac33607242d205c2ce may be useful here

If we set the min tx fee to 0.01 dogecoin that would currently be around 0.3 cents which would be on par with transaction fees before the recent popularity.

When the fee changes will be officially released? I mean v1.21.

Fee requirement is a matter of (default) configuration. We should change it ASAP, i.e. in the next minor release. When the network will be able to propagate cheap transactions, we can change default actual fee calculation.

I understand that tx fee is supposed to be an additional incentive for miners to keep mining, but as far as I understand, new coins are always minted by mining.

I'd not want to buy a piece of candy with doge, because the TX fee would be more than the item I purchased.
I therefore think default 0 fee would be very beneficial for increasing real-world use.
Other possibilities may be to make the fee optional, or only charge a fee when more data is sent than is needed ?

The problem with free is spam - tragedy of the commons. But we can make it very cheap for normal usage yet still prohibitively expensive to spam more than a bit. That's the goal. I have a proposal near done for initial publication. Any day now and apologies to all that this is taking a while.

With the high volatility in price maybe .1 cents equivalent would be better than .3 cents. I think sub 1 penny fees are important and Doge going to $1 plus in the near future isn't impossible. With .1 cent fee equivalent on todays price it would at least give us until Doge 10X from today before going above 1 penny on the fee. Which should be plenty of buffer before needing to discuss this same topic again too quickly.

With the high volatility in price maybe .1 cents equivalent would be better than .3 cents. I think sub 1 penny fees are important and Doge going to $1 plus in the near future isn't impossible. With .1 cent fee equivalent on todays price it would at least give us until Doge 10X from today before going above 1 penny on the fee. Which should be plenty of buffer before needing to discuss this same topic again too quickly.

That can't really be calculated on the fly, you can't set a dynamic fee based on current doge pricing.
It could just be manually adjusted as doge changes in price (which new updates), with that sort of rough target in mind, whether that target is 1c, under 5c or whatever.

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

No, it does not make sense. As 1 Doge = 1 Doge forever.
In the future, all products on sale will just list how much in Doge, not in USD or other fiat currencies.
Doge is the standard currency, remember it.

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

No, it does not make sense. As 1 Doge = 1 Doge forever.
In the future, all products on sale will just list how much in Doge, not in USD or other fiat currencies.
Doge is the standard currency, remember it.

I get what you're saying, but the entire discussion here is predicated on the value of Doge as compared to USD. I'm very pro-Doge, but the likelihood of the government using Doge over a FED backed coin for the USD replacement is next to none. Which means, we'll be having this same exact discussion in the future... should Doge increase in value substantially.

Theoretically, any scheme could be implemented. The problem is that multiple parties are involved in decisions related to transaction fees, and they have to agree. I don't even know how we will go about persuading mining pools to lower fee requirement.

Theoretically, any scheme could be implemented. The problem is that multiple parties are involved in decisions related to transaction fees, and they have to agree. I don't even know how we will go about persuading mining pools to lower fee requirement.

I suspect this won't be a major issue. Even ETH miners who made a significant portion of their value from fees, reluctantly accept the ETH gas fix (even though, in the long run miners are being phased out, and that DOES irk them)
Here, doge fees have historically not been a major part of income at all, and I doubt if they are yet either.
If the value stays high, they'll still make good profit, and likewise keeping fees low will encourage doge to stay actively used, on the network, which long term supports their profits.
If anything I'd say it's better to do it now, rather that wait for ages. That's just how it appears to me, I'm not a miner.

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

It's not really easy, or desirable. You'd need to pull information about price from some price aggregator, and that would produce a dependency that might break in future. If anything is used to calculate fees, ideally it should be info from the chain itself - like txn volume or something. But it's probably easier just to manually tweak it with updates for now.

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

It's not really easy, or desirable. You'd need to pull information about price from some price aggregator, and that would produce a dependency that might break in future. If anything is used to calculate fees, ideally it should be info from the chain itself - like txn volume or something. But it's probably easier just to manually tweak it with updates for now.

That's a good point. I do have an engineering and economics background but new to the crypto (dev) space, so I'm not sure what's technically possible yet with relative ease for a minor release. To use sockets parlance, can arbitrary data even be sent along a "packet" in a block? I might just dig into the source.
I do think for Doge to dominate with this space though (the spendable crypto), the coin should do something no other coin is doing and be the front runner. Right now it's the fun coin, but it can also be a pioneering coin.

Theoretically, any scheme could be implemented. The problem is that multiple parties are involved in decisions related to transaction fees, and they have to agree. I don't even know how we will go about persuading mining pools to lower fee requirement.

I suspect this won't be a major issue. Even ETH miners who made a significant portion of their value from fees, reluctantly accept the ETH gas fix (even though, in the long run miners are being phased out, and that DOES irk them)
Here, doge fees have historically not been a major part of income at all, and I doubt if they are yet either.
If the value stays high, they'll still make good profit, and likewise keeping fees low will encourage doge to stay actively used, on the network, which long term supports their profits. There's profits today, and profits tomorrow. Lower fees supports the latter.
If anything I'd say it's better to do it now, rather that wait for ages. That's just how it appears to me, I'm not a miner.

This is a bit unrelated, but since you know what you're talking about... do we know if there is ever any plans to move away from proof of work for Doge, with the whole green movement going on to save CPU cycles?

Converting entire Dogecoin blockchain network to PoS would be enormous effort and take probably like 2 years or longer. I'm not an expert, but that's my observation by looking at ETH transition from PoW to PoS. It still hasn't been completed and there's no ETA. They are desperately trying to rush it, but pessimists say it might come in 2022 or later. Perhaps it would be much easier to use some connection with different blockchain to run or confirm transactions for Dogecoin blockchain. Again, I'm no expert in that matter, but Cardano is connected somehow with Ergo (ERG) and the latter uses PoW protocol, so Cardano takes the advantage of both. I have no idea if something similar can be used for Dogecoin, maybe I sound a bit delusional, but perhaps there's a way to connect with other blockchains and take advantage of their PoS for some payment in exchange or create a second native token to introduce PoS. You can read about it here how the two work:
https://forum.cardano.org/t/ergo-will-complement-cardano/45412

Without getting into the benefits of POW over POS, I think the main reason to stick with POW is that Doge is already a clone of Bitcoin and Litecoin. As long as we stick to the same structural setup as them we can easily piggy back off of their top of the industry dev work without having to reinvent the wheel and paying for expensive audits.
Just my 0.2 Doge thoughts on the matter

If we ever were to change mining algorithms I think doing what Monero did with RandomX would be really cool for Doge. It gets rid of ASIC miners and allows anyone to mine with a CPU. Since Doge is the people’s crypto and a fan favorite of beginners, I think it would be fun if anyone with a computer could mine it like back in the old days.

Theoretically, any scheme could be implemented. The problem is that multiple parties are involved in decisions related to transaction fees, and they have to agree. I don't even know how we will go about persuading mining pools to lower fee requirement.

I suspect this won't be a major issue. Even ETH miners who made a significant portion of their value from fees, reluctantly accept the ETH gas fix (even though, in the long run miners are being phased out, and that DOES irk them)
Here, doge fees have historically not been a major part of income at all, and I doubt if they are yet either.
If the value stays high, they'll still make good profit, and likewise keeping fees low will encourage doge to stay actively used, on the network, which long term supports their profits. There's profits today, and profits tomorrow. Lower fees supports the latter.
If anything I'd say it's better to do it now, rather that wait for ages. That's just how it appears to me, I'm not a miner.

This is a bit unrelated, but since you know what you're talking about... do we know if there is ever any plans to move away from proof of work for Doge, with the whole green movement going on to save CPU cycles?

I've been doing a bit of research on consensus  models and how these things work recently. As I understand it, there are basically trade offs with doing that (usually either security or decentralization). Dogecoin is one of the most efficient proof of work coins, because of it's fast block reward and also shares mining with litecoin.
There's a swedish outfit trying to make a more efficient asic for dogecoin (for green purposes). And maybe also some of the suggestions regarding scaling under the block size discussion may reduce load?
There are some misnomers in that narrative as well. Such as that the banking system already uses a significant amount of power, and it's usually talked about in terms of bitcoin, which is the most intensive of all coins. It's also not impossible for other chains (multichain), or a second layer to do some of the work for dogecoin (even if they are prone to those forementioned trade offs)

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

It's not really easy, or desirable. You'd need to pull information about price from some price aggregator, and that would produce a dependency that might break in future. If anything is used to calculate fees, ideally it should be info from the chain itself - like txn volume or something. But it's probably easier just to manually tweak it with updates for now.

That's a good point. I do have an engineering and economics background but new to the crypto (dev) space, so I'm not sure what's technically possible yet with relative ease for a minor release. To use sockets parlance, can arbitrary data even be sent along a "packet" in a block? I might just dig into the source.
I do think for Doge to dominate with this space though (the spendable crypto), the coin should do something no other coin is doing and be the front runner. Right now it's the fun coin, but it can also be a pioneering coin.

You can embed data in the block for txn currently. And that will possibly be expanded as the devs work out solutions for xchain enhancement.
I'm very with you on dogecoin taking it's own path where it makes sense. We are in quite a different place now, with tendermint, xchain, defi, new scaling methods etc than when the other bitcoin family coins made their choices. Like there is more information about how things shape up now, and also some newer ideas. There are likely a few ideas from non-pow coins that are also salient.
Whilst it's easier to mostly follow existing development paths, it feels like none of the other coins really got scaling entirely right yet for eg.
Significant deviation would probably require bringing on new coders using bounties or similar, but I think if we can settle on the right solutions for things, and the right idea comes along (one that really seems worth the extra effort) IMO we should be open to it.

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

It's not really easy, or desirable. You'd need to pull information about price from some price aggregator, and that would produce a dependency that might break in future. If anything is used to calculate fees, ideally it should be info from the chain itself - like txn volume or something. But it's probably easier just to manually tweak it with updates for now.

That's a good point. I do have an engineering and economics background but new to the crypto (dev) space, so I'm not sure what's technically possible yet with relative ease for a minor release. To use sockets parlance, can arbitrary data even be sent along a "packet" in a block? I might just dig into the source.
I do think for Doge to dominate with this space though (the spendable crypto), the coin should do something no other coin is doing and be the front runner. Right now it's the fun coin, but it can also be a pioneering coin.

You can embed data in the block for txn currently (although I think that's reserved for external use, not for the network). And that will possibly be expanded as the devs work out solutions for xchain enhancement? So sort of, but not really I think, in terms of what you are thinking.
I'm very with you on dogecoin taking it's own path where it makes sense. We are in quite a different place now, with tendermint, xchain, defi, new scaling methods etc than when the other bitcoin family coins made their choices. Like there is more information about how things shape up now, and also some newer ideas. There are likely a few ideas from non-pow coins that are also salient.
Whilst it's easier to mostly follow existing development paths, it feels like none of the other bitcoin family coins really got scaling entirely right yet for eg. There may be ideas from many of them that could be combined, or outside ideas. Doesn't need to be specifically scaling, but in general any idea that seems worth the extra effort.
Significant deviation would probably require bringing on new coders using bounties or similar, but I think if we can settle on the right solutions for things, and the right idea comes along (one that really seems worth the extra effort) IMO we should be open to it. Even though the pathways for the well worn path are there. Just needs to be an idea that can really make a difference.

I agree if anything is being done that's not an already worn path it would need to be significantly impressive as to warrant moving forward with it but if it's good enough it would definitely be worth it. The only issue is right now there are a lot of people out there using doge who honestly haven't a clue how to make feature requests or get involved in a visible way that could allow us to see what there is an appetite for. The subreddit seems to have questions and requests fairly frequently (e.g. I saw one the other day that sounded interesting but not sure how it could be done in a decentralised fashion about the potential to make Dogecoin accessible over texts for access in third world countries without smartphones) but they always tend to be buried by people trading etc, so maybe we would need to set up some sort of system to allow for the right idea to be brought forward easily by the community on the website or via some other method? It would probably also help stop the narrative that there's nobody actively working on this repo that seems to keep popping up as well which would also be good.

"but they always tend to be buried by people trading etc, so maybe we would need to set up some sort of system to allow for the right idea to be brought forward easily by the community on the website or via some other method? It would probably also help stop the narrative that there's nobody actively working on this repo that seems to keep popping up as well which would also be good."
Just add a flair "Idea" and maybe host some competitions for dogecoins to promote it. The easiest way without making new forums or subs and can easily rally all brains within community.

"but they always tend to be buried by people trading etc, so maybe we would need to set up some sort of system to allow for the right idea to be brought forward easily by the community on the website or via some other method? It would probably also help stop the narrative that there's nobody actively working on this repo that seems to keep popping up as well which would also be good."
Just add a flair "Idea" and maybe host some competitions for dogecoins to promote it. The easiest way without making new forums or subs and can easily rally all brains within community.

I think this already exists but it doesn't seem to be possible to filter by it for anyone to take a look through posts tagged with the flair? I agree we want it to be simple, but might relying on reddit restrict the audience too much to young technical people? Not trying to be pedantic but I don't want to risk the community becoming too much of an echo chamber if you get my drift?

Rather than make the fee a set amount. Is there not a way to make it a small, small percentage of the current market value at the time of the transaction. Is that even possible?

It's not really easy, or desirable. You'd need to pull information about price from some price aggregator, and that would produce a dependency that might break in future. If anything is used to calculate fees, ideally it should be info from the chain itself - like txn volume or something. But it's probably easier just to manually tweak it with updates for now.

That's a good point. I do have an engineering and economics background but new to the crypto (dev) space, so I'm not sure what's technically possible yet with relative ease for a minor release. To use sockets parlance, can arbitrary data even be sent along a "packet" in a block? I might just dig into the source.
I do think for Doge to dominate with this space though (the spendable crypto), the coin should do something no other coin is doing and be the front runner. Right now it's the fun coin, but it can also be a pioneering coin.

You can embed data in the block for txn currently (although I think that's reserved for external use, not for the network). And that will possibly be expanded as the devs work out solutions for xchain enhancement? So sort of, but not really I think, in terms of what you are thinking.
I'm very with you on dogecoin taking it's own path where it makes sense. We are in quite a different place now, with tendermint, xchain, defi, new scaling methods etc than when the other bitcoin family coins made their choices. Like there is more information about how things shape up now, and also some newer ideas. There are likely a few ideas from non-pow coins that are also salient.
Whilst it's easier to mostly follow existing development paths, it feels like none of the other bitcoin family coins really got scaling entirely right yet for eg. There may be ideas from many of them that could be combined, or outside ideas. Doesn't need to be specifically scaling, but in general any idea that seems worth the extra effort.
Significant deviation would probably require bringing on new coders using bounties or similar, but I think if we can settle on the right solutions for things, and the right idea comes along (one that really seems worth the extra effort) IMO we should be open to it. Even though the pathways for the well worn path are there. Just needs to be an idea that can really make a difference.

I agree if anything is being done that's not an already worn path it would need to be significantly impressive as to warrant moving forward with it but if it's good enough it would definitely be worth it. The only issue is right now there are a lot of people out there using doge who honestly haven't a clue how to make feature requests or get involved in a visible way that could allow us to see what there is an appetite for. The subreddit seems to have questions and requests fairly frequently (e.g. I saw one the other day that sounded interesting but not sure how it could be done in a decentralised fashion about the potential to make Dogecoin accessible over texts for access in third world countries without smartphones) but they always tend to be buried by people trading etc, so maybe we would need to set up some sort of system to allow for the right idea to be brought forward easily by the community on the website or via some other method? It would probably also help stop the narrative that there's nobody actively working on this repo that seems to keep popping up as well which would also be good.

Two good ideas in there. There's been discussion about a pinned post discussion things happening over here, on the dev subreddit. I suggested a community liason, if someone had the time, and the right communication style - to basically cross post major discussions and upcoming updates over there to said pinned post.
As for developing nations - kiaos seems to be taking off. Seems feasible to maybe create some wallet interface with that. Actually a really good idea to reach out to the unbanked. Probably not a core dev team project.

"but they always tend to be buried by people trading etc, so maybe we would need to set up some sort of system to allow for the right idea to be brought forward easily by the community on the website or via some other method? It would probably also help stop the narrative that there's nobody actively working on this repo that seems to keep popping up as well which would also be good."
Just add a flair "Idea" and maybe host some competitions for dogecoins to promote it. The easiest way without making new forums or subs and can easily rally all brains within community.

I think this already exists but it doesn't seem to be possible to filter by it for anyone to take a look through posts tagged with the flair? I agree we want it to be simple, but might relying on reddit restrict the audience too much to young technical people? Not trying to be pedantic but I don't want to risk the community becoming too much of an echo chamber if you get my drift?

OK, so I just checked and the flair already exists, but you can only fiter by: Adoption; Discussion; Meme; Serious;
It's always worth a shot to try and doesn't hurt, I think people in sub would be excited about it and there's plenty of hidden talents there who might be discovered this way.

I understand that tx fee is supposed to be an additional incentive for miners to keep mining, but as far as I understand, new coins are always minted by mining doge, this probably made more sense with btc where miners almost only get the fee at some point.

Yes the fees are NOT needed for dogecoin miners since there is always a block reward for the miners.

I'd not want to buy a piece of candy with doge, because the TX fee would be more than the item I purchased.
I therefore think default 0 fee would be very beneficial for increasing real-world use.
Other possibilities may be to make the fee optional, or only charge a fee when more data is sent than is needed ?
A different take would be to somehow have the tx fee go to those who help the network in other ways than mining, like those running full nodes, but that'd probably be a major protocol change.

Yes I am actually a proponent of this.  The only problem with this is then we would get full blocks, and only when the blocks are full would optional transaction fees be necessary.  Fees would stay very low though, lower than anything we could artificially set.  The only downside is with full blocks comes a very hefty blockchain, 500gb added a year.

If we ever were to change mining algorithms I think doing what Monero did with RandomX would be really cool for Doge. It gets rid of ASIC miners and allows anyone to mine with a CPU. Since Doge is the people’s crypto and a fan favorite of beginners, I think it would be fun if anyone with a computer could mine it like back in the old days.

Kind of off topic but randomx has failed and is now dominated by secret GPU's.  Yespower is a true winner, but I don't think the main dogecoin should ever change their PoW.

And FYI PoS has serious security flaws, like a whale could buy up half of the coins and attack the network at will for 0 cost.

Yeah POS would basically give all voting power to Robinhood and the other exchanges that don't let you own your actual coins.

And FYI PoS has serious security flaws, like a whale could buy up half of the coins and attack the network at will for 0 cost.

Yeah POS would basically give all voting power to Robinhood and the other exchanges that don't let you own your actual coins.

Consider a POS sidechain for Dogecoin like smartbch: https://github.com/smartbch/docs

Kind of off topic but randomx has failed and is now dominated by secret GPU's.

Citation needed. The best known platform for running RandomX is AMD Ryzen CPUs.
RandomX is somewhat similar to scrypt in that both are attempting to resist ASICs.
And in their attempt, both sacrifice good properties of Proof-of-Work : simplicity and instant verifiability. RandomX is even (way) more complicated than scrypt, using way more memory, and is even more expensive to verify. But as a result is also way more ASIC resistant.
In scrypt's case, the sacrifices are just a pure negative, since its ASIC resistance has utterly failed.

I think sub 1 penny fees are important

I disagree. sub 10 penny fees are important, while sub .1 penny fees make spam rather cheap. In your fear of fees of a few pennies (for a tx which potentially millions of future nodes will download, store and verify) you are going to let the chain to get much more bloated

Just wondering, and sorry if it is an stupid question but, does the fee
have to be a fixed amount along the network? I mean, couldn't the fee be
based on the amount on subsequent transactions from one wallet in an
specific period of time? Just as with auth methods to avoid spam. Just
wondering if something like that may (ever) be possible.
On Thu, May 6, 2021, 10:11 John Tromp @.***> wrote:

I think sub 1 penny fees are important
I disagree. sub 10 penny fees are important, while sub .1 penny fees make
spam rather cheap. In your fear of fees of a few pennies (for a tx which
potentially millions of future nodes will download, store and verify) you
are going to let the chain to get much more bloated
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dogecoin/dogecoin/issues/1797#issuecomment-833324707,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYDB4KHLVCUOLATJK2EKATTMJFKLANCNFSM4ZE5GRWQ
.

If we ever were to change mining algorithms I think doing what Monero did with RandomX would be really cool for Doge. It gets rid of ASIC miners and allows anyone to mine with a CPU. Since Doge is the people’s crypto and a fan favorite of beginners, I think it would be fun if anyone with a computer could mine it like back in the old days.

Kind of off topic but randomx has failed and is now dominated by secret GPU's. Yespower is a true winner, but I don't think the main dogecoin should ever change their PoW.
And FYI PoS has serious security flaws, like a whale could buy up half of the coins and attack the network at will for 0 cost.

Post proofs otherwise it is pure BS. Yespower is not ASIC resistant and they even say it on their website

yespower in particular is designed to be CPU-friendly, GPU-unfriendly, and FPGA/ASIC-neutral.

I think sub 1 penny fees are important

I disagree. sub 10 penny fees are important, while sub .1 penny fees make spam rather cheap. In your fear of fees of a few pennies (for a tx which potentially millions of future nodes will download, store and verify) you are going to let the chain to get much more bloated

I think sub 1 penny should be the target.  This is where Bitcoin Cash and Litecoin are right now.

I think sub 1 penny fees are important

I disagree. sub 10 penny fees are important, while sub .1 penny fees make spam rather cheap. In your fear of fees of a few pennies (for a tx which potentially millions of future nodes will download, store and verify) you are going to let the chain to get much more bloated

Do nodes actually in theory need to store the whole chain? Could it not be a hash confirmation or compressed or propagated in a more elegant way? There are likely multiple ways the size could be kept down there. And from my understanding these solutions might be pressing anyway based on current node chain propagation regardless of fees. That all said fees have been below 1c for basically all of doge coins existence

Somewhere between 0.1 penny and 1 penny seems to be the sweet spot to keep fees very low and reduce spam.

Do nodes actually in theory need to store the whole chain?

Archive nodes do. Which you need a healthy supply of, to seed all the full nodes in their Initial Block Download, where they download and verify the entire tx history.

Significant deviation would probably require bringing on new coders using bounties or similar, but I think if we can settle on the right solutions for things, and the right idea comes along (one that really seems worth the extra effort) IMO we should be open to it. Even though the pathways for the well worn path are there. Just needs to be an idea that can really make a difference.

Yeah exactly. I'm totally new to the crypto dev space, but I have been a software/web developer my entire life. As such, I'll have to defer some particulars to the more experienced folks here until I learn more. But I do have an economics background as well, so hopefully that could help in some way. Like, we should find a way to capture/leverage this green movement. If adoptability is the goal then that's just one less barrier.
Doge is to the point now where it needs to put on its big boy pants. It has so much attention now. I realize it started as a joke, but like it or not the world is embracing it as more. Which means for Doge to continue the momentum, it's time to start thinking in terms of what we can do with the coin besides just copy/paste from Litecoin, etc. That was then. Times have changed.

I think sub 1 penny fees are important

I disagree. sub 10 penny fees are important, while sub .1 penny fees make spam rather cheap. In your fear of fees of a few pennies (for a tx which potentially millions of future nodes will download, store and verify) you are going to let the chain to get much more bloated

Let's take existing credit or debit cards as the model here. Right now, they work as a percentage rather than a hard coded amount (good). However, USD doesn't have the problem Doge does right now. USD is priced in USD. Doge is not. So while we try to reconcile the difference, so far it's been a hard coded amount (per my understanding).
Credit card frees are on average 2%. Which is extremely high. But it does discourage misuse. However, the only reason they get away with this tax is because it's paid for by the vendor and not the customer... upfront that is. The vendor will charge a higher price to make up for it, but that is transparent to the customer.
The major difference here is, crypto charges that tax to the customer directly. It's plain and obvious now what they are paying as a consumer. Which is to say, a higher fee that would discourage spam would also discourage use. Years ago Bill Grates proposed doing the same thing to email to stop spam from happening. But, it never caught on.
People don't want to pay money to use their money. Yes, fees are everywhere. But up until now people had no choice. Banks controls money and there was only USD. Everything is different now, people have a choice.

I think sub 1 penny fees are important

I disagree. sub 10 penny fees are important, while sub .1 penny fees make spam rather cheap. In your fear of fees of a few pennies (for a tx which potentially millions of future nodes will download, store and verify) you are going to let the chain to get much more bloated

I think sub 1 penny should be the target. This is where Bitcoin Cash and Litecoin are right now. Somewhere between 0.1 penny and 1 penny seems to be the sweet spot to keep fees very low and reduce spam. Also we have to remember that both BCH and LTC will one day have to rely on fees to pay miners, we do not (for the next couple hundred years at least).

Totally. I suppose the question is... how do we accomplish this without hard coding the rate? How do we know at the time of transaction that 0.0X of Doge is 0.01 of USD?

Totally. I suppose the question is... how do we accomplish this without hard coding the rate? How do we know at the time of transaction that 0.00X of Doge is 0.001 of USD?

It's pretty dangerous to interact with real world data since it messes with decentralization. Someone like Maker Dao does it by using multiple exchange oracles. But it comes with a lot of risk since the exchange api's are a single point of failure for your whole coin. In this case for Doge it's not really worth it to add extra failure points when we can just manually update the hard coded fee every 7 years or so.

Totally. I suppose the question is... how do we accomplish this without hard coding the rate? How do we know at the time of transaction that 0.00X of Doge is 0.001 of USD?

It's pretty dangerous to interact with real world data since it messes with decentralization. Someone like Maker Dao does it by using multiple exchange oracles. But it comes with a lot of risk since the exchange api's are a single point of failure for your whole coin. In this case for Doge it's not really worth it to add extra failure points when we can just manually update the hard coded fee every 7 years or so.

Yeah that's a great point. If the volatility of Doge (or any crypto) ever decreases this could work. The only problem is, that's a long way away. Well... maybe not too far away. But, if you look at ETH and BNB right now... those gas fees are high. While the public is getting used to crypto, that may be prohibitive to mass adoption if price fluctuates too wildly in the short term. As in, we only have one real shot to be first in market for the truly spendable cryptocurrency.
And I'm just throwing ideas out here, feel free to pick them apart for viability. Is there a way to measure volatility on the chain? Not so much with price but perhaps frequency over time? That way the data points wouldn't be external. So like if we have a running average and today the average is 30% higher than yesterday's in transaction frequency, we can assume it's volatile.
Brokers will use volatility as a means of increasing spreads or fees. They does this out of greed, but the point is investors are used tot his concept already. It's not anything that would scare them away. And what if we did the opposite? So we'll leverage a familiar concept but make it cheaper during high volatility.
Perhaps we can have two set percentages that are hard coded. One for non-volatile days, as you mentioned, and one that's lower for the days when price may or may not be fluctuating wildly but the frequency increased above the threshold. Volatility and price change usually go hand-in-hand but it's not a guarantee.. But this would give us some metric at least.
What this would give us, is a way to get to the point of mass adoption without relying on a third party. Granted the second lower fee would still need to be high enough to discourage spam, but not so high it becomes prohibitive to transact in Doge if the price suddenly shoots way up (price going down doesn't matter).
Thoughts?

Somewhere between 0.1 penny and 1 penny seems to be the sweet spot to keep fees very low and reduce spam.

 Neither negligible, nor bothersome.
Since dogecoin cannot be expected to go much over $1, a centidoge fee seems good to me.

I think your price target is reasonable. But I do want to point out there does exist a possibility of a USD failure. If that happens, Doge will go up way more than a dollar (let's hope it doesn't though). Granted, if that's the case then then one cent fee would become even cheaper so that's a good thing actually. But, I do just want to point that out is all.

Grin has a fee scaling factor in the node configuration file. If fees were to become too high, we would try to convince the majority of nodes to lower the parameter in that file. This works because fees are part of the network level rather than the consensus level.
Once most of the network has adjusted, you can send out txs with accordingly lower (grin-denominated) fees and have good odds of having it relayed and mined.

Post proofs otherwise it is pure BS. Yespower is not ASIC resistant and they even say it on their website

yespower in particular is designed to be CPU-friendly, GPU-unfriendly, and FPGA/ASIC-neutral.

Also on their website:
"It is also possible to respond to known improvements in future GPUs/implementations and/or to ASICs with new versions of yespower that users would need to switch to."
Want some proof?  Yescrypt was upgraded to Yespower to improve GPU resistance and the majority of coins made the switch.

I think sub 1 penny fees are important

I disagree. sub 10 penny fees are important, while sub .1 penny fees make spam rather cheap. In your fear of fees of a few pennies (for a tx which potentially millions of future nodes will download, store and verify) you are going to let the chain to get much more bloated

I think sub 1 penny should be the target. This is where Bitcoin Cash and Litecoin are right now. Somewhere between 0.1 penny and 1 penny seems to be the sweet spot to keep fees very low and reduce spam. Also we have to remember that both BCH and LTC will one day have to rely on fees to pay miners, we do not (for the next couple hundred years at least).

Totally. I suppose the question is... how do we accomplish this without hard coding the rate? How do we know at the time of transaction that 0.00X of Doge is 0.001 of USD?

Any attempt we try to make the fee adjust without having to touch the code will have tradeoffs.  The good thing here is that min fee can be adjusted without a hard fork, it is so easy to do in fact that it could be done in every minor release if it were somehow necessary.  My thought is at least for the near term, we adjust the fee as needed to keep it below a cent and there are really no downsides.

Grin has a fee scaling factor in the node configuration file. If fees were to become too high, we would try to convince the majority of nodes to lower the parameter in that file. This works because fees are part of the network level rather than the consensus level.
Once most of the network has adjusted, you can send out txs with accordingly lower (grin-denominated) fees and have good odds of having it relayed and mined.

Thanks for this tromp. I'll look into it.

I think sub 1 penny fees are important

I disagree. sub 10 penny fees are important, while sub .1 penny fees make spam rather cheap. In your fear of fees of a few pennies (for a tx which potentially millions of future nodes will download, store and verify) you are going to let the chain to get much more bloated

I think sub 1 penny should be the target. This is where Bitcoin Cash and Litecoin are right now. Somewhere between 0.1 penny and 1 penny seems to be the sweet spot to keep fees very low and reduce spam. Also we have to remember that both BCH and LTC will one day have to rely on fees to pay miners, we do not (for the next couple hundred years at least).

Totally. I suppose the question is... how do we accomplish this without hard coding the rate? How do we know at the time of transaction that 0.00X of Doge is 0.001 of USD?

Any attempt we try to make the fee adjust without having to touch the code will have tradeoffs. The good thing here is that min fee can be adjusted without a hard fork, it is so easy to do in fact that it could be done in every minor release if it were somehow necessary. My thought is at least for the near term, we adjust the fee as needed to keep it below a cent and there are really no downsides.

Great points. We totally shouldn't have a major change for a minor release,... And you're spot on for the short term solution to the concern of rising prices. I'll go take a look at grin (totally n00b to crypto development, but have an economics/financial background)... maybe the solution is already there.

Note that Bitcoin and all derivates also have a configurable parameter minrelaytxfee:
The current default value for the minRelayTxFee in Bitcoin Core is 1000 satoshi/kB (= 1 sat/B). A node operator may specify a different value via the startup parameter -minrelaytxfee= or the configuration parameter minrelaytxfee= which takes an  in [BTC/kB].
The difference is that one either has to change the main.h source code (and recompile) or the node command line parameters to set a different value, while in Grin one need only change an entry in the node configuration file.

Any ideas on how to persuade enough node operators to change the configuration or to update to the new version when it will come out?

Declare some date as official fee changing day, and make a lot of noise about it?!

Unfortunately, it cannot happen in one day. First we need to make sure that cheap transactions are reliably confirmed. Here we need node operators to update fee policies. It will take some time, and we don't know how long. Then we can lower actual fees by changing fee calculation in wallet software.

I think something like avoiding the possibility to run the node if it's not
up to date would be something worthy to add
On Fri, May 14, 2021, 10:54 shibe2 @.***> wrote:

Unfortunately, it cannot happen in one day. First we need to make sure
that cheap transactions are reliably confirmed. Here we need node operators
to update fee policies. It will take some time, and we don't know how long.
Then we can lower actual fees by changing fee calculation in wallet
software.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dogecoin/dogecoin/issues/1797#issuecomment-841111118,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYDB4OLXCVYLFQ26K7ZFJDTNTQODANCNFSM4ZE5GRWQ
.

Here's my 0.02 Doge regarding fee determination.
Have a dynamic tx fee (similar to difficulty adjustment) where the tx fee amount is programmatically adjusted to encourage blocks to be half-full. For example, when block are consistently less than half full, the tx fees are adjusted lower, conversely when the blocks are consistently more than half full, the tx fees are adjusted higher to get back to equilibrium. Over time as Doge is being used more frequently, fees will inevitably rise - the block size can then be manually raised to accomodate more transactions and keep tx fees low.

Here's my 0.02 Doge regarding tx fee determination.
Have a dynamic tx fee (similar to difficulty adjustment) where the tx fee amount is programmatically adjusted to encourage blocks to be half-full. For example, when block are consistently less than half full, the tx fees are adjusted lower, conversely when the blocks are consistently more than half full, the tx fees are adjusted higher to get back to equilibrium. Over time as Doge is being used more frequently, fees will inevitably rise - the block size can then be manually raised to accomodate more transactions and keep tx fees low.

I mean, the fees might as well be basically nothing unless it's over half yeah?

A lot of the talk here is for future development (which is good). But the fee change that devs are working on should go in any day now. Have we (and the devs) decide on what fee we're going to go with? I still think we should do something in the range of 0.001 - 0.005 Doge. That way if Doge price spikes in the coming weeks from the Coinbase listing we wont have to be having this fee discussion again too quickly.

#newbie-idea  As there is high correlation between market value and hashrate (and difficulty), why the fee is not dynamically calculated based on it? Like that you will never have to think about it again in the future. Even if 1 DOGE = 1 DOGE!

Difficulty depends on other factors besides Dogecoin value: Litecoin value, Litecoin block reward (which will change), mining hardware advancements.

Difficulty depends on other factors besides Dogecoin value: Litecoin value, Litecoin block reward (which will change), mining hardware advancements.

Also we are merge mined with EVERY scrypt coin, not just Litecoin, for the record.

Cap wallet ID's for hash rate in some way.  If we can make it so the world can't powermine all the new coins, and everyone has access to grabbing an equal share of the new coins, we could eliminate fees altogether and pay through new coins.  I will mine for a loss now knowing the value of what i mined is going up.  If asic and other corp mining entities are earning all the new dogecoins minted, the centralization will occur, and the people will find a better alternative.  I want do only good everyday to last forever.

Yes the fees are NOT needed for dogecoin miners since there is always a block reward for the miners.

I therefore think default 0 fee would be very beneficial for increasing real-world use.
Other possibilities may be to make the fee optional, or only charge a fee when more data is sent than is needed ?

Yes I am actually a proponent of this.

With 0 fees, how would you prevent spam attacks on the network? Without fees, it would be trivial and without cost for a bad actor to generate such a massive amount of transactions that the network ceases to function. Zero fees opens up the network to DDoS vulnerability.

Some guys have asked about the possibility of zero fees and others have reminded them of DDoS and spam attacks. Just a quick note about that, if we determine some nonzero amount of minimum fee but reimburse that to the users whenever a block is less than 95% full and otherwise burn it, then the spam attack or sending not-so-urgent transactions during network congestion would be costly. Moreover, this still incentivizes users to schedule their transactions according to their priorities which is one of the desired effects of non-zero fees.

Some guys have asked about the possibility of zero fees and others have reminded them of DDoS and spam attacks. Just a quick note about that, if we determine some nonzero amount of minimum fee but reimburse that to the users whenever a block is less than 95% full and otherwise burn it, then the spam attack or sending not-so-urgent transactions during network congestion would be costly. Moreover, this still incentivizes users to schedule their transactions according to their priorities which is one of the desired effects of non-zero fees.

True, but my understanding is the fee goes to miners. This creates incentive for more hashrate to facilitate transactions and secure the network.

True, but my understanding is the fee goes to miners. This creates incentive for more hashrate to facilitate transactions and secure the network.

Sure! We can consider the block reward for that purpose or we can replace zero fees by a small constant amount for the case that the network is not congested.

Fee's should depend on the rate of transactions. For example, higher transaction rate would result in lower fees unlike lower transaction rates result in higher fees.

Sure! I wanted to keep things simple to convey the idea, but as you suggest, a more delicate approach is to have a temporary price impact depending on the rate of transactions. For instance, zero fee if the block is less than half full and from there we can linearly or exponentially increase the fee as a function of the block size.

minrelaytxfee=.1

Is this the best way to activate lower fees before the fee reduction is built into the client?

Yes the fees are NOT needed for dogecoin miners since there is always a block reward for the miners.

I therefore think default 0 fee would be very beneficial for increasing real-world use.
Other possibilities may be to make the fee optional, or only charge a fee when more data is sent than is needed ?

Yes I am actually a proponent of this.

With 0 fees, how would you prevent spam attacks on the network? Without fees, it would be trivial and without cost for a bad actor to generate such a massive amount of transactions that the network ceases to function. Zero fees opens up the network to DDoS vulnerability.

 What would be a viable alternative to stop a massive flood of microtransactions from grinding the network to a halt? I'm not interested in other attacks for the intent of this. Fees prevent this attack. What's your solution? More nodes?

Plenty of ways to stop a DDoS attack ;) (And many other attacks you wouldn't think of)

Such as? What would be a viable alternative to stop a massive flood of microtransactions from grinding the network to a halt? I'm not interested in other attacks for the intent of this. Fees prevent this attack. What's your solution? More nodes?

Well some ideas off the top of my head would be like any bot attack, increase verification process.  Or, not that this is a smart play- but doing something like capping transactions per wallet ID per hour.  You also assume there isn't any money flowing to the miners, the new coins are a source of miner income.  Especially if the mining can be boiled down to a legit cell phone miner running while sleeping.  :)  "No fee" can also mean .000001 doge if you really need something for tracking purposes.

Plenty of ways to stop a DDoS attack ;) (And many other attacks you wouldn't think of)

Such as? What would be a viable alternative to stop a massive flood of microtransactions from grinding the network to a halt? I'm not interested in other attacks for the intent of this. Fees prevent this attack. What's your solution? More nodes?

Well some ideas off the top of my head would be like any bot attack, increase verification process. Or, not that this is a smart play- but doing something like capping transactions per wallet ID per hour. You also assume there isn't any money flowing to the miners, the new coins are a source of miner income. Especially if the mining can be boiled down to a legit cell phone miner running while sleeping. :) "No fee" can also mean .000001 doge if you really need something for tracking purposes. -also why hasn't it already happened when the coin was .000001 in value?

There's no verification process in any blockchain transaction. You can create a new wallet address for every transaction out, although you need to send from the main wallet to do so. Having fee's increase per rate of transactions per time might be one way to stop spam - free in infrequent transactions, with increasing cost, the more common?
You can't mine on a smartphone.  There was recently a case of a person slowly mining large BCH blocks on a raspberry pi, so it might be possible one day to mine on low level hardware, with software improvements.
People don't tend to spam attack networks unless they are popular. It is something you need to consider. But perhaps having something rate/speed based is a good idea. Another possibility is using something like nano, and making the sending wallet address do a small amount of work.

Oof, this was meant to be "Don't forget to include fee logic in 1.21" but... going to make this into a discussion.


[FLINK-25859][Connectors/DynamoDB][docs] DynamoDB sink documentation

What is the purpose of the change

Add documentation for DynamoDB sink

Verifying this change

Manually copied into the flink-web project and built from source

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented?

Data Stream artifact renders as expected:
Flink 1.16

Flink 1.17

Datastream connector reference looks good
Flink 1.16

Flink 1.17

SQL connector still needs work


YAML Linter

Are we planning to add a YAML linter ? If not can you point me docs how to contribute a new linter?

Are we planning to add a YAML linter ?

I have no such plan.

If not can you point me docs how to contribute a new linter?

You may want to have look it these two existing linters for text and XML files: https://github.com/ec4j/editorconfig-linters/tree/master/editorconfig-linters/src/main/java/org/ec4j/linters


Clarification

Great work on the repo. Was working on something similar but glad I found your repo. Saved me a lot of work.
Just a clarification. In the UserResource.php file you wrote:
'emailVerifiedAt' => $this->email_verified_at,
// Use camelCase so it matches the property on the frontend
// (since login isn't a GET request, the TransformApiResponse middleware isn't applied)

Actually, the reason is not that the request to login is a POST request. The real reason is that the TransformApiResponse is added to the api middleware group and routes like login are in the auth.php file which is loaded via the web.php file which applies the web middleware group by default. So, the api middleware group will not be applied and hence, no TransformApiResponse.
Just wanted to clarify this so there is no confusion.
Again, great work ngl!

Hey, first of all, thank you! I'm glad you find it useful. Yeah, you're so right, I mixed up the behavior of TransformApiRequest with the one from TransformApiResponse, because in the latter there isn't even a validation for the HTTP method of the request. Thank you for the clarification, I will correct the comment so there's no confusion :)


Fixup docstrings for mv and lt

This:

Uses math and code formatting where appropriate
Promotes some comments to docstrings
Ensures dead commented out code does not end up as a docstring
Fixes some typos
Merges docstrings duplicated between cls.__doc__ and cls.__init__.__doc__

Results:
https://external-builds.readthedocs.io/html/galgebra/56/generated/galgebra.mv.html
https://external-builds.readthedocs.io/html/galgebra/56/generated/galgebra.lt.html

Looking at #52, it doesn't appear this will create any conflicts


Consistant invoked

We need to reset the invoked status each time Parsed is called.  Also,
we need to properly set invoked on the appropriate parser depending on
what scenario we're in (see tests)

as mentioned in #2 , you could do this in better way, with the ability to tell whether there is user input. using ParserConfig{DefaultAction: func() {}}

InvokeAction is now accept invoked state as argument, version >= 1.4.1


AutoActivityScope Example Fix

The docs say to use Application but the example uses Activity

Woops !

Thanks a lot ;)


--env-file does not expose variables to detect

In the latest revision of the spec, environment variables are exposed during detection.  At the moment, these environment variable are only exposed during the build phase.  They should be exposed during the detect phase as well.

Looks good:
liberty:pack pivotal$ ./pack-676-osx build myapp --builder packs/samples:0.0.1-rc.490 --buildpack ./test-bp/ --env-file <(echo 'TESTME=pass')
Defaulting app directory to current working directory /Users/pivotal/workspace/cncf-buildpacks/pack (use --path to override)
Using user-provided builder image packs/samples:0.0.1-rc.490
Pulling builder image packs/samples:0.0.1-rc.490 (use --no-pull flag to skip this step)
Selected run image packs/run:v3alpha2 from stack io.buildpacks.stacks.bionic
Pulling run image packs/run:v3alpha2 (use --no-pull flag to skip this step)
Using cache volume pack-cache-7bae996a0e238a80f14b74a61e3178bf
===> DETECTING
Using manually-provided group
[detector] 2019/01/04 16:01:59 Trying group of 1...
[detector] 2019/01/04 16:01:59 ======== Output:  ========
[detector]
[detector] 2019/01/04 16:01:59 ======== Results ========
[detector] 2019/01/04 16:01:59 : pass


Webjobs SDK get started page - issue under Configure app settings

[Enter feedback here]
On the page
https://docs.microsoft.com/en-us/azure/app-service/webjobs-sdk-get-started
Under "Configure app settings", it says:

In Server Explorer in Visual Studio, expand the App Service node under Azure.
Expand the resource group that your App Service app is in, and then right-click your App Service app.

However, when I do 1), the only sub item that is shown is "Open Cloud Explorer". When I open that, there is no "View Settings" there, etc.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2e9e1a8a-6284-a230-061e-7cb27258571a
Version Independent ID: 43390e30-04d6-6d4e-018e-21419dbb11e8
Content: Get started with the WebJobs SDK - Azure App Service
Content Source: articles/app-service/webjobs-sdk-get-started.md
Service: app-service
GitHub Login: @ggailey777
Microsoft Alias: glenga

@mperdeck Thanks for raising the issue. We will investigate and update here.

@mperdeck , We have taken this in our queue and will be making changes as per VS 2019. It may take sometime though. I will go ahead and close the issue for now. Feel free to re-open in case you need further help.


no ui showing

The Plugin is not working for me.
Could it be related to the following ?
issue

The master branch already supported neovim0.6+
Would you share your minimum vimrc and neovim version?

Thanks Ray-X after you confirmed me that the issue can not be related to upgrade of nvim, I checked my configs again.
Something was wrong with my servers, we can close this here.


Add delete rollback source option

Summary
I suggest delete source option when using deploy:rollback.
The reason is same as follow.
When using unicorn and similar servers that do 0 downtime deploys by pre-loading a new set of server app instances - removing the old deployed directory will cause errors until the new ones have booted.
issue #547

set :delete_rollback_source, true  #=> delete
set :delete_rollback_source, false #=> not delete
not set(default) #=> delete (same as current)

Short checklist

[x] Did you run bundle exec rubocop -a to fix linter issues?
[ ] If relevant, did you create a test?
[x] Did you confirm that the RSpec tests pass?
[ ] If you are fixing a bug or introducing a new feature, did you add a CHANGELOG entry?

@leehambley care to comment on this one? Back in 2013 (!) you wrote on #547:

I'd also take a patch to make this configurable via a variable.

Personally, given the fact that the maintainers mostly frown upon use of the rollback feature, I would hesitate making any enhancements to it, even in the form of configuration. There is a workaround, since you can override or clear the deploy:cleanup_rollback task.

BTW, thanks @igaiga for the PR! We'll review and let you know if it is accepted.

On further review, I've decided not to accept this PR. There is a simple workaround, which is to add this to your deploy.rb if you'd like to disable the deleting of source on rollback:
Rake::Task["deploy:cleanup_rollback"].clear_actions


OverflowException in High Memory Detection

Past 7 days we had 6 occurrences of overflow exception.

DiagnosticRole | where EventId == 63003 and TIMESTAMP >= ago(7d) and ExceptionType != ""
| summarize count() by ExceptionType, ExceptionDetails


path-display: {"tail"} is being ignored

I prefer to use path-display: {"tail"} for telescope, but for telescope frecency, this is being ignored and the full path is always displayed

Fixed. Sorry for late. Now configs in telescope.setup is available for frecency, like path_display, layout_strategy, and so on.


mud is a mass noun

cool project bros!

Coverage remained the same at 100.0% when pulling a71d67ccf63d4b02adbfe2b99998cbbcf96084c9 on dimitropoulos:patch-1 into de7b35e700caccfb4e74923d98ab9b40006eda04 on blakeembrey:master.


Display name is empty after facebook login in  v4.1.0b3 bootstrap theme

After successfully logging in using facebook login the display name doesn't show up for that profile.

Is the app at Facebook set to Live? If it is at Test, it won't work.

I'm with the SAME problem , login E Successful more just behind the photo . or the name and other information are not displayed.

Hello all, I was  having this  same problem, I  solved  by  changing the  line 6 in model/service.php to
	`	'full_name' => $fb->getName(),`

I hope  this  helps  someone


Update sbt-scalajs-crossproject to 1.3.0

About this PR
📦 Updates org.portable-scala:sbt-scalajs-crossproject from 1.2.0 to 1.3.0
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.portable-scala", artifactId = "sbt-scalajs-crossproject" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.portable-scala", artifactId = "sbt-scalajs-crossproject" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, version-scheme:semver-spec, commit-count:1

Superseded by #203.


Naming bug

There's a problem when naming dupes with numbers. The names get auto sorted but, for example, 4 is put after 15. It's like the sorting system doesn't understand the existance of numbers bigger than 10, so it reads the first number only, so even 300 is put before 4.

Yah its not a bug. Linux does it too. Prepend your numbers with 0 to prevent. 001, 002, 003, 004

I think the autonamer needs to be updated though.

It doesn't work either by adding 0s in front of it. 04 will be put after 015 anyway. That's a bug, and if it's not a bug, that's coded badly.

You mean when files are displayed in a file explorer? As was already mentioned, the fix is to prepend with zeros. 04 vs 15, or 004 vs 015. The trick is to have the same number of digits.
I'm reasonably sure windows used to do this as well, in older versions such as windows XP and windows 7, but I just tested it and windows 10 seems to properly check if the first few characters are numbers, and sorts the files accordingly.

Forgot to reopen

Yeah windows smartly recognizes numbering. I've yet to use a linux file manager as fast and smart as windows explorer.


Error building on Lind Server

ENVIRONMENT USAGE REPORT

4  dbg-linux-x86-64
4  nacl-x86-64-pic-glibc
Done building NaCl
Building Repy in  to /home/lind/lind_project/lind/repy
'./seattlelib/xmlrpc_client.repy' -> '/home/lind/lind_project/lind/repy/repy/xmlrpc_client.repy'
'./seattlelib/xmlrpc_common.repy' -> '/home/lind/lind_project/lind/repy/repy/xmlrpc_common.repy'
'./seattlelib/xmlrpc_server.repy' -> '/home/lind/lind_project/lind/repy/repy/xmlrpc_server.repy'
Done building Repy in "/home/lind/lind_project/lind/repy/repy"
removed './lind_server.mix.new'
It's the same old story; boy meets beer, boy drinks beer... boy gets
another beer.
-- Cheers
Copying component.h header to glibc:
Building glibc
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/lind/lind_project/src/native_client/tools'
Makefile:75: *** No suitable make binary found..  Stop.
make[1]: Leaving directory '/home/lind/lind_project/src/native_client/tools'
[./src/mklind:551] Error: [function: build_glibc()] [arguments: (nil)].
It took 55 seconds
All done.
make: *** [Makefile:8: all] Error 1

I've asked the IT admin to increase our disk space. I have a small suspicion that everything didn't get loaded because of lack of space.
@neelchauhan and I are going to try and reproduce this once were upgraded. Hopefully this can be resolved soon...

@neelchauhan The diskspace has been upgraded on the server. Can you login and attempt to build lind?

So this is pretty weird, its failing at this point in the native client Makefile
COMPAT_VER := $(COMPAT_VER:4.%=)
ifeq ($(COMPAT_VER),)
       $(error No suitable make binary found.)
endif

But the make version is 4.21 and it's the same on my machine where it successfully builds. Not sure whats going on here.

In the start of the Makefile used for native client it says:
MAKE_VERSION is checked because we need to use the compat version if
make is too new (versions after 4.x fail when building glibc32).
VERSION_TEST := $(MAKE_VERSION:4.%=) ifeq ($(VERSION_TEST),) 	MAKE_COMPAT := $(shell find -H \ 				/bin /sbin /usr/bin /usr/sbin \ 					$HOME/bin $HOME/.local/bin \ 				-mindepth 1 \ 				-maxdepth 1 \ 				-type f \ 				-a \( \ 					-name "make" \ 					-o -name "make-[0-9]*" \ 				\) \ 				2>/dev/null \ 				| sort \ 				| tail -n1) else 	MAKE_COMPAT := make endif ifeq ($(MAKE_COMPAT),)        $(error No suitable make binary found.) endif COMPAT_VER := $(shell $(MAKE_COMPAT) --version | sed -n '1 s/.* \([0-9]\)[0-9\.]*$$/\1/p') COMPAT_VER := $(COMPAT_VER:4.%=) ifeq ($(COMPAT_VER),)        $(error No suitable make binary found.) endif
So it should not work if the make version is 4.21

Ah! This seems like a good hint. You can see we include Make 3.82 here. Which is in response to this older issue that we haven't fixed yet.
It seems like make-3.82 either isn't building or isn't properly downloaded? I suggest you try to figure out why that's happening, and use make-3.82 (the updating make issue is pretty complicated and I hit a substantial roadlblock, this seems like lower hanging fruit to get us up and running!)

@jesings I think we ran into some issues with make when were trying to get this up this summer. Any ideas?

I'm going to close this for now as we're using our internal server.


Implement HEALTHCHECK for the airnode-client container

Implement HEALTHCHECK for the airnode-client image, update the docs to restart the container as discussed here (or feel free to come up with a better way).

There are two scenario in which the airnode-client container can stop working:

The invoke command halts i.e it takes longer than a minute to fulfill requests.
There is some error in the code/directory that causes the invoke command to fail instantly.

In the case of 1. Docker has the ability to tag containers from healthy to unhealthy and we can use something like this  to restart the containers ( I addressed this in the PR).
However in case of 2. Docker does not tag the container has unhealthy and assumes its healthy since it does not throw a non error code.
One way to solve this would be to throw an error code on any unhandled promise exceptions but that would require changing the code and adding a bunch of try catch (or something else) to throw an error code.
Another way would be, is that we write a healthcheck script that pipes in the yarn invoke output and then outputs an errorcode if it detects error in the airnode code this would cause the kill command to run and then docker's restart policy would restart the container.
As it stands I've addressed 1. in the PR above but not 2.

@Ashar2shahid
Related to two:
Have you thought on try to catch on the top level of the application and throw an error there?
Also,
Related to docker-autoheal, are we already considering for long term to run docker in production just with docker or do we prefer to use kubernetes (that have their own thing to recycle unhealthy instances)? @bbenligiray thoughts on this?

@MrAngus666
I thought of that but didn't try that. Something like this in the invoke script would probably work.
process.on('uncaughtException', function(err) {
  console.log('Caught exception: ' + err);
  process.exit(1);
});

I wasn't comfortable with handling it on the top level but this should work.
not really sure how else, one would globally catch exceptions in node, open to suggestions.
Kubernetes seems like overkill for this task, Docker ships with swarm which has the ability to recycle unhealthy containers, although I felt adding a layer on top would be a bit much since autoheal does the same thing.

Sorry I forgot to reply to these

are we already considering for long term to run docker in production just with docker or do we prefer to use kubernetes (that have their own thing to recycle unhealthy instances)?

Currently the main function of this image is to provide an easy to use integration environment and Docker is enough for that.
I was thinking that the goal of healthcheck would be to detect issues originating from the container rather than the node. If a node invocation errors, it doesn't mean that the container is unhealthy and a container restart won't do something that the next invocation won't do anyway (I mean the node already keeps restarting itself). So healthcheck is meant to check problems with the container beyond the node (for example an issue related to the linux image).

This was merged in pre-alpha branch, closing this issue.


Can I use this pipe with angular cli?

I use angular cli.
When I try to build project I get an error:
/node_modules/markdown-to-html-pipe/src/markdown-to-html.pipe.ts:2:0
Import assignment cannot be used when targeting ECMAScript 2015 modules. Consider using 'import * as ns from "mod"', 'import {a} from "mod"', 'import d from "mod"', or another module format instead.

Make the import inside the pipe:
import marked from 'marked';

We will release an update for this pipe shortly.
@virgil-av yes, you have to use [innerHTML] binding, since {{ variable }} will only support text nodes. This is documented in our README.

@Invizible The fix is included in<EMAIL_ADDRESS>

Thanks


New release?

Hi @samthor! Thanks for doing this polyfill. I'm just wondering if it's possible to have a new tag/release here every now and then? The last tag was earlier this year and there have been plenty of commits since then (hence, the bower version getting pulled is pretty old).
Thanks a lot for your time.

Yes! I'd love to. Actually my concern is that right now the release possibly doesn't work in IE9, but I can tag a new one.

Thanks for the motivation. Done!

Awesome! Thanks again. Cheers


Guide on how to setup for production usage

Hello and thanks for the great software. I am trying to set this up on a server but am unsure on how to actually make emails sent be received. I'm assuming I need to set up DNS but have no experience with setting up email server DNS. It would be helpful if the documentation or wiki had a section for setting up the domain / DNS.

https://github.com/flashmob/go-guerrilla/wiki/Deploying-(POSIX-system)

Thanks! The link is broken but I found it in the wiki:
https://github.com/flashmob/go-guerrilla/wiki/Deploying-(on-a-POSIX-system)


AddElementsFromHdfs Reducer doesn't aggregate elements in Accumulo

The reducer is configured to use the Accumulo key, which includes the timestamp. Currently the timestamp is set to the current time in milliseconds, so it is unlikely many elements will have an identical key and actually be aggregated. This will put a lot of load on Accumulo to aggregate the elements and causes a lot of unnecessary data to be passed around.

My preferred way of fixing this is to set the timestamp value to 1 for groups with Aggregation. For groups that are not aggregated we can continue setting it to the current time or a random number.

To fix this we will set the timestamp to 1 for all elements. This field is only used if you set the timestampProperty field in your schema. In this case you will need to populate the field yourself, otherwise the value will be defaulted to 1.

Migration Steps
Important - if you have set the timestampProperty in your schema and are using the Accumulo/HBase store this applies to you.
Previously, if you didn't manually set the timestamp value on an element these stores would set the value for you to the current time. This has caused several problems and therefore will no longer happen. If you want to the current time or a different value you will need to set it yourself.
In Accumulo the default timestamp value will now be 1.
In HBase the default timestamp value will now be a random value based on the current time and a random number.
Setting the timestampProperty field in a schema for these stores is now deemed an advanced feature and should only be used if you really understand the effects. We recommend you don't use the timestampProperty in the schema.

Fixed as part of #1565.

Merged into develop.


Enable DT-based sanity-check test filtering

Is your feature request related to a problem? Please describe.
In sanity check we have efficient way to whitelist or to exclude (filter out) tests/test-suites on certain platforms based on

Kconfig switches
ARCHitecture or platform target names
required RAM / Code footprint (with respect to platform capabilities)

We would like to have additional filtering options based on HW capabilities of the platforms that are expressed via Device Tree nodes. This will prevent tests from running and, inevitably, failing, on platform which do not have the required HW capabilities to run those tests.
Describe the solution you'd like
Just to give an example: in some configurations, certain User-space test-suites require a minimum number of ARM MPU regions to execute properly. The number of MPU regions is described by a DTS node in the SoC .dtsi header. We would like sanity check to detect and exclude such tests from running on platforms that do not have the minimum required number of MPU regions.

@nashif @PerMac FYI
If there is already a related discussion about this, please, comment and close the issue.

We have now quite a few of dt_ helpers that can be used in filter. Closing, re-open if needed.


[MERGE LAST] Final PR

Codecov Report

Merging #171 (fcc9155) into master (9dfa1f1) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #171   +/-   ##
=========================================
  Coverage     68.45%   68.45%
  Complexity      690      690
=========================================
  Files           108      108
  Lines          2292     2292
  Branches        233      233
=========================================
  Hits           1569     1569
  Misses          616      616
  Partials        107      107

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9dfa1f1...fcc9155. Read the comment docs.


Compiled program is not working.

Hi,
I just compiled this program as you said in README. I got an exe file with 1.68 MB size. But when i run the file, the window is suddenly vanishing. I couldn't read anything. Any idea ? I am using windows 10 x64.

Hi,
With a little effort I was able to compile it. The problem was that the lack of  "-L/SUBSYSTEM:WINDOWS" compiler switch. It was not added. Adding that switch to your Read Me will also be useful to others.
Now let's talk about the program. I was expecting a file open dialog to select the source file. But the program requires me to type the full file path. There is a slight problem with the position of the cursor while typing.
Is it possible to add a feature for a file open dialog ? If we include an INI file, we can save the frequently used file paths in it. That will be handy.


Support commonjs dependencies, e.g. class-transformer

We use ng-packagr for packaging a Angular 4 Module.
Unfortunately it does not work with the import of class-transformer. It states the nodemodule/class-transfomer does not define / export plainclass.
If we use EmptyObservable from Rxjs the same problem occurs.
Is there a solution for it?
Thanks.

A link to the class-transfomer project.
https://github.com/pleerock/class-transformer

What exactly is not working?

We get the following error:
'classToPlain' is not exported by node_modules/class-transformer/index.js Error: 'classToPlain' is not exported by node_modules/class-transformer/index.js
Import in the service is:
import { classToPlain, plainToClass } from "class-transformer";
and the ng-package.json :
{     "$schema": "./node_modules/ng-packagr/ng-package.schema.json",     "src": "src",     "dest": "dist",     "workingDirectory": ".ng_build",     "lib": {         "entryFile": "app/core/core.module.ts"     } }

Can you please provide more context?
Can you run the build with DEBUG=true env variable? E.g. in pcakge.json:
  "scripts": {
    "build": "DEBUG=true ng-packagr"
  }

Is the issue caused by rollup? If yes, is this an issue with class-transformer because it does not support ES2015 modules?

We get the following debug message:
[debug] rimraf /home/project_wizard_ui/dist
[debug] rimraf /home/project_wizard_ui/.ng_build
[debug] processAssets /home/project_wizard_ui/src to /home/project_wizard_ui/.ng_build/ts
[debug] render stylesheet /home/project_wizard_ui/src/app/app.component.css
[debug] postcss with autoprefixer for /home/project_wizard_ui/src/app/app.component.css
[debug] render stylesheet /home/project_wizard_ui/src/app/project-steps-activation/project-steps-activation.component.scss
[debug] rendering sass for /home/project_wizard_ui/src/app/project-steps-activation/project-steps-activation.component.scss
[debug] postcss with autoprefixer for /home/project_wizard_ui/src/app/project-steps-activation/project-steps-activation.component.scss
[debug] render stylesheet /home/project_wizard_ui/src/app/project-steps-partner/project-steps-partner.component.scss
[debug] rendering sass for /home/project_wizard_ui/src/app/project-steps-partner/project-steps-partner.component.scss
[debug] postcss with autoprefixer for /home/project_wizard_ui/src/app/project-steps-partner/project-steps-partner.component.scss
[debug] render stylesheet /home/project_wizard_ui/src/app/project-steps-personaldata/project-steps-personaldata.component.scss
[debug] rendering sass for /home/project_wizard_ui/src/app/project-steps-personaldata/project-steps-personaldata.component.scss
[debug] postcss with autoprefixer for /home/project_wizard_ui/src/app/project-steps-personaldata/project-steps-personaldata.component.scss
[debug] render stylesheet /home/project_wizard_ui/src/app/project-steps-vehicle/project-steps-vehicle.component.scss
[debug] rendering sass for /home/project_wizard_ui/src/app/project-steps-vehicle/project-steps-vehicle.component.scss
[debug] postcss with autoprefixer for /home/project_wizard_ui/src/app/project-steps-vehicle/project-steps-vehicle.component.scss
[debug] render stylesheet /home/project_wizard_ui/src/app/spa/spa.component.scss
[debug] rendering sass for /home/project_wizard_ui/src/app/spa/spa.component.scss
[debug] postcss with autoprefixer for /home/project_wizard_ui/src/app/spa/spa.component.scss
[debug] ngc /home/project_wizard_ui/.ng_build/ts/tsconfig.lib.json, { basePath: /home/project_wizard_ui/.ng_build/ts })
[debug] re-mapping sources for /home/project_wizard_ui/.ng_build/ts/wizard_core.js
[debug] rollup /home/project_wizard_ui/.ng_build/ts//wizard_core.js to /home/project_wizard_ui/.ng_build/undefined/project-wizard-core/wizard_core.js (es)
BUILD ERROR
'classToPlain' is not exported by node_modules/class-transformer/index.js
Error: 'classToPlain' is not exported by node_modules/class-transformer/index.js
at error (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:170:12)
at Module.error$1 [as error] (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:8306:2)
at Module.trace (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:8407:9)
at ModuleScope.findDeclaration (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:7990:22)
at Scope.findDeclaration (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:5805:39)
at Node.bind (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:6335:28)
at /home/project_wizard_ui/node_modules/rollup/dist/rollup.js:5599:50
at Node.eachChild (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:5613:21)
at Node.bind (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:5599:7)
at Node.bind (/home/project_wizard_ui/node_modules/rollup/dist/rollup.js:6353:23)
This is the tsconfig from class_transfomer :
{
"version": "1.8.0",
"compilerOptions": {
"outDir": "build/es5",
"target": "es5",
"module": "commonjs",
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"sourceMap": true,
"noImplicitAny": true,
"declaration": true
},
"exclude": [
"build",
"node_modules"
]

So I think commonjs is maybe the problem?
Is there a possibility to map the commonjs to es modules like
https://github.com/rollup/rollup-plugin-commonjs
?

Hm, ok. Would it be possible to reproduce this w/ one of the samples ion the integration folder?
From first look, it should be relatively easy to add the plugin to rollup. Just the question is: does it break anything else?
https://github.com/rollup/rollup-plugin-commonjs#usage
https://github.com/rollup/rollup-plugin-node-resolve#using-with-rollup-plugin-commonjs

Hi @sforner405, have you tried to add "class-transformer/index": "class-transformer" to externals in ng-package.json ?

Hi @DDeis ,
unfortunately I ad still no time looking at the problem again, but I will do it this week and give feedback here.

Ok. So we have progress here.
A quick recpature of #83:

in a library, we do not want to include the dependency in the generated bundle
the dependency should be stated in peerDependencies
consumers of the library are resposible to add a correct dependencies section satisfying peers
reason is: a dependency should be included only once in an app's bundle so the library (and thus ng-packagr) MUST NOT include it in a bundle; they just need the dependency for compile-time validation.

If you have any uddates on how commonjs supported can be implemented, let me know!

I think this probably more likely falls under that workign with third party dependencies, but I cant comment there... to be able to reference / wrap ngx-datatable (@swimlane/ngx-datatable) with my prior build configuraiton, I'd reference from libraries package.json as a peerDependency, but also had to add to my rollupconfig
plugins: [
    nodeResolve({ modulesOnly: true, jsnext: true, module: true }),
    commonjs({
      include: ['node_modules/rxjs/**', 'node_modules/@swimlane/**']
    })
  ]

With ng-packager, it seems like referencing as purely peerDependency, with nothing in externals, kinda works... at least ng-packager successfully compiles... but when trying to use my wrapping component, it is trying to resolve that 3rd party lib in a really wonky way.
I tried both with and without this
 "lib": {
    "entryFile": "public_api.ts",
    "externals": {
      "@swimlane/ngx-datatable/index": "@swimlane/ngx-datatable"
    }
  }

And both situations compile library wise... but consuming I get this error when trying to build test app
ERROR in ./dist/design/design.es5.js
Module not found: Error: Can't resolve '@swimlane/ngx-datatable/index' in 'C:\Users\user\Source\Repos\FrontEnd\dist\design\@my'
<EMAIL_ADDRESS>27:0-67
 @ ./src/app/app.module.ts
 @ ./src/main.ts
 @ multi ./src/main.ts

@ronnyek Gosh, now I understand!
This is same as #101. Cause is somewhere in ngc and tsickle.
I can't really tell why sometimes the app builds still works (there are several app builds that seem to work @ngx-translate/core/index...) and why sometimes it does not.

@dherges is there an existing work around for this? I tried something along the lines of this:
"@swimlane/ngx-datatable/index": "@swimlane/ngx-datatable",
"@swimlane/ngx-datatable": "@swimlane/ngx-datatable"
After reading somone suggesting something like that for ngx-translate. Should I just disable annotateForClosureCompiler?

Hi @ronnyek,
you cannot disable annotateForClosureCompiler as this is setting us automatically set during the build. It is a best practice reco from Json Aden's talk (see project readme).
Please let's discuss this further in #101