ERC777 implementation and security clarifications

Those are merely questions and clarifications to better understand the decisions behind the ERC777 implementation. Please don't consider them as critique. We are looking to use your ERC777 implementation code and just want to be confident about it and to make sure any problems, if there are any, are discovered/discussed/understood as early as possible.

In transferFrom why is _transfer called before lowering allowance and _approve? https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC777/ERC777.sol#L123
I checked that the same happens in ERC20. Doesn't it sound safer to first adjust allowance and only then perform the transfer (external call)? (Checks-Effects-Interactions pattern)

Why burn doesn't have limited access (token creator only)? why to allow anybody to burn their tokens? it influences the token economics https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC777/ERC777.sol#L134
maybe by default to let nobody (or only token creator) burn tokens and to add "Burnable" interface which adds the ability for anybody to burn tokens?

Why burning tokens is done by sending them to address(0) instead of some other way (such as a "burnedTokens" counter)? The discussions in https://github.com/ethereum/EIPs/issues/156 and in a few other places show that many people mistakenly sent tokens to address(0) and are looking for ways to now recover them. So knowingly to continue sending tokens to address(0) by design for burning purposes seems undesirable, no?

IERC1820Registry (0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24) and TOKENS_SENDER_INTERFACE_HASH (0x29ddb589b1fb5fc7cf394961c1adf5f8c6454761adf795e67fe149f658abe895) and TOKENS_RECIPIENT_INTERFACE_HASH (0xb281fc8c12954d22544db45de3159a39272895b169a852b314f9cc762e44c53b) and "ERC777Token" and "ERC20Token" are all hardcoded into the token contract without a way to modify them. Is that a good idea? We are all aware that new critical bugs are discovered in contracts very often, some because of solidity modifications or new eips and some because of new attack ideas. Redeploying a token in a new address (redeploying in an old address using things like CREATE2 losses trust) requires a lot of explanations to the users who own the token or who are looking into buying the token. So maybe there should have been provided some alternative secure mechanism instead of hard-coding those things just in case something changes?

How do the calls to _callTokensReceived and _callTokensToSend go hand in hand with the Checks-Effects-Interactions pattern? For example in the _send function _callTokensToSend is called before balances modifications. Same in _burn and _mint.
In this article by OpenZeppelin CTO: https://blog.zeppelin.solutions/onward-with-ethereum-smart-contract-security-97a827e47702
in the "Order your function code: conditions, actions, interactions" section he gives an example where the event emitting is inserted under "2. Effects" before the "3. Interactions". So why _send, _burn, _mint emit the events in the end of the code?

Since _totalSupply is private and is not set/increased anywhere other than in the internal _mint, it means that initial supply is expected to be set by an inheriting contract in the constructor by calling _mint?

The implementation of _callTokensReceived forces receiver to either be an EOA or to implement ERC1820/ERC165. So what happens for multisig wallets? The most popular of them at this time is gnosis. Will it not be able to hold the ERC777 tokens? https://github.com/gnosis/MultiSigWallet/blob/master/contracts/MultiSigWallet.sol I am not sure that even the newer gnosis safe implements that https://github.com/gnosis/safe-contracts/tree/development/contracts
since multisig wallets are important for holding the initial tokens funds, this seems like a critical matter for them to support the ERC777 implementation or otherwise for security reasons, it will be better for token creators to create ERC20 supported by multisig wallets than to create ERC777 without support from multisig wallets.

_callTokensReceived uses extcodesize to decide if the address is a contract so if _mint is called at the constructor of the contract then the test will pass and the contract will be able to get tokens while other tokens after the contract creation will not be able to be sent to it if it doesn't implement the desired interface.

I can answer a few of these questions as apply to the spec rather than the implementation.

Any token holder can effectively burn tokens by sending them to a known inaccessible address (e.g. 0xdead).  However, actually burning tokens can and does reduce total supply as this is logically consistent with burning.

ERC-777 specifically disallows sending of tokens to 0x00.

The hashes are identifiers and there is no point at which they would need to be changed.  The ERC-1820 address is a known address; if ERC-1820 were found to have issues a new standard could supersede it but there is no guarantee it would be directly compatible with ERC-1820 and as such it would most likely require a separate token contract rather than a simple change of address.

total supply should be decremented when burning tokens.

@mcdee Thanks for your comment.

Would a "forced burn" (sending to 0xdead) have same psychological effect on the market and economics as an explicit burn using burn function which decreases total supply and makes EVERYBODY aware that a burn occurred?
I speak about the implementation of _burn function which sends the tokens to 0x00 https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC777/ERC777.sol#L390
as compared to other possible implementations which could just decrease total supply and user balance without calling _callTokensToSend and Transfer event. Why does _burn call _callTokensToSend and Transfer event?
You are saying that if a bug is found in ERC-1820 registry contract then ALL ERC777 tokens would be required to redeploy? This would cause a chaos to token holders (especially non-technical ones) as compared to providing some upgradability behavior in regards to the ERC-1820 address. I understand your argument however I think a more common un-addressed scenario is a simple backward-compatible bugfix upgrade required for ERC-1820 contract which will not break all ERC777 contracts.
I am not sure what did you address by this statement. If you speak about _burn implementation then my question was why is _callTokensToSend called before total supply and balance changes (violating the Effects-Interactions pattern it seems).

Providing a bun() function that decreases total supply is a better solution as total supply simply states the actual total supply.  I'm unqualified to comment on the psychological effect on the market.

That function does not send tokens to 0x00.  If it did it would not be ERC-777 compliant.  Calling tokensToSend() and emitting Transfer() are parts of the spec, but neither of these send tokens to 0x00.

No, I'm saying that superseding ERC-1820 would make no difference to existing contracts as they are already registered with ERC-1820.  Just updating the address of the registry contract would not be effective because there would need to be a full update process (unregistering from ERC-1820, re-registering with the new registry contract, having to check both old and new registries for implementers, handling clashes) for it to continue to work.  Making the registry address variable does not help with these implementation details

The item labeled 5 should have been for 6; apologies.

Thanks for your answers,

By "sending to 0x00" I refer to the call of "_callTokensToSend" and the emission of "Transfer" event (which, because of the naming, make the code reader interpret it as "sending to 0x00" I guess). Since the spec is at a very early stage, of course I am hoping that there is a good explanation for everything and that there are 0 problems and 0 vulnerabilities, but I still ask the questions even if the spec claims its "ok" just to make sure. In this audit I was trying to understand the reasoning behind the implementation including things like this (which can introduce problems for coders which would expect _callTokensToSend or Transfer to be called only for transfers because of the naming. They are not called "_callTokensToSendOrBurn" "TramsferOrBurn"). Also I read in the spec that it says on the one hand that tokensToSend can block the sending operation using revert and on the other hand "The tokensToSend hook MUST be called before the state is updated—i.e. before the balance is decremented". Why does the spec force the tokensToSend hook be called before the state is updated if the revert will revert the state change anyway? might introduce reentrance issues by calling external contract before state modifications, don't you think? If the reason for the external contract to have access to state BEFORE the changes then it could be achieved by passing that state as parameter to the hook or by assuming in the hook that state was modified and subtract the appropriate value to get the previous state if it is necessary for the hook calculations.
Do you refer to a bugfix in the ERC-1820 registry contract (pointed by the hardcoded address in ERC777 open-zepplin implementation) as "superseding ERC-1820"?
You are right, changed my wording from "modified" to "set/increased" now. The question is still valid.

--
Another point arose after reading https://www.wealdtech.com/articles/understanding-erc777-token-contracts/ and https://www.wealdtech.com/articles/understanding-erc777-token-operator-contracts/:

Basically from attacker perspective the _defaultOperators allows a full backdoor on the token in the sense that for any token buyer to trust a token they have to audit any contract listed in _defaultOperators and not only the token contract itself, correct?

Note1: Also "token operator contract can be used with any ERC-777 token and only a single copy needs to be deployed on the blockchain" introduces even more risk in the sense that many tokens creators just copy mindlessly other contracts code which can make one vulnerability in some token operator contract affect multiple deployed ERC777 tokens which use the contract. In this perspective it is great that there is a way to revoke default operators however if an attacker will find a vulnerability in an operator then he might utilize the exploit simultaneously on all affected tokens before they have a chance to revoke him. This DOES increase the attack surface by encouraging different tokens to use common operators contracts. I guess maybe the benefits are bigger than the risk in the minds of the creators. I see the final statement in the second article confirms this: "Any weaknesses in token operator contracts can be magnified when the same token operator contract is used by multiple token contracts. Careful auditing of token operator contracts is highly encouraged.".
Note2: Some of my statements are based on my security research and security code review background (not specifically for the blockchain however security attacks in different fields have common grounds).

The Transfer() event is for ERC-20 compatibility.  A pure ERC-777 token would not emit this, as it has its own Burned() event that is more explicit.

tokensToSend() is a hook that acts before state changes, as per its name (and as opposed to tokensReceived() which is a hook after state changes).  As such it can examine state (account balances) prior to the transfer and decide if the transfer is to proceed or not.
It is also important to understand that the contract in which tokensToSend() is called is specified by the token holder.  As such a number of the guidelines around C-E-I can be relaxed (or alternatively you can think of tokensToSend() as part of the check phase; same end result).

any changes to ERC-1820 would cause a new contract to be deployed; there is no way of putting in changes and retaining the existing address.

As to your point 9), the short answer is "yes" but the important point is that due to the separation of concerns it is far easier to audit a few simple token operator contracts than an entire token contract as would be the case with ERC-20.

Also "token operator contract can be used with any ERC-777 token and only a single copy needs to be deployed on the blockchain" introduces even more risk in the sense that many tokens creators just copy mindlessly other contracts code which can make one vulnerability in some token operator contract affect multiple deployed ERC777 tokens which use the contract.

More risk in having a single, well-examined and audited contract than having everyone write their own?  The purpose is to minimise risk, not to eliminate it.  If people want to write their own token operator contracts they are of course welcome to, but allowing shared contracts provides an alternative that in the majority of cases will be safer for token holders.

