[LIVY-502] Remove dependency on hive-exec

What changes were proposed in this pull request?
This PR removes the dependency on hive-exec. Only modules of Hive which are used after this PR are hive-service-rpc and hive-service. This drastically reduces the amount of JARs needed by the thriftserver module.
The PR takes the Hive classes which we were using and adapts them when necessary (or simpify when we don't need something) in order to work in the Livy thriftserver.
Most of the classes are just migrated replacing all occurrences of HiveConf, HiveSession and other Hive specific classes. Only one class has a quite different logic than Hive's and it is AuthFactory, as we are using a different UGI handling from Hive (as we are not running the TS in a standalone JVM).
The functionalities we are taking from Hive are:

the thrift protocol endpoints (the classes in the cli package), ie. the classes handling lower level details about the communication with the client;
the authentication layer (classes in the auth package, which are used in the ones in cli), despite this PR leaves LDAP and PAM as out of scope as they are not trivial to be ported and not needed for a working solution. We can add them later;
the classes in the operation package which are used to answer to metadata queries by the JDBC driver.

How was this patch tested?
existing UTs + manual tests

cc @jerryshao  @vanzin

Codecov Report

Merging #117 into master will increase coverage by 0.41%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##             master    #117      +/-   ##
===========================================
+ Coverage     70.98%   71.4%   +0.41%
- Complexity      923     924       +1
===========================================
  Files           100     100
  Lines          5498    5564      +66
  Branches        827     827
===========================================
+ Hits           3903    3973      +70
+ Misses         1063    1060       -3
+ Partials        532     531       -1

Impacted Files
Coverage Δ
Complexity Δ

...rver/src/main/scala/org/apache/livy/LivyConf.scala
95.91% <100%> (+2.07%)
21 <0> (ø)
:arrow_down:

...in/java/org/apache/livy/rsc/rpc/RpcDispatcher.java
63.26% <0%> (-4.09%)
19% <0%> (-1%)

...main/scala/org/apache/livy/server/LivyServer.scala
34.83% <0%> (-0.57%)
9% <0%> (ø)

.../scala/org/apache/livy/sessions/SessionState.scala
58.33% <0%> (ø)
2% <0%> (ø)
:arrow_down:

...in/java/org/apache/livy/rsc/driver/JobWrapper.java
80% <0%> (ø)
8% <0%> (+1%)
:arrow_up:

...c/src/main/java/org/apache/livy/rsc/RSCClient.java
83.85% <0%> (+1.24%)
26% <0%> (ø)
:arrow_down:

...ain/java/org/apache/livy/rsc/driver/RSCDriver.java
79.23% <0%> (+1.27%)
42% <0%> (+1%)
:arrow_up:

...scala/org/apache/livy/repl/SparkRInterpreter.scala
60.69% <0%> (+2.31%)
14% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

thanks for the review @vanzin. I have updated the PR description. Let me know if it still needs to be improved.

I think as a first step getting the Hive code in, with the minimal amount of changes necessary, is better.

I am not sure, as the only difference from that was moving from Java to Scala, which saves many conversion back and forth of collections and hence adds unneeded code only to handle this.

overall take another look at whether the things you're forking really need to be forked

I am pretty sure that nothing which is there is unneeded.

@jerryshao @vanzin anymore comments about this?

Thanks for the review @vanzin! I addressed your comments.

I still think there's stuff to clean up here

Not sure what you mean here exactly, but I think that after this patch we may start working with the Hive community in order to make some things easier to be re-used. Eg. we cannot reuse all the auth classes because they depend on the HiveConf we may propose to the Hive community to have them accepting in the constructor the parameters they need instead of the HiveConf, so we can reuse them. This may help reducing significantly the code size here.

Merging to master.


NTR: Negative regulation of GDP-mannose biosynthetic process

Please provide as much information as you can:

Suggested term label:
Negative regulation of GDP-mannose biosynthetic process

Definition (free text)
Any process that stops, prevents, or reduces the frequency, rate or extent of the chemical reactions and pathways resulting in the formation of GDP-mannose.

Reference, in format PMID:#######
PMID: 33986552

Gene product name and ID to be annotated to this term
Human GMPPA and orthologs

Parent term(s)
is_a GO:0009298: GDP-mannose biosynthetic process
Currently the term "GDP-mannose biosynthetic process" doesn't have a regulatory GO term.
Should a "regulation of GDP-mannose biosynthetic process" be created before as a parent?

Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term?

Synonyms (please specify, EXACT, BROAD, NARROW or RELATED)

Cross-references

For enzymes, please provide RHEA and/or EC numbers.

Can also provide MetaCyc, KEGG, Wikipedia, and other links.

Any other information

Note to self, update
https://www.pombase.org/gene/SPBC13G1.02

Hi @rozaru
I'm not sure about this one.
is GMPPA  seems to be part of
GO:0009298 | GDP-mannose biosynthetic process
What is its activity?  I maybe have it annotated incorrectly.
GO:0009298
GDP-mannose biosynthetic process

Agreed,  we would not usually capture 'within-pathway' regulates relations as a "regulation of process" term; these are part of the process.  "regulation of process" terms are for regulation. (i.e control, rather than affect)  that occurs upstream of the module in question.
Thanks!
will close.


Windows.Storage.ApplicationData: ArgumentException when Inkscape is open

Describe the bug
ApplicationData throw ArgumentException ("Value does not fall within the expected range.") on any property while Inkscape is open...
Steps to reproduce the bug

Add var folder = ApplicationData.Current.LocalCacheFolder; on app or window code-behind (no difference).
Open Inkscape (reproduced on v1.0.1 and v1.0.2)
Run App.

Expected behavior
No exception.
Screenshots

Version Info

NuGet package version:
[WinUI 3 - Project Reunion 0.5: 0.5.0]

Windows app type:

UWP
Win32

Yes

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

October 2020 Update (19042)
Yes

May 2020 Update (19041)

November 2019 Update (18363)
Yes

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

Additional context
On UWP (not WinUI) no exception.

@Meloman19 to be clear, this repro requires opening inkscape, an entirely different application?

@StephenLPeters That's right. I was surprised myself.
I opened Inkscape for edit some svg and my running WinUI app crashed with this exception. I tried to launch the application and it crashed again on ApplicationData. But as soon as I closed Inkscape, the application worked fine.
This is reproduced on two completely different computers (my office and my home).

how strange.. @MikeHillberg I'm not sure where to start with routing this one.

This is an old issue and I've opened a bug about it in Project Reunion. It also reproduces when you have GIMP open, or any program that holds a lock on the entire AppData folder.
https://github.com/microsoft/ProjectReunion/issues/101

Since the Project Reunion instance of this issue has been closed as resolved, I'm going to resolve this one as well. If it turns out that there's something WinUI specific still broken, let me know and I'll reopen.


Minor fix of GPU index

Hi @dmitry-vorobiev
Here is a minor fix of GPU index to make it work on single device.
What do you think ?

Yeah, the config is pretty dirty right now. It's what I currently use for small testing.


Support older versions of huggingface_hub

Currently we support the latest version of huggingface_hub due to upload_folder. skops needs to support older versions. Maybe we could use upload_file instead if we want to keep using HfApi?

Why does skops need to support older versions?

Because having tight dependencies makes it hard for users to install multiple integrations. For instance, it would make it impossible for users to have an environment which has skops and Spacy's integration together.
But this is not trivial since we can't simply vendor upload_folder since it depends on create_commit which itself is a new feature.


Escaped characters not escaped

Backslash does not escape characters.
Atom interprets an with an backslash escaped underline character as start of an italic sequence. The same behaviour is happening with *s.
Like in the Markdown definition is written:

Markdown allows you to use backslash escapes to generate literal
characters which would otherwise have special meaning in Markdown’s
formatting syntax.

Thanks so much for reporting this, it will be fixed in the next Atom release, 0.187

Wow, that was quick. Thank you!


Certificate for hosting in Windows Service

I follow this document Host ASP.NET Core in a Windows Service. After starting the service with sc start MyService, it only works for http, it did not redirect to https as this document indicates.
Then I try to configure the urls directly by
           return WebHost.CreateDefaultBuilder(args)                 .ConfigureAppConfiguration((context, config) =>                 {                     // Configure the app here.                 })                 .UseUrls("http://localhost:5000","https://localhost:5001")
The service will fail to start, and check the application log, it says that it fail to find the asp.net core dev certificate.
My current solution is running the service under my own user account.
But, I am wondering how to run the service under local system account. I already check asp.net core dev certificate is installed under Computer/Personal store.
Is there anything could be done from aspnet/Hosting or we should not add more description on the Host ASP.NET Core in a Windows Service

The local system account uses a different certificate store. The dev cert isn't intended for that scenario. You should create a certificate, deploy it with the app, and load it directly.
@guardrex that https link in Windows Services is misleading them.


Font width not correct on Windows

(Original issue 753 created by None on 2012-03-30T09:46:33.111121+00:00)
Hello,
I get too many whitespaces in my text when using ImageFormatter.
The following workaround fixed it for me:
{{{
class DebuggedImageFormatter(ImageFormatter):
def init(self, *args, **kwargs):
ImageFormatter.init(self, *args, **kwargs)
self.fontw = self.fontw -1
}}}
I use this derived class as my ImageFormatter, now the problem is fixed as a workaround
OS is windows server 2003.
In my windows 7 box I have not this problem.
it turns out hat for the same font on windows 7, the fontwidth is 8, and on server 2003, the fontwidth is 9.
I use "Courier New" as font string.

(Original issue 753 last updated on 2012-08-19T09:41:17.081252+00:00)
(Issue automaticaly closed due to status in Bitbucket: wontfix)

(Original comment by birkenfeld on 2012-08-19T09:41:12.616834+00:00)
This would be a bug in PIL and should be reported there.


Save still not working in ID Indoor

Reviewed #4780  & #4772 .  Author seemed to think https would solve problem of saving work in ID indoor.  I tried to find a link with https to no avail.  when I typed in the added s to http to make it https in the current url my browser said the page had a bad certificate.  How do I find the correct web site?

Can you open your issue on their issue tracker instead?  It's not really something we can do anything about in this project.. Thanks!
https://git.framasoft.org/PanierAvide/iD-indoor

Bryan:  Thanks for your note.  I did open an issue on the ID-indoor site.  Thanks for the link pointing me in the right direction.  I am new to OpenStreetMap and there is a lot to learn.
Thanks again,
In Lionism,
Bill Graham
Every Day is a Great Day to be a LION!

On Feb 10, 2018, at 5:40 PM, Bryan Housel<EMAIL_ADDRESS>wrote:
Can you open your issue on their issue tracker instead? It's not really something we can do anything about in this project.. Thanks!
https://git.framasoft.org/PanierAvide/iD-indoor https://git.framasoft.org/PanierAvide/iD-indoor
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/openstreetmap/iD/issues/4786#issuecomment-364701658, or mute the thread https://github.com/notifications/unsubscribe-auth/AiolNX6T50UMf5BeJvZGmBH65CwDqdSTks5tThr1gaJpZM4SBGlI.

The issue is now solved (was related to https).


How can we get the value of user input

Hi @rajat2911, do you mean the value from an input step? If so, you can access it in a Bash script as follows:
INPUT_VALUE=$(buildkite-agent meta-data get <input_key>)

See docs.
If you need more help, I recommend you reach out to support or post on the forum. 😊


Update ALVR to 20.9.1

Hey, firstly, I have to say, that I really like your repo. It has helped me a lot in setting up my own NixOS config and getting ALVR to work.
I saw, that your version of the ALVR package is one version behind. I took the liberty of copying your code and modifying it a bit. I needed to add "SDL2" to the buildInputs for it to work, but now I got the newest version 20.9.1 to work on my system.
Here is my code: https://github.com/ellwoodb/nixos-config/blob/main/pkgs/alvr/default.nix
I have to say, I am not an expert in Nix and have not really written any packages, so if you see any issues please let me know. If my code is good, maybe you could update your repo, or even make a pull request to nixpkgs (I saw you contributing there as well).
Have a nice day!

Thank you! I will update this repo but not Nixpkgs as other contributors are working towards building entirely from source.

Sounds good. Glad I could help!


ghcide-nix support for ghc 8.8 ?

hello there, i'm contributing to the ghc compiler, but the ghc.nix instructions say ghcide does not support ghc version 8.8 yet, i was wondering when you expect this issue to be fixed ? thanks for taking the time to read this issue

We already support GHC 8.8. We're currently working on 8.10.

@ndmitchell , oh ok, that's good to know, this link for ghc.nix says it's currently unavailable: https://github.com/alpmestan/ghc.nix#using-ghcide--currently-unavailable , i'm contributing to ghc, so i really need ghcide to aid me in the devolopment of ghc.

You can still use ghcide if you build it from source. It may take like half an hour, but it is definitely doable.
As I read the issues, there is nothing that ghcide can do to aid ghc.nix.

@fendor , ok sounds good, now that i know ghcide supports ghc version 8.8, i'll go back to the ghc.nix devs to see what progress they've made in getting ghcide working. i'm upgrading all my stuff from ghc 8.6 to 8.8, so i'm guessing some things will break. i am finally able to get nix-shell working in emacs(lorri+direnv+emacs-direnv) using a workaround, so i finally got ghcide(with ghcWithHoogle) working in that setup. if i have to build ghcide manually, i'll do it, but, i might wait until this gets fixed. also, i just upgraded to nixos 20.03, so i'm trying to get things up and running with that channel.
anyways,
thanks for the update,
(this virus has really slowed things down)

@zeta-00 you can use https://github.com/cachix/ghcide-nix/pull/32, but to get the binaries you'll need to wait another day or three.

@domenkozar , sounds good, thanks for the update

With ghcide + haskell.nix + ghc 8.8, I'm getting

ghcide compiled against GHC 8.8.3 but currently using an unknown version of GHC . This is
unsupported, ghcide must be compiled with the same GHC version as the project.

... because ghc is broken in the package database. With reinstallableLibGhc, ghc just isn't in the package database. Either scenario breaks the compatibility check.
I guess in the long term, hopefully the package database stuff can be fixed, but we probably also need an opt-out flag from this check.

@fiadliel See #534, seems like a different issue.

Merged

ghcide has already support for ghc-8.8


[website] Hide 'become a diamond sponsor' box on landing page

[x] I have followed (at least) the PR section of the contributing guide.

Since all 3 spots for diamond sponsors are filled, we can disable the "Become a sponsor" box on landing page.
Request: https://github.com/mui-org/material-ui/pull/28737#issuecomment-933188757

Can we encode the maximum number of diamond sponsors and the current number of diamond sponsors? Just so that this automatically updates and we don't have to manually ensure the data is consistent.

@eps1lon I agree! I pushed a commit.


Where is DockPanel?

And what is Relative Panel?
When coming to this page or any of the pages in the left nav from a search result or other link, there are very few clues that this is UWP specific and not the WPF flavor of XAML.  Something should be visible at all times to indicate which XAML these docs are for, like making the breadcrumbs sticky, or the left nav having a sticky title for the doc group.

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

ID: b8cecd85-5983-c683-d8ea-6c010b7b2b58
Version Independent ID: 8a77e197-6c7c-3fcb-7ecf-e52f4a270d2d
Content: Responsive layouts with XAML - UWP app developer
Content Source: windows-apps-src/design/layout/layouts-with-xaml.md
Service: unspecified
GitHub Login: @muhsinking
Microsoft Alias: mukin

@StingyJack DockPanel is included in the UWP Community Toolkit.

@michael-hawker - its not about the dock panel, specifically. I was trying to find some info for a colleague about the choices available for layout containers and stumbled into this bit of confusion. The doc page doesnt really make it clear this is for a different and less common version of XAML.

Jim - please decide if a comment or addition is required in the documentation.

This feedback was given to the Docs engineering team.


Playlist view "Rows" change order of metadata shown

Hi. I hope u r fine 😃
main issue
Currently the rows show like this:
[Artist Name] - [Album Title] - [Track Title]
I want to be able to change it to my liking. for example:
[Track Title] - [Artist Name]
for that, I think a syntax based option may come in handy. users can just copy paste variables and organize in their way. for example:
[%title%] - [%artist%]
etc.
 I tried to change things here but I dont see what is changing. could u please tell me what it is for?

Hi @vfxturjo,
the screenshot you've posted are the playlist settings for the original foobar but not for my theme!
That means you can't do anything there, because my theme has his own playlist. The script can be found
in your foobar2000\profile\georgia-reborn\js\Playlist\main.js
To be able to change the playlist row, you need to modify the code in the main.js in the // * TITLE init block here:
const title_query = g_properties.show_header ? (pref.showPlaylistTrackNumbers || pref.showPlaylistIndexNumbers ? track_num_query : '') +
(pref.showArtistPlaylistRows && pref.showAlbumPlaylistRows ? `${margin}%artist% - %album% -  %title%[ '('%original artist%' cover)']` :
	pref.showArtistPlaylistRows ? `${margin}%artist% -  %title%[ '('%original artist%' cover)']` :
	pref.showAlbumPlaylistRows  ? `${margin}%album% -  %title%[ '('%original artist%' cover)']` :
`${margin}%title%[ '('%original artist%' cover)']`) : `${margin}   %artist% - %album% - ${showTrackNum} %title%[ '('%original artist%' cover)']`;

-TT

hi. sorry i didnt understand that my screenshot was for original foobar... I associated it cz I saw the theme was called "Columns-UI"
anyway, I tried to modify the code you mentioned. But for some reason it is not reflected in the theme :(
this is the current code:

also I was thinking... if you can make it available with GUI or cliclable/draggable options, that would be really helpful.
thanks in advance!

That's because you have forgot to add one - %artist% tag in your default playlist row state pattern ( the one with your line comment #5123-5129 ).
If you would use top menu Options > Playlist > Show artist name in all rows
top menu Options > Playlist > Show album title in all rows
and top menu Options > Playlist > Album header > Album header
you would see your new changes.
I don't know why you would change any of these anyways because you already have the playlist header that shows the artist anyways.
Also the options Show artist name in all rows and Show album title in all rows was intended to use with compilations
( various artist ) or when using radio ( streaming ). And top menu Options > Playlist > Show artist name on difference is
albums with %album artist% and %track artist%, you could also use it with compilations ( various artist ).
-TT

Hey @vfxturjo,
I have made things easier and now you don't need to tinker in the config file anymore:

Added option to customize the playlist track row via top menu Options > Playlist > Track row > Customize track row
Enter your desired custom pattern for:

When playlist header is being displayed ( default )
When playlist header is deactivated ( Options > Playlist > Album header > Album header )

This is already available in the latest working in progress version, you can get it from here:
https://github.com/TT-ReBORN/Georgia-ReBORN/discussions/74#discussion-4190799
-TT


need to run   pip install --no-cache-dir -r requirements.txt

I don't understand why this is needed. Did you try following the instructions for how to use the poetry config, as described in the README at https://github.com/smucclaw/gsheet/tree/main/natural4-server ? There shouldn't be any need to manually pip install.


Dropdown Search onOpen fires 2 times when clicking on Icon

Steps
Create a Dropdown with search component. Add onOpen handler. Click on the arrow on the right to open it.
Expected Result
It fires once.
Actual Result
It fires twice.
Version
0.78.2
Testcase
https://codesandbox.io/s/6nx916460r
click on right arrow to open - look in the console

This seems to be related to the search prop.  I'll look a bit deeper into it.  It seems to me that it may have something to do with this bit of code in componentDidUpdate
  const openable = !search || (search && minCharacters === 1)

        debug('mouse is not down, opening')
        if (openOnFocus && openable) this.open()

Working on this at #2744

fixed in https://github.com/Semantic-Org/Semantic-UI-React/pull/2744


[BUG] Use the multi-registry feature with Nacos registry that set namingLoadCacheAtStart=true, the cache of NacosNamingService will overwrite each other

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

Environment

Dubbo version: build from mater branch
Operating System version: Mac OSX
Java version: 1.8

Steps to reproduce this issue
When I use the multi-registry feature of Dubbo with setting namingLoadCacheAtStart=true(default is also true in Dubbo), the cache of NacosNamingService will overwrite each other.
If two registries have different services,  some of the services will be lost because of overwriting.
For example, we have settings as below:
<dubbo:registry id="registryDev" address="nacos://<IP_ADDRESS>:8849?namingLoadCacheAtStart=true"/>
<dubbo:registry id="registryTest" address="nacos://<IP_ADDRESS>:8848?namingLoadCacheAtStart=true"/>

If registryStable overwrites registryDev, the consumer can't find the GreetingService in registryDev.

Expected Result
The different registry has different cache folder, so the cache will not overwrite each other.
PS: zookeeper works well with multi-registry feature of Dubbo.
Actual Result
The cache of NacosNamingService will overwrite each other.
If two registries have different services,  some of the services will be lost because of overwriting.

Final Solution
Step1: Nacos support User-Defined cacheDir
I have submitted PRs to both Nacos Client v1.x and v2.x, see: https://github.com/alibaba/nacos/issues/5747.
It will be released around July 2021.
Step2: Dubbo specify the cacheDir of Nacos

How to use it.
Just set namingCacheRegistryDir to different sub dir, if you want to avoid NamingCache overwriting each other, for example:
<dubbo:registry id="registryDev" address="nacos://<IP_ADDRESS>:8849?namingCacheRegistryDir=sub1"/>
<dubbo:registry id="registryTest" address="nacos://<IP_ADDRESS>:8848?namingCacheRegistryDir=sub2"/>


compile erc20 contract error

solang: llvm/lib/IR/Instructions.cpp:1358: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed.
compile erc20 get error, code is here https://github.com/paritytech/pallet-contracts-waterfall/tree/master/contracts/solidity/erc20

I can reproduce this. I'm looking into it

I can reproduce this. I'm looking into it

I can reproduce this. I'm looking into it

another question, what's the address of the contract in substrate with solang?

I can reproduce this. I'm looking into it

another question, what's the address of the contract in substrate with solang?

I'm not sure where or what address you're after. If you mean the address of the current contract, you can get it with address(this). This will emit code which calls seal_address(). Is that what you are after?

I'm not sure where or what address you're after. If you mean the address of the current contract, you can get it with address(this). This will emit code which calls seal_address(). Is that what you are after?

when I call transfer function from another contract, it's always failed, the constructor input address is erc20 contract's address

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

contract TokenTransfer{
    IERC20 public wowToken;
    constructor(address _token) public {
        wowToken = IERC20(_token);
    }

    function tokenTransfer(address _to, uint _amt) public {
        wowToken.transfer(_to,_amt);
    }
}

when I call transfer function from another contract, it's always failed, the constructor input address is erc20 contract's address

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

contract TokenTransfer{
    IERC20 public wowToken;
    constructor(address _token) public {
        wowToken = IERC20(_token);
    }

    function tokenTransfer(address _to, uint _amt) public {
        wowToken.transfer(_to,_amt);
    }
}

I suspect the problem of transfer() failing is that the receiving contract does not have a receive() payable external {} function.
I am not sure this is the same as Ethereum Solidity, this should be checked. In Solang, a contract must have a receive() function else value transfers to it are not allowed (unless value is  sent with an external call, like foo.bar{value:102}() and this bar function is marked payable).
The rules of when value transfers are denied are not very clear when it comes to ethereum solidity.

I suspect the problem of transfer() failing is that the receiving contract does not have a receive() payable external {} function.
I am not sure this is the same as Ethereum Solidity, this should be checked. In Solang, a contract must have a receive() function else value transfers to it are not allowed (unless value is  sent with an external call, like foo.bar{value:102}() and this bar function is marked payable).
The rules of when value transfers are denied are not very clear when it comes to ethereum solidity.

The compilation issue is fixed. We now need to address the transfer() issue.
Can you please check if adding the receive() payable external {} works? Thank you.

The compilation issue is fixed. We now need to address the transfer() issue.
Can you please check if adding the receive() payable external {} works? Thank you.

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

no, it's not work...

So I merged another change, which should solve the issue with transfer(). Please let me know if things are working as expected now.

no, it's not work...

Sorry I was barking up the wrong tree. Let me look at this again.

Sorry I was barking up the wrong tree. Let me look at this again.

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

compile erc20.sol, and the compile TokenTransfer.sol，upload and instance in substrate, TokenTransfer contract init with erc20 contract accountId
//https://github.com/OpenZeppelin/openzeppelin-contracts

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

/**
 * @dev Implementation of the {IERC20} interface.
 *
 * This implementation is agnostic to the way tokens are created. This means
 * that a supply mechanism has to be added in a derived contract using {_mint}.
 * For a generic mechanism see {ERC20Mintable}.
 *
 * TIP: For a detailed writeup see our guide
 * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
 * to implement supply mechanisms].
 *
 * We have followed general OpenZeppelin guidelines: functions revert instead
 * of returning `false` on failure. This behavior is nonetheless conventional
 * and does not conflict with the expectations of ERC20 applications.
 *
 * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
 * This allows applications to reconstruct the allowance for all accounts just
 * by listening to said events. Other implementations of the EIP may not emit
 * these events, as it isn't required by the specification.
 *
 * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
 * functions have been added to mitigate the well-known issues around setting
 * allowances. See {IERC20-approve}.
 */
contract ERC20 is IERC20 {
    using SafeMath for uint256;

    mapping (address => uint256) private _balances;

    mapping (address => mapping (address => uint256)) private _allowances;

    uint256 private _totalSupply;

    constructor(uint256 initValue) public {
        _totalSupply = initValue;
        _balances[msg.sender] = initValue;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function totalSupply() public view override returns (uint256) {
        return _totalSupply;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function getAddress() public view returns (address) {
        return address(this);
    }

    /**
     * @dev See {IERC20-balanceOf}.
     */
    function balanceOf(address account) public view override returns (uint256) {
        return _balances[account];
    }

    /**
     * @dev See {IERC20-transfer}.
     *
     * Requirements:
     *
     * - `recipient` cannot be the zero address.
     * - the caller must have a balance of at least `amount`.
     */
    function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(msg.sender, recipient, amount);
        return true;
    }

    /**
     * @dev See {IERC20-allowance}.
     */
    function allowance(address owner, address spender) public view virtual override returns (uint256) {
        return _allowances[owner][spender];
    }

    /**
     * @dev See {IERC20-approve}.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function approve(address spender, uint256 amount) public virtual override returns (bool) {
        _approve(msg.sender, spender, amount);
        return true;
    }

    /**
     * @dev See {IERC20-transferFrom}.
     *
     * Emits an {Approval} event indicating the updated allowance. This is not
     * required by the EIP. See the note at the beginning of {ERC20};
     *
     * Requirements:
     * - `sender` and `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     * - the caller must have allowance for `sender`'s tokens of at least
     * `amount`.
     */
    function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(sender, recipient, amount);
        _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount, "ERC20: transfer amount exceeds allowance"));
        return true;
    }

    /**
     * @dev Atomically increases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue));
        return true;
    }

    /**
     * @dev Atomically decreases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     * - `spender` must have allowance for the caller of at least
     * `subtractedValue`.
     */
    function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue, "ERC20: decreased allowance below zero"));
        return true;
    }

    receive() payable external {}

    /**
     * @dev Moves tokens `amount` from `sender` to `recipient`.
     *
     * This is internal function is equivalent to {transfer}, and can be used to
     * e.g. implement automatic token fees, slashing mechanisms, etc.
     *
     * Emits a {Transfer} event.
     *
     * Requirements:
     *
     * - `sender` cannot be the zero address.
     * - `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     */
    function _transfer(address sender, address recipient, uint256 amount) internal virtual {
        require(sender != address(0), "ERC20: transfer from the zero address");
        require(recipient != address(0), "ERC20: transfer to the zero address");

        _beforeTokenTransfer(sender, recipient, amount);

        _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
        _balances[recipient] = _balances[recipient].add(amount);
        emit Transfer(sender, recipient, amount);
    }

    /** @dev Creates `amount` tokens and assigns them to `account`, increasing
     * the total supply.
     *
     * Emits a {Transfer} event with `from` set to the zero address.
     *
     * Requirements
     *
     * - `to` cannot be the zero address.
     */
    function _mint(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: mint to the zero address");

        _beforeTokenTransfer(address(0), account, amount);

        _totalSupply = _totalSupply.add(amount);
        _balances[account] = _balances[account].add(amount);
        emit Transfer(address(0), account, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`, reducing the
     * total supply.
     *
     * Emits a {Transfer} event with `to` set to the zero address.
     *
     * Requirements
     *
     * - `account` cannot be the zero address.
     * - `account` must have at least `amount` tokens.
     */
    function _burn(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: burn from the zero address");

        _beforeTokenTransfer(account, address(0), amount);

        _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
        _totalSupply = _totalSupply.sub(amount);
        emit Transfer(account, address(0), amount);
    }

    /**
     * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
     *
     * This is internal function is equivalent to `approve`, and can be used to
     * e.g. set automatic allowances for certain subsystems, etc.
     *
     * Emits an {Approval} event.
     *
     * Requirements:
     *
     * - `owner` cannot be the zero address.
     * - `spender` cannot be the zero address.
     */
    function _approve(address owner, address spender, uint256 amount) internal virtual {
        require(owner != address(0), "ERC20: approve from the zero address");
        require(spender != address(0), "ERC20: approve to the zero address");

        _allowances[owner][spender] = amount;
        emit Approval(owner, spender, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`.`amount` is then deducted
     * from the caller's allowance.
     *
     * See {_burn} and {_approve}.
     */
    function _burnFrom(address account, uint256 amount) internal virtual {
        _burn(account, amount);
        _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount, "ERC20: burn amount exceeds allowance"));
    }

    /**
     * @dev Hook that is called before any transfer of tokens. This includes
     * minting and burning.
     *
     * Calling conditions:
     *
     * - when `from` and `to` are both non-zero, `amount` of `from`'s tokens
     * will be to transferred to `to`.
     * - when `from` is zero, `amount` tokens will be minted for `to`.
     * - when `to` is zero, `amount` of `from`'s tokens will be burned.
     * - `from` and `to` are never both zero.
     *
     * To learn more about hooks, head to xref:ROOT:using-hooks.adoc[Using Hooks].
     */
    function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
}