You mean that redeploying ERC-1820 at a different address for a bugfix will have to introduce a new ERC number and will be considered "superseding ERC-1820"? It can't still be ERC-1820, just with a bugfixed new address redeployment? Because if it can then my argument about allowing upgradability for that contract address seems valid (by the way the new CREATE2 opcode CAN actually allow redeploying in same address as explained here: https://blog.ricmoo.com/wisps-the-magical-world-of-create2-5c2177027604 , although it is unrelated to the discussion here).

Fixed links*

CREATE2 was not used to deploy ERC-1820 and cannot be used to redeploy it in case of changes.  Any changes would make it something other than ERC-1820.  And as above just changing the address of the registry within a token contract would end up with a broken implementation unless a number of additional steps were also taken by the token contract to migrate entirely to the new registry contract (and even then it would not remain an ERC-777 compliant contract, as ERC-1820 is mandated within the ERC-777 spec).

@mcdee Thanks for all the answers.
Regarding original questions just to clear out for anybody reading this, what is left unanswered are questions number: 1, 6, 7, 8.

Wow, this is a great discussion, thank you @guylando and @mcdee!

6. Since _totalSupply is private and is not set/increased anywhere other than in the internal _mint, it means that initial supply is expected to be set by an inheriting contract in the constructor by calling _mint?

Indeed, there's no concept of 'initial supply' in our implementation of ERC777, but if you do need an initial holder, calling _mint in the constructor will achieve that. You can read more about different supply mechanisms using our API in this forum post

7. (UPDATE: I see the validation in _callTokensReceived  does not apply to the ERC20 functions which pass "false" to the validation boolean. Can you confirm it that this makes ERC777 work with multisig wallets which support ERC20?) The implementation of _callTokensReceived forces receiver to either be an EOA or to implement ERC1820/ERC165. So what happens for multisig wallets? The most popular of them at this time is gnosis. Will it not be able to hold the ERC777 tokens? https://github.com/gnosis/MultiSigWallet/blob/master/contracts/MultiSigWallet.sol I am not sure that even the newer gnosis safe implements that https://github.com/gnosis/safe-contracts/tree/development/contracts
   since multisig wallets are important for holding the initial tokens funds, this seems like a critical matter for them to support the ERC777 implementation or otherwise for security reasons, it will be better for token creators to create ERC20 supported by multisig wallets than to create ERC777 without support from multisig wallets.

Our ERC777 contract implements ERC20 compatiblity as described in the EIP, which relaxes the requirement on recipient contracts to implement the ERC777TokenReceiver, but only when using the transfer method. So yes, any contract can hold this ERC777, as long as transfer is used and not send.

8. _callTokensReceived uses extcodesize to decide if the address is a contract so if _mint is called at the constructor of the contract then the test will pass (since  extcodesize returns 0 at the constructor) and the contract will be able to get tokens while additional tokens after the contract creation will not be able to be sent to it (using the ERC777 new functions) if it doesn't implement the desired interface.
   https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/utils/Address.sol#L23
   https://ethereum.stackexchange.com/questions/15641/how-does-a-contract-find-out-if-another-address-is-a-contract/15642#15642

This is 100% correct, but it's important to keep in mind that the purpose behind this requirement is to help avoid having tokens locked in contracts. A more thorough check is as far as I know not possible, and I think the EIP authors made the right call by using extcodesize.

1. In transferFrom why is _transfer called before lowering allowance and _approve? https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC777/ERC777.sol#L123
   I checked that the same happens in ERC20. Doesn't it sound safer to first adjust allowance and only then perform the transfer (external call)? (Checks-Effects-Interactions pattern)

This is actually a great point! ERC20 doesn't have this issue because transfer does not perform an external call, but this may happen here. I don't think this is a security concern, but the EIP specifies that tokensToSend must be called before the state is updated, and tokensReceived after. Our implementation does not currently adhere to this, at least when it comes to ERC20 allowances. @frangio do you agree with this interpretation of the EIP?

Yes, I agree, we're gonna have to change our implementation to update allowances before calling tokensReceived.
Thank you for the review @guylando! It helps a lot. Let us know if you have any more questions or comments.

No more questions or comments, although some of my points were partially answered or I do not agree with the decisions (in point 3 deciding if publicly allowing anybody to decrease total supply is maybe worse psychologically/economically than letting users send tokens to 0xdead, in point 4 I am not convinced that hardcoding the 1820 registry address is a good idea in light that any minor fix of 1820 which will be uploaded to a new address will force ALL ERC777 TOKENS which are based on openzeppelin to redeploy which is a mass).
Anyway my main goal was to raise awareness and to understand the decisions so this was achieved it seems so I am closing this unless you want to keep it open for the change you wrote that you are going to do.

Also regarding the decision on allowing what I wrote in point 8, need to put a lot of thought if this allows some exploit or not. Sounds dangerous but I have no example for an exploit (dangerous because it is the type of things that everybody can think is safe until there comes someone who thinks of some cool exploit which nobody thought about before. the exploit could utilize some existing ethereum/solidity behavior or some future behavior which will come in the future).

I'm not sure how point 8 could lead to an exploint: there's no inherent issue with a contract that is not an implementer having tokens. Such a thing could be achieved without resorting to the constructor trick: a contract may register an implementer, receive the tokens, and then unregister it.
The intent behind this requirement is to prevent contracts that are unaware of 777's existence (and therefore lack any mechanisms to transfer the tokens out of these contracts) from receiving tokens in the first place, since they would be effectively burned, but it is still possible for a contract to implement the interface and have no way of transferring them, getting us back to square one. The requirement is not a security one, but an attempt to avoid unfortunate scenarios (that cannot be 100% avoided).

@frangio we want to use the ERC777 but waiting for the changes you wrote. Any idea when they will be merged to this repo or can you suggest on the exact changes which we should manually do so that our changes will be consistent with your changes?
Thanks

@guylando They will be available later today in a new release candidate. The final 2.3.0 release will be available later this week or early next week.

@guylando you can use the latest release candidate, including these changes, by running
npm install openzeppelin-solidity@next

@nventuro Thanks!

Note that in https://github.com/OpenZeppelin/openzeppelin-solidity/releases/tag/v2.3.0-rc.3 the link to the code of ERC777 is outdated and does not point to the latest code.
I left some more comments about ERC777 code at https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1751:
https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1751#issuecomment-492431424
https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1751#issuecomment-492436903
https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1751#issuecomment-493136584

Anyway, good job on the quick implementation and fixes!

@guylando

I would suggest not to waste time on that until ERC777 gets more support

Yeah this has been our thought process as well. We only made sure that a future opt-out API would be feasible in terms of backwards compatibility.

I believe there is a difference between sending to irrecoverable address and burning which decreases total supply because the first is not visible to the non-technical investors while the second one will change the token total supply on coinmarketcap which might cause undesired reaction from non-technical investors who follow the token in coinmarketcap and similar tools

Accidentally found a "proof" of the difference between burning and sending to an invalid address:
https://github.com/ethereum/EIPs/pull/867#issuecomment-365746101
https://github.com/ethereum/EIPs/pull/867#issuecomment-365747423
where the difference is enhanced in such discussions as of the retrieval of stuck tokens which wouldn't be discussed about burned tokens

So from legal point of view there is more claim to the owner of the tokens that he still owns legally the tokens which were sent to an invalid address than for him to claim he owns burned tokens.


JMX Refactor + Add healthchecks

Extract JMX into a new module, and add HealthCheck support.
Contributions for this are welcome, it may not happen if I have to find time for it.
See #92 #149 #830

:+1: for continued jmx support.
it's used heavily at the day job and i find it extremely useful for random side projects.

Same here! Having health checks available via JMX would enable us to easily extend our monitoring.

+1 for continued JMX support--came here specifically looking for health check support.

+1 to what @ariens said

Alright, JMX definitely stays.

I am trying to fix this issue. There are two options

Extend current JMXReporter with a new static forRegistry method with HealthCheckRegistry argument  and a new builder
A new HeathCheckJMXReporter class which will handle health check reporting.

I prefer option 1. Let me know your comments.

on this high level both sound kind of like the same for me. The second one sounds a bit more decoupled.

On exploring further I see that I cannot implement option#1 since health check is a different module. I am going ahead with option#2.

Woah, this is great to hear @sivasamyk. Thank you very much! :)

Hi @sivasamyk! Thanks for working on this! I agree with option #2. If you aren't already I'd love to see JMXReporter and JMXHealthCheckReporter extracted to their own module, metrics-jmx.

sure, let me try it

Also moving JmxAttributeGauge class from metrics-core to metrics-jmx module. Any comments?

That's a tough one. Sure why not.

Hi All,
Just checking in to see what the current status of "JMX support for HealthChecks" is.
I have a use case - use the Healthcheck module to expose a GREEN/RED/YELLOW-like status in JMX, with ability to manual re-run Health Checks from JMX console.  Keeping in mind that it can be expensive to run these tests, especially on a production system under load.
I'm considering using a Cache Gauge to work around the existing limitations.  This was suggested in a google groups thread that I'm now unable to find...
Any and all advice greatly appreciated.
Thanks,
Rob

I found the post:
https://groups.google.com/forum/#!msg/metrics-user/-w4vMI_hKdE/UTXtdnzc7CcJ
I was just hacking around this very problem this week so I have a pretty good idea what is going on here.
The JMX Reporter has to register mbeans for each value to report.  The central problem here is Healthchecks do not have a value.  Instead you need to execute a healthcheck, get a Result, and then publish the result.  One reason no one has coded this up is in many cases these checks are non-trivial and not something you want to run too frequently.
In the end it boils down to :
Metrics are a snapshot which can be published trivially.
Healthchecks are a test to execute with an undefined performance impact.
Once I understood the problem better I decided I did not want to publish my own healthchecks this way.  i chose instead to use a Console or Slf4jReporter (I wrote my own) because that also let me track healthcheck status over time.  Where JMX only gives you that if you have something attached and recording state when the problem occurs.  It is not as useful for debugging after the problem has occurred.
If you still wish to publish healthcheck but want to limit the published rate to reasonable frequency one workaround is to create a CachingGauge at the same time you create the healthcheck and use it execute the healthcheck and publish the state at a predetermined rate so that it can be viewed along side other metrics.  It isn't ideal but it is less work than adding HealthCheckRegistry Listeners, adding a new mbean for each healthcheck and dealing with possible performance issue of running checks frequently.

What are the odds that JMX will see the 4.0 version? JMX reporting was found to be the most suitable in the situation with many little services for monitoring with Zabbix.


Add ballerinax/amadeus.* connectors

Description
Add Amadeus connectors
Type of change

[X] New feature (non-breaking change which adds functionality)

Test Configuration:

Ballerina Version: 2201.0.3 (Swan Lake)
Operating System: Ubunutu
Java SDK: Java 11

Checklist:
Changes to OpenAPI definition

[x] Modified info section of the OpenAPI definition file - Example

description - what the connector is about
x-ballerina-init-description OpenAPI extension - connector initialization details
x-ballerina-display OpenAPI extension - connector name and path to the connector icon

Changes to connector module

[X] Added license header at the top of each .bal file.
[X] Added Package.md as per the guide here
[X] Added Module.md for the module of the  connector as per the guide here
[X] Added connector icon to the root of the connector. Icon needs to be a png of 200x200 px size with name icon.png
[X] Added Ballerina.toml file with following information. For keywords refer to guide

Verifying connector module

[X] Compiled the connector successfully with the targeted ballerina version.
[X] Conducted smoke tests on the connector (Recommended when OpenAPI definition is obtain from an unofficial source)

Security checks

[X] Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines?
[X] Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets?

Latest commit was to mark some fields as required https://github.com/ballerina-platform/openapi-connectors/compare/cb5a955dee49aa04cb8474dcbf1d5f73991a9a65..6f5de85752e37be203c621706c67a8e310d11d54


Add Monster Attack Game logic

Add logic to the monster attack game so that the player can battle different monsters until either all monsters are dead or the player is dead.

Completed with pull request #6.


License conflict w/ EULA

Describe the bug
It appears there is a conflict with LICENSE and EULA.
There is a nebulous "Stable versions of ownCloud Infinite Scale are subject to EULA". "Stable versions" is not defined.
I do not doubt 3 years ago OCIS was Apache.  But it really can not be considered Apache V2  w/ included EULA.
See the end of https://github.com/owncloud/ocis/blob/master/LICENSE
Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

The above Apache 2 is quite clear that is conflicts with the EULA.
FWIW, Nuxeo does a fairly good job, minus the double negative usage, on their license page.
BTW:  I think OCIS is really cool.  Kudos!
Steps to reproduce
Open up the LICENSE.  Open up the EULA.  Read.  Or contact ASF or FSF or what not.
Expected behavior

License to not be Apache
Free for non-commercial usage, open core, or some such thing.
Describe very clearly licensing and spell out "Stable versions"

Actual behavior

Mix of Apache license and EULA
Owncloud OCIS website trumpets Apache-v2

Agreed, this EULA is in direct conflict with the license. If you want to make this proprietary, at least be honest about this. Additional terms like this are total BS.

Let me start with the idea: ownCloud Infinite Scale (server side!) is Apache licensed in all its source code. Binary builds are also Apache with one exception, the QAed version of each stable release - currently that is 3.0 ...
As we wanted to make those builds still available through github we might have added some confusion. I can't follow the expected behavior above ...
So first I hope to be clear on the expected behavior with my above statemt ... is that correct? Then we can check where there is confusion and how to solve it.

Binary builds are also Apache with one exception, the QAed version of each stable release

Stable versions are what 99.9% of users are interested though. So binaries are effectively proprietary with the exception of development builds..
This EULA is trivial to work around, but it will still alienate the FOSS community. It's your prerogative I guess, but to me this seems like a major mistake for such an early stage project.

Please check https://github.com/owncloud/ocis/pull/6755 for more clarification on the topic.
Note that the EULA is only valid for builds provided by ownCloud GmbH, and allows even commercial use widely.
Usage of the source code can obviously not be limited. Also note that the builds of Infinite Scale contain a mix of licenses like AGPL for the web frontend and Apache2 for the backend.

If ocis server is fully apache 2.0 license, why there is the EULA contained in the github ocis Server repository?
Here:
https://github.com/owncloud/ocis/tree/master/assets
For me that's causing trouble in terms of figuring out, whether ocis server is really open source. Thatswhy I'd rather not touch ocis at all since not clearly stating it's open source commitment.
Requests:

I request you remove all traces of EULA from the ocis Server Sources, so there's no doubt that only apache 2.0 License is the
Can you clarify what the license of the ocis desktop app and ocis mobile app is?

Thanks a lot!

If ocis server is fully apache 2.0 license, why there is the EULA contained in the github ocis Server repository?

Because binaries are published via this repo as well.

Can you clarify what the license of the ocis desktop app and ocis mobile app is?

Please check the individual repositories for that.
https://github.com/owncloud/client
https://github.com/owncloud/ios-app

I'm unsure if this is the appropriate place to discuss this issue, but I do not know where there is a better place to bring this on the table.

If ocis server is fully apache 2.0 license, why there is the EULA contained in the github ocis Server repository?

Because binaries are published via this repo as well.

Ok. I understand that's a simple practical reason to have it that way.
At the same time, I assume the sole existence of this EULA document within this repository creates doubt and ambiguity about the licensing of the project and very likely causes damage to the reputation of this open source project within the aspect whether the project will stick to the open source path on long term.
I'm judging the situation that the people in the linux environment - including me - lost trust in owncloud - in the company and therefore in the project too - since the fork of nextcloud happened. What's regarding myself, I heard that the owncloud company is all about business and money (preconception) but I'm curious, if that is changing.
So I think it's vital for the company and the project to take every opportunity to regain or build up trust and I again recommend and request to remove that EULA document from this repository. Perhaps a seperate repository with the enterprise related stuff maybe a solution.

At the same time, I assume the sole existence of this EULA document within this repository creates doubt and ambiguity about the licensing of the project and very likely causes damage to the reputation of this open source project in regards of whether the project is committed to the open source path and will stick to on long term or not.

Can you elaborate on this?
I think the EULA is quite precise and clear how it is applied.

If a software is offered under the Apache 2.0 license it is considered as Open Source. If it is offered under the here written EULA it is not. And as already written her, the EULA as laid out in this repository and the Apache 2.0 license are mutually exclusive the can not be applied usefully at the same time.
The existence of this EULA document in this oCIS-repository means for me: The EULA conditions overrules the apache 2.0 license and thus oCIS is not Open Source.
Whereas @hodyroff and @dragotin are mentioning that the EULA is only applying to binary builds and @DeepDiver1975 states that the document is located in this repository only because of practical reasons for building the enterprise oCIS distribution:

Note that the EULA is only valid for builds provided by ownCloud GmbH, and allows even commercial use widely.

So I assume, that ownCloud GmbH wants this repository be fully Open Source under Apache 2.0 license only.
But with that EULA document existing here, that's not clear for me. Without consulting a lawyer and reviewing the situation this is absolutely unclear to me und I'd rather not touch this software at all.
To fix that the EULA document should be removed from this repository. This also would be one valid answer to the question: "Is oCIS really meant to be Open Source?"

Ok, for me it is quite clear.
The code is Apache 2.0 which it a very permissive OSI license.


Fixes from M1 work

Description

This PR brings over the M1 Mac changes found in concert with @natalie-perlin. These include removing a (currently not supported by M1 GNU) REAL128 variable as well as a CMake change for building when Baselibs is not found.
Related Issue

Motivation and Context

It should let MAPL build on an M1. If nothing else, it doesn't break building on other chips.
How Has This Been Tested?

I've built and ran with the GEOSgcm and zero-diff.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Trivial change (affects only documentation or cleanup)

Checklist:

[ ] I have tested this change with a run of GEOSgcm (if non-trivial)
[x] I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
[x] I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

No reason adas should fail. I'll re-run.


Added support to query for a specific language/word combo

also modified the output speech based on feedback

Looks good


Skin Packs

Support for custom Skin Packs !!! 🎉
Press 3 in the main menu and select a skin pack with live preview
Note that this commit contains a temporary resource file, for development purposes
closes #137

@DiddiLeija I saw the comments. Will work on them tomorrow 😉


Heterogenous recordings

Is your feature request related to a problem? Please describe.
Listening to Kaya de Barbaro's talk, I am thinking we should support heterogenous recordings (such as sensor data) along with the audio.
Describe the solution you'd like
Add the following columns to recordings.csv:

session_id
session_offset: offset to align a given recording with others from the same session (identified by session_id). i.e, once all recordings have been shifted by session_offset seconds, they are aligned.
For now recording_device_type can help distinguish the recorders and even other kinds of sensors.

RE problem: this is definitely something on behive/echolalia's mind!!
(it would be SO cool to have heart rate data together with audio data)

I think it does not require much work on our end.
We could have several sets of recordings (just as we do for annotations), for instance: audio, heart-rate, accelerometer etc.
They'd all lie in recordings/ and be indexed in the metadata as well.
But then they should be sync'd, so start_times at the second level (or even better) should be achieved...

Actually, @alecristia, we already need this for Marvin's pilot, because we will need aligned LENA/BabyLogger recordings.
Here is my suggestion:
Add the following columns to recordings.csv:

session_id
session_offset: offset to align a given recording with others from the same session (identified by session_id). i.e, once all recordings have been shifted by session_offset seconds, they are aligned.
For now recording_device_type can help distinguish the recorders and even other kinds of sensors.

What do you think ?
In reality, the shift might not be constant, /but/ I think this is enough for now...

The only thing I don't like so much with the session_id is that it is one more ad-hoc information, when maybe we could find a more natural way to mimic it.

agreed on the fact that shift isn't constant but this is good enough for now.
For an improved version, I wonder if the routines you developed for Solomon could be used to tag recs as being suspect if the shift is very large?
RE session_id you mean something like date & time of start (rounded to something reasonable for all recs)?

agreed on the fact that shift isn't constant but this is good enough for now.
For an improved version, I wonder if the routines you developed for Solomon could be used to tag recs as being suspect if the shift is very large?
We could use that, or try something more sophisticated. @MarvinLvn mentioned https://en.wikipedia.org/wiki/Dynamic_time_warping. If the mapping function can be roughly approximated by a simple, constant translation everything is fine, but we could tag the recordings for which the approximation does not hold. I might give a try to this technique. We could have some function in our package to compute the shift between pairs of recordings !