/**
 * @dev Wrappers over Solidity's arithmetic operations with added overflow
 * checks.
 *
 * Arithmetic operations in Solidity wrap on overflow. This can easily result
 * in bugs, because programmers usually assume that an overflow raises an
 * error, which is the standard behavior in high level programming languages.
 * `SafeMath` restores this intuition by reverting the transaction when an
 * operation overflows.
 *
 * Using this library instead of the unchecked operations eliminates an entire
 * class of bugs, so it's recommended to use it always.
 */
library SafeMath {
    /**
     * @dev Returns the addition of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `+` operator.
     *
     * Requirements:
     * - Addition cannot overflow.
     */
    function add(uint256 a, uint256 b) internal pure returns (uint256) {
        uint256 c = a + b;
        require(c >= a, "SafeMath: addition overflow");

        return c;
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     */
    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        return sub(a, b, "SafeMath: subtraction overflow");
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting with custom message on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     *
     * _Available since v2.4.0._
     */
    function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b <= a, errorMessage);
        uint256 c = a - b;

        return c;
    }

    /**
     * @dev Returns the multiplication of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `*` operator.
     *
     * Requirements:
     * - Multiplication cannot overflow.
     */
    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
        // Gas optimization: this is cheaper than requiring 'a' not being zero, but the
        // benefit is lost if 'b' is also tested.
        // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
        if (a == 0) {
            return 0;
        }

        uint256 c = a * b;
        require(c / a == b, "SafeMath: multiplication overflow");

        return c;
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function div(uint256 a, uint256 b) internal pure returns (uint256) {
        return div(a, b, "SafeMath: division by zero");
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts with custom message on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        // Solidity only automatically asserts when dividing by 0
        require(b > 0, errorMessage);
        uint256 c = a / b;
        // assert(a == b * c + a % b); // There is no case in which this doesn't hold

        return c;
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function mod(uint256 a, uint256 b) internal pure returns (uint256) {
        return mod(a, b, "SafeMath: modulo by zero");
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts with custom message when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b != 0, errorMessage);
        return a % b;
    }
}