RE session_id you mean something like date & time of start (rounded to something reasonable for all recs)?
It could be that or something like. e.g. "20200102_child1", i don't know. So that's what bothers me, it is a bit ad-hoc - although it is necessary to group all simultaneous recordings by "something". And we might want to leave the possibility of several sessions occurring the same day. So I don't think we can escape this ad-hoc session_id for now...


Poonam: Tc 0036 add to cart add product to cart

Poonam--I am done with my Add to Cart(TC0036) test case and pushed code.
Please let me know if any suggestions.

sir, please review only feature file. And let me know if any changes required.


Image upload: internal server error / out of memory error

Intervention image causes an out of memory error when large images are being resized.

Running IdeaSpace on AMPPS locally I get an internal server error when uploading an image, even a very small image.
This is in the log:
[2016-07-07 11:24:55] local.ERROR: exception 'Illuminate\Session\TokenMismatchException' in /Applications/AMPPS/www/idea.space/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php:67

The TokenMismatchException happens when there is a different between the token generated and embedded in the page and the token on the server side. I am not an expert on AMPPS but I bet it has something to do with the session configuration in your setup. I tested IdeaSpace with MAMP and it worked out of the box.

This could be helpful for you: http://chilion.nl/configure-ampps-for-laravel/

after upping the size of panorama image to 20 mb but kept the post size at 8 mb i uploaded an almost 3 mb image and it gave me the internal server error

@qwani did you get an out of memory error in storage/logs/laravel.log? It can happen on shared hosts if there is not enough memory available for php. I hope I can address this memory error better in the upcoming release. Any ideas are welcome!

yes it was as you said and the server admin fixed it, i will share his souloution when he reply back to my email thank you for this good software,
when will we be able to add 360 videos ?

Great, you could post the solution on https://forum.ideaspacevr.org
I am working on the v1.0.0 release which includes 360 videos. Hope to have it ready soon!

sure ill post it to github page wish all good luck
On 11/12/16, Chris<EMAIL_ADDRESS>wrote:

Great, you could post the solution on https://forum.ideaspacevr.org
I am working on the v1.0.0 release which includes 360 videos. Hope to have
it ready soon!
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/IdeaSpaceVR/IdeaSpace/issues/27#issuecomment-260080062

--
po.box 2668
zip code :71461


Data preprocessing codes

Dear Authors,
Many thanks for this excellent work and for providing the codes. I would like to know whether you are planning to release the codes for the data preparation from the original step and mesh files of ABC dataset. Indeed, I would like to train on another dataset and I guess that without these codes this would not be possible.
Many thanks in advance!

Hi Haoxiang, I would like to train on another dataset, too. Could you release the codes for data preparation?


doc link give 404

thanks and congratulations for this 1.0.0-rc1 release ! awesome !!!
small doc update :
go to https://docs.page/Apparence-io/camera_awesome/getting_started/awesome-ui#-need-more-customization-
See docs give 404

Thank you 👍
That seems to have been an error of docs.page that provides it.
This seems working now.
Sorry for this, I close.


vdc step is ok before the cs is deployed

Installation information

jumpscale version: 9.1.3
operating system: Ubuntu 16

Detailed description
When running a blueprint, the vdc step went ok before the cs has been deployed .. it was still in a deploying state.
step:3 (ok)
- vdc                       vdc2                           | install         (ok)

Steps to reproduce
Execute a blueprint for creating a machine

Verified


Declaring a method should not add return type any

TypeScript should never generate code that adds any. When declaring a method, add :void instead.

I'm lacking context on this - do you mean in a quick fix?

@DanielRosenwasser yeah. TypeScript should be about enforcing to use types and not ever suggest to use any.

Maybe it could just return :never given it throws in the implementation.

@bpasero can you make the report a bit more actionable please? Right now it's just one sentence and is really unclear which feature area you're referring to

@RyanCavanaugh I recorded a video:

Ah, indeed. No return type annotation at all would be preferable.

Thanks for the prompt fix!


Feature requests for extended usage

When trying to encode this anime (16-bit PNG) my filtering greatly benefited from applying the descale plugin in some uncommon ways. Since the ideas are theoretically reasonable, I wish they could be implemented from the plugin side in a better form.
Descaling by field
For this anime, a possible choice of parameters for getting rid of cross-conversion is
top_descaled = Delanczos(top_field, 1920, 360, src_top=1/6)
bot_descaled = Delanczos(bot_field, 1920, 360, src_top=1/6)

The result needs a src_top=1/3 shift for correct centering. Another "common" pair of offsets are src_top=1/12 for top field and src_top=-1/12 for bottom (example).
Descaling with border padding
By descaling as mentioned above, you may immediately see the border brightness artifact is much amplified in the output.
I guessed the artifact in the source was caused by upscaling with poor border handling, so I simulated the situation as if the fields were upscaled from 362p content with black top and bottom lines, and did the following instead:
top_descaled = Delanczos(top_field.std.AddBorders(top=1, bottom=1), 1920, 362, src_top=1/2, src_height=360 + 4/3).std.Crop(top=1, bottom=1)

The result was not perfect, but the amplification was successfully suppressed, so that post-processing was made possible with less radius and minimal strength. Similar approaches work for a number of 2010s anime with 720p native resolution with border brightness issues.
It might be possible to implement in the descale plugin by directly adjusting scaling weights, and hopefully the result could be more accurate than the current zero-value padding approach (which naturally incurs underflow).
Your comments are very much appreciated.

Part 1 of this request is out of scope of this project and should be handled by a wrapper.
Part 2 has been implemented in #10 by @YomikoR.


Re-render pages for fresh compat data (April 2020 edition)

Please re-render all pages with the compat macro, so that users see the latest data.
cc @escattone

Thanks for creating this issue @Elchi3!
Summary
I run this gist within a ./manage.py shell_plus on a celery-worker pod, and scale-up the api and kumascript pods to six (6) pods each before I make the run. It usually takes about 1-2 hours to render about 20K documents.
Acceptance Criteria

[ ] All documents that use the compat macro have been successfully re-rendered on prod

I re-rendered 21,160 documents that contain the compat macro in about 68 minutes.


Owner shares of resources should not override user shares of same privilege

@dtarb There has been a general discussion between myself and @pkdash about whether sharing requests that do not result in a change of permission should be accepted or raise an exception. At present:

Owner shares that set the same privilege as before are accepted and change the grantor of privilege to the owner, even though there is no change in actual privilege. Thus, "owner shares are idempotent".
Non-owner shares of the existing privilege are rejected and the first grantor is preserved. Thus, "non-owner shares are not idempotent".

It is somewhat desirable -- from a social standpoint -- to preserve the first grantor as a matter of record and disallow actions that change that grantor for no good reason. At this point, with the undo routines removed in PR #1576,  the grantor field is purely informational, but it seems rather rude to overwrite it simply because "owners should be able to do anything".
However, changing this has some small chance of breaking the UI, and there is no time before AGU to check that non-idempotence of owner actions doesn't break the UI. Thus this change is deferred until after AGU.

I could go either way on this one and am happy to leave it to after AGU

Addressed in PR #1710


Conversion process hit the URL twice

I have a setup which will generate an URL with one time token access. I was wondering why I always fail in generating PDF. My log says I have two requests from Athena. The first one, yield in HTTP 200. And another one (of which the token no longer valid), yield 401.
Apparently this line https://github.com/arachnys/athenapdf/blob/master/weaver/converter/athenapdf/athenapdf.go#L45
actually hit my URL before the actual conversion task.
log.Printf("[AthenaPDF] converting to PDF: %s\n", s.GetActualURI())

Of course, switching GIN_MODE to release immediately fixed my issue (after hours of frustration). Maybe we can log s.URI instead of calling getActualURI

Hey @neofreko, apologies for the frustration you had to go through for it to work nicely.
Unfortunately, I'm not convinced that the aforementioned line of code is the reason for generating an additional HTTP request, nor am I convinced that setting GIN_MODE to release is the solution to your problem. Something would be amiss otherwise.
Firstly, s.GetActualURI() never makes any HTTP request. In fact, it uses s.URI sometimes (and it probably does in your case). It was created so that we can retain original URLs for conversions that cannot not be done remotely due to the content-type. It's not the greatest of designs, but it'll be refactored soon.
Secondly, setting GIN_MODE to release only influences the logging, and stats behaviour. And neither of those should be making an additional HTTP request to the conversion source. I can confirm that this is at least the case on my end.
In essence, logging s.URI instead of s.GetActualURI() will not make any difference.
The real source of the extra HTTP request is from : https://github.com/arachnys/athenapdf/blob/ed68bc1abb6f38059e60cb47384878ab9fe2c417/weaver/converter/source.go#L111
It was introduced to allow us to do some pre-processing prior to the actual conversion (e.g. if the conversion source needs to be downloaded, and if the content-type is acceptable - in the future).
Unfortunately, there is not simple config to turn this off at the moment. However, if you don't mind getting your hands a little bit dirty, try changing:
func convertByURLHandler(c *gin.Context) {
	s := c.MustGet("statsd").(*statsd.Client)
	r, ravenOk := c.Get("sentry")

	url := c.Query("url")
	if url == "" {
		c.AbortWithError(http.StatusBadRequest, ErrURLInvalid).SetType(gin.ErrorTypePublic)
		s.Increment("invalid_url")
		return
	}

	ext := c.Query("ext")

	source, err := converter.NewConversionSource(url, nil, ext)
	if err != nil {
		s.Increment("conversion_error")
		if ravenOk {
			r.(*raven.Client).CaptureError(err, map[string]string{"url": url})
		}
		c.Error(err)
		return
	}

	conversionHandler(c, *source)
}

To something like:
func convertByURLHandler(c *gin.Context) {
	s := c.MustGet("statsd").(*statsd.Client)

	url := c.Query("url")
	if url == "" {
		c.AbortWithError(http.StatusBadRequest, ErrURLInvalid).SetType(gin.ErrorTypePublic)
		s.Increment("invalid_url")
		return
	}

	source := converter.ConversionSource{URI: url}

	conversionHandler(c, source)
}

The above will bypass the pre-processing entirely by giving the raw ConversionSource struct.
Let me know if that helps or if you have any other questions :smile:
And once again, my apologies for the inconveniences you had to go through.

@MrSaints
LOL, so much for my wild guess :p
No worries, I've adjusted my own backend a bit to work around above issue. Keeping a fork of athenapdf is a bit too much for me at the moment. Hopefully, above issue can be addressed properly in the future.
Thank you for this fine software :). Leanest converter I've found so far.

Are there any plans to make this configurable. We use Athena for report generating, something that is often quite costly. Hitting the URL twice is making everything take much longer than needed.

I've hit the same issue with a one time token access.

Just an update. In v3, the service assembly will on longer hit a target URI twice.
The only caveat however, is that a mime type will have to be specified or a fetcher. Otherwise, there is no way to: 1. know what converter we should use if none is specified, and 2. inform the converter beforehand what the input file type is (which is essential in some cases).
I would advise against using a fetcher if a site has lots of assets that are linked using relative URIs.
To a certain degree, this improvement may also open up some security loopholes. The nice thing about the service performing a pre-conversion check (to fetch metadata) in the old version is that it unintentionally acted as a gatekeeper / border control.
I observed this with our demo site which blocked a lot of undesired conversions before it even hit the converter itself.


Space doesn't work

Workflow version
2024.2
Alfred version
5.5.1
macOS version
13.7.2
Debugger output
[15:23:25.885] Placeholder Images[Keyword] Processing complete
[15:23:25.889] Placeholder Images[Keyword] Passing output '300 300' to Split Arg
[15:23:25.890] Placeholder Images[Split Arg] Processing complete
[15:23:25.891] Placeholder Images[Split Arg] Passing output '300 300' to Arg and Vars
[15:23:25.891] Placeholder Images[Arg and Vars] Processing complete
[15:23:25.892] Placeholder Images[Arg and Vars] Passing output 'https://picsum.photos/300 300/.jpg' to Conditional
[15:23:25.892] Placeholder Images[Conditional] Processing complete
[15:23:25.892] Placeholder Images[Conditional] Passing output 'https://picsum.photos/300 300/.jpg' to Post Notification
[15:23:25.893] Placeholder Images[Post Notification] Processing complete
[15:23:25.893] Placeholder Images[Post Notification] Passing output 'https://picsum.photos/300 300/.jpg' to Play Sound
[15:23:25.936] Placeholder Images[Arg and Vars] Passing output 'https://picsum.photos/300 300/.jpg' to Debug
[15:23:25.941] Placeholder Images[Debug] Interpreting given values as:
 Width: 300 300
Height:

More details
If i set the separator to a space it works, but it doesn't work with the config

would also be nice to have a fallback to set one number & if second size isn't set, it uses the first size for both. please, thank you very much for your great work 🙏

Thank you for the report and the request. Fixed the bug and added the feature in 2024.3.


⚠ Bofrost.fr has degraded performance

In ef1af20, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1857 ms

Resolved: Bofrost.fr performance has improved in 3ff8c39 after 7 minutes.


29- To-Do-List UI change

whenever we open application in desktop mode footer is overlapping to the container.
I want to solve this issue so please assign this issue to me.

Can you provide a screenshot for the same?

whenever we open application in desktop mode footer is overlapping to the container. I want to solve this issue so please assign this issue to me.

Can you provide a screenshot for the same?


Combine all postprocessing ffmpeg commands into one

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like this: [x])
Use the Preview tab to see what your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2018.12.17. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2018.12.17

Before submitting an issue make sure you have:

[x] At least skimmed through the README, most notably the FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones
[x] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

[ ] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[x] Feature request (request for a new functionality)
[ ] Question
[ ] Other

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add the -v flag to your command line you run youtube-dl with (youtube-dl -v <your command line>), copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'-v', u'http://www.youtube.com/watch?v=BaW_jenozKcj']
[debug] Encodings: locale cp1251, fs mbcs, out cp866, pref cp1251
[debug] youtube-dl version 2018.12.17
[debug] Python version 2.7.11 - Windows-2003Server-5.2.3790-SP2
[debug] exe versions: ffmpeg N-75573-g1d0487f, ffprobe N-75573-g1d0487f, rtmpdump 2.4
[debug] Proxy map: {}
...
<end of log>

Description of your issue, suggested solution and other information
When I download a video and embed metadata, first youtube-dl downloads the two formats, then combines them with one ffmpeg command, then adds metadata with another ffmpeg command.  This causes the file to be overwritten twice, which adds a significant amount of wear on the hard drive, as well as taking quite a while longer than necessary.
The way it currently works:
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-f', u'137+140', u'--embed-thumbnail', u'--add-metadata', u'-v', u'https://www.youtube.com/watch?v=BaW_jenozKc']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2018.12.17
[debug] Python version 2.7.12 (CPython) - Linux-3.14.0-x86_64-with-Ubuntu-16.04-xenial
[debug] exe versions: ffmpeg 2.8.15-0ubuntu<IP_ADDRESS>, ffprobe 2.8.15-0ubuntu<IP_ADDRESS>, phantomjs 2.1.1
[debug] Proxy map: {}
[youtube] BaW_jenozKc: Downloading webpage
[youtube] BaW_jenozKc: Downloading video info webpage
[youtube] BaW_jenozKc: Downloading thumbnail ...
[youtube] BaW_jenozKc: Writing thumbnail to: youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.jpg
[debug] Invoking downloader on u'https://r3---sn-vgqsrn7l.googlevideo.com/videoplayback?fvip=3&id=o-ACzw29AwTmcE_ba9kIPIvf80A_Cg6gre4l7V1A1fb5_F&ei=CtkiXOWXAbSE7gLXroSoDQ&ms=au%2Crdu&mt=1545787586&mv=m&pl=26&keepalive=yes&source=youtube&mm=31%2C29&mn=sn-vgqsrn7l%2Csn-vgqsdn7s&ip=2601%3A401%3A501%3Ad430%3A8965%3Afbf9%3A8545%3A6dc6&gir=yes&itag=137&dur=9.800&mime=video%2Fmp4&signature=3664E74131573A89B4A7D175CAD810DCC2D6C6D9.34545F06D5DA5F22262B43C8F7C684B1D25E6667&expire=1545809258&ipbits=0&clen=2208750&requiressl=yes&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278&lmt=1387961822987808&sparams=aitags%2Cclen%2Cdur%2Cei%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Ckeepalive%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cexpire&c=WEB&key=yt6&initcwndbps=1732500&ratebypass=yes'
[download] Destination: youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f137.mp4
[download] 100% of 2.11MiB in 00:02
[debug] Invoking downloader on u'https://r3---sn-vgqsrn7l.googlevideo.com/videoplayback?fvip=3&id=o-ACzw29AwTmcE_ba9kIPIvf80A_Cg6gre4l7V1A1fb5_F&ei=CtkiXOWXAbSE7gLXroSoDQ&ms=au%2Crdu&mt=1545787586&mv=m&pl=26&keepalive=yes&source=youtube&mm=31%2C29&mn=sn-vgqsrn7l%2Csn-vgqsdn7s&ip=2601%3A401%3A501%3Ad430%3A8965%3Afbf9%3A8545%3A6dc6&gir=yes&itag=140&dur=9.891&mime=audio%2Fmp4&signature=14C46EBF6A3ED71FD65D7C0017DF6B68333E6EF4.C714426F4B5508269807BC152D0DF22371729330&expire=1545809258&ipbits=0&clen=157753&requiressl=yes&lmt=1387961817989105&sparams=clen%2Cdur%2Cei%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Ckeepalive%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cexpire&c=WEB&key=yt6&initcwndbps=1732500&ratebypass=yes'
[download] Destination: youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f140.m4a
[download] 100% of 154.06KiB in 00:00
[ffmpeg] Merging formats into "youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.mp4"
[debug] ffmpeg command line: ffmpeg -y -i 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.f137.mp4' -i 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.f140.m4a' -c copy -map '0:v:0' -map '1:a:0' 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.temp.mp4'
Deleting original file youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f137.mp4 (pass -k to keep)
Deleting original file youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f140.m4a (pass -k to keep)
[ffmpeg] Adding metadata to 'youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.mp4'
[debug] ffmpeg command line: ffmpeg -y -i 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.mp4' -c copy -metadata 'comment=test chars:  "'"'"'/\ä↭𝕐
test URL: https://github.com/rg3/youtube-dl/issues/1892

This is a test video for youtube-dl.

For more information, contact<EMAIL_ADDRESS>.' -metadata 'description=test chars:  "'"'"'/\ä↭𝕐
test URL: https://github.com/rg3/youtube-dl/issues/1892

This is a test video for youtube-dl.

For more information, contact<EMAIL_ADDRESS>.' -metadata 'artist=Philipp Hagemeister' -metadata 'title=youtube-dl test video "'"'"'/\ä↭𝕐' -metadata 'date=20121002' -metadata 'purl=https://www.youtube.com/watch?v=BaW_jenozKc' 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.temp.mp4'
[atomicparsley] Adding thumbnail to "youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.mp4"
[debug] AtomicParsley command line: AtomicParsley 'youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.mp4' --artwork 'youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.jpg' -o 'youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.temp.mp4'