@GalaIO can you please provide me with exact steps to reproduce please.
Thank you.

compile erc20.sol, and the compile TokenTransfer.sol，upload and instance in substrate, TokenTransfer contract init with erc20 contract accountId
//https://github.com/OpenZeppelin/openzeppelin-contracts

pragma solidity ^0.6.0;

/**
 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
 * the optional functions; to access them see {ERC20Detailed}.
 */
interface IERC20 {
    /**
     * @dev Returns the amount of tokens in existence.
     */
    function totalSupply() external view returns (uint256);

    /**
     * @dev Returns the amount of tokens owned by `account`.
     */
    function balanceOf(address account) external view returns (uint256);

    /**
     * @dev Moves `amount` tokens from the caller's account to `recipient`.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transfer(address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Returns the remaining number of tokens that `spender` will be
     * allowed to spend on behalf of `owner` through {transferFrom}. This is
     * zero by default.
     *
     * This value changes when {approve} or {transferFrom} are called.
     */
    function allowance(address owner, address spender) external view returns (uint256);

    /**
     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * IMPORTANT: Beware that changing an allowance with this method brings the risk
     * that someone may use both the old and the new allowance by unfortunate
     * transaction ordering. One possible solution to mitigate this race
     * condition is to first reduce the spender's allowance to 0 and set the
     * desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     *
     * Emits an {Approval} event.
     */
    function approve(address spender, uint256 amount) external returns (bool);