The way it would ideally work:
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-f', u'137+140', u'--embed-thumbnail', u'--add-metadata', u'-v', u'https://www.youtube.com/watch?v=BaW_jenozKc']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2018.12.17
[debug] Python version 2.7.12 (CPython) - Linux-3.14.0-x86_64-with-Ubuntu-16.04-xenial
[debug] exe versions: ffmpeg 2.8.15-0ubuntu<IP_ADDRESS>, ffprobe 2.8.15-0ubuntu<IP_ADDRESS>, phantomjs 2.1.1
[debug] Proxy map: {}
[youtube] BaW_jenozKc: Downloading webpage
[youtube] BaW_jenozKc: Downloading video info webpage
[youtube] BaW_jenozKc: Downloading thumbnail ...
[youtube] BaW_jenozKc: Writing thumbnail to: youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.jpg
[debug] Invoking downloader on u'https://r3---sn-vgqsrn7l.googlevideo.com/videoplayback?fvip=3&id=o-ACzw29AwTmcE_ba9kIPIvf80A_Cg6gre4l7V1A1fb5_F&ei=CtkiXOWXAbSE7gLXroSoDQ&ms=au%2Crdu&mt=1545787586&mv=m&pl=26&keepalive=yes&source=youtube&mm=31%2C29&mn=sn-vgqsrn7l%2Csn-vgqsdn7s&ip=2601%3A401%3A501%3Ad430%3A8965%3Afbf9%3A8545%3A6dc6&gir=yes&itag=137&dur=9.800&mime=video%2Fmp4&signature=3664E74131573A89B4A7D175CAD810DCC2D6C6D9.34545F06D5DA5F22262B43C8F7C684B1D25E6667&expire=1545809258&ipbits=0&clen=2208750&requiressl=yes&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278&lmt=1387961822987808&sparams=aitags%2Cclen%2Cdur%2Cei%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Ckeepalive%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cexpire&c=WEB&key=yt6&initcwndbps=1732500&ratebypass=yes'
[download] Destination: youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f137.mp4
[download] 100% of 2.11MiB in 00:02
[debug] Invoking downloader on u'https://r3---sn-vgqsrn7l.googlevideo.com/videoplayback?fvip=3&id=o-ACzw29AwTmcE_ba9kIPIvf80A_Cg6gre4l7V1A1fb5_F&ei=CtkiXOWXAbSE7gLXroSoDQ&ms=au%2Crdu&mt=1545787586&mv=m&pl=26&keepalive=yes&source=youtube&mm=31%2C29&mn=sn-vgqsrn7l%2Csn-vgqsdn7s&ip=2601%3A401%3A501%3Ad430%3A8965%3Afbf9%3A8545%3A6dc6&gir=yes&itag=140&dur=9.891&mime=audio%2Fmp4&signature=14C46EBF6A3ED71FD65D7C0017DF6B68333E6EF4.C714426F4B5508269807BC152D0DF22371729330&expire=1545809258&ipbits=0&clen=157753&requiressl=yes&lmt=1387961817989105&sparams=clen%2Cdur%2Cei%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Ckeepalive%2Clmt%2Cmime%2Cmm%2Cmn%2Cms%2Cmv%2Cpl%2Crequiressl%2Csource%2Cexpire&c=WEB&key=yt6&initcwndbps=1732500&ratebypass=yes'
[download] Destination: youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f140.m4a
[download] 100% of 154.06KiB in 00:00
[ffmpeg] Merging formats into "youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.mp4"
[debug] ffmpeg command line: ffmpeg -y -i 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.f137.mp4' -i 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.f140.m4a' -c copy -map '0:v:0' -map '1:a:0'  -metadata 'comment=test chars:  "'"'"'/\ä↭𝕐
test URL: https://github.com/rg3/youtube-dl/issues/1892

This is a test video for youtube-dl.

For more information, contact<EMAIL_ADDRESS>.' -metadata 'description=test chars:  "'"'"'/\ä↭𝕐
test URL: https://github.com/rg3/youtube-dl/issues/1892

This is a test video for youtube-dl.

For more information, contact<EMAIL_ADDRESS>.' -metadata 'artist=Philipp Hagemeister' -metadata 'title=youtube-dl test video "'"'"'/\ä↭𝕐' -metadata 'date=20121002' -metadata 'purl=https://www.youtube.com/watch?v=BaW_jenozKc' 'file:youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.temp.mp4'
Deleting original file youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f137.mp4 (pass -k to keep)
Deleting original file youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.f140.m4a (pass -k to keep)
[atomicparsley] Adding thumbnail to "youtube-dl test video ''_ä↭𝕐-BaW_jenozKc.mp4"
[debug] AtomicParsley command line: AtomicParsley 'youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.mp4' --artwork 'youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.jpg' -o 'youtube-dl test video '"'"''"'"'_ä↭𝕐-BaW_jenozKc.temp.mp4'

@dstftw what is this a duplicate of?  I searched, as well as looked at every issue tagged postprocessor, and couldn't find it.


Remove-ePOComputer is handling the return message incorrectly

Remove-ePOComputer : Unknown response while deleting computer <ComputerName> from ePO: @{name=<ComputerName>; id=112401; message=Computer deleted successfully; status=0}

Should be looking at $Result.Status, not just $Result

Resolved by updating to $Result.Status


RemoteMap may be null, NullPointerException will be thrown in ClusterUtils

[ ] I have searched the issues of this repository and believe that this is not a duplicate.
[ ] I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment
Dubbo version: 2.7.10
Operating System version: macos
Java version: java8
Steps to reproduce this issue
RemoteMap may be null, NullPointerException will be thrown in ClusterUtils
Pls. provide [GitHub address] to reproduce this issue.
Expected Result
NullPointerException will not be thrown

close #7653 via #7655


[Create news][Display news] User can create news without any image

Environment: Windows 10 x64, Mozilla Firefox 76.0 (64-bit)
Reproducable: always
Build found: commit b517ccb
Steps to reproduce

Go to GreenCity https://ita-social-projects.github.io/GreenCityClient/#/welcome
Log into the system.
Click on 'Eco news' link in the header.
Click on 'Create news' button.
Enter valid data in 'Title' and 'Content' fields (e.g. "NASA photo showing the Earth's atmosphere").
Select 1 tag (e.g. "News").
Drag & drop invalid file type into 'Picture' field (e.g. ".txt" file from attachment)
(news_ru.txt).
Click on 'Publish' button.

Actual result
News are published without any image.

Expected result
News are published with default  image.

User story #459 #460 #469 #470
Test case

Verified.


Why ol.geom.Linestring.getCoordinates() returning array of coordinate

I'm currently working with ol.geom and I noticed that:
ol.geom.LineString.getCoordinates() return {Array.ol.Coordinate} Doc
while
ol.geom.Polygon.getCoordinates() return {Array.Array.ol.Coordinate} Doc
Why this isn't normalised? Point have return like LineString (without highest Array) but I think that all outputs should be 'same'

A polygon is made up of rings, to allow for holes. The outer ring is the first entry in the array, then followed by inner rings. ol.geom.LinearRing is probably what you are looking for:
polygon.getLinearRings().forEach(function(linearRing) {
  var coordinates = linearRing.getCoordinates(); // {Array.<ol.Coordinate>}
});


Too many symbol files - These symbols have no corresponding slice in any binary

Integration Method: CocoaPods
Xcode Version: 8.2.1 (8C1002)
Library Version: 3.0.6
Platform: iOS
Device: iPhone 6 Plus
Language: Swift
CocoaPods Version: 1.0.1
[ ] A/B Testing Manually Disabled? (DISABLE_MIXPANEL_AB_DESIGNER) - NO
Description:
While submitting the app to iTunesConnect, we encountered the issue:

Too many symbol files - These symbols have no corresponding slice in any binary [6CC7C205-D2BB-374B-B35C-8610F13F1C6B.symbols, D606A810-1E50-32FC-9B04-BC4AC9668CAF.symbols]

A quick check for .dSYM, yielded that the Mixpanel produces that .symbols
UUID: 34D88E0F-CD2D-3E38-A848-AA543964ABCF (armv7) Mixpanel.framework 1.dSYM/Contents/Resources/DWARF/Mixpanel
UUID: 7FB18318-F0D7-36DE-B576-EC31FCE2B677 (arm64) Mixpanel.framework 1.dSYM/Contents/Resources/DWARF/Mixpanel
UUID: D606A810-1E50-32FC-9B04-BC4AC9668CAF (armv7) Mixpanel.framework.dSYM/Contents/Resources/DWARF/Mixpanel
UUID: 6CC7C205-D2BB-374B-B35C-8610F13F1C6B (arm64) Mixpanel.framework.dSYM/Contents/Resources/DWARF/Mixpanel

I assume, that the CocoaPods configuration is wrong here.
The project has two targets: the app and the appex. The Podfile configuration is this:
target 'App' do
    use_frameworks!
# ...
    pod 'Mixpanel/Mixpanel'
    pod 'Mixpanel/AppExtension'
# ...
end

target 'Appex' do
    use_frameworks!
# ...
    pod 'Mixpanel/AppExtension'
# ...
end

The README suggests to use pod 'Mixpanel' for iOS and pod 'Mixpanel-AppExtension' for an appex, so I've changed the Podfile to the following and hit pod install:
target 'App' do
    use_frameworks!
# ...
    pod 'Mixpanel'
# ...
end

target 'Appex' do
    use_frameworks!
# ...
    pod 'Mixpanel-AppExtension'
# ...
end

Is this correct?
Will there be any functionality missed due to this setup?
Could you please suggest the correct setup in this case?
Expected Behavior:
Mixpanel does not produce "too many symbols"

Your setup with Mixpanel-AppExtension looks correct to me. You haven't version locked Mixpanel-AppExtension, right? It only exists as of 3.0.9 - just double checking since you said you're using 3.0.6. Otherwise perhaps CocoaPods needs to be updated? I'm really not sure but I know it's in the CocoaPods specs repo here.

Hi @pchien
Thank you very much for assistance.
Knowing the CocoaPods version in README would be a huge help, BTW. I am on v1.0.1 right now.
Upon first build, after updating Mixpanel to 3.0.9, with the configuration above, I've got this:
import Mixpanel /// <=== No such module 'Mixpanel'

After doing the conditional import
#if EXTENSION_TARGET
import Mixpanel_AppExtension
#else
import Mixpanel
#endif

...the issue seems to go away.
And, finally, the initial issue with "too many symbols" is gone.

I am reopening it, because, while "too many symbols" is gone, upon launching the app on the device, I got:
dyld: Library not loaded: @rpath/Mixpanel_AppExtension.framework/Mixpanel_AppExtension
  Referenced from: /private/var/containers/Bundle/Application/18566837-6060-48D1-9774-B7D0B3CC2C7C/SKB.app/PlugIns/SKB.appex/SKB
  Reason: image not found

So, it seems now to me, that we still have to add pod 'Mixpanel-AppExtension' to the App target:
target 'App' do
    use_frameworks!
# ...
    pod 'Mixpanel'
    pod 'Mixpanel-AppExtension'
# ...
end

target 'Appex' do
    use_frameworks!
# ...
    pod 'Mixpanel-AppExtension'
# ...
end

Note, that I have a "Remove Framework folder" Run Script build stage as suggested by this CocoaPods issue.
Also, note that Instructions works when the Podfile has this config:
target 'App' do
    use_frameworks!
# ...
    pod 'Instructions', :git => 'https://github.com/ephread/Instructions.git', :branch => 'master'
# ...
end

target 'Appex' do
    use_frameworks!