    /**
     * @dev Moves `amount` tokens from `sender` to `recipient` using the
     * allowance mechanism. `amount` is then deducted from the caller's
     * allowance.
     *
     * Returns a boolean value indicating whether the operation succeeded.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    /**
     * @dev Emitted when `value` tokens are moved from one account (`from`) to
     * another (`to`).
     *
     * Note that `value` may be zero.
     */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /**
     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
     * a call to {approve}. `value` is the new allowance.
     */
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

/**
 * @dev Implementation of the {IERC20} interface.
 *
 * This implementation is agnostic to the way tokens are created. This means
 * that a supply mechanism has to be added in a derived contract using {_mint}.
 * For a generic mechanism see {ERC20Mintable}.
 *
 * TIP: For a detailed writeup see our guide
 * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
 * to implement supply mechanisms].
 *
 * We have followed general OpenZeppelin guidelines: functions revert instead
 * of returning `false` on failure. This behavior is nonetheless conventional
 * and does not conflict with the expectations of ERC20 applications.
 *
 * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
 * This allows applications to reconstruct the allowance for all accounts just
 * by listening to said events. Other implementations of the EIP may not emit
 * these events, as it isn't required by the specification.
 *
 * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
 * functions have been added to mitigate the well-known issues around setting
 * allowances. See {IERC20-approve}.
 */
contract ERC20 is IERC20 {
    using SafeMath for uint256;

    mapping (address => uint256) private _balances;

    mapping (address => mapping (address => uint256)) private _allowances;

    uint256 private _totalSupply;

    constructor(uint256 initValue) public {
        _totalSupply = initValue;
        _balances[msg.sender] = initValue;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function totalSupply() public view override returns (uint256) {
        return _totalSupply;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function getAddress() public view returns (address) {
        return address(this);
    }

    /**
     * @dev See {IERC20-balanceOf}.
     */
    function balanceOf(address account) public view override returns (uint256) {
        return _balances[account];
    }

    /**
     * @dev See {IERC20-transfer}.
     *
     * Requirements:
     *
     * - `recipient` cannot be the zero address.
     * - the caller must have a balance of at least `amount`.
     */
    function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(msg.sender, recipient, amount);
        return true;
    }

    /**
     * @dev See {IERC20-allowance}.
     */
    function allowance(address owner, address spender) public view virtual override returns (uint256) {
        return _allowances[owner][spender];
    }

    /**
     * @dev See {IERC20-approve}.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function approve(address spender, uint256 amount) public virtual override returns (bool) {
        _approve(msg.sender, spender, amount);
        return true;
    }

    /**
     * @dev See {IERC20-transferFrom}.
     *
     * Emits an {Approval} event indicating the updated allowance. This is not
     * required by the EIP. See the note at the beginning of {ERC20};
     *
     * Requirements:
     * - `sender` and `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     * - the caller must have allowance for `sender`'s tokens of at least
     * `amount`.
     */
    function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(sender, recipient, amount);
        _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount, "ERC20: transfer amount exceeds allowance"));
        return true;
    }

    /**
     * @dev Atomically increases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue));
        return true;
    }

    /**
     * @dev Atomically decreases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     * - `spender` must have allowance for the caller of at least
     * `subtractedValue`.
     */
    function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
        _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue, "ERC20: decreased allowance below zero"));
        return true;
    }

    receive() payable external {}

    /**
     * @dev Moves tokens `amount` from `sender` to `recipient`.
     *
     * This is internal function is equivalent to {transfer}, and can be used to
     * e.g. implement automatic token fees, slashing mechanisms, etc.
     *
     * Emits a {Transfer} event.
     *
     * Requirements:
     *
     * - `sender` cannot be the zero address.
     * - `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     */
    function _transfer(address sender, address recipient, uint256 amount) internal virtual {
        require(sender != address(0), "ERC20: transfer from the zero address");
        require(recipient != address(0), "ERC20: transfer to the zero address");

        _beforeTokenTransfer(sender, recipient, amount);

        _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
        _balances[recipient] = _balances[recipient].add(amount);
        emit Transfer(sender, recipient, amount);
    }

    /** @dev Creates `amount` tokens and assigns them to `account`, increasing
     * the total supply.
     *
     * Emits a {Transfer} event with `from` set to the zero address.
     *
     * Requirements
     *
     * - `to` cannot be the zero address.
     */
    function _mint(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: mint to the zero address");

        _beforeTokenTransfer(address(0), account, amount);

        _totalSupply = _totalSupply.add(amount);
        _balances[account] = _balances[account].add(amount);
        emit Transfer(address(0), account, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`, reducing the
     * total supply.
     *
     * Emits a {Transfer} event with `to` set to the zero address.
     *
     * Requirements
     *
     * - `account` cannot be the zero address.
     * - `account` must have at least `amount` tokens.
     */
    function _burn(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: burn from the zero address");

        _beforeTokenTransfer(account, address(0), amount);

        _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
        _totalSupply = _totalSupply.sub(amount);
        emit Transfer(account, address(0), amount);
    }

    /**
     * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
     *
     * This is internal function is equivalent to `approve`, and can be used to
     * e.g. set automatic allowances for certain subsystems, etc.
     *
     * Emits an {Approval} event.
     *
     * Requirements:
     *
     * - `owner` cannot be the zero address.
     * - `spender` cannot be the zero address.
     */
    function _approve(address owner, address spender, uint256 amount) internal virtual {
        require(owner != address(0), "ERC20: approve from the zero address");
        require(spender != address(0), "ERC20: approve to the zero address");

        _allowances[owner][spender] = amount;
        emit Approval(owner, spender, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`.`amount` is then deducted
     * from the caller's allowance.
     *
     * See {_burn} and {_approve}.
     */
    function _burnFrom(address account, uint256 amount) internal virtual {
        _burn(account, amount);
        _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount, "ERC20: burn amount exceeds allowance"));
    }

    /**
     * @dev Hook that is called before any transfer of tokens. This includes
     * minting and burning.
     *
     * Calling conditions:
     *
     * - when `from` and `to` are both non-zero, `amount` of `from`'s tokens
     * will be to transferred to `to`.
     * - when `from` is zero, `amount` tokens will be minted for `to`.
     * - when `to` is zero, `amount` of `from`'s tokens will be burned.
     * - `from` and `to` are never both zero.
     *
     * To learn more about hooks, head to xref:ROOT:using-hooks.adoc[Using Hooks].
     */
    function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
}