# ...
    pod 'Instructions/AppExtensions', :git => 'https://github.com/ephread/Instructions.git', :branch => 'master'
# ...
end

Hi @evgeniyd! I happened to see this issue linked to a CocoaPods issue, and I noticed you're using CocoaPods 1.0.1. You'll need to upgrade to at least 1.1.0 to get your pods working with app extensions. Have a great day!

Hi @benasher44
Do you happen to know what's changed since then in CocoaPods, that might help to resolve the issue?

It properly ensures extension pods are in the right place to be loaded by dyld at launch time.

The blog post mentions some of the details around updates to framework handling: http://blog.cocoapods.org/CocoaPods-1.1.0/

Hey @evgeniyd let us know if it works to use pod 'Mixpanel' in your app target and pod 'Mixpanel/AppExtension' in your app extension target in your Podfile. It should work.

Hey @evgeniyd , if you are using Swift in your project, I also suggest having a look at our Swift implementation, which now also supports app extensions: https://github.com/mixpanel/mixpanel-swift Thanks!

Hi @yarneo
First of all, we have migrated to CocoaPods 1.1.0 and applied the suggested separation of podspecs for the app and the appex. It works great!
Regarding the Mixpanel migration to Mixpanel Swift - we have already considered this option and will do the migration soon.
Thank @yarneo @benasher44


not work with a certain url eg:https://wallstreetcn.com/articles/3351394 in android

if the website which generate it's content dynamically by javascript, this tool can not get the height correctly, in most case, the height always return 0, which cause this problem


Update Stream Ack Manager unit test and code refactor

Description
Update Stream Ack Manager unit test and code refactor
Check List

[X] New functionality includes testing.
[ ] New functionality has a documentation issue. Please link to it in this PR.

[ ] New functionality has javadoc added

[X] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

https://github.com/opensearch-project/data-prepper/issues/4534


Place Markers with open info windows on a map using ng-repeat

Is there a way to place some markers on a map using ng-repeat that having all the info windows open when they appear ???  At the code showing at the screen dump i can't do it works.!

Same issue here. I have the issue even when I use just one marker with an info-window (code from example page). I can place marker and info-windows but the click event is not working at all...

Please do not use info-window within ng-repeat. It's been discussed several times.
Here is an example
https://github.com/allenhwkim/angularjs-google-maps/blob/master/testapp/infowindow_compile.html


Fix wasmtime.loader with multiple functions

This is showing off how I'm not exactly a Python expert, but the
previous iteration didn't work because lambda closure captures didn't
work as I expected!
Closes #65

The idiom here is drawing inspiration from https://stackoverflow.com/questions/2295290/what-do-lambda-function-closures-capture/2295372#2295372 for what to do.


[Java] Use immutables value-annotations instead of value artifact

Describe the enhancement requested
As annotation processors are configured directly within maven-compiler-plugin instead of being discovered through the dependencies, there's no need to use org.immutables:value dependency which contains both annotation and the annotation processor, vs org.immutables:value-annotations which only contains the annotations
Similarly org.checkerframework:checker-qual is only needed (vs org.checkerframework:checker) and scope can be limited to provided
Component(s)
Java

Issue resolved by pull request 41790
https://github.com/apache/arrow/pull/41790


feat: port CategoryTheory.Groupoid.VertexGroup

Two things not working:

[ ] the [simps] before  vertexGroup is giving weird error: Failed to find constructor nvMonoid in structure Div.
[ ] in a failing simp in vertexGroupIsomOfMap, what is the correct way to port vertex_group_mul, i.e. how to access the mul of vertexGroup?

slightly weird that the linter suggested to use the name
CategoryTheory.Groupoid.CategoryTheory.Functor.mapVertexGroup, which does not seem rignt: please double check...

https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/failing.20.60simps.60

This PR/issue depends on:

leanprover-community/mathlib4#2883
By Dependent Issues (🤖). Happy coding!

This PR/issue depends on:

leanprover-community/mathlib4#2883
By Dependent Issues (🤖). Happy coding!

bors merge


Finite Elements and Verification Examples

After searching for shape functions for hexahedrals to add in MSolve i run into CalculiX .  This code contains a lot of  elements types and analysis types with extensive  documentation. Also note that a series of verification examples are available againts which we could test our code.

I am posting also a "periodic table of finite elements" that might be useful for adding new elements. femtable.pdf

I post here also FEAP manual that contains many verification examples for Contact(@VasilisMerevis), FE2 (@Gerasimos01 ) and Isogeometric Analysis that we could utilize.


[Bug]: Lints reported on generated files

What happened?
Haven't verified, but we think we currently run linters on all srcs of a *_library including those in bazel-out which means we're reporting lint violations on generated code. This is not desirable, we should probably filter them out.
Follow-up from #62
Version
HEAD
How to reproduce
No response
Any other information?
No response

Related to this, the line in ruff.bzl can be .path instead of .short_path: https://github.com/aspect-build/rules_lint/blob/31abe826d0a5c2d1c2f68e145103a8e18480b505/lint/ruff.bzl#L93
The .short_path is only needed to eslint.bzl where we're translating copied source files in the output tree to their original source tree location.


Update website bucket with new additions

This is currently how we have the Openlinks-Homepage and the Openlinks-React-Application separated- Add more bucket information...

Before I can update anything, I need to review the Homepage we updated and make sure the Auth0 env variables are the same as the Production Auth0 ones!


Aw-Watcher-Spotify data not visible in ActivityWatcher

I seemed to have correctly followed the instructions in the README. Program works when running poetry run aw-watcher-spotify, yet no data seems to be appearing in the ActivityWatcher webapp. Is there a step I've missed?
I've also noticed the program not as a module/watcher in the menubar, perhaps I need to add it there. How would I do that?
I'm running this all on MacOS Catalina (10.15.6). Thanks in advance!

There's no visualization currently available for the Spotify watcher, but
you should be able to browse the data through the "Raw Data" tab.
On Wed, 16 Sep 2020, 04:46 B1zguy<EMAIL_ADDRESS>wrote:

I seemed to have correctly followed the instructions in the README.
Program works when running poetry run aw-watcher-spotify, yet no data
seems to be appearing in the ActivityWatcher webapp. Is there a step I've
missed?
I've also noticed the program not as a module/watcher in the menubar,
perhaps I need to add it there. How would I do that?
I'm running this all on MacOS Catalina (10.15.6). Thanks in advance!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ActivityWatch/aw-watcher-spotify/issues/13, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKXDOT7IE4DQWJZTVZ6TETSGARG7ANCNFSM4RODMKWA
.

Noticed the same. Currently I see now point using it because of no visualisation. Also a question: Do I need to keep it running on command line via poetry run aw-watcher-spotify or can I have it running on background without Terminal. This is not imminent based on the documentation.

@ronilaukkarinen run it in the background and close that terminal poetry run aw-watcher-spotify &. This does come with having to setup logging to not miss any errors/bugs. so poetry run aw-watcher-spotify >> log.log &

how does one connect this to activitywatcher? i can't see it in my raw data tab.


Fix

Addresses interop with VB.NET #38
e7e1ff8 Adds [<assembly: ExtensionAttribute()>] to AssemblyInfo.fs, Adds AssemblyInfo.fs to Chessie.fsproj
7b9c724 Creates test projects for VB using code from the C# project
02ff8a9 Adds test project to solution, may want to exclude this one and do it manually as it seems my version Visual Studio is ahead of the project

/cc @mexx what do you think?

could you please take a look at the travis/mono build?

LGTM, besides the travis/mono build error.

After some investigation, and learning looks like the mono vb.net compiler is basically running Visual Basic 8 from Visual Studio 2005, with no plans to upgrade beyond that.
So things in the tests that have come since then, don't work:
Auto-Properties
Object Initialization using With
Lambdas
List Initialization using {}
Linq query syntax
I'll assume you guys would still want tests written, so I'll re-implement them old school style.

Ok, need some suggestions here on how you guys would like me to proceed.
Had a lapse, forgetting in 2005 we also didn't have Extension methods,  which is what this PR is specifically trying to enable for VB.  Mono has no support for it, and will likely never.

I would vote for simply exclude the tests on mono, as VB support is that much limited on mono.

Yes. Either somehow ifdef the stuff or just delete the Vb project
altogether.
On Jan 29, 2016 21:26, "Max Malook"<EMAIL_ADDRESS>wrote:

I would vote for simply exclude the tests on mono, as VB support is that
much limited on mono.
—
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Chessie/pull/39#issuecomment-176953172.

Removed the project. It builds, learned a lot from what started as a simple effort and proof of concept for work.

thanks!


[Info] Mod Compatibility Issues

Below is a list of all current mod incompatibilities that are present with the Compatibility Layers and the corresponding Issues:

[ ] Inventory Hud+ [Link] - Crashes or lags game with errors [Issue]
[ ] Sophisticated Backpacks (Unoffical Fabric port) [Link] - Various aspects of equipping and general use case within Accessories Slot is broken [Issue]
[ ] Inventorio [Forge/Fabric] [Link] - Crashes out right or issues involved with opening inventory leading to inability to open the screen [Issue]

Am I able to help you somehow?

Am I able to help you somehow?

This page is here to act as a list for all the problematic mods that are incompatible with fixes needing to be placed either on me with specific mixins that I can't sustain forever or for the mod authors to support Accessories API figuring a way to enable such when even detecting compat layers.


CVE-2022-24795

Hello, I am a member of the GitHub Security team and am seeking a maintainer contact for this project with regards to https://github.com/brianmario/yajl-ruby/security/advisories/GHSA-jj47-x69x-mxrm
We were unable to establish contact with a maintainer for this project during the coordinated disclosure process for CVE-2022-24795. If this project is still actively maintained, we'd like to offer our assistance in getting this issue resolved in your library. If it is no longer actively maintained, we recommend archiving this repository.

I'm actively maintaining a derived version at https://github.com/robohack/yajl/  (on the default branch "bsdmake").
I'm not sure what this could mean for lloyd/yajl, except to say that I would not be opposed to archiving it.
(as lloyd/yajl, and thus so far my own variant, do not directly do their own memory allocation error checking, I think the simple quick hack is to add a basic assert(), and a safer fix would be a direct call to abort(); though also allowing greater than 2^31 byte buffers on 32-bit platforms through use of a non-exponential size increment might be appropriate)