/**
 * @dev Wrappers over Solidity's arithmetic operations with added overflow
 * checks.
 *
 * Arithmetic operations in Solidity wrap on overflow. This can easily result
 * in bugs, because programmers usually assume that an overflow raises an
 * error, which is the standard behavior in high level programming languages.
 * `SafeMath` restores this intuition by reverting the transaction when an
 * operation overflows.
 *
 * Using this library instead of the unchecked operations eliminates an entire
 * class of bugs, so it's recommended to use it always.
 */
library SafeMath {
    /**
     * @dev Returns the addition of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `+` operator.
     *
     * Requirements:
     * - Addition cannot overflow.
     */
    function add(uint256 a, uint256 b) internal pure returns (uint256) {
        uint256 c = a + b;
        require(c >= a, "SafeMath: addition overflow");

        return c;
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     */
    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        return sub(a, b, "SafeMath: subtraction overflow");
    }

    /**
     * @dev Returns the subtraction of two unsigned integers, reverting with custom message on
     * overflow (when the result is negative).
     *
     * Counterpart to Solidity's `-` operator.
     *
     * Requirements:
     * - Subtraction cannot overflow.
     *
     * _Available since v2.4.0._
     */
    function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b <= a, errorMessage);
        uint256 c = a - b;

        return c;
    }

    /**
     * @dev Returns the multiplication of two unsigned integers, reverting on
     * overflow.
     *
     * Counterpart to Solidity's `*` operator.
     *
     * Requirements:
     * - Multiplication cannot overflow.
     */
    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
        // Gas optimization: this is cheaper than requiring 'a' not being zero, but the
        // benefit is lost if 'b' is also tested.
        // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
        if (a == 0) {
            return 0;
        }

        uint256 c = a * b;
        require(c / a == b, "SafeMath: multiplication overflow");

        return c;
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function div(uint256 a, uint256 b) internal pure returns (uint256) {
        return div(a, b, "SafeMath: division by zero");
    }

    /**
     * @dev Returns the integer division of two unsigned integers. Reverts with custom message on
     * division by zero. The result is rounded towards zero.
     *
     * Counterpart to Solidity's `/` operator. Note: this function uses a
     * `revert` opcode (which leaves remaining gas untouched) while Solidity
     * uses an invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        // Solidity only automatically asserts when dividing by 0
        require(b > 0, errorMessage);
        uint256 c = a / b;
        // assert(a == b * c + a % b); // There is no case in which this doesn't hold

        return c;
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     */
    function mod(uint256 a, uint256 b) internal pure returns (uint256) {
        return mod(a, b, "SafeMath: modulo by zero");
    }

    /**
     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
     * Reverts with custom message when dividing by zero.
     *
     * Counterpart to Solidity's `%` operator. This function uses a `revert`
     * opcode (which leaves remaining gas untouched) while Solidity uses an
     * invalid opcode to revert (consuming all remaining gas).
     *
     * Requirements:
     * - The divisor cannot be zero.
     *
     * _Available since v2.4.0._
     */
    function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
        require(b != 0, errorMessage);
        return a % b;
    }
}

@GalaIO this contract compiles fine. What issue are you seeing when you try go upload the contract to substrate?


Improve visualisation of invalid features

Show invalid features with a red border. (Pablo Carbonell)

Fixed, but still could be improved using built-in ng-form validation.


add copyright to to pkg/utils/dataset_condition.go

Ⅰ. Describe what this PR does
add the copyright to to pkg/utils/dataset_condition.go.
Ⅱ. Does this pull request fix one issue?

NONE
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

assign @ronggu


Handle querystrings and content-disposition

This turned out to be a lot more work than I expected, because the get-stream usage didn't allow access to the HTTP headers, so I had to rewrite quite much to get what I need.
The 404 test was broken on master (it uses a async function without await), by the way.
cc: @sindresorhus

Thanks @silverwind. Looks great.
I did a follow-up commit https://github.com/kevva/download/commit/77fb55666be905c194dfa2ce6b9ca66389c42625 to simplify it slightly. Could you look it over and 👍 if good?


Create Make workflow

This PR adds a basic CI config that will run the lint and all tasks to ensure sokol_gp builds.
This can be useful to verify that future changes and PRs can at least be compiled without issues.

Thanks, merged in https://github.com/edubart/sokol_gp/commit/ec9f6369f770494617e0e1e03e446163a9068c4f


How to integrate interrupts into embedded-hal

Interrupts are an important topic in microcontroller programming, but so far there's no support for them in embedded-hal. I'd like to start a discussion about whether such support should be added, and what it could look like.
I think right now we need two kinds of contributions to this discussion:

If you have any thoughts about what interrupt support should look like, please post them here.
If you maintain an implementation of embedded-hal, feel free to summarize how your crate supports interrupts, and how that does or doesn't interact with the embedded-hal traits. I plan to post my own experiences later.
Same, if you've written a driver based on embedded-hal. How does your driver use interrupts? What does it need that is currently missing from embedded-hal?

There's been some previous discussion in #37.
Edit (2018-03-08): Feedback from driver authors is also needed. Added it to the list.

Good stuff you're adding a new ticket for this very important topic.
There's from my side at least three important aspects to cover:

Interrupt generation configuration (certainly a HAL topic)
Interrupt handler setup
Interrupt handling (maybe a HAL topic)

All of this has to be done manually right now but at least for the setup of the interrupt handlers there's already some support (for Cortex-M MCUs) in the cortex-m-rt and cortex-m-rtfm crates with the largest problems being:

The interrupt handler definition is static and happens on a program level
The interrupt generation configuration is completely disconnected from the interrupt handler itself and happens dynamically somewhere in the program

Ideally there would be a possibility for an embedded-hal implementation to insert a static interrupt handler definition at compile time from a macro call inside the program. Only at this level the compiler can ensure that the required resources are still available and the HAL implementation that the interrupt generation setup and the interrupt handler itself match up and are will be operational.
One alternative might be to always use a veneer for all interrupt handlers and allow the HAL to assign the real interrupt handler at runtime. Of course higher level Cortex-Ms and other architectures may allow to change the interrupt handlers on the fly instead of being fixed addresses in flash.

Just want to chime in and say that this is sorely needed. I'm developing a small crate for HC-SR04 which ideally should use interrupts to measure return value from sensor. At the moment I have implemented it as a non-blocking type where users are responsible for calling an update function to inform the sensor of the interrupt event. This is one use-case where some form of abstract interrupt handling would be beneficial.
Without much experience in embedded work, the workflow I would imagine is something along the line of users passing a type implementing Nr and exposing a crate that contains either a macro or function which can setup the interrupt to call a selected method from the sensor crate. For my own use I would not mind that, initially at least, the user of the sensor crate would be responsible for configuring the interrupt (e.g. manage the correct line for interrupt, etc.), but letting the sensor crate select the, possibly private, function to handle the interrupt and so on.

@nordmoen Unfortunately it doesn't quite work like this. First of all each platform has a completely different way of setting up the interrupts and different capabilities when it comes to them (e.g. some platforms have a number of interrupts and you're completely free to map them to certain "events" happing in the system, while others have very specific interrupts mapped to exact peripherals).
Then there's a lot of options depending on user choice, e.g. if you want to have an interrupt when a button is pressed you'll need to tell the system whether it is pulled low or high and also whether you'd like it edge-triggered or level-triggered; some also allow debouncing, etc.
Then there's different ways how the interrupts work in the system, e.g. Cortex-M0 have a fixed interrupt/exception handler table at the beginning of the flash, whereas Cortex-M3 or higher have the same but can can change the address of the interrupt handler table and then there're other chips allowing to completely dynamically remap interrupts.
And of course, once you successfully arrived in the interrupt handler, you still need to know how to deal with the interrupt, i.e. figure out what exactly the cause of the interrupt was and also clear it, which again, is completely MCU dependent...