👋 @robohack you can find our patches for the 1.x branch included with yajl-ruby here

Actually I take that suggestion for calling abort() back.  (The assert() is still useful of course, but can't be expected to be enabled in all circumstances.)
The best general solution is to recommend that a user-supplied realloc call do whatever error handling it would do for a realloc() failure whenever an allocation of zero bytes is requested.

A long time ago, I have done a ticket:

https://github.com/lloyd/yajl/issues/219


Software Features To Add

The software is simple, and i like that. However i feel there are some basic features that need to be added:
Undo/Redo - Others have also mentioned it, nothing worse than deleting an outline you just worked on
Eraser - I know you can select and delete, but a simple eraser to quickly fix those missed freehand outlines. Also allow different sizes/shapes
Simple shapes - add things like circles, stars, ect. that can be easily and evenly made without having to freehand.
Text - add simple text  so once again it can be somewhat even and alot easier to create.
Basically look at Windows Paint. Add many of those features while still keeping it simple

Let me add to Madness44 list
-- Text - Need to have the ability to outline text in one color and then fill with another
-- Shapes -- Need to be able to outline in one color and then fill with another
-- Photo import -- for easy tracing, be able to resize the picture either "on the griddle" or when the import is being done.

I agree with these all.  Getting the list ready.


Create hermann-emanuel-berufskolleg.txt

@RobinKamps Pull request merged. Please notice that free educational license for JetBrains tools is for high and higher schools students, i.e. those who are over 13 of age. Thank you!


How to extend existing type definitions

I have two types:
type A = {
  foo: string,
  bar: Array<string>
}

type B = {
  baz: string,
  a: A
}

However, I want B.a.bar to be Array<number> instead of  Array<string>. I don't want to copy all of A to B.a because in real code, it's a lot of definitions. I various things, but all of them failed. Intersections failed when trying to destruct B.a somewhere in the code.
type B = {
  baz: string,
  a: {...A, bar: Array<number>}
  a: A & {bar: Array<number>}
  a: A | {bar: Array<number>}
}

How can I achieve this in flow?

type _A<T> = {
  foo: string,
  bar: Array<T>
};

type A = _A<string>;

type B = {
  baz: string,
  a: _A<number>
};

This is very good advice, thank you.


Avoid type warnings when adding tuples to vectors

This simple typing fix avoids this warning from the tea cup example:

Thank you!


Couple more changes

Couple more changes that i found useful in my tabletop typescript journey.

I found some more things, i will be closing this PR, verifying all the other changes i found and adding tests before i openthe next merge, sorry for the notificatinos


Sync eng/common directory with azure-sdk-tools for PR 6118

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/6118  See eng/common workflow

/check-enforcer evaluate


C++ based example

Hello Mister Benlau,
We would like to implement your framework in one of our new project.
We would be very interested in an example using C++ instead of QML.
What do we want exactly in our case ? Having stores and actions management in C++.
We would very pleased and grateful if you could have some time for it.
Have a nice day !

Hello,
So far I only have an example in listening to the actions from QML in C++. Quick Flux is a bit overkill for a pure C++ application. It should need a new framework.
However, there has a problem in making a Flux implementation for in C++.  That is the data type to be passed to Dispatcher. C++ is strong type language but Dispatcher allow any kind of data to be passed to the dispatch() function. Ofcoz, it could use QVariant type just like what Quick Flux did. But I think C++ developer do not really like this approach.
Therefore, I don't have a solid answer about how to make it for C++ yet.

Thanks for your answer.
I will keep you informed if I find a solution for this issue.

@benlau could you also mention what is the preferred way of interacting with stores/actions  from c++ code? Unless I missunderstand something I should be changing properties in the store singleton, right?


async/await support

Guys, what do you think about using async/await on the server side (https://babeljs.io/docs/plugins/transform-async-to-generator/)?
I think this is the future of asynchronous programming in JS. We can potentially remove promise-resolving callbacks and switch to it.
I could integrate this. Thoughts?

Yeah, async/await is awesome. It would be great if you could send a PR.

@somus great! Get started to work on this.

Here we go #248.

Perhaps I've misunderstood the request, but it is already possible to use async/await on the server with the latest version of MERN.


style: 2021-09-20 linter warnings batch 25 / 26

style: 2021-09-20 linter warnings batch 25 / 26
Description
Fix the linter errors in the Fabric Test Ledger class (packages/cactus-test-tooling/src/main/typescript/fabric/fabric-test-ledger-v1.ts)
Acceptance Criteria

Each linter warning is either fixed or a specific new issue is created aimed at exactly that one linter warning where applicable: If fixing a linter warning requires a larger refactoring of the codebase, then it is justifiable to break it out into it's own GH task.
The pull request submitted links to all (if any) additional issues that were created for the linter warnings that did not fit in the scope of the issue.

Full List of Linter Warnings
packages/cactus-test-tooling/src/main/typescript/fabric/fabric-test-ledger-v1.ts
190:52  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
292:52  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
396:67  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
535:14  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
588:28  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
644:30  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
776:25  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
830:29  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
866:34  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
1319:15  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

can you add me on this one too? Thank you!

@yayoiukai2021 Yup, assigned it just now, thank you in advance for the contribution!

Reassigning due to inactivity.

Closing due to the linter numbers having gone stale in the meantime.
We need to invent a better way of tracking linter warnings for future issues like this that we'll open because the line numbers are ephemeral and therefore not well suited for this.
Please see these if you'd still like to work on linter warnings that are beginner-friendly:
https://github.com/hyperledger/cacti/issues/2674
https://github.com/hyperledger/cacti/issues/2675


change the Readme to match with the new behavior

readme should be updated to match the new connector behavior

Also describe logical replication slot and publication creation (see https://github.com/ConduitIO/conduit/issues/165#issuecomment-1074259834).


pull request for e2e test at 01/29/2017 07:45:11

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Not able to connect MySQL

Bug description
Dear Members, while i am trying to connect with the MySql port is closed error coming.

Kindly help to resolve this.
How to reproduce the bug
1: Run the docker container
2: Login
3: go to add database
Screenshots/recordings

Superset version
master / latest-dev
Python version
3.10
Node version
16
Browser
Chrome
Additional context
While i am using given docker image i am not able to connect with MySQL
Checklist

[X] I have searched Superset docs and Slack and didn't find a solution to my problem.
[X] I have searched the GitHub issue tracker and didn't find a similar bug report.
[X] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

+1

https://stackoverflow.com/questions/73757001/connect-superset-to-postgresql-in-a-docker-container-the-port-is-closed

Are you running in docker? Just saw this come across the wire:
https://github.com/apache/superset/pull/28124

Looks like that PR #28124 that Evan linked will implement the fix from @Thinking80s 's StackOverflow link (which has many upvotes) - hopefully that addresses this case.  Given the lack of response from the original poster, this should be closed when that merges.


Embed tag inside extended template seems to be broken

The following template is supposed to work: https://twigfiddle.com/l3d401
It seems, that the template path/name resolution is not working as expected (TwingErrorLoader: Unable to find template). Instead of the correct template element.twig the embedded template is resolved to main.twig.
I can provide a working (or in this case not working) example, if required.

I investigated this issue a bit further: The problem occurs if you provide a relative path to the render method. I have created a repository to illustrate the bug. This used to work somewhere around version 3.0.0.

Hello, @ofabel have you any workaround on this?

@dawidskowron , is it still happening with Twing 5? If so, I have to fiw this.

Hello, @ofabel have you any workaround on this?

Our workaround at the moment is not to use this feature. So yes, it is still broken in version 5.


Improved job listings browser in Wagtail admin

Currently when browsing job listings in the Wagtail admin (via the sidebar, Job Listings > Job Listing Pages) users can only see job titles. This is confusing because multiple jobs may have the same title but differ only by region.
This PR improves that browse page to also show job division, grades, regions, open date, and close date. Users can now sort by title, division, open date, and close date. They can also search in the page search box by job title only.
Changes

Job listings browser in Wagtail admin now shows more columns and is searchable by job title.

Testing

This is most easily tested by using a production database dump that has all of the necessary job models already (grades, regions, etc). Load one and browse to the job listing browser to review these changes.

Review

@cfpb/cfgov-backends

Screenshots
Old view:

New view:

Note that the new view explicitly sorts regions alphabetically:

Notes

Holding this PR pending feedback from relevant users on other feedback they might like to see.

Checklist

[X] Changes are limited to a single goal (no scope creep)
[X] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the front end playbook
[X] Passes all existing automated tests
[X] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[X] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

Stakeholders have approved these changes; removing hold label and open for review.

Thanks for the review @rosskarchner.


Optimize MultiTermQueryConstantScoreWrapper for case when a term matches all docs in a segment.

Description
This PR brings over an optimization we recently made to TermInSetQuery (#1062) to MultiTermQuery more generally.

@gsmiller I think the question is, is it worth adding all those extra conditionals? I don't think the DocIdSet#all will really be that much faster in practice (I'm not even sure how often this optimization will hit for users anyway).
Usually if a term is so dense that it is matching all the documents, then we aren't really reading actual postings anyway: we basically just read a single byte header that means "all ones" for the 128-doc FOR block and don't do any actual read/decoding.

@rmuir that's a fair point. I'll put up another iteration shortly that tries to address this feedback. Hopefully it will converge on something that makes sense to everyone :)

@rmuir did you have any other feedback or opposition to this change? Sorry, it dropped off my plate for a bit but picking it up now and looking to get it merged. Thanks again!

nope, looks good


Caching functions adds weird/senseless code

var window_alert=window['alert'];window_alert('123'); produces (0,window.alert)("123"); in ADVANCED_OPTIMIZATIONS. In SIMPLE_OPTIMIZATIONS or when calling window_alert for multiple times, it works fine.
Looks like a quick fix but I am not into GCC.
In my project, this problem appears often.

As far as the compiler knows, window_alert and window.alert might have subtly different behavior, if the body of alert referenced this at all. The (0, window.alert) thing ensures that it's called as a normal function (so that this will be the global object, or undefined in strict mode) rather than as a property of window (in which case this will be window).
If you describe why you want to alias the alert function we can probably recommend something.

Oh, yes! My fault.