IMHO at HAL level of abstraction interrupts are not self-sufficient. Every interrupt is a part of hardware block (timer, dma, spi, i2c, ...) with specific details.

I think it would be preferable for end users to have events support in existing modules instead of abstract interrupts.
After adding event-like support to existing modules it will be more clear if it worth to generalise interrupts API or not.

To me, embedded-hal describes the interface that drivers provide to user code, and concepts such as interrupts and DMA are implementation details that are the responsibility of the driver.
That doesn't mean that these traits are optimal for every purpose. If they aren't, one can use a more suitable driver-specific API or write a custom driver that does exactly what is needed.
I do think there will ultimately be a handful of traits for each hardware protocol - we already have blocking and non-blocking variants, and I can also see zero-copy ownership-passing interfaces as well as command queues and scatter-gather for some types of hardware.
However, even those more complex traits must abstract away the details of how drivers are implemented and instead focus on the protocol that the client and driver agree to.

@jcsoo

To me, embedded-hal describes the interface that drivers provide to user code, and concepts such as interrupts and DMA are implementation details that are the responsibility of the driver.

And by "driver" you mean? At the moment they're they are the responsibility of the application. And while I do agree with everything you've said I still think we should at least have the capability of simplifying the use of interrupts with embedded-hal implementations.

And by "driver" you mean? At the moment they're they are the responsibility of the application. And while I do agree with everything you've said I still think we should at least have the capability of simplifying the use of interrupts with embedded-hal implementations.

By "driver" I mean whatever concrete type is implementing the trait, and "client" covers the code that is calling the methods of the trait. "Application" covers a lot of territory and could include code on both sides of that boundary.
As far as interrupts go, I see two separate but related concerns.
First is the issue of hardware interrupts and the various methods of configuring them, especially how one dispatches to handlers at either build time or run time. That requires using a combination of vendor-specific code to configure the interrupts (maybe "Low-Level HAL" is a good term for this), perhaps a cross-platform build-time or link-time tool (RTFM and cortex-m-rt do some of this) to manage static dispatching, or alternatively, architecture-specific tools for managing vector relocation (as on Cortex-M) and/or run-time interrupt dispatch mechanisms.
Second is the question of how to structure an application as a whole to work well in an asynchronous environment. Embedded-HAL doesn't really deal with that at all - it simply supports a blocking or non-blocking model and pushes policy to either the driver or the code calling the interface. For some applications a busy loop or call to WFI is fine, but for others we start wanting some parts of an RTOS.
Both of those areas haven't had as much attention as Embedded-HAL itself because they involve much more policy and complexity than Embedded-HAL.
I'd be very interesting in seeing specific examples of applications that run into these issues. I've done some experimentation with both dynamic handler assignment using relocated vector tables and dispatchers, each of which has strengths and weaknesses, and I've also been working on coming up with a core set of primitives on which to base a simple RTOS.

@jcsoo

"Application" covers a lot of territory and could include code on both sides of that boundary.

I respectfully disagree. The application (or more commonly called "firmware" in embedded systems) is the binary running on the system which sets up the hardware and drivers and binds all bits and pieces together to achieve whatever it is supposed to do in the end. While it could theoretically provide an HAL implementation consumed by the drivers it uses, this is not really the intended use case.

Both of those areas haven't had as much attention as Embedded-HAL itself because they involve much more policy and complexity than Embedded-HAL.

I agree with the two points but you're missing one important detail from my POV: the traits in embedded-hal serve as a common interface for HAL implementations, drivers and applications. And as such I would also expect a common interface to figure out which interrupts can be used by a peripheral, activate it and of course take ownership. embedded-hal seems like the natural place for such an interrupt.

I agree with the two points but you're missing one important detail from my POV: the traits in embedded-hal serve as a common interface for HAL implementations, drivers and applications. And as such I would also expect a common interface to figure out which interrupts can be used by a peripheral, activate it and of course take ownership. embedded-hal seems like the natural place for such an interface.

My understanding is that embedded-hal is specifically about common ways of using drivers and explicitly excludes initializing and configuring them - see the documentation:

Out of scope
Initialization and configuration stuff like "ensure this serial interface and that SPI interface are not using the same pins". The HAL will focus on doing I/O.

Initialization and configuration (of which interrupt management is one part) is hugely important, but it's also incredibly broad with many, many possible approaches. Because of that I think it's better handled outside of this crate, which should keep its focus on defining a minimal set of interfaces for interoperability.

Yes, the embedded-hal traits define the interface, they do not actually do anything (well, not a lot) by themselves.

And as such I would also expect a common interface to figure out which interrupts can be used by a peripheral, activate it and of course take ownership. embedded-hal seems like the natural place for such an interface.

Do you mean that interrupts can be relocated in MCU on hardware level? That looks reasonable point to reflect support in independent interface.

@puzrin Some (most?) MCU have mappable interrupts, e.g. STM32 with the EXTI but that's only a part of my point. When you're using interrupts there's a common set of operations you'll typically need to do:

Set it up
Activate it
Deactivate it
Check whether it has been tripped
Clear it
...

By having a generic trait for interrupts in embedded-hal, the HAL implementation can provide specific implementations for the trait for the available interrupts and model them similarly to other peripherals thus simplifying the handling.

For exti it could be reasonable to have exti hal, not abstract interrupts call. I can't understand what can be common with dma or timer there.

EXTI is STM32 specific and thus not a good choice for a trait. The abstraction is not about the interrupt handler calls but the interrupt setup and handling; it would be great if the interrupt handlers could be abstracted, too, but that would require some serious magic which is beyond my skills.
I have an idea. Let me see if I can find some time later today to test it and come up with a proposal.

The abstraction is not about the interrupt handler calls but the interrupt setup and handling

Ah, seems i got your point. It it's something like pin definitions, that may be useful to configure autogenerated mcu hal-s.

I've added a rough cut of my idea here: https://github.com/therealprof/embedded-hal/tree/features/interrupts
This is what an exemplary implementation for the RTC0 interrupt on a NRF51 might look like (of course this should be composable with other drivers):
use nrf51::RTC0;

use hal::interrupts::IRQ;

pub struct Irq<I> {
    irq: I,
}

impl Irq<RTC0> {
    pub fn new(irq: RTC0, prescaler: u32) -> Self {
        let rtc0 = unsafe { &*RTC0::ptr() };
        rtc0.evtenset.write(|w| w.tick().set_bit());
        rtc0.prescaler.write(|w| unsafe { w.bits(prescaler) });
        Irq { irq }
    }
}

impl IRQ for Irq<RTC0> {
    fn enable(&mut self) {
        self.irq.evtenset.write(|w| w.tick().set_bit());
        self.irq.intenset.write(|w| w.tick().set_bit());
        self.irq.tasks_start.write(|w| unsafe { w.bits(1) });
    }

    fn disable(&mut self) {
        self.irq.evtenset.write(|w| w.tick().clear_bit());
        self.irq.intenset.write(|w| w.tick().clear_bit());
        self.irq.tasks_stop.write(|w| unsafe { w.bits(1) });
    }

    fn clear(&mut self) {
        self.irq.events_tick.write(|w| unsafe { w.bits(0) });
    }
}

To use it one would instantiate the component:
    let mut rtc0irq = interrupts::Irq::new(p.RTC0, 64_000);
    rtc0irq.enable();
    // plus whatever magic is needed to activate the interrupt, e.g. via NVIC
    // plus the magic to set up the interrupt handler

and in the interrupt handler one would clear it:
    rtc0irq.clear();

This is an interesting idea, but I have a couple of questions.

How do you get the peripheral back so that you can call functions on it?
How do you propose access is gained to the rtcirq0 object in the interrupt, when it is likely to have been created on the stack?

How do you get the peripheral back so that you can call functions on it?

I'd compose it into the HAL implementation if necessary.

How do you propose access is gained to the rtcirq0 object in the interrupt, when it is likely to have been created on the stack?

Using the usual static Mutex<RefCell<Option<>>> hack which is required anyway regardless whether this this new trait is utilised or not.

Looking at just external interrupts, what would be wrong with creating something like:
// In init()
let int0 = gpioa.pa0.into_floating_input(&mut gpioa.crl);
int0.attach_interrupt();

// Later
fn exti0() {
...
}

Where Interruptable is a trait created by the device crate implemented for each pin with whatever specific set up is needed for that MCU.

Ideally for a interrupt trait, there would be some way to attachMethod( method: ... ) or attachFunction(fn: ... ).
The current way I would implement drivers would be as globals. Then put the drivers "event" code in the interrupt handler. Could it be preferrable to instead put the struct implemeting interrupt as a global and then put that struct in the interrupt handler.
Ex I have a pin that implements Interrupt. This pin would be global, and in the interrupt handler I would put pin.handler(), instead of driver.event()
I am extremely new to rust, so please tell me if there would be another way and why this is would not be possible. I just know that If i implemented a driver that required an object with an interrupt trait, I would like to in that driver attach the code to be run when the interrupt fires.

Agree this seems like something that would ideally be provided by embedded-hal. Can we have a list, akin to #37 about requirements? Off the top of my head, we'd need 'enable, disable, and clearfor a base trait. We could have aPendabletrait that also addspendandunpend`.
Would they need anything, at the HAL level, other than just the interrupt number?
While it would be nice to encapsulate the interrupt vector setup in the HAL, I don't think it's necessary to proceed with a trait or two that describes the basic functions of the interrupt controller.

I was recently working on an embedded linux program and the concept of an interrupt for linux-embedded-hal would be quite different than pend and unpend. In that world, what you get is not a static interrupt handler, but a mspc::Channel::Rx, which makes me wonder if some sort of no_std channel would be a better abstraction for drivers to consume than trying to abstract away the very hardware dependent interrupts.

This is an old thread, but I implemented this or a similar abstraction for Embassy, but perhaps embedded-hal is a more appropriate place to implement these generalized abstractions?  These abstractions are beneficial to my use case, and I can open a PR if there's interest.


Create staging environment and upgrade to Cairo 0.9

Apologies for the messy diff, I thought that I needed to upgrade to Cairo 0.9 to get the staging contracts to work but that ended up not being the case. Here are the changes in this PR:

rename publisher-utils/ to publisher/ (has the utils folder in it, and has grown far beyond the initial sample code)
create a separate set of staging contracts (publisher registry, oracle controller and oracle implementation, and pontis publisher account; though same admin and publisher keys) that we can use for testing. Use those contracts for the update prices github action which previously would fail because of nonce collision issues with the actual publisher (running on Lightsail) on prod. As part of this, increase the Pontis version to 0.4.12
Upgrade Cairo to 0.9 and fix our tests which now deal with contract classes, not contract definitions


[Feature] Make Security Tokens Optional

Is your feature request related to a problem? Please describe.
If a project does not contain sensitive information, it is forced to be encrypted anyway and requires a matching token to be opened. This becomes an obstacle when trying to share projects.
Describe the solution you'd like
I would like to be able to turn token generation off before creating a project to make it accessible to others regardless of which tokens they have. Ideally you can also switch it back on before creating another project at any time.
Describe alternatives you've considered
I need to view several users projects and each have generated a unique token. I could request these tokens from them but they work on rotating schedules and could take a full week to get those tokens from them. I could have them create one token that is shared between all projects, but they could forget to use that token on project creation.
Additional context
Since this is an internal group, we should be able to open each other’s projects without issue or added complexity if there isn’t sensitive information.

+second that


Docs: How-to - Scaling - ClickHouse

See https://github.com/openedx/openedx-aspects/issues/78#issuecomment-1910413023

Can we close it? https://docs.openedx.org/projects/openedx-aspects/en/latest/technical_documentation/how-tos/production_configuration.html


modified Device::Modbus::TCP in socket creation phase

not fully tested; not sure this is the best way to return if a socket could not be opened; just a proposal ;-)
modified Device::Modbus::TCP to return silently unless socket was created succesfully. Prevents caller from dying.

HI, was too late in the night when I made this commit, it just doesn't work ;-) sorry for that, my bad

Thank you so much for your interest! I hope you get to test Device::Modbus and that it serves your needs. I'd be glad to see more contributions.


WIP: Hotfix for Swift 3 Docker build

@psuter This will fix #600 ?
PG ?

It looks like this is a temp fix, let's leave #600 to track proper fix shows up in https://github.com/apple/swift-corelibs-libdispatch

@csantanapr that's the hope. PG 366.

Seems like this was fixed at the source?

Yes.

Any lessons learned for the future on this incident? Any actions to handle it better, notifications, prevent, etc..?

We should consider depending on fixed commits in their history, I think. Pulling from the latest is a recipe for disaster as we've seen when they break it, and also for surprises when a sterilized build jumps over many versions at once due to Docker caching.
On the downside, it's more work for us to port their improvements, which are still frequent at this early stage of development for Swift on Linux.

I agree then let's open an issue to discuss and move forward with what are the changes we need short term and long term.

@psuter
Created #608 please add more input on what's your proposal to move forward. We can have folks like @jasonpet or @bjustin-ibm help if need it the work items.


Index inconsistent state

This issue may be related to https://github.com/magento-hackathon/AsyncIndex/issues/19
From time to time it happens, that related products "pop out" of the index and therefore are not shown at frontend anymore. To fix, I have to do a manual index of "Category Products".
I have enabled Async-Index with partial-indexing.
Anyone having a similar problem?

just a guess: could the problem be, that the non-partial-index is performed within a single transaction?


QCPortal: ReactionDataset.query_components function

Is your feature request related to a problem? Please describe.
It is unwieldy to get data from a ReactionDataset which is not a products-minus-reactants observable.
Describe the solution you'd like
A query_components function analogous to query which returns a DataFrame of fields (e.g. energy, Result, stdout) for reactants and products.
Example output:
# Methane Dimer | cp | 0 | / coefficient / field
# Methane Diemr / nocp / 0 / coefficient / field
# Methane Diemr / nocp / 1 / coefficient/ field

Describe alternatives you've considered
This can be currently achieved with:
mol_id = ds.data.records[0].stoichiometry["default"]
ret = client.query_results(molecule=5, method="B3lYP", basis="aug-cc-pVDZ")
print(ret[0].get_stdout())

@dgasmith please @ me on the PR so I can see how this works.

Resolved by PR #385. This functionality is in get_molecules and get_records.


Tty field appears with label stdin on the deployment/stateful set creation as form screen.

Describe the bug
The tty field on enabling Stdin appears with title as stdin on the deployment/stateful set creation as form screen.

Steps to reproduce

Set up a cluster with chart v2.5.3-rc1 and rancher image as master-head-a549b47
Go to create deployment page.
Select Stdin as Yes.
The TTY field appears with label `stdin'

Additional Info
Same behavior in display view of the deployment.

Verified with master-head -e4ce376
Validation - Pass
The TTY is appearing fine now.


Add default bean with SimpleDeadlineManager

Adds SimpleDeadlineManager to be the default bean when applying AxonAutoConfiguration.

First of, thanks for the pull request! That's always much appreciated.
Do note however that the SimpleDeadlineManager does not store deadlines, at all.
It is thus a far from safe solution to using deadlines.
From that point, I'd be quite hesitant to merge this in, as it is dangerous to put assumptions on the SimpleDeadlineManager.
@abuijze / @m1l4n54v1c, what do you guys think. Add this, plus a massive warning that the SimpleDeadlineManager isn't safe for production?

I'm fine with this change. It would be a valuable addition to add a QuartzDeadlineManager if there is a quartz on classpath...

While I do value the initiative taken to submit this pull request (well done!), I would vote against merging it. In my opinion, defaults chosen by AutoConfiguration should be reasonably suitable for production use. The SimpleDeadlineManager is not. It should therefore be an explicit user-made choice to add this one.

Closing the PR as we'd prefer a auto config for the QuartzDeadlineManager as that is production ready. As stated, the SimpleDeadlineManager might cause issues for users who accidentally use this in production, issues we'd prefer to overcome.
@mhyeon-lee, we still very, very much appreciate the effort you've put in to this! We very much hope to see future pull request from your hand to improve the framework. :-)